Usually I like to post glamorous stuff, like 3D swirly things and experiments. Occasionally, however, I feel the need to release a little code in the interest of helping a few people out. This code is a review of sorts, since I already posted a similar utility back in June. However, since then I have been expanding my code library and I thought I’d share the latest and much improved version. It’s really a simple concept, but having this in my toolbox has lightened my workload as an ActionScripter considerably.

Advantages

This utility allows you to publish any symbol from Flash and access it at runtime from an ActionScript-only project, such as in Flex Builder. This has a few advantages:

• Easy storage of many assets in one file
• Ability to change graphics without recompiling the main application
• Faster load times with only one HTTP request (as opposed to many separate images and sounds)
• Ability to import vector graphics and animations at runtime
• Smaller main SWF size

The one disadvantage that I can think of is that you’ll need to recompile your library SWF every time you make a change. However, I think the advantages above outweigh this.

Differences in v1.5

Here are the main differences from the last version:

• The class is no longer static. This allows for more than one instance of SWFLibrary at a time.
• The class can now return instances of Sprites, MovieClips, and Sounds from a library SWF.

Usage

1 - In Flash, select “Export for ActionScript” in the symbol’s Linkage settings in the Library (ex. ‘Character’).
2 - Publish the Flash file as a SWF.
3 - Load the SWF into an instance of SWFLibrary
4 - Access the symbol through SWFLibrary, using the class name chosen in Step 1.

A SWFLibrary can be used with four lines of code. Here’s what you’ll need:

// creates an instance of SWFLibrary, adds a listener, and loads a SWF
var gameAssets:SWFLibrary = new SWFLibrary
gameAssets.addEventListener( Event.COMPLETE, handleAssetsLoaded );
gameAssets.load( "myCustomGameAssets.swf" );
 
// accesses the asset (assumes there is a symbol exported as 'Character' in the loaded SWF, as seen in step 1 above)
// this code should run after the Event above has fired
var mySprite:Sprite = gameAssets.getSprite( "Character" );
addChild( mySprite );
 
// gets the asset as a MovieClip (assuming, of course, that it actually is a movieclip)
var myMC:MovieClip = gameAssets.getSprite( "Character" );
addChild( myMC );
 
// getting a sound
var mySound:Sound = gameAssets.getSound( "SoundLinkageNameHere" );
mySound.play();
// === ===

After a symbol has been retrieved from SWFLibrary, it may be treated like any other object.

Download

DOWNLOAD SOURCE

So have fun with this. Hopefully it saves you as much time as it saves me.

To explain what this is, and instead of writing something new, I’ll just quote directly directly from the website:

So there you have it. Go take a look and let me know what you think!

I make a lot of decisions daily based on things I think I know, but really have just always assumed. And so, on this bus ride, I decided to get to the bottom of a few of them. The first experiment I tried was with the read and write speeds of Objects, Arrays, and Dictionaries. In the past, I have always used Arrays when I need all the nifty sorting and organization methods, Dictionaries when I need fast access, object keys, or weak references, and Objects pretty much never (because they’re messy and slow). So yesterday I decided to see if my assumptions were actually valid, or if I had been doing things wrong this whole time.

So I set up a quick class to test. I created a Dictionary, an Object, and an Array, and then I put 100,000 integers in each one for the write test, and read them back out for the read test. This is what I got (all times are average and in milliseconds).

Obviously there are many more benchmarks that I could have run, but I also had a pretty good book on that bus. I think I’ve done enough experimentation to prove that, once again, my assumptions are invalid.

This is something simple enough that I hesitate to post it, but maybe someone else can benefit. Plus, I always try to have something new on Mondays. Anyway, this a technique I once used back in the dark ages of ActionScript development (meaning AS2). Last week, however, I suddenly had need of it again.

The Scenario

The AS3 event model is a pretty slick deal- much better than the six different ways we used to do it back in AS2. However, I ran into a spot last week in which it failed me. I had several different components in completely different parts of an application, and I wanted them all to listen to each other. That in itself is no problem. The problem was that I also wanted them to be completely unaware of each other, in hopes of keeping the code a bit more encapsulated. So how does one listen for an event that comes from a source whose very existence is unknown?

