When you load a Flex application and run it, it may appear that not much is going on. As a user, you typically see a progress indicator until the application has loaded and initialized. However, behind the scenes an intricate process kicks off and runs its course until the application is ready to display to the user. As a Flex developer, you don’t often have to concern yourself with exactly what is happening behind the scenes, but this knowledge can help you to better understand how to build an application and how to diagnose problems.
As we mentioned earlier in this chapter, Flex applications are .swf files that run in Flash Player. Historically, Flash Player was created to play back vector animations. Therefore, although the capabilities of Flash Player have grown tremendously since its earliest stages, its historical roots remain, and Flash Player still uses a timeline metaphor when running .swf content. Flash Player supports the concept of frames—much like frames of a movie. These frames occur sequentially over time, and unless otherwise instructed, Flash Player will automatically play back the frames of an .swf file as they are available because the .swf format is a progressive download format. That means Flash Player doesn’t need to wait for an entire .swf file to download before it can begin to read the .swf content and play it back or run it. As we’ll see in just a moment, the Flex framework uses this fact to its advantage. Each frame can contain elements of the application, be they code or embedded assets. As soon as the contents of a frame are downloaded, they're available for use.
If you ran the test from Example 5-1, you may have noticed
that the SystemManager
class is a subclass of the flash.display.MovieClip
class because the type
attribute of the extendsClass
tag is
flash.display.MovieClip
. The MovieClip
class is used frequently when creating
Flash content using the Flash authoring tool because MovieClip
supports multiple frames, something
that is useful when using the timelines of Flash authoring. On the other hand, Flex
really doesn’t rely on timelines much. All Flex components have just one
frame. Therefore, the MovieClip
class
isn’t used much in Flex development. The SystemManager
class is one notable exception.
The reason that SystemManager
extends MovieClip
is that SystemManager
instances have exactly two frames:
the first frame is very lightweight, containing only enough content to
manage and monitor download progress. The second frame contains everything
else, including the majority of the Flex framework, the Application
instance, all custom classes, and
embedded assets. Because of SystemManager
’s two-frame nature, it can quickly
display a progress indicator to the user (because the first frame downloads quickly)
while the second frame continues to download and initialize.
The SystemManager
instance is the only major part of a Flex application that exists
for the entire application life cycle. The Preloader
instance exists for the first frame
and only for a brief time on the second frame while the application is
initializing. The Application
instance exists on the second frame only. Figure 5-1 shows the
relationship of these three parts to the two-frame timeline.
The details of how an application downloads and initializes are as follows. This sequence is condensed and simplified. We’ve omitted many cumbersome details for the sake of clarity and readability.
The first frame of the .swf
downloads, and a SystemManager
instance is automatically created.
The SystemManager
loads
resource bundles.
Simply put, resource bundles are collections of text or embedded resources that are accessible via keys. Resource bundles can be used at compile time or at runtime. You can read more about resource bundles later, in the Localizationˮ section of this chapter.
The SystemManager
stops the
timeline on frame 1, preventing anything from frame 2 from running
until later.
The SystemManager
creates a
Preloader
instance.
The SystemManager
registers
the ResourceManager
class
(you can learn more about this in the Localizationˮ section of this chapter) to make it
available in frame 1, and passes the ResourceManager
any resource modules
specified using a query string or FlashVars.
FlashVars are variables passed into the Flex application via an HTML page. You can read more about FlashVars in Chapter 20.
The SystemManager
starts the
Preloader
sequence.
The Preloader
instance
creates a preloader display.
The Preloader
starts to
download runtime shared libraries.
The Preloader
monitors the
progress of the main .swf
download as well as the runtime shared libraries, dispatching events
to notify the display when there is progress.
When everything has downloaded (the runtime shared libraries and
the main .swf), the Preloader
instance dispatches an initProgress
event, which notifies the SystemManager
that everything is ready to
start initializing the Application
object.
Once the SystemManager
receives an initProgress
event, it
goes to the next frame, causing the Application
object to instantiate.
The Application
object begins
to start up, and it runs through its startup life cycle, including
layout management.
When the Application
has
initialized, it dispatches a creationComplete
event, notifying the
Preloader
object.
The Preloader
dispatches a
complete event notifying the SystemManager
that it is complete.
The SystemManager
adds the
Application
instance to the display
list and removes the Preloader
and
preloader display.
Both the SystemManager
and
the Application
objects dispatch an
applicationComplete
event.
At that point, everything is downloaded and initialized, the application is visible, and the user can start to interact with it.
One important point to remember is that the overwhelming majority of the code for a Flex application is placed on frame 2. That means that most of the Flex framework, including all the UI components and data components, is available only on frame 2. It also means that by default, all your custom classes and components are available only starting on frame 2.