Before I start, let me say that there has been a lot of discussion about the SystemManager on various blogs. Deepa posted a fantastic write-up on the SystemManager back in October 07, which really got me interested in learning about it more. Working on Flex-less MXML is what finally pushed me to understand exactly why it’s such a critical class. There’s a lot to cover about the SystemManager, from the behavior of the Flash Player to the behavior of the Flex compiler, so buckle up, cause this is a long one.
Note 1: A recurring theme in this post is the fundamental behavior of the Flash Player. Flex would be nowhere without Flash, so if we desire true understanding of Flex, we must also understand the Flash Player.
Note 2: For some of this, it is helpful to turn on the -keep-generated-actionscript flag in the FlashBuilder compiler options. To do this, go to Project –> Properties –> Flex Compiler. In the “Additional compiler arguments” field, type “-keep” at the end of the arguments list. FlashBuilder generates ActionScript from all your MXML, including a dynamic subclass of SystemManager. This will instruct FlashBuilder to place that code in the bin-debug/generated folder.
To understand the SystemManager, you must first understand that…
Every Flex Application is a 2-Frame Flash Movie
Yes, every one of them. The Flash Player is capable of downloading just the data for the first frame and streaming the rest of the movie. Therefore a trend started in the earlier days of Flash-only developing; you typically put a very small loader object on your first frame that displays the loading progress of the rest of the SWF to the user. That way the user has a visual indication that something is happening, and the movie gets preloaded to a point where the user won’t experience any playback hiccups.
That is awesome… why do I care?
Good question. First, lets examine the implications of Flash’s load-and-stream feature:
From a movie perspective if frames aren’t loaded, the movie stops until they are loaded. If the movie is constantly experiencing this, the movie’s framerate essentially becomes a function of the speed of the user’s internet connection.
From a code perspective, if frames aren’t fully loaded, classes can’t be accessed. Calling new MyObject() will throw a runtime error, “1065: Variable MyObject is not defined.” This is because the frame that contains the definition for that class hasn’t been fully loaded.
Oh I see now, so we need a small preloader on the first frame?
Exactly. All that silly Flash that we thought we left behind when we became “Enterprise Flex Developers” has come back to bite us in the ass. But never fear, the SystemManager is here.
The SystemManager is a fancy MovieClip. The SystemManager has a few duties, including:
- Create and initialize the pre-loader to show to the user during app load and startup.
- Manage loading in RSLs.
- Manage module logic. If the SystemManager is the root of the SWF, he knows he is a Flex Application. If he is not the root of the SWF, he knows he is a module, and must communicate with whichever SystemManager is the root of the SWF (see if you can spot the logical flaw of the assumption made in that sentence, there will be a quiz later). SystemManager must communicate events both ways between modules/app, such as mouse and keyboard events.
- Manage Event.RESIZE events dispatched from the Stage.
- Manages the embedded fonts list
- Initializes the various manager singletons, such as ResourceManager and StylesManager.
- Manages top-level application windows. The SystemManager maintains a
cursorChildrenlist and apopUpChildrenlist, for tooltips and pop-up windows respectively. - Once all the code for the movie is loaded, SystemManager creates your actual Application instance and calls
initialize(). - Adds the Application to the stage once the Application dispatches its FlexEvent.CREATION_COMPLETE event. This is why the Application doesn’t have a reference to the stage when its FlexEvent.CREATION_COMPLETE is dispatched, when all the other components do.
How it works
How the SystemManager does its thing. Matching colors are event listening/dispatching pairs.
Frame 1 |
Frame 2 |
|
|
Hold on, I’m a Flex developer. I don’t work with frames.
I don’t have access to the timeline of my SWF. Actually, you do.
It’s through an undocumented meta tag, [Frame], which is really just a shortcut for the -frames compiler option. You can read all about the frame meta tag at Roger Gonzalez’s blog, but here’s the gist of it: If you add the [Frame] meta tag to the top of the Application class of your project, the Flex compiler will insert a frame before the frame that your Application is on. If you specify the factoryClass property on the meta tag, the Flex compiler will generate a subclass of whichever class you specify as the factory, and put that on the frame it creates. If you open up the mx.core.Application class, you’ll see the line [Frame(factoryClass="mx.managers.SystemManager")] near the top. This tells the Flex compiler to create a frame before the mx.core.Application, and attach a generated subclass of mx.managers.SystemManager.
The Flex compiler will generate a subclass of your factory class that implements IFlexModuleFactory. As long as your SystemManager implements IFlexModuleFactory, your code will compile. The Flex compiler overrides the info() method and returns information specific to your Application, such as a list of embedded fonts and the name of your Application.
And with this meta tag, you can override the default SystemManager implementation. As Roger says, “if the [Frame] metadata exists on the base class of your application, a subclass of the factory will be generated. If the metadata is directly on your application class, it will be honored, but no subclass will be generated; its assumed that you’ve already written the appropriate factory.”
Why this is cool
Most Flex developers will never even know the SystemManager exists, and they shouldn’t have to. Adobe has done a good job of masking Flash behind a more professional, Java-like framework with Flex. If you want to write an app with zero dependence on the Flex framework, but still use the fantastic FlashBuilder IDE, debugger/profiler, MXML, and binding, this is really good to know. You can write an Application based on Sprite, write your own stripped down version of the SystemManager, and then write MXML and take advantage of Flex’s bindings and generated code. Rock on.
Tags: flash, Flex, MXML, SystemManager
AWESOME!! I was struggling hard to understand this concept and really wanted to understand this. Thanks!!
Can you also explain as to what happens after this.. like on user interaction how does flash re-renders the frame or something on flex app lifecycle.
Hey this was a fantastic read. really. More helpful than you know. I do have a question on where you say the following:
“[...] to write an app with zero dependence on the Flex framework [...] You can write an Application based on Sprite, write your own stripped down version of the SystemManager, and then write MXML and take advantage of Flex’s bindings and generated code.”
Can you elaborate on this a bit? I have been trying to figure this out.
1- How exactly would you strip down the SysMgr?
2- If you lose the dependency on the Flex framework, how can you write MXML and use binding? Will you not compile with MXMLC at the end of the day? and will your final swf not include the SWF?
Thanks!
Phineas
1. Here’s one that I wrote for Reflex: http://github.com/guyinthechair/reflex/blob/master/src/reflex/tools/flashbuilder/ReflexApplicationLoader.as#L20
It has some references to classes in my Reflex fork, but you can easily remove those. To use it, simply add [Frame(factoryClass="reflex.tools.flashbuilder.ReflexApplicationLoader")] above the class definition of your Document class (example here: http://github.com/guyinthechair/reflex/blob/master/src/reflex/components/Application.as#L12 )
2. No matter what, you have to compile with mxmlc, but that doesn’t mean you’re compiling the Flex framework into your application. Mxmlc is just the mxml and as3 compiler. If you use binding in MXML classes, yes mxmlc will generate AS3 which uses the Flex framework’s binding code. Fortunately that only compiles in a small part of the larger framework. If you don’t like relying on Flex’s binding classes, you can write your own. To use them, you’ll have to download the mxmlc project and modify the Apache Velocity template files which define how mxmlc should translate the MXML to AS3.
Great, that’s in line with what I thought.
One more (hopefully) quick yes/no question… To improve on the logic in PopupManager, I’m going to extend SystemManager. and register my own subclass of PopupManagerImpl. I’ll also subclass mx.core.Application as MyApplication, add the [Frame] metadata for my own SystemManager, and use MyApplication as the base class for my App’s entry point. So far so good, yeah?
Now, What about AIR? AIR entry points typically extend WindowedApplication, which has no [Frame] metadata in it, since it extends Application. How do I get my AIR app to use my custom SystemManager? Simple subclass WindowedApplication and add the meta data there? I’d assume yes, but want to be doubly sure.
ps: Thanks for that fast response!
Pretty much. If you still want mxmlc to generate code for your system manager (it overrides the create() method and specifies which RSLS to load and which application class to instantiate) you should do what you’re thinking of (subclass Application, override [Frame], then subclass that again).
If you have a system manager implementation and don’t want mxmlc to use it as a factory, you can put it in the (assuming you’re using MXML)
Understood, all is well.
Thanks again!
Hi Paul
great introduction – short and very helpful!
Many thanks for sharing
Marc
Hi Paul,
Really confused with this point
Once all the code for the movie is loaded, SystemManager creates your actual Application instance and calls initialize().
I’m under the impression initialize() is part of addChild()–>$childAdded()
Could you please explain?