How Composite Application Framework loads

Composite Application Framework initial state

Before Composite Application Framework loads anything defined in MultipleStockService.axml, it loads some required interface libraries. It also sets up a hierarchy of application domains that other objects can use.

View full size graphic

Composite application initial state

Shapes used in loading diagrams

The first and most important element that Composite Application Framework sets up is the interface domain. This domain is where the framework loads any interface libraries. It loads a few interface libraries into this space for its own use, but it also loads mosaic-om, which is the tile development library. The mosaic-om library allows interfaces such as ITile and IApplication to serialize between objects.

Composite Application Framework also adds some objects to this domain, including PropertyChangeEvent and IList. These two common classes are the only exception to the no Flex SDK Rule. Client Component Framework uses PropertyChangeEvent and IList to make elements bindable and, therefore, they are also available to use.

As a child of the interface domain, Composite Application Framework loads the runtime used by Adobe AIR or a web browser. (Although the runtime is a series of SWF files, for simplicity, just one is shown in the illustration.) It also makes available an application domain for each supported Flex SDK. This architecture allows tiles to share a single Flex SDK definition, which both reduces the amount of memory that an application requires and decreases load times. (Again, for simplicity, the illustration shows only one domain, Flex 4.5.0.)

Application load process

For the next step in the loading process, Composite Application Framework downloads the application XML and the referenced catalogs. The framework downloads these objects from the server, starts to resolve any references in them, and collects what it needs to load. For example, for MultipleStockService.axml, the framework scans the AXML file and retrieves the definition for the following objects from the catalog:

• A ServiceClass named NYSEStocks

• A ServiceClass named NASDAQStocks

• A TileClass named NYSEStocks

• A TileClass named NASDAQStocks

• A TileClass named StockDetailsTile

These classes are five of the six objects that the application requires. Client Component Framework loads the sixth object, which is the all-important interface library, when it loads each of the parts. However, it loads the SWF file only once.

Service references

The ServiceReference elements in the MultipleStockService.axml point to ServiceClasses in the StockService.cxml catalog file. The definition of these ServiceClasses instructs Composite Application Framework to load a GXML file, which is a Client Component Framework configuration. For more details about the contents of these files, see the documentation that is provided with the MultiStockService sample application.

After Composite Application Framework loads, a set of Services is registered in the Service Registry for lookups that take place later. Normally, each Service would get its own application domain directly under the interface domain. However, in this case, the GXML files instruct Composite Application Framework to register two instances of the same class from the same SWF file. Therefore, only one application domain is created and two classes are instated from it.

View full size graphic

Composite application initial state with service references

At this point, the StockDataInterfaceLibrary.swf is already loaded into the interface library, even though the AXML did not specify it. This is because the ServiceClasses GXML configuration specified that they are required, so Composite Application Framework loaded the dependency for it. This means that all the interfaces exposed in the GXML file are now available for other Tiles and Services to use.

TileClass

The AXML for this sample defines three TileClasses to use, NASDAQStocks, NYSEStocks, and StockDetails. The first two are from a single UIComponent tile and the last is a module tile. Once the three TileClasses are in a catalog, their usage is completely transparent to anyone using them. This allows a developer to build a composite application from them without worrying how the object was created.

UIComponent tile

When Composite Application Framework encounters the NYSEStocks Tile, it loads the GXML referenced in the catalog and loads the StockDataTableModule.swf into a new application domain that is a child of the Flex 4.5.0 domain. Next, Composite Application Framework creates a new instance of a UIComponent for NYSEStocks Tile. Composite Application Framework then sees the NASDAQStocks Tile and because it is the same SWF, skips loading it again. Finally, Composite Application Framework creates a new instance of a UIComponent in the same application domain for NASDAQStocks Tile.

Module tile

When Composite Application Framework encounters the StockDetails tile, it does something fairly similar to what it does with the UIComponent tile, with one significant difference. The TileClass for this object does not define a GXML nor does Experience Services generate one. Composite is responsible for creating its own GXML and loading that. This can be done only in certain cases when the Tile does not use any services. Once Composite Application Framework calculates a GXML for this tile, it loads the tile under the Flex 4.5.0 domain just like the other tiles but, as a sibling, not in the same domain. It then creates a new module and places it on the screen. Like any other module, if more then one instance of the object is required, Composite Application Framework does not load the SWF again. Instead, it creates a new instance of the object in the application domain. This instance can then live anywhere on the display list. This makes our final application domain structure:

View full size graphic

Final application domain structure

There are two new application domains, one for each SWF that was loaded, and inside them three new instances, one for each tile that is currently displayed.

Shared Flex SDKs (Flex 4.5.0)

Adobe provides shared Flex SDKs that load their respective frameworks via RSL only when requested. Each supported SDK is configured through a special GXML and only that file is loaded initially. The RSLs and the rest of the SWF bits are only loaded when a tile actually requests the use of it. In the case of the sample application, the Flex 4.5.0 SDK is loaded on startup because the Composite Application Framework runtime uses it. However, the Flex 3.6.0 GXML is actually loaded and ready in case any tile attempts to make use of it. These bundles are only used for module tile or UIComponent tile and not used by application tiles. Any tile loaded under a shared Flex SDK can share the framework classes and therefore do not need to link them in directly, minimizing file size and memory footprint.