Making a FlexApplication Application
Now let's make the application in a separate Flex Builder project. Nothing fancy, we'll just make a static reference to the CustomPanel:

<?xml version="1.0" encoding="utf-8"?>
<!-- FlexApplication.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns="*">
    <CustomPanel />
</mx:Application>

Link our library, compile, and run the application.

To resolve the reference during compile time we had to add our recently created library FlexLibrary.swc to the project's Library Build Path. The default link type is to merge-in the SWC's content.

Merging the contents of SWC results in an optimized, non-overlapping size of the monolithic application. The size of such a self-sufficient FlexApplication.swf is 123KB.

Now let's alter the setting and turn static linking dynamic and setting the Link type to RSL. We'll accept the (default) value of Auto extract.

As a result of the Auto extract the file FlexLibrary.swf will appear adjacent to the FlexApplication.swf. The size of the FlexLibrary.swf will be 236K, nearly as much as the entire FlexLibrary.swc, but the size of the FlexApplication.swf itself will decrease to 40K.

As you can see, Flex attempts static linking of RSL content (Merged into code) by default. This ensures that the smallest size of the resulting monolithic SWF, because it carries only the code that was deemed relevant during the compilation process.

Naturally, the total of 236K + 40K takes two times longer to download then downloading of the statically linked 123K. However, once you have a family of three applications to offer the same user, all approximately the same size and all reusing the same FlexLibrary.swf, it becomes (236 + 3*40) versus 3*123 and you break even.

The download considerations are less relevant on the fast connections and, perhaps, are not relevant at all in scenarios where you can count on the browser cache to keep SWF files loaded for the next run of the application. A typical example of the latter would be a corporate environment, but then again, some administrators set policies to wipe out the browser's cache on user logoff.

Static versus Dynamic Linking: Development Perspective
While the time of the initial download is an important factor in favor of static linking, we have to consider development productivity as well.

Let's look at enterprise applications. Driven by user requirements, they tend to change frequently. Many enterprise applications tend to be on the larger side, growing in functionality and, accordingly, size, with phased delivery to the users. As an application gets to tens of megabytes, the time required to build the monolithic application becomes a noticeable setback to developer productivity. The problem escalates in a team development where it translates into many hours wasted every day.

And, regardless of size, let's look at the use case of portlet-style add-ons. These are modules that are simply impossible to reference statically in advance. In fact, they are not even supposed to be pre-loaded at all: unlike RSLs they get loaded on demand.

All in all, we need to be able break the application into a set of modules that can be built independently and linked dynamically at runtime.

So, You Say Dynamic Linking?
By now the reader may say, "OK, I got the message, I'll go with RSLs to modularize my development with dynamic linking." Not so fast. Like ancient Achilles, these mighty RSLs have a small weak spot: their well-being depends on static linkage from the main application.

Oh, but doesn't that ruin the hope of dynamic linking? The answer is no, and the explanation is just around the corner in the next section.

First, however, let's create an application to expose the problem. We'll build a FlexApplication2.mxml application. Unlike our previous example, it won't contain static references to CustomPanel. Instead, FlexApplication2 will create instances of a CustomPanel (or any other object for that matter) dynamically, given a name of the class definition as it's done in the function createComponent():

<?xml version="1.0" encoding="utf-8"?>
<!-- FlexApplication2-->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns="*">
    <!--CustomPanel /-->
    <mx:Button label="CreatePanel" click="createComponent('CustomPanel')"/>
    <mx:Script>
      <![CDATA[
        private var displayObject:DisplayObject;
        private function createComponent(componentName:String) : void {
          var clazz : Class = getDefinitionByName(componentName) as Class;
          displayObject = DisplayObject(new clazz() );
          this.addChild(displayObject);
        }
      ]]>
    </mx:Script>
</mx:Application>

If you run the application and click the "Create Panel" button, the code terminates abnormally.

The reason for this error is that many times mxmlc complements classes with additional initialization code at the SystemManager level. But if the relevant classes are completely shielded from mxmlc it's absolved from taking care of them. Let's explain this in detail. Please have another look at the generated SystemManager of the FlexApplication that we had in the previous example:

package {
import mx.managers.SystemManager;
import flash.utils.*;
import flash.system.ApplicationDomain;
import mx.core.IFlexModuleFactory;
public class _FlexApplication_mx_managers_SystemManager extends mx.managers.SystemManager
implements IFlexModuleFactory {
    public function _FlexApplication_mx_managers_SystemManager() {
      super();
    }
    override public function info():Object {
      return {
      "currentDomain": ApplicationDomain.currentDomain,
      "layout" : "vertical",
      "mainClassName" : "FlexApplication",
      "mixins" : ["_FlexApplication_FlexInit",
        "_activeTabStyleStyle", ...
        "_ControlBarStyle", "_PanelStyle", "_CustomPanelWatcherSetupUtil"
      ]
      ,
      "rsls" : [{url: "FlexLibrary.swf", size: -1}]
      };
    }
} //_FlexApplication_mx_managers_SystemManager
}

If we compare this SystemManager with the one generated for FlexApplication2 we'll see that in the latter case the mixins array is short of the three values: "_ControlBarStyle," "_PanelStyle," and "_CustomPanelWatcherSetupUtil."

The classes referenced in the mixins array take part in the initialization sequence of the application upon the initial load. In particular, CustomPanelWatcherSetupUtil is the class that facilitates the binding for the variable instanceNumber of CustomPanel. In the case of FlexApplication2, this part of the initialization "gets forgotten."

Now that you have seen the differences between the applications manifested in _<ApplicationName>_mx_managers_SystemManager files, you're likely to notice the others, such as files <ApplicationName>_FlexInit.as. For example, in Chapter 8 we annotated the EmployeeDTO class with the metadata keyword RemoteClass:

   [RemoteClass(alias="com.theriabook.composition.dto.EmployeeDTO")]

In the case of SimpleAutoCompleteWithDynamicDataDemo, this metadata annotation results in the following:

package {
[Mixin]
public class _SimpleAutoCompleteWithDynamicDataDemo_FlexInit
{
    . . . .
    public static function init(fbs:IFlexModuleFactory):void
    {
    . . . .
    flash.net.registerClassAlias(
     "com.theriabook.composition.dto.EmployeeDTO",
     com.theriabook.composition.dto.EmployeeDTO
    );
    . . . .
    }
} // FlexInit
} // package

And again, the registration snippet

    flash.net.registerClassAlias(
      "com.theriabook.composition.dto.EmployeeDTO",
      com.theriabook.composition.dto.EmployeeDTO
    );

wouldn't have materialized if the compiler didn't know about the EmployeeDTO.

All in all, MXML files as well as metadata-annotated ActionScript classes might not get the expected initialization support if you put them in RSL and don't explicitly reference them in the calling application.

Conclusion
The second part of this article will discuss dynamic linking, self-initialized libraries, RSL vs. custom loading of the dynamic libraries, embedded applications and SWFLoader, and optimization of application size.

To order a copy of Rich Internet Applications with Adobe Flex & Java, please go to www.riabook.com.