Option #1

Option #1 was to make all my events bubble, and have each component add event listeners to some display list parent that all the components shared. This would ensure that everyone got their events, but it makes everyone dependent on the current setup. What if I wanted to move a component elsewhere and now it didn’t share that parent? Plus, it’s not a solution that is guaranteed to work in a different app. Plus, it involves children referencing their parent, which I am against on a fundamental, perhaps even a spiritual level. So, scratch Option #1.

Option #2

Then I thought maybe each component should store a reference to all the other components. But once again, you can throw the whole “loosely-coupled” idea out the window. Something about this solution just didn’t feel right.

Option #3

Option #3 was the old AS2 method of creating a central static Broadcaster class and telling everyone to listen to it. Now the only dependency each component had was to one static communication class. Everything else could change as long as they were listening to the Broadcaster. And so, as my great-grandmother has told me, sometimes the old ways are best.

Source

There’s really not much to explain with this class. The only challenge was making a static class into an EventDispatcher, but that turned out to be pretty easy (thanks to G. Skinner, who originally gave me the idea for a static EventDispatcher). Behold:

/**
 * A central event broadcaster
 *
 * @author	Zack Jordan
 * 			{ P I X E L W E L D E R S . C O M }
 */
package com.pixelwelders.events
{
	import flash.events.Event;
	import flash.events.EventDispatcher;

	public class Broadcaster
	{

		private static var eventDispatcher			: EventDispatcher;

		/**
		 * Broadcasts an event to all listeners
		 * To listen to any and all events, use Broadcaster.addEventListener()
		 *
		 * @param	event		The Event to broadcast
		 * @return				nothing
		 */
		public static function broadcast( event:Event ): void
		{
			dispatchEvent( event );
		}

		// === S T A T I C   E V E N T   D I S P A T C H E R ===
		public static function addEventListener( type:String, listener:Function, useCapture:Boolean=false,
			priority:int=0, useWeakReference:Boolean=true ):void
		{
			if ( !eventDispatcher ) eventDispatcher = new EventDispatcher();
			eventDispatcher.addEventListener( type, listener, useCapture, priority, useWeakReference );
		}

		public static function removeEventListener( type:String, listener:Function, useCapture:Boolean=false ):void
		{
			if ( eventDispatcher ) eventDispatcher.removeEventListener( type, listener, useCapture );
  	    	}

		public static function dispatchEvent( p_event:Event ):void
		{
			if ( eventDispatcher ) eventDispatcher.dispatchEvent( p_event );
		}

	}
}

As you can see, this is just a static wrapper for an instance of EventDispatcher. I just route all the methods of the EventDispatcher to static methods, and voilá. As always, if you can think of a better way, just drop it in the comments.

This is something I’ve begun using recently, and I thought I would post about it to see if I can help anyone else who’s been thinking about this. I’ve seen some other articles on this, but they’ve had some shortcomings that I think I have improved on. Of course, there’s room for tons of improvement on my class as well, so feel free to extend this to your little collective hearts’ content. The source is downloadable at the bottom of the page, or you can continue to the second page of this article to view it all without downloading. Anyway: onward!

The Need

Okay, so: as a Flex developer who does a lot of ActionScript-only projects, I often run into situations in which I need to import some artwork. This artwork may be in any number of formats, and they all require different solutions. However, for a project that I’m working on now (which I would expound upon if it wasn’t [apparently] top-secret), I needed to import hundreds of little images in a vector format. Furthermore, the client hinted that it would be nice, if not mandatory, to be able to swap out images later without sending it back to me for a recompile. So, I had to do a bit of thinking.

However, it turns out that the solution is really not that hard. When working with Flash, there is really only one vector format worth worrying about, and that is SWF. And furthermore, it turns out that there is a kinda slick way to import all the assets contained in a SWF into a Flex ActionScript project. In the following class, I’ve just smoothed the process a little bit.

The Theory

1- Create a MovieClip in Flash CS3 and check Export for ActionScript in its linkage properties. Remember the class name that you give it, because you’re going to need that to pull this asset back out of its mother SWF.

