If you are interested in developing large application in Flex, it’s a good idea to break up parts into modues or separate application. This encourages loose coupling, improves the ease of updating and out sourcing development.
If your project is an AIR application then you will probibly want to load those modules locally (rather than rely on the web) and download/update them at runtime, rather than having to package them with your applicaiton. If this is the case you will no dout run into a host of problems involving application and security domains.
Adobe support this concept using the, “Marshall Plan“, an environment for protecting your main application from the many porential risks of downloading excutiable code. Be sure to read the 58 pages of info in this PDF.
The key points of the Marshall Plan are, Application Domains, and Secutiry Domains. In a nut shell, Application domains seperate class definitions (so you can use the same framework/singletons in each app) and security domains protect against applicaitons traversing into their reletaves.
If you want to do anything slightly complicated with your sub applications (RPC, use frameworks, etc) you will need to load them into a separate application and security domain. This does cause some problems with your sub application’s components that try and access high level objects (like stage and mouse), but apparently you can work around these :/
One of the first hurdles in running sub applications in seperate security and application domains is communication. The Marshall Plan has restricted communication in AIR down to a single shared EventDispatcher called sharedEvents, which is located inside the loaderInfo for the SWFLoader and the subApplication. Documentation on this is non existant, and I found myself routing around in debug mode trying to find the correct reference, and here it is:
// From the parent app where mySubApp is an instance of SWFLoader var e:Event = new Event('testFromParent'); mySubApp.content.loaderInfo.sharedEvents.dispatchEvent(e); mySubApp.content.loaderInfo.sharedEvents.addEventListener( 'testFromSubApp' , _eventFromSubApp ); // From the sub app var e : Event = new Event('testFromSubApp'); this.systemManager.loaderInfo.sharedEvents.dispatchEvent(e); this.systemManager.loaderInfo.sharedEvents.addEventListener( 'testFromParent' , _testEventHandler);
That right there is the basics of communicating between the two. Untyped objects can also be passed through, and typed objects (like ArrayCollections) will be converted to generic objects. They key is knowing to use the loaderInfo in the, “content” of the SWFLoader, and that the loaderInfo in the child app is in the systemManager.
I have created a demo AIR application that downloads a sub application, stores it locally, loads it in, and shows them both communicating.
Download the source code here or just the AIR application.
This entry was posted on Wednesday, February 11th, 2009 at 5:29 pm and is filed under Random. You can leave a comment and follow any responses to this entry through the RSS 2.0 feed.
This is excellent! While a lot of articles exist on the Marshall Plan, this is the first case of actual practical code samples I have found.