Runtime Components

DIGG IT!     0 Comments Published Thursday, September 11, 2003 at 9:50 AM .

Aren't components great. Unfortunately the Flash community is only seeing 1/2 the picture. Maybe that should change...

In MX2004 and MX components are authortime in that they focus on assisting the developer before a project has been compiled. This form of reuse is beneficial to most projects but runtime components have some distinct advantages and have a proven history in other software markets.

Advantages:

1. Units of Deployment - Runtime components sit in an organized manner on a file system or web server ready to be imported into the Flash player at runtime. When a component is needed, it is imported, configured, instantiated, and later destroyed.

2. Late Binding - The later you bind a component into a runtime environment (flash Player) the more flexible the implementation. A runtime model allows importing a wide selection of components at runtime. Actually one could argue that the current authortime model is fully bound at compile time and thus limited at best.

3. Application Size - Since runtime components are imported externally, they need not contribute to the base applications size. The current MX authortime approach is identical to shipping MFC (Microsoft Foundation Classes) or the Java Swing library with your application. This is not an ideal practice and makes your applications bloated. In an online environment, this is even more troublesome. One big plus here is that components can be used across applications and even within other components with even less bandwidth burden than a single app. This is essentially a reuse multiplier as the browser cache acts as a repository for components that have already been loaded. Loading a component again is nearly instantaneous as it is on the local machine and doesn't require network operations.

4. Versioning - Runtime components operate on a URL as such they can be easily versioned. This allows a legacy application to continue to use the components it was built to support although each component has been upgraded many times. Ideally an application author can select the specific version of the component needed allowing conflicts to be minimal.

Disadvantages:

1. Framework - There is little software to assist the developer in terms of implementing an effective runtime model in Flash. IOLib, Outlet (Bhall), PowerSDK have made progress in this regard but things could be better and much simpler for the end developer. Ideally it could be this easy:

//load allows passing a configuration data
MC.load( path, InstanceConfig )

//load a MM ComboBox version6 into this movieclip
myMC.load( 'com.macromedia.listbox.6', {data:[1,2,3], labels:['One','Two','Three'], editable:false, rowcount:2, enabled:true, visible:true, minHeight:100, minWidth:100})

Fun Eh....

To make that happen, you need to manage loading a swf, brokering the loading of classes in dependent order and handle instantiation. Not an easy feat at runtime, but it is possible!

2. Component Interface Standards - There is no standard way to import, configure, instantiate and destroy a component loaded externally. The events and base code needed to make this work has not been established so that many components can work together under a common model. The basics of the MovieClipDatatype provide a fantastic foundation.

3. No components - Currently there are no components that are configured to operate in a runtime fashion. Although it is easy to port FUI or FUI2 components to a runtime model, we still lack the public interface to support this effort.

In a perfect world, the flash community could come to open agreement for a runtime component interface standard. This standard would allow many component authors to build components to a runtime standard and essentially create a market for runtime swf components, including components that ship within Flash MX and MX2004. This standard would consist of a standard set of events and methods that could be fired to make a component work once imported. These components should also expose the public interface to the developer for development and documentation purposes.

It is worth noting that with runtime components it is useful to provide developers with design-time controls to assist during development only to implement the runtime component model at compile time. This covers the best of both worlds allowing flexible deployment with flexible authoring.

If anyone is interested in discussing this further please email me. I would be willing to assist with the establishment of standards for runtime components as it would be infinitely valuable to a project at hand. After all component systems are only as good as the quality and quantity of components they contain.

Cheers,

ted ;)

---