Ted Patrick > { Events & Community } > Adobe Systems

This is the first post in a series of observations on using component in Flash. It is my hope that you will keep an open mind about what I have to say. There are quite a few hardened opinions on this topic and this series is going to differ from what you have heard before. If you have feedback to contribute, please do not hesitate to comment here or post a longer reply on your own blog.

Purely looking at the improvements in the development toolset for Flash, it is obvious we have come a very long way. The transition from smartClips to V2 components is a fairly dramatic leap. Looking at my collection of smartClips in the Flash 5 IDE makes this all the more apparent. For me, the trouble begins when you stop looking from the authoring perspective and look at the mechanics of what happens at runtime. From the runtime perspective the Flash Player has changed very little since version 5.0 with some very notable exceptions (zlib compression, shared objects, rtmp, amf). If you limit your view in terms of component support, the player has changed far less.

Fact: At runtime, Components are MovieClips

When you compare a SmartClip or V1 or V2 component at runtime, externally they are just a MovieClip and internally a collection of MovieClips, properties, and methods working together to form a reusable unit of software. The V2 components are much more sophisticated in functionality but from the external barrier that defines an instance, they are exactly the same as all other MovieClips and can be manipulated in an identical manner. (Not to say that manipulation will not have an adverse effect on some components)

In looking at components from this perspective, the primary differences between in each generation and type of component are as follows:

1. Properties and methods vary from component to component. This is primarily associated with class inheritance but most components have data and methods within the component instance outside of the associated class.
2. Instantiation Data varies from component to component - Some components require data to be present during instantiation while some do not.
3. Internal MovieClips vary depending on the state of the component over time and vary widely from component to component.

If we were to further refine this list and limit our view to public methods and properties, we would certainly exclude #3. The remaining items loosely define the real component interface. That is to say that if we present different data and execute different methods within this interface, the component would behave in a different manner.

Another aspect is that MovieClips are different from their data counterparts. They are different in that MovieClips are managed by depth and data by reference and value. In dealing with MovieClips you have to be careful as MovieClips overwrite at depth not by reference. Depths were originally created to hold animation key frames and were overwritten when another key frame occurred at a common depth. In this respect they cooralate to the timeline very well but expose problems when used as a component metaphor. As depth is a limiting factor, MovieClips can only be created by designating a depth within the following methods:

createEmptyMovieClip
attachMovie ( V2 createObject reuses attachMovie )
duplicateMovieClip
createTextField

This forces the developer to deal with depth procedurally and can often create problems when dealing in bulk with MovieClips. In PowerSDK v16 I implemented a depth free MovieClip Class that made working with components much easier. This experiment proved successful in that large volumes of MovieClips could be instantiated and destroyed without dealing with depth except in a relative manner (above, below, top, bottom). Don’t misunderstand, depth has real value, but working with depth should be managed by the player and simple errors should be avoided.

Looking back to the component interface discussion, component state is stored loosely across a pool of public and private properties. If one wanted to persist component state, it would require understanding what properties matter to the particular component and how to correctly recreate component state at a later time in a consistent manner. Flash components to date are not designed to support persistence as they lack a defined interface. In my experience making components persistent is very difficult to achieve in a scalable manner, especially when attempting to observe encapsulation rules.

Component destruction can also be problematic as some components do not encapsulate their data in a reusable manner and are highly dependent on component external assets (MovieClips and data). Many components require external assets to be present at runtime creating a pollution problem in both the player namespace _level0 and _global. Most if not all of these dependencies are undocumented and unnecessary. This is not to mention library linkage pollution in naming library assets. Recently I spent 3 solid days debugging an app because a SWC component was overwriting another components linkage id. In terms of destruction, components should manage destruction of the assets that they create both inside and outside of the component instance. Currently they do not and the developer is left to mop-up the mess that components leave behind. I find it especially troubling that most of these dependencies could be avoided using simple techniques available today.

In Summary, here is my top 5 problems with components in Flash:

1. Component interfaces are not defined
2. Instantiating components dynamically can be problematic
3. Depth is a limiting factor in working with components
4. Persisting component state is very difficult due to a lack of a defined interface
5. Component destruction can be problematic due to problems with encapsulation

Next week, I am going to redefine the above problems by borrowing from existing component technology ( XUL, COM, WX ) and applying it to Flash in a fundamentally new way.

Cheers,

Ted ;)