Thanks to meekgeek for sharing his work incorporating timeout into the previously posted startup monitor code. I am here responding to Cliff's "can you reconcile..." above. I am interpreting the timeout requirement as set out in the meekgeek posting. There is no connection with the app resource's actual loading process, which, once started, runs on independently of the startup manager.
The Startup Manager Utility is currently the following 4 classes:
StartupResource, StartupMonitorProxy, IStartupProxy, StartupResourceLoadedCommand.
Taking this new work into account, I think the list of classes would become:
StartupResourceProxy, StartupMonitorProxy, IStartupProxy, StartupResourceLoadedCommand, StartupResourceTimedOutCommand; plus retain StartupResource, see below.
StartupResourceProxy has the advantage that the client app can name it and can retrieve it, assuming it is registered of course, and can thus have access to certain properties. I would prefer not to require that the client's own resource proxy has to extend StartupResourceProxy, since that may impose on the client app design. Instead, say the constructor is:
public function StartupResourceProxy( proxyName:String, appResourceProxy :IStartupProxy )The cient app must instantiate its app resource proxies before the StartupResourceProxys. The loadResources method of StartupMonitorProxy can now invoke the client loads via the IStartupProxy reference held by the StartupResourceProxy. The StartupResourceProxy and the appResourceProxy must have different names, assigned by the client app.
In thinking about the internals of StartupResourceProxy, I think it makes sense to keep the StartupResource as a separate class: the proxy is a front for the StartupResource, the data property of the proxy is of type StartupResource, the proxy constructor creates the StartupResource. So, that takes us to 6 classes in the utility. StartupResource would no longer have the 'proxyName' property.
Let this StartupResourceProxy have
- public methods for client use, e.g.: read/write 'requires', read/write 'timeout', read accessors for 'status', maybe also a setForRetry() to cause status change from TimedOut back to Empty
- internal methods for utility own use, as in access from StartupMonitorProxy.
This has a new timeout property, and a new TIMED_OUT status value, with associated access methods, per meekgeek's posting. The setStatusToLoading method starts the timer. On timeout, a notification is sent e.g. STARTUP_RESOURCE_TIMED_OUT. This is handled by the StartupResourceTimedOutCommand, which in turn calls the StartupMonitorProxy#resourceTimedOut method. Questions: is there a non-zero default timeout? a timeout of zero means we ignore timeout? For now, my default would be zero.
- resourceList is now a list of StartupResourceProxys
- let addResource() continue to have just one arg; let the client app set the timeout for the resource directly via the StartupResourceProxy
- resourceTimedOut(): set resource status, add to timedOutResourcesList
- allResourcesLoaded() is renamed to something like isLoadingFinished(), because some resources may have timed out and other resources may require those and so on, so we may be finished even though all resources are not loaded.
How does the client app know we're finished but not complete? Say we send a LOADING_FINISHED_INCOMPLETE note instead of a LOADING_COMPLETE note. In the incomplete case, we could send in the note body an array of the incomplete StartupResourceProxys, to make it easy for the client to set those for retry if desired. And if retry is desired, the client invokes monitor.loadResources() again to try the outstanding resources. I know Cliff expects features that cause the utility itself to retry a number of times before reverting to the client, but I'm ignoring that for now.
Continues to just have the 'load' method, I don't see an example use of 'onComplete'.
Cliff/Meekgeek/others - any comments on the above? Subject to your comments, if this is worth doing, it may be easiest for me to incorporate this into the utility at this time, since I have my hands on it.