Modular applications

Sometimes our flex application’s size becomes very large. Due to this, we are facing many problems such as bandwidth, network traffic and it will take more time to load. We have many ways to solve this problem such as

1. Do not embed the assets into the project.
2. Modules.

About Modules

Modules are the swf files which can be loaded and unloaded dynamically by an application. The user cannot run the modules independently in the browser or the flash player. But the user can share the modules in any number of applications.

Benifits 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. For example, a “reporting” feature can be separated into a module that you can then work on independently.
• Any number of applications can share the modules.

Creating the Modules

To create the modules we should create seperate mxml or actionscript class and an application that uses the modules. We can create the modules in two ways, one is by using the mxml and by using the actionscript class.

Creating the modules by using the mxml

An MXML-based module file’s root tag should be <mx:Module>. Within this tag we can create all our child containers and components.Ofcource we can have our styles and scripts also. We should compile the modules using the mxmlc command-line compiler or the compiler built into Adobe Flex Builder. The swf file will be created after we compile the modules.

<?xml version="1.0" encoding="utf-8"?>
<!-- modules/MyModule.mxml -->
<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" width="400" height="300">
	<mx:Script>
		<![CDATA[
			import mx.collections.ArrayCollection;
	        	[Bindable]
	        	public var expenses:ArrayCollection = new ArrayCollection([
	            		{Month:"Jan", Profit:2000, Expenses:1500},
		            	{Month:"Feb", Profit:1000, Expenses:200},
		           	{Month:"Mar", Profit:1500, Expenses:500},
	        	    	{Month:"April", Profit:2000, Expenses:600},
	            		{Month:"May", Profit:2500, Expenses:700},
		            	{Month:"June", Profit:3000, Expenses:500},
		            	{Month:"July", Profit:4000, Expenses:400}
	        	]);
		]]>
	</mx:Script>

	<mx:DataGrid dataProvider="{expenses}" >
		<mx:columns>
			<mx:DataGridColumn dataField="Month" headerText="Month" />
			<mx:DataGridColumn dataField="Profit" headerText="Proft" />
			<mx:DataGridColumn dataField="Expenses" headerText="Expenses" />
		</mx:columns>
	</mx:DataGrid>
</mx:Module>

Creating the modules by using ActionScript

To create a module in ActionScript, we should create a file that extends either the mx.modules.Module class or the mx.modules.ModuleBase class. Extending the Module class is the same as using the <mx:Module> tag in an MXML file. You should extend this class if your module interacts with the framework; this typically means that it adds objects to the display list or otherwise interacts with visible objects.

package modules{
    import mx.modules.ModuleBase;

    public class ArithmaticModule extends ModuleBase {

        public function ArithmaticModule () {

        }

        public function add(a:Number, b:Number):Number {
            return a + b;
        }

	public function subtract(a:Number, b:Number):Number {
            return a - b;
        }

	public function divide(a:Number, b:Number):Number {
            return a / b;
        }

	public function multiply(a:Number, b:Number):Number {
            return a * b;
        }
    }
}

Loading the modules

We can load the modules in our applications by using the <mx:ModuleLoader> mxml tag or mx.modules.ModuleLoader and mx.modules.ModuleManager ActionScript classes. Typically, we use one of the following techniques to load MXML-based modules:

• ModuleLoader : The ModuleLoader class provides the highest-level API for handling modules.
• ModuleManager : The ModuleManager class provides a lower-level API for handling modules than the ModuleLoader class does.

Using the ModuleLoader class to load modules

We can use the ModuleLoader class to load module in an application or other module. The easiest way to do this in an MXML application is to use the <mx:ModuleLoader> tag. We set the value of the url property to point to the location of the module’s SWF file. The following example loads the module when the application first starts:

<?xml version="1.0"?>
<!-- modules/MySimplestModuleLoader.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:ModuleLoader url="MyModule.swf"/>
</mx:Application>

We can change when the module loads by setting the value of the url property at some other time, such as in response to an event. Setting the target URL of a ModuleLoader triggers a call to the loadModule() method. This occurs when we first create a ModuleLoader with the url property set. It also occurs if we change the value of that property. If we set the value of the url property to an empty string (“”), the ModuleLoader unloads the current module.

Using the ModuleManager class to load modules

You can use the ModuleManager class to load the module. This technique is less abstract than using the <mx:ModuleLoader> tag, but it does provide you with greater control over how and when the module is loaded. To use the ModuleManager to load a module in ActionScript, you first get a reference to the module’s IModuleInfo interface by using the ModuleManager getModule() method. You then call the interface’s load() method. Finally, you use the factory property of the interface to call the create() method and cast the return value as the module’s class.

The IModuleInfo class’s load() method optionally takes an ApplicationDomain and a SecurityDomain as arguments. If you do not specify either of these, then the module is loaded into a new child domain. The following example shell application loads the ColumnChartModule.swf file and then adds it to the display list so that it appears when the application starts:

<?xml version="1.0"?>
<!-- modules/ModuleLoaderApp.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="initApp()">
    <mx:Script>
        <![CDATA[
        import mx.events.ModuleEvent;
        import mx.modules.ModuleManager;
        import mx.modules.IModuleInfo;

        public var info:IModuleInfo;

        private function initApp():void {
            info = ModuleManager.getModule("MyModule.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);
        }
        ]]>
    </mx:Script>

    <mx:VBox id="vb1"/>

</mx:Application>

Note: MXML-based modules can load other modules. Those modules can load other modules, and so on.

Unloading the Modules

We can unload the modelues in two ways:

1. If we set the value of the url property to an empty string (“”), the ModuleLoader unloads the current module.

2. Calling the unloadModule() method of the ModuleLoader instance.
public function removeModule(m:ModuleLoader):void {
m.unloadModule();
}

Modular applications best practices

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 (or loaded late into the shell’s application domain). When you promote one of those classes to the shell, the class can then be used by all modules. 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;

This technique also applies to components. The module that first uses the component owns that component’s class definition in its domain. As a result, if another module tries to use a component that has already been used by another module, its definition will not match the existing definition. To avoid a mismatch of component definitions, create an instance of the component in the main application. The result is that the definition of the component is owned by the main application and can be used by modules in any child domain.

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.

One way to verify this is to ensure that a relative URL for the module’s location doesn’t require “../” (“up one level”) notation to navigate outside the application directory or one of its subdirectories.