As you probably know, its pretty easy to use a custom preloader in flex to replace the built in preloader shown as a flex application loads. There are a few tricks to remember with a custom preloader though, remember that the preloader is built to be displayed until the flex framework is done downloading. As such, the preloader won’t display until all the classes needed by the preloader are done downloading. For this reason, its really important to remember that your custom preloader class doesn’t make use of the flex framework, because if it does, the users will see nothing until enough of the framework has been loaded to display the preloader, and the preloader will only be displayed while the remainder of the framework is downloaded. Fortunately, the DownloadProgressBar class makes little use of the flex framework, as it extends Sprite, instead of UIComponent, and only utilizes a few event classes from flex, which don’t require any additional framework classes. A quick google search can show you dozens of examples on subclassing DownloadProgressBar to create a preloader which matches your application. A larger challenge is faced when you have additional needs from a preloader. Frequently, we are tasked with writing a preloader which is shown during the initial download, as well as remaining displayed until some startup procedures are complete within the application. Some might try to approach by referencing Application.application within the preloader, to listen for a custom event indicating that the startup procedures are complete. Of course, this is not an ideal solution, as referencing the Application class will link in the mx.core.Applicaiton class, which in turn links in around 170k worth of the Flex framework. A better approach is to create a new class, which is not linked to the flex framework, which can act as an event bus between the main application and the preloader. If this class is built as a singleton, you can be assured that both the main application and the preloader are accessing the same instance, allowing for a simple and convenient mechanism for the preloader to listen to the main application, without needing any reference to the application or the flex framework.
package net.digitalprimates.preload { public class PreloadEventBus extends EventDispatcher { public var isReady:Boolean = false; private static var _instance:PreloadEventBus; public static const READY:String = "READY"; public static function getInstance():PreloadEventBus { if (!_instance) { _instance = new PreloadEventBus(new SingletonEnforcer()); } return _instance; } public function PreloadEventBus(singletonEnforcer:SingletonEnforcer) { if (!singletonEnforcer) { throw new Error("PreloadEventBus is a singleton class, use getInstance() instead"); } } } } class SingletonEnforcer {}
With this class, when the main application is done with its startup procedure, it’s a simple process to get a reference to the PreloadEventBus, set isReady to true, and dispatch an event.
protected function applicationCustomStartupDone(event:Event) { var bus:PreloadEventBus = PreloadEventBus.getInstance(); bus.isReady = true; bus.dispatchEvent( new Event ( PreloadEventBus.READY ); }
In the custom preloader, you can override the set preload method, and instead of listening for the complete event as the base class does, listen for the INIT_COMPLETE event, which indicates that the application has loaded, and had its initialize event dispatched. In the event handler for this method, you will get a reference to the PreloadEventBus, check if the application has already set the isReady flag to true, and if not, listen for the READY event.
private function bus:PreloadEventBus = PreloadEventBus.getInstance(); override public function set preloader( value:Sprite ):void { preloader.addEventListener( FlexEvent.INIT_COMPLETE , initComplete); }
An important thing to note is the lack of call to super.preloader in this overridden setter. If the base classes setter is allowed to run, the preloader will act as initially intended, such that it disappears when the application is done downloading. As the purpose of this preloader is to allow for the application to determine when to hide the preloader and start the app, its important we override this functionality. You may find that you need to listen for other events here, such as ProgressEvent.PROGRESS, FlexEvent.INIT_PROGRESS or Event.COMPLETE. This example shows the bare minimum you would need to make use of the preloader
private function initComplete( event:Event ):void { if (bus.isReady) { completePreloader(event) } else { bus.addEventListener(PreloadEventBus.READY, completePreloader); } }
While its not expected that the application will be done with its initialization procedures before the INIT_COMPLETE, but, based on how the application is built, it is possible. To avoid this race condition, the isReady property of the PreloadEventBus is used, so that the preloader only listens for the READY event if the application is not already done with its startup. Last but not least is the completePreloader method, which is called when the preloader has determined that the application is ready. With the logic in initComplete, this same method will be used, regardless whether the state of the application was determined by the isReady property, or by listening for the PreloadEventBus.READY event.
private function completePreloader(event:Event):void { dispatchEvent( new Event( Event.COMPLETE ) ); }
Event.COMPLETE is used, as this is the event for which the system manager listens, to know that the preloader is done with its job. By preventing its normal mechanism of dispatching, and only dispatching it when the application determines it is ready, you have a nice clean approach to allow the the preloader to display as long as it needs to.