Packaging for runtime

DIGG IT!     1 Comments Published Wednesday, September 17, 2003 at 8:03 AM .

One of the more difficult tasks in making a good runtime model for Flash is deciding how to package code for reuse. This is especially true considering the many dependent classes and managers needed when using MX 2004 components.

Ideally adding a runtime framework to the Flash player should be easy and require as few calls as possible. Here is how this is done in PowerSDK.


1. Load PowerSDK version 18 into _level1000

loadMovieNum ("/PSDK/18/core.swf", 1000)

PowerSDK uses the file system or URL to allow the framework to be reused across applications. The URL above allows you to specify a framework version to use in your application and to specify where the folder is located. Once 'core.swf' loads, it will proceed to load other components based on the URL path to itself. So long as the framework remains in the organized structure, you don't have to worry about a thing. In this case, the call is loading version 18 of PowerSDK to an arbitrary layer 1000 of the player. This is typically the first call in every one of my applications.

The core.swf also sorts code based on player version allowing you to support the current player version and the one prior. In this case, F6 and F7 are supported by PSDK. So if you loaded a component at a path 'com.macromedia.mx.core.view' it would be located at these 2 locations:

/PSDK/18/6/com/macromedia/mx/core/view.swf
/PSDK/18/7/com/macromedia/mx/core/view.swf

Although these 2 swfs have the same name, they are compiled for optimized use with a particular player version. When core.swf (f6) loads it uses the player version to load components from the correct file system. This allows you to develop to a common model, but deploy to an optimized player. This is very different to developing to the weaker player model as it allows performance to be optimized where it can be yet maintain backward compatibility to a feasible extent. Mostly it helps combat the development problems associated with legacy support.


2. What to import and how to import it

PSDKImport = new XML('')

The new PowerSDK framework supports 2 loading properties, pre and post defined in an XML Object. PRE allows you to load components in advance of the init() execution. POST are loaded as soon as init has executed in the order within the XML object. There is also some other functionality, but I will get into that later on!

Another important consideration is dependencies. When you load a component, the component should inform the framework about its dependencies prior to instantiation. Instantiating a class without a superclass causes all sorts of problems at runtime. Ideally the framework should handle the leg work needed to make this happen without user intervention. In PowerSDK, I use callbacks to denote a dependency in a recursive manner:

// within the component 'com.macromedia.mx.core.view' we denote the following dependencies
// 'com.macromedia.mx.core.UIComponent' and 'com.macromedia.mx.core.UIObject'
PSDK.import('com.macromedia.mx.core.UIComponent')
PSDK.import('com.macromedia.mx.core.UIObject')

After all of the dependent components are loaded, the _global/_level0 instances are created in reverse dependency order via the framework. Inside each component SWF the class is declared within a wrapper init() method that places the instance into _global or _level0. This organized preloading and instantiation allows the application to load as little as possible via a simple developer interface. It also makes your components smaller as they can depend on other components for services and functionality. This sort of breaks some rules for componets (encapsulation) but it is very effective.

3. Initialize the application with an INIT method

init = function(){}

Once this is complete, the player is conditioned for runtime reuse. All in all I have found the PowerSDK framework invaluable as it allows you to reuse solutions via the Player not by the Authoring IDE. Most importantly, it make reusing code across applications easy and keeps your applications small and tight.

On Components - I have a distorted view of what a component it. I view a component as "a reusable unit of deployment". This means that anything that can be deployed into a swf is eligible. How it is organized internally is up to the developer, externally it must be able to be reused in an organized manner. Although this may rub some people the wrong way, this view has helped me surmount many problems that a purist OOP outlook would not have permitted. There are many ways to write software, none of them are wrong. Each has advantages and disadvantages in certain situations and each is just another option along the road to a completed project.

Cheers,

ted ;)

---