Flash Component Architecture: v1 vs. v2
If you've been interested in learning about components, you may have noticed a lot of recent discussion about "v1" vs. "v2" architecture. "Version 1" refers to Flash MX-compatible components, using ActionScript 1.0. "Version 2" refers to the new component architecture, based on ActionScript 2.0 for use with Flash MX 2004.
With the release of MX 2004, ActionScript has evolved into a more robust object-oriented language. The differences between AS 2.0 and AS 1.0 are too significant to go into great detail here; a few simple examples will help you understand how they impact the v1 vs. v2 component architecture choice. AS 2.0 offers strict data typing (meaning that variables must be defined as numbers or strings, for example, and stay with that data type), strict case-sensitivity, and the benefits of a true object-oriented languageincluding public and private classes and proper inheritance. AS 1.0 employs weak data typing (meaning that a variable with a number value can later be reassigned a string value without error), is case-insensitive in some ways, and does not offer true public and private classes for optimal object-oriented programming. (For a more detailed description of these compatibility issues, see the sidebar "Component Migration.")
|Figure 1. The End Result: This is an example of our finished sample component in action.|
The differences between the v2 and v1 components
are similar in some ways. To get the most of the v2 architecture, you need to use ActionScript 2.0 and define private and public classes. Another feature v2 offers is an extensible framework that allows components to share code structures and accomplish common tasks by sub-classing. Neither of these features is available to v1 components.
I won't be focusing on the v2 architecture in this article for a variety of reasons. To begin with, it helps to learn the basics of how to put a v1 component together from nothing, before learning the v2 base framework that you can extend. Second, it can be easier for the uninitiated to embrace the less-restrictive structure of ActionScript 1.0 and move on to the changes, and benefits, of ActionScript 2.0 as experience is gained. But there's a more important reason that applies to all skill levels: By focusing on the earlier version of the architecture you'll learn how to create a component that is compatible not only with many Flash MX 2004 projects, but also Flash MX filesand even Flash 5 files, in some cases, where legacy issues may be at stake. .
As hinted above, v2 components won't work in versions of Flash prior to MX 2004. If a component is authored in MX 2004 using ActionScript 2.0, it will require at least that version of ActionScript to function, preventing its use in Flash versions prior to MX 2004. But there's also no guarantee that v1 components will work in all MX 2004 projects, so a little project planning is recommended. Again, see the brief sidebar "Component Migration" for more information.
Learn Step by Step
It's true that components can offer a lot of power and flexibility, and with that comes a necessary support infrastructure. However, there's no reason that you have to start with an overly complex example. You certainly don't have to begin by using every component feature right away, and you can embrace some of the more important coding techniques early, and add more complex concepts as you become more comfortable.
In keeping with this step-by-step methodology, I will begin this article with a simple hard-coded MovieClip, then replace some of the hard-coded values with user-defined parameters, and finally add features that really allow components to function as standalone widgets. (Click here to download the code for this article or use the link in the left-hand column.)
The Sample Component
My goal is to create a very simple sample component that will allow you to focus more on the process of creating the component and less on general ActionScript. As such, I will focus on only one feature for the utility; I will not spend time on error-checking user-entered values, and I won't cover all the best practices recommended for bulletproof coding. You can add these types of checks and balances to your final product as your comfort level grows.
The example component I've developed will automatically "stamp" a copyright symbol in the lower right corner of your movie. This is a stripped example of something you might use to automatically (and programmatically) brand your movies. I've used similar techniques to programmatically add phrases such as "BETA," a watermark, a datestamp, etc., without having to worry about doing it by hand again and again.
I will focus on changing only one parameterthe opacity of the artwork's white backgroundwhich is accomplished by adjusting the _alpha property one of the component's parts. An _alpha of 0 is transparent, and an _alpha of 100 is opaque. The final component, complete with an optional custom user interface (more on that later), is shown in Figure 1.
In this article, you'll learn how to:
- Create a normal hard-coded Movie Clip (MC)
- Create user-definable parameters
- Create a live preview so users can change parameter values and see the effects
- Add a plain text description about the component to the Reference panel
- Add a custom icon to your component for distribution to others
- Manually install the component for testing.
In February, DevX will publish part 2 of this article, which will discuss how to:
- Add a custom user interface to the Properties pane, to set parameters
- Enhance the component with a custom class when it is initialized
- Make your code more user-friendly and better insulated by defining "getter" and "setter" wrappers
- Enhance the Reference panel description, and add custom actions to the Action panel using XML
- Package the component for distribution with the Extension Manager.