Techniques for Delivering Modular Flex Applications
Please enabled JavaScript and install Flash Player 8 or above for view the content.
Additional Info
More from flash
Views: 1,637 | Comments: 0 | Favorited: 0 | Rating: 0
Login to rate
Speaker: Roger Gonzalez
Job title: Flex Compiler
Company/Organization: Adobe Systems
MAX 2006 Beyond Boundaries
Techniques for Delivering Modular Flex Applications
Roger Gonzalez
Flex Compiler :: Adobe Systems
SWF File Format
Assets – Bitmaps, Vector Artwork, Sounds, Video, Fonts, etc.
Code
frames
Draw to Stage
Streaming
A SWF is organized into a stream of “frames” containing definitions and actions.
A frame can be “played” only after it has been fully downloaded. Playing a frame executes all buffered instructions associated with the frame.
The frame “play head” can be stopped or set to a different location.
Draw a face in different location on many frames, loop back to beginning when done.
Place instance of shared asset in new location on many frames, loop back to beginning when done.
Programmatically create an instance of a shared asset and animate it on the stage in response to timer events.
Much more flexible…
Programmatically create an instance of a shared asset and animate it on the stage in response to timer events.
Much more flexible… which leads to new requirements!
Programmatically create an instance of a shared asset and animate it on the stage in response to timer events.
Much more flexible… which leads to new requirements!
--externs [symbol][…] List of definition names (classes, functions, etc.) to mark as external (omit from linking).
--load-externs Load a file (link report!) containing a list of definition names to mark as external. Buggy in 2.0, requires 2.0.1.
--external-library-path [path-element][…] Compile against libraries in this path, but add all definitions found to the list of externs.
The AVM verifier requires that hard type dependencies found in a definition signature must be satisfied before any Actionscript Bytecode (“ABC”) block requiring them is visited. (This requires careful MovieClip timeline choreography!)
Hard dependencies linked “extern” must generally satisfied early by loading RSLs.
Hard type dependencies found only inside method bodies may be resolved late!
A soft dependency can be formed using ApplicationDomain.
Soft dependencies can be resolved by late-loading a SWF containing the definition.
--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. Buggy in 2.0, Requires 2.0.1.
[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. *
Reduce dependencies
Interfaces
Mixins and registries
Satisfy hard dependencies
Load a RSL
Load into a context where externs are satisfied by a parent ApplicationDomain
Satisfy soft dependencies
Load a SWF
Provide a definition in a frame later in the same SWF
RSLs contain definitions loaded (into ApplicationDomain.currentDomain) by the preloader before the application is started.
The external-library-path option is used to omit RSL definitions during linking.
The SWF inside the RSL SWC must be extracted and deployed for runtime loading. The runtime-shared-libraries option is used to specify the URL where this SWF can be found.
In general, the aggregate size of any single dynamically linked application plus the RSL it loads will be larger than if the application were statically linked.
RSLs may improve amortized download performance when shared between multiple applications.
Startup time for a dynamically linked application is potentially much longer than that of a statically linked application.
Need to analyze your use case carefully!
Shell application loads external module SWFs
Each module root class implements a class factory, with a standard interface
Product of module class factory implements an interface known to the shell (and/or shell implements an interface known to the modules)
Shared interfaces provide type-safe communication and enforce a good abstraction layer without adding significantly to SWF size.
New package that implements the Shell/Module pattern!
Available in 2.0.1 (pester Matt Chotin to get on private beta)
Modules are compiled just like applications.
Singleton ModuleManager maintains URL-to-factory map.
Clients register for events to be notified of factory status.
Used by new runtime stylesheet feature!
Low-Level API
Loading application uses ModuleManager
Modules implement IFlexModuleFactory (info+create) directly
Mid-Level API
Loading application uses ModuleManager
Modules extend Modulebase (compiler generates factory with one product)
High-Level API
Loading application uses
Modules are built using
Solution: Data file specifies list of portlets SWFs to load, each honors a common interface contract.
Perfect example of Shell/Module pattern.
Portal and portlets can be developed independently without full recompile as long as the interface API is preserved.
Only portlets needed by a particular user will ever be loaded.
Solution: bundle packages of related screens into individual SWFs.
Fits Shell/Module pattern.
Functionality can be loaded on demand, perhaps unloaded on a LRU basis.
Solution: export classes on frame(s) following application.
Supported in mx.modules!
frame class implements IFlexModuleFactory
Factory is “published” to ModuleManager when frame is fully streamed in
Clients register for factory notification events as usual
Maintains single file deployment!
Deploying multi-SWF applications adds new failure paths.
Embedded fonts don’t work very well across SWF boundaries.
ApplicationDomain.currentDomain is weirder than you might ever imagine.
MXML framework has too many interdependencies to take significant advantage of modules, mainly of interest when writing large amounts of user code.
Being unloadable requires care.
Need to wait ‘til 2.0.1 for official support!
http://blogs.adobe.com/rgonzalez
Techniques for Delivering Modular Flex Applications
Roger Gonzalez
Flex Compiler :: Adobe Systems
SWF File Format
Assets – Bitmaps, Vector Artwork, Sounds, Video, Fonts, etc.
Code
frames
Draw to Stage
Streaming
A SWF is organized into a stream of “frames” containing definitions and actions.
A frame can be “played” only after it has been fully downloaded. Playing a frame executes all buffered instructions associated with the frame.
The frame “play head” can be stopped or set to a different location.
Draw a face in different location on many frames, loop back to beginning when done.
Place instance of shared asset in new location on many frames, loop back to beginning when done.
Programmatically create an instance of a shared asset and animate it on the stage in response to timer events.
Much more flexible…
Programmatically create an instance of a shared asset and animate it on the stage in response to timer events.
Much more flexible… which leads to new requirements!
Programmatically create an instance of a shared asset and animate it on the stage in response to timer events.
Much more flexible… which leads to new requirements!
--externs [symbol][…] List of definition names (classes, functions, etc.) to mark as external (omit from linking).
--load-externs Load a file (link report!) containing a list of definition names to mark as external. Buggy in 2.0, requires 2.0.1.
--external-library-path [path-element][…] Compile against libraries in this path, but add all definitions found to the list of externs.
The AVM verifier requires that hard type dependencies found in a definition signature must be satisfied before any Actionscript Bytecode (“ABC”) block requiring them is visited. (This requires careful MovieClip timeline choreography!)
Hard dependencies linked “extern” must generally satisfied early by loading RSLs.
Hard type dependencies found only inside method bodies may be resolved late!
A soft dependency can be formed using ApplicationDomain.
Soft dependencies can be resolved by late-loading a SWF containing the definition.
--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. Buggy in 2.0, Requires 2.0.1.
[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. *
Reduce dependencies
Interfaces
Mixins and registries
Satisfy hard dependencies
Load a RSL
Load into a context where externs are satisfied by a parent ApplicationDomain
Satisfy soft dependencies
Load a SWF
Provide a definition in a frame later in the same SWF
RSLs contain definitions loaded (into ApplicationDomain.currentDomain) by the preloader before the application is started.
The external-library-path option is used to omit RSL definitions during linking.
The SWF inside the RSL SWC must be extracted and deployed for runtime loading. The runtime-shared-libraries option is used to specify the URL where this SWF can be found.
In general, the aggregate size of any single dynamically linked application plus the RSL it loads will be larger than if the application were statically linked.
RSLs may improve amortized download performance when shared between multiple applications.
Startup time for a dynamically linked application is potentially much longer than that of a statically linked application.
Need to analyze your use case carefully!
Shell application loads external module SWFs
Each module root class implements a class factory, with a standard interface
Product of module class factory implements an interface known to the shell (and/or shell implements an interface known to the modules)
Shared interfaces provide type-safe communication and enforce a good abstraction layer without adding significantly to SWF size.
New package that implements the Shell/Module pattern!
Available in 2.0.1 (pester Matt Chotin to get on private beta)
Modules are compiled just like applications.
Singleton ModuleManager maintains URL-to-factory map.
Clients register for events to be notified of factory status.
Used by new runtime stylesheet feature!
Low-Level API
Loading application uses ModuleManager
Modules implement IFlexModuleFactory (info+create) directly
Mid-Level API
Loading application uses ModuleManager
Modules extend Modulebase (compiler generates factory with one product)
High-Level API
Loading application uses
Modules are built using
Solution: Data file specifies list of portlets SWFs to load, each honors a common interface contract.
Perfect example of Shell/Module pattern.
Portal and portlets can be developed independently without full recompile as long as the interface API is preserved.
Only portlets needed by a particular user will ever be loaded.
Solution: bundle packages of related screens into individual SWFs.
Fits Shell/Module pattern.
Functionality can be loaded on demand, perhaps unloaded on a LRU basis.
Solution: export classes on frame(s) following application.
Supported in mx.modules!
frame class implements IFlexModuleFactory
Factory is “published” to ModuleManager when frame is fully streamed in
Clients register for factory notification events as usual
Maintains single file deployment!
Deploying multi-SWF applications adds new failure paths.
Embedded fonts don’t work very well across SWF boundaries.
ApplicationDomain.currentDomain is weirder than you might ever imagine.
MXML framework has too many interdependencies to take significant advantage of modules, mainly of interest when writing large amounts of user code.
Being unloadable requires care.
Need to wait ‘til 2.0.1 for official support!
http://blogs.adobe.com/rgonzalez
Comments
Post Comment
You want to comment?Join VCASMO for a free account, or Login if you are already a member.