In this excerpt from our book, Rich Internet Applications, we'll cover how to set up large applications intended for Web or, more broadly speaking, distributed deployment. As an example let's consider an enterprise application that consists of hundreds of screens, reports, forms, and dashboards. Accordingly, about a dozen engineers specializing in GUIs, frameworks, data layers, and business domains are working on this application in parallel.
Every application "run" in Flex Builder as well as the invocation of the application's MXML file processed by the Web-tier Flex compiler requires an application build. Needless to say, this takes time. The bigger the application, the more time it takes.
Developers need a fast process of building and deploying their applications.
The application also has to be partitioned for team development both vertically (application screens) and horizontally (UI, skins, reusable components, and back-end code). Imagine working on two "portlets," one of them showing a DataGrid and the other a TreeView. You have a choice: either package a 1MB module with both portlets or download separate ones (500K each) on demand. The latter way has the additional benefit of isolating the work between the team members.
Finally, the model should allow the extensibility of the product, meaning the integration of patches and portlet-style add-ons as well as external Flex subsystems shouldn't impact the main build.
We'll try to accommodate these requirements emphasizing the productivity of team development and deployment flexibility. But first let's review the deployment scenarios from the business point-of-view in detail.
Deployment Scenarios
Throughout this excerpt we'll use the term patches, which are the fixes and additions made to an application between releases. Add-ons are the parts of the application that are typically added over time. Similar to patches add-ons blend seamlessly into the hosting application, both visually and programmatically.
In some cases the application build may not even "know" about specific add-ons since they're different for each user type. For example, an enterprise application can reveal more screens or more functionality within these screens to internal users. In this case we talk about portlet-style add-ons.
Plug-ins are independent applications that don't share the look-and-feel of the main application. No intensive interaction between the main application and plug-ins is expected.
Application Domains 101
As much as we don't like to duplicate the work done by the Adobe Flex documentation team, we have to cover the subject of Application Domains since it's essential to this chapter. So, here are the facts.
All code loaded from an SWF file lands in one or another application domain. Conversely, instances of the flash.system.ApplicationDomain class stores the tables of the ActionScript 3.0 definitions and class definitions in particular.
A system domain contains all the application domains and there's a current domain where the main application runs. There's also a parent domain for each domain except the system one. System domains, quite naturally, happen to be the parent of the main application's domain.
The definition of the loaded classes as long as they remain loaded can't be overriden down the parental chain. Attempts to reload a class that's already been loaded by its parent will fail. If you're coming from the Java side, you may have seen a similar mechanism called Java ClassLoader.
We also have to mention the security domains of the Flash Player, since partitioning the classes (visibility) via application domains is within the confines of the security domains. The choice of a security domain is relevant for use cases when we need to load an SWF file coming from a different server, which is outside the scope of this chapter.
So, an application domain is the mechanism that (a) supports multiple definitions of the same class where children can access parent definitions seamlessly or (b) lets child definitions be tentatively merged with parent ones so that accessing the other party's definitions is seamless for both the child and the parent.
This mechanism is enacted by flash.display.Loader and mx.controls.SWFLoader controls.
The first choice is represented by the syntax new ApplicationDomain(Appli cationDomain.currentDomain) while the second one is ApplicationDomain.currentDomain.
A specific sub-case of (a) is the use of a system domain as a parent: new ApplicationDomain(null), which results in the ultimate separation of the (class) definitions, eliminating any overshadowing.
Either way, the required application domain is getting assigned the applicationDomain property of a Flash.system.LoaderContext instance, which, in turn is used as an argument to construct a flash.system.Loader, or acts as a property of an mx.controls.SWFLoader.
There are nuiances in accessing child definitions from the parent as well as in loading/accessing possibly overshadowing the class definitions.
When you bring existing Flex subsystems (perhaps even written in a different version of Flex) under a common application umbrella, it makes sense to resort to a separate application domain. At the same time, if you need to dynamically load DataGrid definitions, it makes sense to load them in the same application domain where the main application is running.
Runtime Shared Libraries 101
Flex documentation defines Runtime Shared Libraries (RSL) as "a library of components." We would like to start with the clarification that RSL is not a file but a pattern of using an SWF file from within another SWF file.
Specifically, SWFs marked as RSLs are automatically pre-loaded during the application's bootstrap as opposed to being explicitly loaded by the code you write. To be exact, definitions contained in the SWF are loaded into the applicationDomain of the hosting application.
Now how does the application's bootstrap know which SWF files are to be pre-loaded?
Here is an answer. Let's assume that:
a) You made the file FlexLibrary.SWC (using the compc compiler explicitly or from within the Flex Builder's Library Project);
b) You've created the file FlexApplication.mxml, which refers to components from FlexLibrary.SWC;
c) While compiling FlexApplication.mxml you instructed the mxmlc compiler that FlexLibrary.SWC contains an image of an SWF to be pre-loaded during the bootstrap (this will be explained later in this chapter).
Then, the corresponding ActionScript file generated by the mxmlc compiler will have the code fragment shown below. You'll find this and other files in the generated folder of your application project once you set the compiler's option to keep-generated-actionscript=true:
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" : "absolute",
"mainClassName" : "FlexApplication",
"mixins" : ["_FlexApplication_FlexInit", ......]
,
"rsls" : [{url: "FlexLibrary.swf", size: -1}]
};
}
}
}
As a reminder, the SystemManager is a parent of all the displayable objects within the application, such as the main window (an instance of mx.core.Application), pop-ups, cursors, etc. SystemManager also creates the mx.preloaders.Preloader that loads SWF files.
Please note that FlexLibrary.swf is not an RSL. As we said above, RSL is a usage pattern rather than a file. What makes FlexLibrary.swf part of this pattern is the intent to pre-load it during the application startup communicated by us to the mxmlc compiler.
"currentDomain": ApplicationDomain.currentDomain,
This illustrates that the RSL approach results in class definitions from the library are loaded into the same domain where the definition of the application classes belong. That's why, in particular, we find the RSL technique especially useful for delivering various patches, which should be loaded prior to any other class definitions.
SWFs and SWCs: What's Under the Hood How do our SWC files relate to SWFs? Like every Flex SWC, FlexLibrary.SWC contains the library.swf and catalog.xml files. The latter describes the hierarchy of dependencies found in library.swf, which can potentially become FlexLibrary.swf (depending on the selected link type described below).
When we compile FlexApplication.mxml containing references to FlexLibrary.SWC in the library search path, there are three link types to choose from:
- External - The catalog.xml in the FlexLibrary.swc will be used to resolve references; however the code contained in library.swf won't be included in the body of the FlexApplication.swf. The External link type assumes that by the time FlexApplication needs to create instances of classes from the library.swf part the definitions for these classes will somehow get loaded in the relevant applicationDomain.
- RSL - The catalog.xml in the FlexLibrary.swc will be used to resolve references; code contained in library.swf won't be included in the body of the FlexApplication.swf. So far sounds like External, right? Here's the difference: all definitions originally contained in the library.swf part will be upfront-loaded into the main applicationDomain during application startup.
- Merge-in - Classes that are explicitly referenced by the code (and their dependencies) explicitly get included in the FlexApplication.swf. This is a default option for statically linked applications and guarantees that the definitions of all referenced classes as well as the classes they depend on are loaded into the main applicationDomain outright.
Suppose we went with dynamic linking via RSL. As illustrated in the previous code fragment, this means pre-loading the FlexLibrary.swf. Here's the question: where do we get this FlexLibrary.swf from? Under one scenario we can let Flex Builder extract and rename the library.swf from the FlexLibrary.swc. In Flex Builder (project Properties >Flex Build Path> Library Path) this option is called Auto extract swf. Alternatively, we could have declined auto-extracting and unzipped the SWF from the SWC ourselves. As we'll show later, there's yet another way of explicitly controlling the upfront build of FlexLibrary.swf.
We'll illustrate these cases in the next section.
Making the FlexLibrary.swc
Let's make an SWC in Flex Builder by creating a new Flex Library Project. The only component we're going to add to this SWC is the CustomPanel from the following code which enumerates the instances of itself and imprints the number of the instance as part of its title, using the variable instanceNumber that we've declared bindable:
<?xml version="1.0" encoding="utf-8"?>
<!-- CustomPanel.mxml -->
<mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml" title="'Custom' Panel
#{instanceNumber}" width="300" height="150" creationComplete="instanceNumber=++count;" >
<mx:Script>
public static var count:int;
[Bindable]
private var instanceNumber:int;
</mx:Script>
</mx:Panel>
To ensure that our CustomPanel is accounted for (in both library.swf and catalog.xml) we have to verify that it's included in the Flex Library Build Path. Please be aware that every time you add or rename files in your Library Project the corresponding checkbox in Flex Builder gets cleared.
After we click OK, Flex Builder will invoke the compc compiler to create the FlexLibrary.swc in the output bin folder.
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.