2005 Adobe Systems Incorporated. All Rights Reserved. 1 Modules Alex Harui Flex SDK Adobe Systems, Inc

2005 Adobe Systems Incorporated. All Rights Reserved.1

Modules

Alex Harui

Flex SDK

Adobe Systems, Inc.


Agenda

Answer the 7 question words (why, what, who, where, which, when, how):

What are Modules?

And what are Runtime Shared Libraries (RSLs)?

Why Modules?

Who invented them?

Which is better: Modules or RSLs?

When do I use them?

Where do I use them?

How do I use them?

Under the hood


What are Modules?

Modules is the name of a specific feature of Flex that is used to break applications up into smaller pieces.

RSLs (Runtime Shared Libraries) is the name of another specific feature of Flex that is used to share common code between two different applications

Modules can also be used to share code between applications


Why Modules?

MXML makes it really easy to assemble components into an application.

<mx:Application …> <mx:TabNavigator …> <mx:VBox> <mx:Label … \> … </mx:VBox> <mx:VBox> <mx:DataGrid … \> … </mx:VBox> </mx:TabNavigator></mx:Application>

Eventually your application will get very big.

As your application gets bigger, it takes longer to start up.

Modules will improve startup time in most cases.


Who invented Modules?



Roger Gonzalez was the developer for Modules



Roger Gonzalez was the developer for Modules

MAX 2006 presentation and demos: http://blogs.adobe.com/rgonzalez/


Which is better: Modules or RSLs?

Neither. They serve different purposes.

RSLs are libraries of supporting classes (and assets) other classes need in order to operate.

RSLs load before the application starts and can actually penalize load time if the RSL is not already in the browser cache.

Thus, no advantage if no other application is sharing that RSL.

Modules are libraries of classes (and assets) that you only need after application startup (or choose dynamically at startup).

You cannot refer to the classes in a module, only the interfaces they share with the application.

A large application will almost always benefit from using Modules, but may not benefit from using RSLs.


When do I use Modules?

When your application size and startup time become a factor and there is code and/or assets that are not needed at startup time.

When you want to choose dynamically between a set of similar classes and/or assets.

When you don’t want to recompile every line of code in your application every time something changes (and there are no class interdependencies on some portion of the application).

When there is code you want to share with other applications (consider RSLs and custom Components as well).

When there is code that can’t be upgraded to the most recent version of Flex you are using.


Where Do I Use Modules?

Navigators: ViewStack, TabNavigator, Accordion

PopUp Dialogs

Themes/Styles

Localized Strings and Assets

Shared code between modules

Anything else configurable or optional


How Do I Use Modules?

For Navigators: Hopefully you’ve already converted to an MXML Component

<mx:Application …> <mx:TabNavigator …> <mx:VBox> <mx:Label … \> … </mx:VBox> <local:MyDataGridView /> </mx:TabNavigator></mx:Application>

MyDataGridView.mxml<mx:VBox> <mx:DataGrid … /> …</mx:VBox>



For Navigators: Replace MXML Component with ModuleLoader

<mx:Application …> <mx:TabNavigator …> <mx:VBox> <mx:Label … \> … </mx:VBox> <mx:ModuleLoader url=“MyDataGridView.swf” /> </mx:TabNavigator></mx:Application>

MyDataGridView.mxml<mx:VBox> <mx:DataGrid … /> …</mx:VBox>



For Navigators: Wrap Component in mx:Module tag

MyDataGridView.mxml<mx:Module …> <mx:VBox> <mx:DataGrid … /> … </mx:VBox></mx:Module>

If the top-level is a VBox, HBox or Canvas, simply replace the tag

MyDataGridView.mxml<mx:Module …> <mx:DataGrid … /> …</mx:Module>



For PopUp Dialogs: Let’s say the app looks like

<mx:Application …> <mx:Script> private function showLogin():void { var loginDialog:LoginDialog = new LoginDialog(); PopUpManager.addPopUp(loginDialog,…); } </mx:Script> <mx:Button label=“login” click=“showLogin()” /></mx:Application>

LoginDialog.mxml<mx:TitleWindow> <mx:Label …/> …</mx:TitleWindow>



For PopUp Dialogs: You could do this:

LoginDialog.mxml<mx:TitleWindow> <mx:ModuleLoader url=“loginContent.swf” /> …</mx:TitleWindow>

But a slow network could leave the dialog blank for a while…



For PopUp Dialogs: So, this is probably better:

<mx:Application …> <mx:Script> private function showLogin():void { var m:IModuleInfo = ModuleManager.getModule(“LoginDialog.swf”); m.addEventListener(ModuleEvent.READY, function(e:Event) { var dlg:IUIComponent = m.factory.create(); PopUpManager.addPopUp(dlg,…); }); m.load(); } </mx:Script> <mx:Button label=“login” click=“showLogin()” /> </mx:Application>



For PopUp Dialogs: The dialog itself just gets wrapped in mx:Module

LoginDialog.mxml<mx:Module … > <mx:TitleWindow> <mx:Label …/> … </mx:TitleWindow></mx:Module>



For Themes/Styles: Use Runtime CSS feature

For Localized Strings/Assets

Wait for next release of Flex



For Shared Code Between Modules: Two modules will sometimes have the same classes (or assets).

However, you have to be careful if those classes are Managers.

Common mistake is to unwittingly bring in Managers (PopUpManager, DragManager) in a module and use it from another module.

We’ll see in Under The Hood why that doesn’t work

So, factor out common code into another module, load it before you load the module that uses it, or even right after app startup.

public class SharedCode extends ModuleBase{ private var dragManager:DragManager; private var popUpManager:PopUpManager;}



For Shared Code Between Modules: Load the common code library like an RSL.

var m:IModuleInfo = ModuleManager.getModule(“SharedCode.swf”); m.load(ApplicationDomain.currentDomain);



Making Modules: By default a mx:Module-based module will have a copy of lots of

the classes in the main application because it is based on Container and UIComponent and other parts of the framework.

That means you would end up loading this code twice.

Special compiler options tell the linker to gamble that the loading application will have the required classes.



Making Modules: Generate a link-report of all of the classes in the main application

mxmlc --link-report <filename> mainapp.mxml

Use the –load-extern to tell the linker not to link in those classes into the module.

mxmlc --load-externs <filename> module.mxml

You can use other advanced options as well: --externs [symbol][…]

List of definition names (classes, functions, etc.) to mark as external (omit from linking).

--external-library-path [path-element][…]Compile against libraries in this path, but add all definitions found to the list of externs.


Modules

Any questions before we go under the hood?


Under the Hood – Application Domain

Classes and their methods belong to ApplicationDomains.

The “new” operator searches the ApplicationDomain of the method for the class definition and then makes a new class instance

If it can’t find a definition it will search the parent ApplicationDomain if there is one.


Flash ApplicationDomain is the top-level

Flex Framework and your application are a child.


DisplayObject…

Sprite

…

Event

= extends

Flash Player

UIComponentContainer

…

Application

MyApp

MyApp.mxml

= parent


When Flex loads a SWF, its classes are loaded either into the parent ApplicationDomain or a child ApplicationDomain

RSLs go in the parent ApplicationDomain


DisplayObject…

Sprite

…

Event

Flash Player

MyApp

MyApp.mxml


…

Application

FlexRSL.swf


When Flex loads a SWF, its classes are loaded either into the parent ApplicationDomain or a child ApplicationDomain

RSLs go in the parent ApplicationDomain


DisplayObject…

Sprite

…

Event

Flash Player

MyApp

MyApp.mxml


…

Application


Child ApplicationDomains can be unloaded

Modules default to the child ApplicationDomain

As the SWF sets up its classes, any class already defined is not added to the ApplicationDomain, even if it is a child.

First-in Wins


DisplayObject…

Sprite

…

Event

Flash Player


…

Application

MyApp

MyApp.mxml


…

Module

MyModule

MyModule.mxml



Classes defined in a child ApplicationDomain cannot be seen from the parent ApplicationDomain Therefore, the main application cannot reference the classes in a module

as classes

The application and module can both share interfaces

DisplayObject…

Sprite

…

Event

Flash Player


…

Application

MyApp

MyApp.mxml


…

Module

MyModule

MyModule.mxml

IMyModule IMyModule

= implements


Flex Managers are also “first-in wins”

This can cause confusion between modules.

The first DragManager loaded becomes the DragManager for all modules, but MyModule2 cannot see that DragManager



…

Application

MyApp

MyApp.mxml

DragManagerList

ComboBox

Module

MyModule

MyModule.mxml

DragManagerDataGrid

…

Module

MyModule2

MyModule2.mxml

Manager DB


That’s why shared code should be in the main application or loaded into the main ApplicationDomain



…

Application

MyApp

