Flex Framework Features for Supporting Large Applications

The session largely covered the use of sub applications to support large applications, a feature that was introduced in Flex 3.2.



Primary approach is to split up into separate SWF files

Can be a problem if they are built using different versions of framework

Move shared code into runtime shared libraries (RSLs)

Get code out of the main application

Normal RSL can only be shared within an application domain

Framework RSLs can be shared cross domain

If it doesn’t need to be shared, put it in a module

No advantage to browser caching if there is only one application in a domain

RSLs cannot be removed from memory

RSLs load before app is started, modules load after app is started

Modules have partial class interaction
You cannot refer to their classes directly
You refer to shared interfaces

Optimized modules have classes they share with the application stripped out to reduce redundant downloading

Modules can be removed from memory

Multi-version apps (The Marshall Plan)



Flex 3.2 allows sub-applications

Sub applications allow you to mix SWFs that are based on different versions of the framework within an application

Only supports 3.2 or later

Only works for sub-applications, not RSLs or modules

Difference between module and application is start tag (and how they are loaded)

Each sub-application is loaded into a separate application domain
Data has to be shared via marshelling
No class integration
No direct references in scripts
No strong typing
No stripping out of shared classes

Class names are essentially classname@application

Singletons are not really singletons (e.g., the tooltip manager is just the manager for that app domain) – they have to talk to one another

No strong typing
You take something that is passed to you, create your own local class of the same type, and then copy over the properties you need.

Styles are not marshelled.
Each application must load their own
No inheritance or use of styles from main app

Resource bundles are not marshaled

Browser manager is turned off in sub applications

Drag/drop requires marshalling data on drop

Use systemManager.getSandBoxRoot instead of just systemManger when listing for keyboard and mouse events in capture phase

Sub applications must load their own RSLs

Remote object / data services / other AMF have serialization issues if the data is not in the main application

The sub application must be loaded into a separate security domain and then use allowdomain to enable sharing

Sub applications can step into other applications (they are insecure) by walking up the parent/child chain
Only load one sub application at a time to prevent cross-scripting
Sub applications can cross-script each other if loaded from the same domain

When using modules
systemManager.toplevelSystemManager

When using sub applications
systemManager.getSandboxRoot
Sandbox.mouseevent