When I first joined the Flex framework team, the Flex SystemManager seemed like a black magic, voodoo-y class that no one in their sane mind wanted to touch. In fact, the one time I did make a change to SystemManager (early in my development career), I inadvertently ended up pulling in all of UIComponent and bloating Flex development SWFs that week by a good 10k. Oops – good thing we have tests to check for mistakes like that.
Some time later, I started researching SystemManager in order to speak about it in one of my talks. I had an epiphany: SystemManager is not so scary. In fact, I’d go so far as to say that it is the most important class in the entire Flex framework.
So, let me try to make SystemManager less mysterious and explain how it enables the creation of Flex applications.
What does the Flex SystemManager do?
SystemManager is really the engine behind getting your Flex application up and running. Its most important job is creating the Application instance and adding it to the Flash Player display list. It also acts as the parent to all top-level items like popups, tooltips, and cursors in a Flex application. In addition to parenting them, SystemManager handles focus between these top-level items.
SystemManager creates my application? Tell me more….
This is what is so cool about SystemManager. There is a definite order to what happens the moment a Flex SWF is hit and it starts streaming down to a Flash Player client. Lets talk about that sequence of events.
First, it is imperative to understand that a Flex SWF is a 2-frame movie. The first frame of a Flex SWF contains the SystemManager, the Preloader, the DownloadProgressBar and some “glue” helper classes. Remember, the Preloader is what creates the DownloadProgressBar control which displays the progress of a Flex application downloading and being initialized. The second frame of a Flex SWF contains the rest of the Flex framework code, your application code and all of your application assets like embedded fonts, images, etc. By creating a 2-frame movie, Flex applications can take advantage of the streaming support built into the Flash Player and a preloader can appear before all of the Flex framework code and your application code are downloaded.
So, here’s the order of things once an mxml file or Flex SWF is hit. First, enough bytes for frame 1 are streamed down to the Flash Player. The Flash Player executes those bytes by creating a SystemManager instance. The first thing the SystemManager does is instruct the Flash Player to stop at the end of frame 1. The SystemManager then goes on to create the Preloader which creates the DownloadProgressBar control and pops that up on the client screen. The Preloader then starts tracking the rest of the bytes streaming in from the Flex SWF. Once all the bytes for the Flex framework and application code are in, the System Manager goes on to frame 2 and instantiates the Application instance.
Once the Application instance has been created, the SystemManager does a very important thing. It sets Application.systemManager to itself. This is how you, the application developer, can access the SystemManager at a later time. After the systemManager property has been set on the Application instance, the Application goes on to create its children. Eventually, once all the Application child controls and containers have been created, sized and positioned, the Application dispatches the creationComplete event. Once the creationComplete event has been dispatched, the Preloader removes the DownloadProgressBar control and the SystemManager adds the Application instance to the Flash Player display list. (Aside – the Flash Player display list is basically the tree of visible or potentially visible objects that make up your application. When you add and remove child components to your application, your basically just adding and removing them from the display list).
Once the Application is added to the Flash Player display list, the Application dispatches its applicationComplete event and voila! The Application has been created and is up on the screen ready to be interacted with.
Phew – that was a mouthful, but hopefully it made sense. If you read over it a couple of times, you’ll see the execution of tasks once a Flex application is hit is very methodical.