When you build a Flex application, you create an .swf file. Users can then run the application using Flash Player, just as they would any other .swf file that was created by any other means (e.g., by using the Flash authoring tool). Flex .swf files have two distinct characteristics:
When building Flex applications, the developer has access to and uses a vast library of ActionScript classes known as the Flex framework. The parts of the framework the developer uses are compiled into the resultant .swf file.
At runtime, the Flex framework code that is compiled into the .swf dictates a particular way in which the application will load, initialize, and run.
The Flex framework has been designed in such a way that it “just works” without you, the developer, needing to know too much about it. Yet, having a better understanding of the inner workings of the Flex framework will aid you in many ways. For example, the Flex framework provides built-in preloading functionality, and it uses a default progress indicator (unless you tell it otherwise). That means you get these capabilities for free, and they will work without any extra effort on your part. However, you can also customize the progress indicator, as well as customize what happens while the application is downloading and/or initializing, to suit your needs. Without a better understanding of the Flex framework, customizing Flex in this way may be difficult. This is also true of other scenarios, including customizing component creation policies, localizing applications, and using shared libraries.
In this chapter, we’ll take an in-depth look at the Flex framework. We’ll talk about some practical topics, such as how to localize an application using resource bundles. We’ll also talk about some things that you probably won’t feel are immediately and directly applicable to the work you do. For example, we’ll talk about something known as an application domain, which determines how content loaded at runtime is partitioned. However, don’t spend too much time worrying about whether you fully understand the more complex topics just yet. It’s likely that sometime after reading this chapter, you’ll be working on a Flex application that requires a customized solution that takes you into realms of code and framework knowledge you hadn’t had to venture into previously. At that time, you may want to return to sections of this chapter to review how the Flex framework handles initialization, component life cycles, or any of the other topics we’ll talk about in the following sections.
How is a Flex application structured? At first glance, the answer to
that question may seem obvious: every Flex application has an Application container object with lots of other
components nested inside it. That is true, but it’s only part of the
story. Behind the scenes, the Flex framework does more than just create
instances of the components and the Application container you know about because you
wrote the corresponding MXML code. The Application is clearly an important part, but
it’s just one of the following three major pieces of a complete Flex
application:
SystemManagerPreloaderApplication
This breakdown of SystemManager,
Preloader, and Application as the three most significant pieces
of a Flex application is not something you’ll find anywhere in the Flex
documentation. This is a purely subjective determination by the authors of
this book. However, it is very helpful to focus on these three significant
parts both to learn about their individual roles and to better understand
how they relate to each other.
The mx.managers.SystemManager
class is arguably the most important class in a Flex application.
Without SystemManager, no Flex
application could run. However, despite its importance, you will see
very few references to SystemManager
in most works on Flex, including this book. Why is that? In part it’s
because SystemManager does its job
well enough that you don’t even have to know about it 99% of the time.
Another reason you don’t hear too much about SystemManager is that you cannot do much to
configure or change it. Yet, you shouldn’t overlook SystemManager; otherwise, you will not fully
understand what a Flex application is.
It’s natural enough to assume that the root container or display
object in a Flex application is the Application object created by the MXML application document. After all, you
never write any code to create a parent for the Application object. However, behind the scenes
the Flex framework does create a parent for the Application object, and that parent is an
instance of the SystemManager class.
You can verify this by outputting the description of the parent of an
application using the test code in Example 5-1.
Example 5-1. Displaying the description of the parent of an application
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
creationComplete="creationCompleteHandler();">
<mx:Script>
<![CDATA[
import flash.utils.describeType;
private function creationCompleteHandler():void {
textArea.text = flash.utils.describeType(parent);
}
]]>
</mx:Script>
<mx:TextArea id="textArea" width="100%" height="100%" />
</mx:Application>If you run this test, you’ll see a description of the
application’s parent property type. In the description, you can see that
the parent is of type SystemManager.
The description contains a great deal of text. You can see the type of
the application’s parent by looking at the base attribute of the top-level type tag.
Note
SystemManager has a property
called topLevelSystemManager. This
is a reference to the SystemManager
instance that is at the root of everything running in Flash Player at
that time. For a Flex application loaded as the main application
within Flash Player, this property will always be self-referencing.
However, a Flex application loaded into another Flex application also
has its own SystemManager, and that
SystemManager object’s topLevelSystemManager will reference the
SystemManager object of the parent
Flex application rather than itself. For more information on loading
Flex applications into other Flex applications, see the discussion of
ApplicationDomain in Understanding Application Domainsˮ later in this
chapter.
The SystemManager instance of
an application is responsible for managing application startup, and it
is also the container for not only the application, but also all the
tool tips and pop ups in the application.
Note
Although you don’t frequently need to reference SystemManager for an application, you can do
so if necessary. All subclasses of UIComponents (including Application) have a systemManager property that references
SystemManager for the application.
The primary way in which developers are likely to use SystemManager is to listen for events that
are dispatched by any display object in the application. When those
events bubble up, the last object to have an opportunity to handle the
event is SystemManager.
When the Flex application first starts it creates the SystemManager instance. The SystemManager instance needs to do a few
internal things first, but one of its primary responsibilities is to
create a Preloader instance. The
Preloader object is responsible for
monitoring the download progress of the main application, gathering the
list of runtime shared libraries and starting to download them, as well
as creating a progress indicator to display to the user.
When you create a Flex application, you must have a main
application MXML document, usually with a root tag of Application. All components that you include
in the application are added directly or indirectly to the Application instance (although when you
programmatically add a pop up using PopUpManager, the component is technically
added to the SystemManager instance,
not the Application). For instance,
in Example 5-1 the root
tag is Application, and it contains a
text area component nested within it. It is evident that the Application component plays a major role in
all Flex applications. Much of this book is focused on code that you can
write that has an effect on the Application component or its
contents.