I wrote this series of articles to provide instructions and present techniques required to create ActionScript 3.0 components in Adobe Flash CS3 Professional. After following along with this series, you will learn how to do the following:
For the purpose of this series, I focus on creating components modeled after the Flash CS3 User Interface components. These components all leverage shared base classes and other classes—which I refer to as the "User Interface Component Infrastructure."
There's a lot of functionality in the Infrastructure that makes the process of creating a component faster and easier. Additionally, there are many conventions that, if followed correctly, can make new components compatible with the User Interface components. However, there is a lot to know about using and extending the Infrastructure's APIs. In order to offer a comprehensive overview, I've dedicated the majority of this article to working with these APIs.
Creating a FLA-based editable component, built in the same style as the User Interface components, is the primary focus of this series. But I will briefly cover how to create a SWC-based, non-editable component as well.
To complete this article series, you will need to install the following software:
To get the most from this article series, you should be familiar with Flash CS3, including how to manipulate the Timeline, the Property inspector, the Components panel, the Components inspector, the Library, and the Actions panel. You should also be familiar with the basics of ActionScript 3.0, including the declaration and the import of packages and classes, declaration modifiers (
static, etc.), the difference between a class and an interface, strict mode, the event model, and the display list.
This series is built around one main example, a MenuBar component, which is meant purely as a sample and not as a full, robust implementation. Therefore, it comes with no promises or warranties of full or correct behavior. The MenuBar component does not attempt to match all the functionality of the Adobe Flex 2 MenuBar component or of any other production-quality MenuBar widget or component. You'll be creating the MenuBar component as a sample project, with the primary goal of illustrating how you can build your own components.
In this series, I've formatted code snippets and references to a specific package, class, function, or property by name with a fixed-width font, like this:
You'll notice that not every reference to the TileList component, for example, is formatted this way. This is because references to the Library symbol TileList are not formatted using the same font. The component TileList is comprised of the Library symbol named TileList and the ActionScript class
fl.controls.TileList, which is tied to the Library symbol.
Convention dictates that the class name and symbol name should be identical, and following this convention greatly simplifies and facilitates project organization, but they do not necessarily have to be the same. For example, a symbol named Foo could be exported for ActionScript as the class
Bar. So when you double-click the symbol on the Stage to edit it, you are editing TileList, but when you change its properties by writing code, you are accessing an instance of
TileList for short. This can be a little confusing, but my hope is that the formatting will make things less confusing.
You'll also notice some text set apart in a sidebar like this. When I discuss more esoteric technical details that will be illuminating to some and befuddling to others, or when I discuss more complex examples, I set the text apart in this way.
You may find this series more digestible—at least upon the first read—if you skip these sidebars for now. Some of this material covers in-depth topics that might make more sense after you have completed the series and have had some experience working with components. At that point, you might find it helpful to review the series again and focus on the more advanced areas of interest.
Now that I've clarified the formatting conventions used in this series, let me discuss what a component is and what it does.
A component is generally a user interface widget, like a button, a checkbox, or a menu bar. Rather than having to write all the code and create all the art for these widgets yourself, you can simply drag components into your FLA file.
Flash developers can manipulate a component with ActionScript, but in many cases it is also possible to configure them by setting parameters in the Property inspector. Components do not have to be simple user interface widgets, and some can be quite complex, like the FLVPlayback component that plays videos or the DataGrid component that presents a table of data.
Among the different versions of Flex, Flash, and ActionScript, there are many different ways to define what is a component. In this series, I'm almost exclusively discussing ActionScript 3.0 components that are created and used in Flash CS3. In the context of Flash, a component is a movie clip or compiled clip that the Flash developer can drag out of the Components panel into a FLA file. The movie clip should be exported for ActionScript and also should expose parameters that can be set in the Parameters tab of the Property inspector or in the Components inspector.
A component has Live Preview, which means it adjusts proportionately in response to changes in width and height (instead of simply scaling like most shapes and symbols). It also updates itself to reflect parameters set by the Flash developer, such as dataProvider, label, or visible.
Authoring the Live Preview support for Flash CS3 ActionScript 3.0 components is actually quite similar to authoring the Live Preview support for ActionScript 1.0 and 2.0 components. It is important to note that when I discuss Live Preview in ActionScript 3.0 components, it is not related to the design view preview supported by Flex Builder 2.
The User Interface components included with Flash CS3 are built upon what I will refer to in this series as the "User Interface Component Infrastructure." The Infrastructure consists of the classes defined in the
fl.* packages. It is not to be confused with the Flex 2 framework, which is defined by the classes in the
mx.* packages. I specifically avoid using the term framework when referring to the User Interface Component Infrastructure to avoid confusion with the Flex 2 framework.
To be built with the Infrastructure, a component's class must extend
fl.core.UIComponent and it should also adhere to other guidelines and requirements enumerated in this series. You must implement specific methods to plug into the invalidation and styling models, for example, and there are specific guidelines on how to set up your FLA file.
The main example covered in this series, the MenuBar component, is built upon the User Interface Component Infrastructure, as most components likely will be. Flash CS3 does ship with some components that are not built upon the Infrastructure: the FLVPlayback and the FLVPlaybackCaptioning components. Creating components that are not based on the Infrastructure is outside the scope of this series.
A FLA-based component is a movie clip that is editable by a Flash developer. When you drag a FLA-based component from the Components panel to the Stage or to the Library, behind the scenes it is just as though you opened a FLA file as an External Library and dragged in a symbol from that Library.
Dragging the component into a FLA file also imports all the Library symbols used by the component into the FLA file's Library, and those symbols are editable as well. The primary reason to make components FLA-based is to include the Library symbols that are used to skin the component as editable. The User Interface components included with Flash CS3 are all FLA-based components for this reason.
A SWC-based component is a compiled clip. Compiled clips can be seen as prepublished SWFs embedded within your Library. Since SWC-based components are prepublished, they cannot be edited at all by the Flash developer.
SWC-based components publish faster than a movie clip or a FLA-based component, primarily because all of its ActionScript is precompiled. The FLVPlayback and FLVPlaybackCaptioning components are examples of SWC-based components.
The User Interface FLA-based components use a technique to take advantage of the publish efficiency gained by using SWC-based components. Each UI component includes a compiled clip, called the ComponentShim. This compiled clip includes all of the precompiled ActionScript definitions for the User Interface components, including the entire User Interface Component Infrastructure. Later in this series I'll cover more details about how this compiled clip shim works and how you can use the same trick in your components.
ActionScript 2.0 also supports SWC files, but as you can imagine they are in a different format from ActionScript 3.0 SWC files. ActionScript 2.0 SWC files are completely incompatible with ActionScript 3.0 SWC files and compiled clips. Any SWC file can be copied into Components folder in Flash. Flash can identify which components are ActionScript 2.0 and which are ActionScript 3.0 and treats each one accordingly.
Read what's coming in the rest of the parts in this series, so you can decide where you'd like to go next:
As you research more information about working with ActionScript 3.0 and creating components, you might find the following resources to be very helpful:
Jeff Kamerer is a computer scientist at Adobe Systems who has worked on the Flash authoring team since 2002.