A few months ago, I embarked on a project for 24 Hour Fitness that involved something I had only heard about at the 2008 Adobe MAX conference in San Francisco – “flex sub-applications”. There, I attended a lecture by Alex Harui on Flex Framework Features to Support Large Applications (listen to the lecture here on Adobe TV). I must admit the lecture had probably put many to sleep, but I was fascinated by the concept and to this day (granted, MAX was just a few months ago) I believe this will become a very important topic to many as the complexity and possibilities available in large-scale Adobe Flex applications becomes ever apparent.

For this reason, I appended a “Part 1″ to the title of this article as I don’t know if I can squeeze my experience with sub-applications into just one writing and I certainly plan in the coming months to venture even farther into these murky waters.

I think Alex’s main point behind his lecture was to unveil the new Marshall Plan bundled with Flex 3.2 (released during MAX). But before I can describe what the Marshall Plan is, it’s important to know why it came about.

Most applications you’ll ever build in Flex are probably on the smaller scale, ranging from anywhere between a few hundred kilobytes (final SWF size) to several megabytes of compiled Flex code (including the Flex framework). This doesn’t include embedded images or other assets which could dramatically increase that size (I typically try very hard NOT to embed assets to keep the final SWF as lean as possible). Some applications could be significantly larger, spanning hundreds or thousands of commands (if you use Cairngorm or other such MVC architecture), classes and MXML.

It’s always very important to understand that the entire application frame of your final SWF will be downloaded to the client in one shot. This could be a lengthy wait for some and the solution has always been to break up that large application into pieces, or “modules” that could be loaded and unloaded during runtime.

The possibility of caching some code in the client’s Flash Player for re-use by other applications was also created by using Runtime Shared Libraries (RSL’s). But because of “full class integration” (the ability to reference classes in the RSL by classname), the RSL must be compiled with the same version of Flex as the main application. RSL’s also have the disadvantage of not being unloadable. Once an RSL has been loaded at the onset of application startup, it’s there to stay.

Modules are another example of re-using functionality. Modules are collections of classes compiled into a SWF and are loaded by ModuleLoader. Classes in modules are not directly referenced by the main application. Instead both refer to a shared interface (IDataGrid, for example). This is called “partial class integration”. Modules can also be unloaded and removed from memory. Unfortunately because the main application and module share at least some assets, modules, too must be compiled by the same version of Flex as the main application.

Which brings us to a new concept called “sub-applications”, released as a part of Flex 3.2 in November, 2008 at Adobe’s MAX conference in San Francisco. Sub-applications have NO class integration, which is needed to support multi-versioning .

Sub-applications are completely individual, separate applications (identified by the root tag), compiled into a SWF that is loaded by a parent application through the SWFLoader component (you can also use Loader and added the loader object as a child to SWFLoader).

Previously, Flex 2 also supported the concept of sub-applications in that you could use SWFLoader to load another SWF application. You could even access properties in the sub-application from the main application using the SystemManager class. Unfortunately, Flex 2 was only able to load the sub-application into the same “SecurityDomain” (or sandbox) as the parent application. By playing in the same sandbox, the sub-application could have unrestricted access to variables in the main application…an unwanted side-effect especially if the sub-app is untrusted (say, written by a third-party).

With Flex 3.2, you have a little more control over how the sub-application SWF is loaded, primarily through two properties of SWFLoader. One is trustContent (which existed in Flex 2) and the other is loadForCompatibility (new as of Flex 3.2). And the changes in the Flex source code revolving around the new loadForCompatibility feature really serve as the basis for the new Marshall Plan.

The trustContent property specifies whether the sub-application is loaded into the same SecurityDomain as the host. This property is defaulted to false, which means SWF content loaded from separate domains (xyz.com instead of abc.com) will load without error if the separate domain does not have a crossdomain.xml policy file declaring that your domain has rights to access its content. This is preferred behavior, however your parent application would not be able to access the SWF content (via SWFLoader.content). This property is directly tied to the SWFLoader.loaderContext.securityDomain property and can also be set manually via ActionScript.

Setting trustContent to true is equivalent to copying the loaded SWF to your own server and loading it from there. This is one way to get around any security sandbox restrictions you might experience, however I also noticed that it also can cause other complications, most notably with singleton’s like Cairngorm’s ServiceLocator (which I’ll discuss in a later post).

The loadForCompatibility property specifies whether the sub-application is loaded into a peer ApplicationDomain as the parent (when set to true), or into a child ApplicationDomain (when set to false). This flag only pertains to applications loaded within the same SecurityDomain (if trustContent == true).

Child ApplicationDomains inherit classes from the parent (like UIComponent, Container, etc). This can cause obvious problems if both applications were compiled with different versions of Flex. A child sub-application written in Flex 3.2 may not wish to inherit the UIComponent definition of its parent application that was written in Flex 4. The loadForCompatibility flag forces SWFLoader to load the sub-application into a separate ApplicationDomain (when true) which keeps the definitions for these classes separate. This is most needed for multi-versioned applications. This flag should only be set to true if you know both applications will always be compiled with the same version of Flex.

In my next article, I’ll discuss some of the pitfalls I ran into with sub-applications and specifically, Cairngorm-based sub-applications. Stay tuned!