Distributing the Flash component

When you distribute this component, you distribute a FLA file. It contains all the library symbols of this component, which is how the visual assets are distributed.

But you probably don't want to distribute the code along with the component FLA. This is where the ComponentShim symbol comes in. In effect, ComponentShim enables you to compile all your code into your FLA library, so that when you distribute the component FLA library, you can distribute the compiled code and not have to include your class files.

Create a MovieClip component to be the shim

Create a movie clip in your library and give it some meaningful name, like Shim. To make it easy to find it on the Stage later, include some shape on frame 1 of Shim. Then right-click Shim in the library and select Linkage. Check the Export for ActionScript and Export in First Frame check boxes and assign a name to the class, such as Shim (the class name is arbitrary; just ensure that it does not conflict with any real classes). Click OK to register the changes.

Next, right-click Shim in the library and select Convert to Compiled Clip. If your classes compile properly, you will see a symbol in your library with the component icon (as opposed to the MovieClip icon) with a name like "Shim SWF" (it will append "SWF" to whatever the name of the source movie clip is).

Here is where you may think you've run into a major problem. (I know I did.) The Shim SWF component must be added to each movie clip in your library that links to a real class. For each such movie clip in your library, you must add Shim SWF to frame 2 of the movie clip. Because I had over 30 movie clips in my library that linked to real classes, that meant I had to add the Shim SWF to 30 separate movie clips. And because I had to recompile the Shim SWF each time I updated my code, this meant I would have to do this each time I wanted to update the component.

Seeing as the whole purpose of this exercise was to build an efficient workflow, this was a game-stopper to me. I couldn't spend 20 minutes to update the Shim SWF instances throughout my app each time I wanted to test an update.

This led to the final major architectural adjustment in my video player: the shift from inheritance to encapsulation.

Encapsulate, don't extend

Flash is an incredibly visual environment. In most projects—including the code-heavy ones—controlling visual elements with code is essential. This means your code, which resides in class files, must be able to control symbols from the FLA file, either directly from the library or on the Stage. There are two basic ways of doing this: encapsulation and inheritance.

Encapsulation means that your class has a pointer to a movie clip, so the code can control the movie clip by talking to the pointer. Inheritance means that your class is a movie clip, so it can control the movie clip by controlling itself.

Here are two very simple classes that attempt to illustrate that point—both would set the alpha of a movie clip to 50%:

Encapsulation sample

package
{
      import flash.display.MovieClip;
      public class EncapsulationSample
      {
         public var mc:MovieClip;
            function EncapsulationSample()
            {
            mc = new MovieClip();
            mc.alpha = .5;
            }
      }
}

Inheritance sample

package
{
      import flash.display.MovieClip;
      public class InheritanceSample extends MovieClip
      {
            function InheritanceSample()
            {
                  alpha = .5;
            }
      }
}

If I wanted to instantiate each of these from the Stage and add the generated movie clip to the Stage, the code for both cases would look like the following:

var encap:EncapsulationSample = new EncapsulationSample();
addChild(encap.mc);
var inherit:InteritanceSample = new InteritanceSample();
addChild(inherit);

Back in the ancient, mystical world of ActionScript 2.0, I was never really that comfortable with movie clip inheritance. In most cases, I opted for encapsulating my movie clips rather than extending them. With the ease and flow of ActionScript 3.0, however, I've utilized inheritance much more frequently. Hence my problem. As I explained when I described Version 1 of the video player, I used inheritance for dozens of classes, linking the movie clips in my FLA library to custom class files that extended the movie clip and defining the behavior for those assets (such as mute button, progress bar, title bar, and so on). Unfortunately, this is not a wise path when it comes to creating components.

So, as one of dozens of similar examples in my source, I have a TitleBar in my video player. Up until this point in development, I had a TitleBar MovieClip in my library that linked to a TitleBar.as class file. That TitleBar class file extended MovieClip and then included all the other code that I needed to run my TitleBar. But when publishing as a FLA-editable Flash component, this meant I would have to update the Shim SWF in the TitleBar.

To ensure that I would have to update only the Shim SWF in one location throughout my component, I went through and changed all the code to utilize encapsulation instead of inheritance. Returning to my TitleBar example, this meant that the TitleBar MovieClip in my library now linked to a nonexistent class, TitleBarMC. My TitleBar.as class no longer extended MovieClip but instead now included a property called mc, which was an instance of the TitleBarMC MovieClip. So my TitleBar class could still effectively control my TitleBarMC MovieClip but I would not have to update the Shim SWF in the TitleBar at all.

At the end of this refactoring process, the only movie clip in my library that required the Shim SWF was the main component MovieClip, ABMP_flc, which you built in Step 2. Figures 17 and 18 illustrate the changes. The resulting source looked something like Figure 19.

Figure 17. Before, with inheritance

Figure 18. After, with encapsulation

Figure 19. Video player refactored for encapsulation

Moving on

I finally had my video player working all three ways: as a Flash SWF, as a Flex component, and as an editable Flash component. However, I had accumulated three separate code bases along the way to make it happen. The whole point when I started was to get the project to where I had only one code base to maintain and update.

So now I just had to make that happen.

Page 6 of 7

Previous Page

Next Page