Open Source Actionscript Based Project Utility Library on Google Code

As promised in the last post, I’ve uploaded an open source library coded by myself and a few friends. The library is intended for Actionscripters creating Flash experiences who prefer to work in Flex Builder or FDT. If you think the Flash CS3 coding environment sucks, then this library is for you!

Here is a high level overview of the current utilities

externalassets:

I’ve wrote several posts about this, but I feel like I haven’t even scratched the surface of how cool building Flash experiences in this way is. The basic gist is that you create your assets in Flash CS3, export them in a SWF, with the symbols with the export as actionscript linkage property set and a custom class name set. You then load them into your Actionscript project in Flex Builder using the AssetLoader class (only one line of code to load one or more SWFs). Once loaded you access the symbols via the AssetFinder class, which returns them as MovieClips. Using this method, you can dramatically reduce the size of the initial loading of your Flash experience, since you can load SWFs as you need them. You can also enforce a strict separation of visual assets and application control. No matter how the buttons change as long as their frame labels stay the same and the symbol is exported under the same class name your code doesn’t have to change at all. Also, since your project is based out of Flex Builder, you can use Subclipse as a version control app directly in your coding application! The FLA’s can be just a small part of your total project, and can be version controlled as well. For really small projects this is probably overkill, but for a medium to large size experience you’ll find the extra effort involved to set up a project in this way pays dividends when the inevitable torrent of changes or bugs come along at the eleventh hour.

displayextended:

This library was written by a good friend of mine and fellow member of this open source project, Zach, and it contains classes that help extend the Sprite class and wrap the MovieClip class. Basic functionality is automated such as buttons, build in and out sequences, and it even can chain multiple build in or out sequences. Most importantly it works in conjunction with the AssetLoader and AssetFinder and is intended to act as a wrapper for MovieClip assets loaded in from external SWFs.

To download the library, just click:

http://actionscripterutilities.googlecode.com/svn/trunk/

in your favorite SVN utility (Subclipse is the shit if you’re using Flex Builder or FDT).

If you would like to contribute, submit a bug, submit a feature request, or just yell at someone, just shoot me a mail at crebstock [at] gmail [dizzot] com.

Loader for Actionscript Flex Builder and FDT Projects

Since I started using Flex Builder to code Flash projects, one of the major hurdles I’ve had to deal with is how to get Flash based assets into Flex Builder. To accomplish this end, I’ve created a multi loader library that lets you load one or more SWF files at runtime. These SWF’s are then registered into the Application domain and any exported symbols in them become available.

This is really just an extension on the concept discussed by BigSpaceship and others in the past. You load one or more SWFs, then access the movie clips contained within them via the getDefinitionByName method. The main benefit of this library is that you can with one line load one or more SWFs and the class acts much the same as a single loader. You can still add all the same events to it that you would a normal Loader object, and the class manages the individual loading of the SWFs. This makes it super easy to create a preloader that works no matter how many SWFs you are loading. The percentage is actually accurate regardless of how many SWFs are being loaded as well.

This project I’ve uploaded shows a simple usage of it, and it breaks down pretty quickly (The loader source can be found as a flex builder project archive here, and the standalone swc can be downloaded here:


aLoader = new AssetLoader();
aLoader.addEventListener(ProgressEvent.PROGRESS, traceStatus);
aLoader.addEventListener(Event.INIT, assetLoadComplete);
aLoader.load("circleassets.swf", "squareassets.swf");


You can see here that once you declare it, you can add the event listeners and then pass as many SWFs as you want to the load function. All of them will be seperately stored and loaded for you automatically. For the purposes of the ProgressEvent function, the bytesTotal and bytesLoaded properties of the ProgressEvent are treated as if you are loading one large SWF, the size of all the swfs combined. This way the percentage is accurate for any preloader percentage displays that need to listen to the ProgressEvent.


public function traceStatus(evt:ProgressEvent):void
{
trace( evt.bytesLoaded + "/" + evt.bytesTotal );
}


Also note that we’re listening for Event.INIT, and not the Event.COMPLETE. Since we’re waiting for the loaded SWFs to be registered to the application domain we need to make sure that they have been registered and all of their internal elements are available before we attempt to access them. Once all of the SWFs are loaded, its easy to access their internal symbols:


public function assetLoadComplete( evt:Event ):void
{
trace("load complete");

var square:MovieClip = AssetFinder.FindMovieClipAsset( "com.view.assets.RadOutSquare" );
addChild( square );
square.x = 250;
square.y = 250;
}


You should also take a look at the FLA’s in the project to get an uderstanding of how to create the symbols. Note that I use the “com.view.assets” prefix in front of the actual symbol name, if you look in the FLA you’ll find that same prefix on the exported symbol name. If all the symbols that are to be imported at runtime are named in this same way, its much easier to keep them organized. Once the getDefinitionByName method returns, the variables will have references to the MovieClips inside the SWF with the proper name. They are MovieClips and as such can be treated exactly like a MovieClip with no adverse side effects. So there you have it, a simple class for loading multiple SWFs into an actionscript project, and you get to minimize your time spent in Flash CS3.

To import the swc into your project, first move the swc into a folder that won’t get deleted, (I usually make a libs folder on the top level of the project folder). Then just right click on your projects root file, then click on properties. Once the properties window pops up, click on the Actionscript Build Path option.

Then select the library path button at the top. From there, the add swc button should be visible, click it and browse to your swc. Once you’ve successfully linked to the swc you only need to import the right classes to use them:


import com.loaderutil.AssetFinder;
import com.loaderutil.AssetLoader;


There is still the hurdle of how to best organize and manage these symbols once they’ve been imported. Some friends and I have been working on some classes to help optimize that process as well. Once they get to a certain point I’ll add them to the library and post the new source up here.

Why is Adobe attempting to resurrect Director?

Director 11 is on the scene, and I can’t help but wonder why? Why waste time on Director when we have copious amounts of really amazing 3D toolsets for Flash, many of which are nearing maturity to the point where supporting them would make more sense. Some of these people are doing truly amazing things, throw them a bone Adobe! Hardware acceleration already works with Flash through browsers, its worked with Projectors for a long time. If I were Adobe I would pull a page out of Google’s book and hire the creators of Papervision3D and tell them their full time job is to continue to move the platform forward. For web based things, Director is dead. The latest version of the runtime is stuck at 50% in the US. HALF of all people don’t even have Shockwave installed. Why should they? Very little is done on Shockwave. And whats up with all the runtime environments anyways? Flash, AIR, Acrobat and Director? How about rolling some of the key abilities of director into Flash, which is already installed everywhere? For local things, just focus on AIR and hardware acceleration.

In short, I think Adobe should discontinue Director and focus on Flash and AIR. Shockwave in its very nature conflicts with the goals of both Flash and AIR, and is yet another runtime that must be installed on people’s machines. Before Director 11 there hadn’t been an update for years, nobody was doing new Shockwave content online. I think Adobe should hire the creators of Papervision and tell them to further the platform, integrate the Flash player more with Papervision, focus on integrating hardware acceleration and graphics library support into AIR, oh… and let Shockwave stay dead.