Flash's New MovieClipLoader Class
As part of my ongoing experimentation with the new features of Flash MX 2004, I recently gave the new MovieClipLoader ActionScript class a real-world run through. The results were overwhelmingly positive, but with one big issue that could cause some developers headaches.
To preface this, I should note that the preloading of content in Flash, despite its near ubiquitous nature, has never been fully supported in ActionScript. Macromedia provided some hooks to write your own preloaders, but for newbies (and some old-school pros) the construction of preloaders was a laborious, hair-pulling experience. The support was so limited, it elicited an online petition drive. But with Flash MX 2004, and the new MovieClipLoader class, all that should be history.
MovieClipLoader comes packed with a bunch of methods that provide listener callbacks to the content you wish to load. In other words, you don't have to write loops, or attach EnterFrame events to dummy movie clips to retrieve loading progress. Once you initiate the loading of content - whether a swf or jpeg - the new onLoadProgress() method (with built-in properties for loadedBytes and totalBytes) is executed; allowing the easy creation of a graphical progress bar or textual field to receive and display the data.
Experienced ActionScript coders may think - Yeah, so what? We've been able to do this for years - which is true. But the MovieClipLoader class also includes some very handy methods for "intelligent" loading that were quite difficult, and laborious, to write in the past. This includes onLoadInit(), onLoadError(), onLoadComplete(), and a couple of trash-collecting methods: removeListener(), and unLoadClip().
onLoadInit() and onLoadComplete() are similar - both detect when a piece of loaded content has finished - yet onLoadInit() is much more powerful. onLoadComplete() fires when total and loaded bytes are equal, and not much else. onLoadInit(), on the other hand, fires when the ActionScript contained in the first frame of your loaded movie completely loads. In other words, if your loaded movie contained instructions for how it should be presented on the stage, onLoadInit() provides the necessary hook to only display your loaded content when it's good and ready.
onLoadError() is somewhat self-explanatory. It's a last-ditch "catcher" that fires if your content of interest doesn't exist. In the past, most developers simply skipped this task for the sake of brevity. But with onLoadError(), developers can easily provide feedback to the end-user if something goes wrong.
Finally there is removeListener() and unLoadClip(). removeListener() removes the listener object you set up to monitor your preloading. Why would you want to remove it? Memory. By deleting the listener -- which in most situations will never be used again -- you have one less ActionScript object floating around soaking up memory; memory that could be better allocated to other items.
unLoadClip() is similar to unloadMovie(), in that it unloads (deletes) loaded content. But unLoadClip() is a more integrated method, for it automatically receives the same target initiated by loadClip(). In other words, it knows, in advance, what you need to unload without you having to point at it.
So now comes the rub. From what I've been able to discern, onLoadProgress() only works in the browser plug-in - not locally. If you "Simulate Download" in the local Flash player, onLoadProgress() fails to provide feedback. The listener automatically jumps to onLoadComplete(), even though your content hasn't fully loaded yet. Perhaps this is a limitation of the local player, or a bug. But either way, the issue will prevent developers from adequately testing their preloaders -- something that could be especially problematic if the preloader contained animation -- unless they load the swf from a server with their web browser.
The good news here is that long-time Flash developers finally have the robust API for preloading content they've been asking for, and newbies will be able to create preloaders with greater ease.
Comments
great article! damn local flash player - thx for pointing us to the solution!
Posted by: Daniel at February 24, 2004 11:33 AM
Thanks for pointing that out. It saved me from pulling my hair out.
Posted by: Obelisk at March 8, 2004 7:09 PM
