In the GatewayHook startup() method, I am creating and registering some scheduled tasks using the ExecutionManager. These tasks are unregistered at shutdown(). This is all working well.
My question is: Is there a good method for accessing and modifing these runnable Objects instantiated in the GatewayHook later from other scripts? Do I just create a new instance elsewhere and register it again with the same task name to overwrite these objects? Or are GatewayHook objects accessible somehow?
Since everything in a module is created from a hook method, having an object in the hook that tracks everything and is passed to all module classes as a constructor argument is the general way to solve this kind of problem. For script functions in particular, you can register an instance of your scripting class instead of the static class, and have that instance hold a reference to the hook.
In simple cases, and for some corner cases, use a static field and static method in the gateway hook. Store into the static field during .setup() or .startup().
{ Fixed category. }
There's two strategies, both are valid.
The first is to treat your module hook as if it were a singleton, by setting the value of a public static field of type WhateverMyModuleHookTypeIs to this during setup, so you can always get your hook instance.
The second is through the API. ModuleManager::getModule will return a GatewayModule. Then, GatewayModule::getHook will return your GatewayHook instance, which you can cast into the actual type.
How do you get the module manager from the API? (Without resorting to the non-API IgnitionGateway?)
From GatewayContext::getModuleManager?
Modules are handed a GatewayContext. Scripting isn't, but this is about modules.
{ I think the scripting tag is a red herring. Reread the OP's actual question. }
And how does something in a module get the gateway context that was given to the gateway hook?
Presumably you pass the context around to things that care about it as you instantiate them. That's what we tend to do.
Otherwise yeah, use a singleton (we also use this pattern), or use the private API.
I entirely agree. 