Flash Tutorials

Section 2 : Building components that don't rely on Export in first frame

As you have seen previously if you use export in first frame, the preloader doesn't work and the visitors will encounter a fairly long blank screen even before the preloader/first keyframe. Using the previous technique would suffice on most occasions. However when you start using components you have to deal with someone else's linked assets in your movie as well. Most components rely very heavily on linked assets, especially UI Components that use skin elements/movieclips. The more components you use, the greater is the preload lag before the first keyframe gets loaded.

To demonstrate this, let's take a look at the Push Button component (Flash UI Components set 1)

Lets try it out :

1. Create 2 scenes in a new Flash movie, preloader and main.
2. Add a stop action in the Main scene to prevent the movie from looping continuously. You could create a preloader in the first keyframe as we did in the previous section, but right now lets focus on the component itself.
3. Now drag the Push Button component from the components panel to the stage of Main scene. Test the movie.

As you can see even though there is nothing on the first keyframe (preloader scene frame 1), there are a few kilobytes on it. These kilobytes are a result of the various linked assets used in the Push Button component.

If any other components were used in this flash movie they would further add to the preload lag.

Lets see exactly which assets of the Push Button Component are causing this pre-load lag here. These are all the linked assets in the Push Button Component.

1. Push Button Component : The component itself is export in first frame!
2. FUIComponent : The SuperClass that all Flash UI Components inherit from.
3. Flabel : The textfield used for text display in the button.
4. fpb_states : contains all the states (up, over, down, disabled) of the button.
5. fpb_hitArea : the hit area of the push button.

There is also another linked asset FBoundingBox, but throughout the FUIComponents it is never export in the first frame and hence we will not concern ourselves with it. The FBoundingBox symbol is where a component's background skin element is found.

Make Changes :

1. Disable (un check) export in first frame from each of these symbols. Simple!!!

If you test the movie now however it will not work since the component assets won't get exported at all. We still need to add these assets to the stage at author time for them to get exported.

We could use the technique discussed in the first section. Create an assets scene and dump these linked assets onto it. However that would mean any movie that uses the push button would have do that as well. Not a very neat solution! What we really need is to put these assets in the component itself so the component would be self-describing so to speak.

We could add these assets to the component's timeline itself and make them small or invisible. But that would unnecessarily pollute the component at runtime and use up memory/resources.

What if we put them inside a movieclip inside the component after the first keyframe AND prevent the playhead from advancing to the second keyframe. Since the playhead would never come to the 2nd keyframe no resources would be used to display the assets and they would get exported as well. Perfect right?

The next obvious question is which movieclip do we put them in? OR do we create a separate holder movieclip in every FUIComponent!

Fortunately every FUI component has a deadPreview movieclip in it. The deadPreview movieclip contains a placeholder graphic that gets hidden in the SuperClass (FUIComponentClass) as soon as it's init method is run, by actionscript in this superclass,

this.deadPreview._visible = false;
this.deadPreview._width = this.deadPreview._height = 1;

We will add the linked assets to this movieclip's 2nd keyframe and give it a stop action in the first. Thus the assets will get exported just before the keyframe that needs them.

We could further clean up the deadPreview, by unloading it's contents with unloadMovie(). In the FPushButtonClass's init method after the super.setSize(), add this line, this.deadPreview.unloadMovie (); Thus freeing up even more resources. Now if you test the movie you will find that the buttons works as expected and there is not preload lag as well.

There is a total of 36 bytes on the first keyframe now! Can i say Yippee now!!!

Although this is a fairly straightforward technique, the Flash UI Components do not use this, nor do most third party components ( including some of mine i might add:-) ). Hence when using a lot of components together you will notice a more pronounced preload lag before the first keyframe.

The good news is I have modified all the Macromedia Flash UI Components (set 1 & 2) to use this technique. Here's a look at what the Flash UI Components set 1 before and after results look like. I have used the tiny preloader component for the preloader in these movies as well.

There's nearly 61kb (with compression enabled) on the first frame. Until these 61kb are loaded the user won't even see the preloader. Click the image to see the preview.

In contrast the entire load has shifted to the second keyframe. The 2kb on the first keyframe are due to the preloader scripts. Click the image to see it's preview.

This technique is also very useful when dealing with shared assets, specially Runtime shared assets. If you plan things out properly you can actually make use of the same UI components throughout a site very smartly indeed! And the components will sit quietly in the library when not in use as well:)

One very important issue with this technique that needs to be considered is compatibility with components that don't use this technique. If for instance you were to drag a 3rd party component (that follows the Flash UI architecture) that does not use this technique into the library which does, mixed results would be obtained. The order of execution of the components could be affected. Simply put all hell could break loose!!!

There are only 2 ways about using this technique is, either you use the technique in all the Flash UI Components (and Flash UI architecture depending ones too) or none at all. There is no middle ground here, and if you mix both these types of components together, you can almost expect unexpected results. However it should not be a problem to use this technique in most FUI components, and it only takes a few minutes to implement. A small price to pay don't you think! I hope most developers would update some of their existing components to use this technique. Lets hope it's not wishful thinking though:-).

I hope this tutorial would have helped you in building more preloader friendly and compact components.