About modules
Modules are SWF files that can be loaded and unloaded by an application. They cannot be run independently of an application, but any number of applications can share the modules. The main application, can dynamically load other modules that it requires, when it needs them.
Benefits of modules
- Smaller initial download size of the SWF file.
- Shorter load time due to smaller SWF file size.
- Better encapsulation of related aspects of an application.
ModuleManager and ModuleLoader
Module domains
By default, a module is loaded into a child domain of the current application domain. You can specify a different application domain by using the applicationDomain property of the ModuleLoader class. Because a module is loaded into a child domain, it owns class definitions that are not in the main application’s domain. For example, the first module to load the PopUpManager class becomes the owner of the PopUpManager class for the entire application because it registers the manager with the SingletonManager. If another module later tries to use the PopUpManager, Adobe ® Flash® Player throws an exception. The solution is to ensure that managers such as PopUpManager and DragManager and any other shared services are defined by the main application (This technique also applies to components). Typically, this is done by adding the following to a script block:
import mx.managers.PopUpManager;
import mx.managers.DragManager;
private var popUpManager:PopUpManager;
private var dragManager:DragManager;
Because a Flex module must be in the same
security domain as the application (SWF) that loads it, when you’re using modules in an AIR application any module SWF must be located in the same directory as the main application SWF or one of its subdirectories, which ensures that like the main application SWF, the module SWF is in the AIR application security sandbox.Creating ActionScript-based modules
Reducing module size
To reduce the size of the modules, you can optimize the module by instructing it to externalize classes that are included by the application. The result is that the module includes only the classes it requires, while the framework code and other dependencies are included in the application.
To externalize framework classes with the command-line compiler, you generate a linker report from the application that loads the modules. You then use this report as input to the module’s load-externs compiler option. The compiler externalizes all classes from the module for which the application contains definitions. This process is also necessary if your modules are in a separate project from your main application in Flex Builder.
1. Generate the linker report and compile the application:
mxmlc -link-report=report.xml MyApplication.mxml
2. Compile the module and pass the linker report to the load-externs option:
mxmlc -load-externs=report.xml MyModule.mxml
Using the ModuleManager class to load modules
import mx.events.ModuleEvent;
import mx.modules.ModuleManager;
import mx.modules.IModuleInfo;
public var info:IModuleInfo;
private function initApp():void {
info = ModuleManager.getModule(“ColumnChartModule.swf”);
info.addEventListener(ModuleEvent.READY, modEventHandler);
// Load the module into memory. Calling load() makes the
// IFlexModuleFactory available. You can then get an
// instance of the class using the factory’s create() method.
info.load();
}
private function modEventHandler(e:ModuleEvent):void {
// Add an instance of the module’s class to the display list.
vb1.addChild(info.factory.create() as ColumnChartModule);
}