MyApp.mxml

DragManagerList

ComboBox

Module

MyModule

MyModule.mxml

DragManagerDataGrid

…

Module

MyModule2

MyModule2.mxml

Manager DB

DragManager


Under the Hood – Flash Player

Flash Player is a deferred display list renderer

A list of drawing commands are gathered Line from (0,0) to (100,100), fill area with color, etc.

The list is built from: Graphical objects in a SWF Frame

ActionScript



Two kinds of frames

Flash Player Frames

SWF Frames

SWF Frame Set of graphical objects to be added/removed from display list

Code to be used to further alter the display list

Flash Player Frame At some interval:

Adjust set of graphical objects if needed

Run any code that needs to be run

Render the results of the display list



Flash Player Frames can be rendered many times per SWF Frame

Flash Player streams in a SWF and tries to render ASAP

Here’s a simplified SWF:

SWF Frame 1 SWF Frame 2

id=“Circle”

Circle.x += 10

id=“Rect”

Rect.x += 10

Assets

Code



Until a full SWF frame is read, the player does not have a full set of instructions to render


id=“Circle”

Circle.x += 10

id=“Rect”

Rect.x += 10

Read ptr



If the SWF Frames load quickly the animation is like a flip book.


id=“Circle”

Circle.x += 10

id=“Rect”

Rect.x += 10



The second SWF Frame is ready by the time of the next Flash Player Frame so it is drawn without hesitation


id=“Circle”

Circle.x += 10

id=“Rect”

Rect.x += 10



Assuming there is a stop() request in SWF Frame 2, the player will not rewind to the beginning and will continue executing code, moving both shapes.


id=“Circle”

Circle.x += 10

id=“Rect”

Rect.x += 10



The animation will therefore appear smooth.


id=“Circle”

Circle.x += 10

id=“Rect”

Rect.x += 10



The shapes will eventually slide off-screen unless other code stops it.


id=“Circle”

Circle.x += 10

id=“Rect”

Rect.x += 10



If the SWF Frames are larger (or the network slower), the wait for the SWF Frames to finish loading will become a factor.


id=“Circle”

Circle.x += 10; more code…

id=“Rect”

Rect.x += 10; even more code...



SWF Frame is only partially read. The player still does not have a full set of instructions to render


id=“Circle”


id=“Rect”




Finally a full SWF Frame is read. Player executes instructions


id=“Circle”


id=“Rect”




If stop() requested, player does not try to render SWF Frame 2, and re-executes code in SWF Frame 1 then renders again.


id=“Circle”


id=“Rect”




We’re still waiting for SWF Frame 2 to load. SWF Frames are no longer paired to Flash Player Frames


id=“Circle”


id=“Rect”




Finally, SWF Frame 2 completes loading. Code in SWF Frame 1 detects that and tells the player to render SWF Frame 2, so the Rectangle can appear and start moving.


id=“Circle”


id=“Rect”



Under the Hood: Preloaders and RSLs

This technique of stopping after SWF Frame 1 loads and playing an animation while waiting for SWF Frame 2 is the basis of the Flex Preloader

The Flex Framework is at least 135Kb. Waiting for 135Kb in Frame 1 could result in potentially long “dead-air”

So, the Framework is placed in SWF Frame 2, and a Preloader plays an animation while we wait for SWF Frame 2.

We also wait for RSLs as well, because if code in SWF Frame 2 required a class in the RSL, it would not run properly

But wait, there’s more…


Under the Hood: Special Module Feature

If modules were packed onto the SWF as SWF Frame 3, 4, etc:

It would not affect application startup time

There would be fewer network requests

The entire SWF would be self-contained (unless it has other external assets) and therefore have fewer pieces to deploy

Of course, any change to a module then requires rebuilding the entire SWF.


Under the Hood: Special Module Feature

MXMLC Compiler options and metadata

--frame [label] [classname][…]Flex models each frame as consisting of a primary definition and its dependency graph. This configuration option allows you to specify the name of the primary definition for frames following the first (root class) frame.

[Frame(factoryClass)]Flex AS3 metadata where a class specifies a requested factory class to be exported on the previous frame, implicitly constructing a backwards daisy-chain of frame definitions.

Order is important as you would have to wait for all modules before a particular module to stream in before you can use that module.


Modules

Q & A

Documents

2005 Adobe Systems Incorporated. All Rights Reserved. 1 Modules Alex Harui Flex SDK Adobe Systems, Inc