Flex 3 Preloading Explained

Recently during some framework development we needed to create a custom preloader that played nicely with the main Application. Implementing this functionality will be covered in a later post, but for time being this entry is intended to illustrate in detail what is going on during the load process.

Preloading in Flex 3 can either be very easy or very complicated depending on the level of control you require. Obviously vanilla applications can use the default system and need no extra work, but implementing custom preloaders that have more complex functionality (visually or behind the scenes) can take a little while the first time round.

The classes involved

Firstly, due to the slightly confusing naming conventions used in the classes involved with preloading a few definitions are useful:

• SystemManager - A non visual class responsible for, among many many other things, creating the Preloader instance.
• Preloader - A non visual class responsible for managing and monitoring main SWF and RSL loading, and the creation of the visual preloader.
• IPreloaderDisplay - An interface that must be implemented by the visual class intended to display load and initialization progress.
• DownloadProgressBar - The default implementation of IPreloaderDisplay (The standard rounded corner box with progress bar and basic messaging appearing during load and initialization of a Flex application.)

Note: Setting a custom visual preloader (IPreloaderDisplay implementation) on a Flex application can only be done through the “preloader” attribute of the main Application node.

The Process

1. Main swf starts loading.
2. System manager starts up, creating an instance of the Flex framework Preloader.
3. The Preloader creates an IPreloaderDisplay instance which listens to the Preloader for progress updates.
4. Once the Preloader has finished its load phase it moves into the initialization phase, where FlexEvent.INIT_PROGRESS events are dispatched until a FlexEvent.INIT_COMPLETE signals that the application is ready to be displayed.
5. When the IPreloaderDisplay hears the FlexEvent.INIT_COMPLETE event it dispatches an Event.COMPLETE, unless this is heard before its minDisplayTime has elapsed, in which case a timer is set for the remainder of the duration to ensure the minDisplayTime is respected, after which the Event.COMPLETE is dispatched signifying the end of its visual display responsibilities.
6. The Event.COMPLETE event dispatched by the IPreloaderDisplay instance is heard by the Flex Preloader which in turn dispatches a FlexEvent.PRELOADER_DONE
7. The FlexEvent.PRELOADER_DONE is then heard by the SystemManager triggering its preloader_preloaderDoneHandler() which adds the main Flex Application to the displayList and dispatches the FlexEvent.APPLICATION_COMPLETE event.

Boiled down to 7 steps it seems fairly simple but fathoming this from scratch took a little while. The purpose of this post is only to explain how the process works, but in later posts I’ll show how a custom IPreloaderDisplay and overridden Application allow the conglomeration of main swf and multi-stage initial asset load processes into one simple progress bar.