2- Publish your SWF. Make a note of where it’s going so you can load it in Flex.

3- In Flex, set up a Loader with the typical listeners (see my source below for details) and load the SWF.

4- Once the Loader has successfully loaded the SWF, the part you are interested in is the Loader’s contentLoaderInfo property (which is an instance of the LoaderInfo class, if you’d like to check the Flash help files for more information). This property now contains the data from your Flash CS3 SWF. Interestingly enough, a LoaderInfo class contains an instance of the ApplicationDomain class, which in turns contains all class definitions that are contained in that SWF. Since you checked Export for ActionScript on your MovieClip, that means there is a definition for it in the ApplicationDomain of this LoaderInfo. You just need to pull it out and instantiate it.

5- You have to do a little dancing around with types to get your MovieClip back out, since you will be pulling it out as an instance of Class, not as an instance of MovieClip. However, with a couple lines of code, it’s easy enough to actually create an instance of your original Flash CS3-authored MovieClip.

The Code

Here are the vital parts of the code, as seen below in the source download link at the bottom of the page. These are contained in a wrapper class that I wrote that surrounds Loader.contentLoaderInfo.

This is the handler that is called when the Loader successfully loads the SWF. Notice that we save the LoaderInfo (called “contentLoaderInfo”) for later use. This is the package of all the assets we have just imported.

private static function handleLoadComplete( event:Event ): void
{
	loaderInfo = loader.contentLoaderInfo;
	dispatchEvent( new Event( Event.COMPLETE ) );
}

And here is where the real magic happens, and it must be called after the above handler. Notice how we get a real live Sprite instance from the definition in our LoaderInfo instance. Plus, it looks just like the asset you created in Flash at the beginning of this article.

public static function getAsset( id:String ): Sprite
{
	var Asset:Class = loaderInfo.applicationDomain.getDefinition( id ) as Class;			
	return Sprite( new Asset() );
}

Summary

This is as basic as it gets. My source below extends this enough for me to use it in the aforementioned project (as well as adding some basic error handling), but this could be extended for all types of applications. For instance, my class only returns instances of Sprites because that is what I am interested in. However, you could also return the class itself (un-instantiated), or anything that you might find in LoaderInfo.applicationDomain. The possibilities are… well, not limitless. But more than you might think.

Source

The zip contains a RuntimeLibrary class (shown below), an example using it, and some sample assets in a SWF (with the matching FLA so you can see that they are nothing special- just Exported for ActionScript). As you can see, I’m doing some basic error handling, but you may want to do something a little more robust; or, you may want the error. Feel free to change whatever you want- that’s the beauty of open-source!

DOWNLOAD SOURCE

/**
 * A utility to load a SWF at runtime.
 * This makes all definitions in the loaded SWF available.
 * You can use this to load graphics elements created in Flash CS3 into Flex ActionScript projects
 * 
 * @author	Zack Jordan
 * 			{ P I X E L W E L D E R S }
 * 			pixelwelders.com/blog
 */
package com.pixelwelders.graphics
{
	import flash.display.Loader;
	import flash.display.LoaderInfo;
	import flash.display.Sprite;
	import flash.events.ErrorEvent;
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.events.IOErrorEvent;
	import flash.net.URLRequest;
 
	public class RuntimeLibrary extends EventDispatcher
	{
 
		private var request				: URLRequest;
		private var loader				: Loader;
		private var loaderInfo			: LoaderInfo;
 
		/**
		 * Constructor- creates a new RuntimeLibrary
		 * 
		 * @param			nothing
		 * @return			The newly-created RuntimeLibrary 
		 */
		public function RuntimeLibrary()
		{
			request = new URLRequest();
			loader = new Loader();
			loader.contentLoaderInfo.addEventListener( Event.INIT, handleLoadComplete );
			loader.contentLoaderInfo.addEventListener( IOErrorEvent.IO_ERROR, handleIOError );
		}
 
		// === A P I ===
		/**
		 * Loads a swf into this RuntimeLibrary
		 * 
		 * @param	url		the URL of the SWF to load
		 * @return			nothing
		 */
		public function load( url:String ): void
		{
			request.url = url;
			loader.load( request );
		}
 
		/**
		 * Creates and returns an instance of the specified class from the loaded SWF
		 * If the specified class does not exist, dispatches an ErrorEvent and returns an empty Sprite
		 * 
		 * @param	id		Name of the class in the loaded SWF
		 * @return			An instance of the specified class, or an empty Sprite if the class is not found
		 */
		public function getAsset( id:String ): Sprite
		{
			try
			{
				var Asset:Class = loaderInfo.applicationDomain.getDefinition( id ) as Class;
			} catch ( error:ReferenceError )
			{
				trace( "Asset not found." );
				dispatchEvent( new ErrorEvent( ErrorEvent.ERROR ) );
			}
 
			return Asset ? Sprite( new Asset() ) : new Sprite();
		}
 
		// === E V E N T   H A N D L E R S ===
		private function handleLoadComplete( event:Event ): void
		{
			loaderInfo = loader.contentLoaderInfo;
			dispatchEvent( new Event( Event.COMPLETE ) );
		}
 
		private function handleIOError( event:IOErrorEvent ): void
		{
			trace( "load error: " + event.text );
		}
 
	}
}

A) In poker, a card that is the only one of its rank.
B) In animal husbandry, the sole surviving offspring of a litter.
C) In astrology, a single planet alone in a hemisphere (or some crap like that).
D) In mathematics, a set with only one member.
E) In England, a small village about 7 miles north of Chichester in West Sussex.

All of these things share a trait, and that trait is that each is the only one of its kind. If two kittens survive from a litter, neither one is a singleton. If a set has more than one number, it is not a singleton. In works the same way in object-oriented programming; a Singleton is a class that allows only one instance of itself; if there are more than one, that class cannot be a Singleton.

So why would one want a class that only allows one instance of itself? I can think of many applications. A ScoreKeeper class for your game, perhaps, or a Countdown class that keeps track of how much time you have to complete a level. In OS Wars I use a Singleton to keep track of all building resources currently in the game. There’s another one that keeps track of all the units on the battlefield. In fact, the Battlefield itself is a Singleton, because there’s no reason I would ever need more than one.

Another great thing about a Singleton is that, because there is only one, it’s very easy to get to. With a normal object, you have to worry about passing it around to the various classes that might need it. With a Singleton, that’s not necessary. All you need to do is import the class and voilà- there’s your Singleton.

It works this way because the class itself keeps a static reference to the only instance of itself. So instead of calling the constructor to get a reference to a new instance, you call the SingletonClassName.instance method to get a reference to the already-created instance. If that doesn’t make sense, here’s an example. This first piece of code is what a normal ScoreKeeper class would look like. With this structure, you can use that syntax that everyone knows and loves, new ScoreKeeper(), which returns a brand new ScoreKeeper every time it’s called.

package
{
	public class ScoreKeeper
	{
		public function ScoreKeeper()
		{
			trace( "new ScoreKeeper" );
		}
	}
}

But suppose you wanted to ensure that there was only one ScoreKeeper, and you wanted to be able to easily access it from any location in your program. That means two things: A) the constructor can only be called once, and B) you need to keep track of the new ScoreKeeper that one time the constructor does get called. What good is having one instance of a class if you can’t get to it? So here’s the Singleton version of the above class:

package
{
	public class ScoreKeeper
	{
		private static var _instance:ScoreKeeper;
 
		public static function get instance()
		{
			if ( !_instance )
			{
				_instance = new ScoreKeeper();
			}
 
			return _instance;
		}
 
		public function ScoreKeeper()
		{
			trace( "new ScoreKeeper!" );
		}	
	}
}

There are two differences here: the static variable _instance and the static method get instance(). The _instance variable is where the actual instance of this class is stored. And the get instance() method, of course, enables you to access this instance. So to access this Singleton, you would use:

ScoreKeeper.instance;

And to call any methods or properties of the Singleton, you would use this syntax:

ScoreKeeper.instance.addScore( 50 );
trace( ScoreKeeper.instance.score );

This of course assumes that your class has a public method called addScore() and a public property called score. You can get to any public methods or properties this way.

This also adds one more layer, called lazy initialization. Look in the get instance() method, and notice that before it returns a reference to the Singleton, it checks to see if that reference exists. If so, it simply returns it. If not, it creates it first and then returns it. Either way, you’re guaranteed to get the one existing instance.

There is one problem remaining- if you were so inclined, you could still call the constructor without going through get instance(), which would of course result in two Singletons. And as we discussed above, making two of something makes it not a Singleton anymore. So how can we prevent this? There are a few ways I’ve seen floating around, but the simplest is this:

package
{
	public class ScoreKeeper
	{
		private static var _instance:ScoreKeeper;
 
		public static function get instance()
		{
			if ( !_instance )
			{
				_instance = new ScoreKeeper();
			}
 
			return _instance;
		}
 
		public function ScoreKeeper()
		{
			if ( _instance )
			{
				throw new Error( "Singleton already exists- use get instance() to access" );
			} else {
				trace( "new ScoreKeeper!" );
			}
		}	
	}
}

The new lines are in the constructor. The get instance() method still only calls the constructor once, but if you forget it’s a Singleton and call the constructor later, you get a runtime error.

There are also a couple more complicated ways of ensuring that your Singleton is in fact a Singleton, but I haven’t lost too much sleep over over it. I usually even leave out the check in the constructor. Just remember that if it has _instance and get instance(), and a big comment up at the top that says “SINGLETON!”, it’s probably a Singleton.

I want to tell you a story about a man- a desperate man. We’ll call him Ted. Ted was a graphic designer who was just getting into Flash, and so he took a freelance job with a local Flash development house to put his new skills to use. This company tasked him with creating a fun little app that allowed the user to customize a car image. The user, they said, should be able to add logos, spoilers, “dubs,” etc. and then download his/her fantastic creation as a wallpaper. In fact, they continued, we’ve already finished the layout and the car images- here’s an FLA and a zip of all 170 possible combinations.

At this point, many developers are already putting this app together in their own minds. Twenty lines of code, maybe a splash of XML, a big image directory- call it a day. That is, in fact, what the development company expected. However, the days turned to weeks and Ted had not turned in his project. Phone calls became less frequent and more harried. Finally, hours before deadline, Ted emailed a link to the project. It loaded a bit more slowly than anticipated, but it was assumed that it was just because of the size of the graphics. Which, as we were to find, it was.

However, the client soon decided that a small change was needed. Because of the rather lengthy turnaround time with Ted (who was now slogging through another project), the development company gave it to an in-house guy this time, who was confident that he could make the change in a half hour. How complicated could an app like that possibly be? He downloaded Ted’s source from the development server and opened it… and that part of his soul that every human is born with, that sings because the Earth is beautiful and its people are good- that part died within him.

The source files bore the unmistakable mark of a madman, drunk with desperation. The project contained one hundred seventy keyframes, each containing one of the car images. To view one image, in other words, required downloading its 169 siblings as well. Furthermore, each keyframe held five buttons for adding the various options to the car. Five completely new instances per keyframe, each with a unique instance name (redSpoiler155_btn, redSpoiler156_btn, etc.). Furthermore, each of the five buttons had a variant of the following code attached directly to it:

on(release){gotoAndStop(51)}

170 x 5 = 850 identical lines of code. In 170 unlabeled keyframes. Attached to 850 separate and unique button instances. In a project with 170 wallpaper-sized images that, when compiled, produced a 20MB SWF. The reason neither the development house or the client noticed the download time was because they were operating on A) industrial-strength Internet connections and B) the assumption that the freelancer hired was not a complete sociopath.

To be fair, we all know what happened. The guy had gained a couple skills and went with what he knew, rather than doing a ten-minute Google search, without ever thinking seriously, there has to be a better way. Nonetheless, the second his “techniques” came to light, the development house called him to request that he invoice them immediately and go work for someone else.

They say on certain nights, when the moon is full, you can still hear the feverish and half-insane clicking of a man attaching code to onstage objects.