Now that you’ve been through 3 exhaustive tutorials on ant for flex, it’s time to use your knowledge you’ve gained to turn your back on the built-in Flex compiler and switch to ant for your builds. This part applies to FlexBuilder (and FlashBuilder) users only although it may apply if you’re using some other eclipse-based plugin. If you’re using another program like TextMate or Flash CSx, you can skip this article.

Replacing the default builder with your ant tasks

The rest of this article will show you how to use your ant build script to perform the building actions found in FlashBuilder.

In FlashBuilder, the following building actions can be executed

• Build Project – Occurs when the user manually builds the project.
• Build Automatically – When the option is checked in the Project menu, the code is automatically build when you save a file. Usually incrementally.
• Clean – ‘cleans’ the project folder by doing a complete, non-incremental build and removing temporary files.

These actions are all called by various actions and handled by one or more builders. In terms of the eclipse SDK, a builder is an XML file that describes how the various build actions will be executed. In FlashBuilder, all of these are set up to use the Flex “builder” by default. You can add new customized builders to supplement these build actions. You can also deactivate the default builder an just use your ant builds instead but you will lose the ability to see inline errors in your code.

In order for this to work however, you need to start out with some solid, well-tested ant tasks.

Step 1 – Create the appropriate ant targets

Create a target in your build.xml for each of the actions listed above. Call each target “build”, “autoBuild”, and “clean”. You can probably start with the “build” target and reuse it for the other two. To write an incremental build target (used for the build-automatically action) there is an example in Part 2 of this article.

Before moving on, please test your build script thoroughly to be sure there are no errors and that your files are compiling correctly.

Note, I’m not going to go into the details here about exactly how to write your ant script. If you’re considering switching to ant as your primary builder then A) your project has special needs that need to be addressed by a custom build script and I don’t know what those needs are and B) you need to know what you’re doing with ant before completely abandoning FlashBuilder’s defaults. I will say, save the fancy stuff for your release build targets and do incremental builds by default since you’ll be running these scripts quite a lot.

Step 2 – Create a builder for your ant build script

1. Open the properties for the project you want to edit. Project -> Properties
2. Select the Builders item in the left menu. You will see that the default builder “Flex” is already set up.
3. Click the New… button. A dialog will come up with templates for the new builder.
4. Choose the “Program” type. (On my configuration, I see an option for “Ant Builder” also which is what I should probably be using, however, I haven’t gotten it to work yet and it doesn’t seem to generate any specific errors when it fails so I gave up and went with Program. If you know how to fix this, let me know!)
5. Name the builder “flexAntBuilder”
6. Set the location field to the ant binary you’re using. If you’re not sure where the binary is located, you can use the command which ant in the command line. Mine is at /usr/bin/ant
7. Set the Working directory to your project’s home directory. If you’re not sure, browse to it.
8. In the arguments field, enter the name of the target you want to run. In this case build.
9. Optional: Click on the Refresh tab. Here you can chose whether to refresh the files in your workspace when the build completes.
10. Click on the Build Options tab. Here, under the “Run the Builder:” heading near the bottom, is where you’re going to set the properties that determine when this particular task is run. For the ‘build’ target, uncheck everything except “During Manual Builds”.
    • For your “autoBuild” target, you’re going to uncheck everything except “During auto builds”
    • For your “clean” target, you’re going to uncheck everything except “After a clean”
11. Repeat steps 1-10 for the other two targets.
12. When all targets are added, optionally uncheck the “flex” builder from the builders menu in your project properties to use the ant tasks exclusively. Now your ant scripts will be used instead of the flex builder.

That’s it! Be sure to test things and make sure you’re not getting any errors.

What to expect from here

So you’ve unchained yourself from the system and are using your ant scripts to build your project. Congratulations, you’re a huge nerd! From this point on, changing the compile settings in the Project Properties dialog (like the build path) may be ineffective. You’ll need to make changes to your build path in the ant file.

The results from your builds will appear in the Console view. Here you can see the progress of builds and check for errors in the code. As I mentioned before, if you deactivate the flex builder you won’t get inline errors in your code any longer.

Finally, adding the new builders will create a new invisible folder in your project’s root folder called .externalToolBuilders where your builder definitions will be kept. You don’t need to do anything with this folder, but be aware that it’s there.

That concludes this 4 part epic post about ant tasks for flex! I hope you found it useful. If you have anything to add, please post comments!

This third installment talks about tips and tricks for using ant with version control systems.

Defining external properties for each user

Since not everyone’s machine is the same and letting everyone build a project is a major reason to use ant, it’s good to avoid hard coding paths to files within your build.xml file. As such, I use a lot of <property> tags to set up paths and such. But you also don’t want to have several people constantly editing your build.xml because it could get broken or out of sync. Oh no! What do we do!?

Luckily, ant lets you define a set of properties in an external file. This is a simple text file containing name=value pairs and commented using #. By default, the recommended filename is build.properties. Here’s an example:

build.properties and version control

If you’re working with multiple people, you are probably using a version control system like svn. If you are and you want to avoid people accidentally checking in a build.properties file there are a couple of simple tricks. First, create a copy of build.properties and call it built.properties.template and check that into the repository. Then each user can make a local copy called build.properties. You can also add build.properties to the ignore list for your folder using SVN so that noone will accidentally check it in. Run svn pe svn:ignore and add build.properties to the list. Finally, if you need to make sure that your users have a local copy of build.properties, there’s a task for that!™

Adding SVN tasks

As I work with SVN quite a lot, I found that including SVN in my builds can be quite useful. For example you could:

• Update your working copy when doing a clean build.
• Check in a release build automatically.
• Export your source code without those pesky .svn files to be included in a zip file.
• Include the revision number of the working copy as a constant definition in the code using conditional compiliation.

To do this, you’ll need to first download the SVN tasks for ant. They can be found on the Tigris.org website. Please note, that these tasks are a part of SubClipse, which is a free interface for working with Subversion from within Eclipse. I don’t know if the tasks will work without subclispe, but if you haven’t used it, I’d definitely recommend trying it out anyway. By the way, if you use CVS, there are already tasks included in ant. Once they’re downloaded, add the task .jars to the libs/ant folder in your project. You’ll need to use another <typedef> tag in your build script to get these to work. Here’s an example snippet that simply runs an update on the working copy. You can see all the available commands in the svnant documentation.

That’s it for part 3. In Part 4, I’ll talk about setting up a builder for your ant file in FlashBuilder.

In this part, I get more nitty-gritty about working with flex’s ant tasks.

Using the flex ant tasks

I spent quite a lot of time making tweaks to get my scripts to use the Flex tasks and hopefully, now you won’t have to. In the end, there’s very little benefit to using the official Flex ant tasks over using a generic <exec> task (a type of ant task that simply runs an executable file with nested <arg> tags for command line arguments) and if you’re having trouble with them, I’d recommend abandoning the flex tasks and using $lt;exec>. The main thing I had trouble with was getting the <taskdef> tag to work correctly.

For those new to ant, a <taskdef> tag is a required tag that defines a third-party ant task within the build.xml file. It associates a task name with a .jar file (compiled from the java code for the task). In the case of flex tasks, the java file is typically located within your flexbuilder sdk directory. On my mac, that’s here:

/Applications/Adobe\ Flash\ Builder\ Plug-in\ Beta\ 2/sdks/${SDK_VERSION}/ant/lib

Where ${SDK_VERSION} is your target sdk version (e.g. 4.0.0). There are a few ways to load additional tasks into your build.xml file. All of them require you to reference the .jar’s location somehow and then define a new task using <taskdef>.

1. Copy the .jar file for the task into ant’s lib directory. I don’t personally like this option because it makes it very difficult to switch between different versions of the sdk. Also, it requires all users of the script to copy the files on their local machines. (You can also add it to ~/.ant/lib to control the libraries on a user level)
2. Reference the .jar file’s location using a command line argument -lib. Even worse than the first option since it requires each user to add the library manually every time the build script is run.
3. Include the .jar’s location inside the build script. It took me a long time to figure this one out since I didn’t see it in the manual for ant, but it’s certainly my preferred method for adding tasks. It allows you to keep everything self contained within the build.xml so changing the location of the .jar is as simple as setting a property in the build script.

When using the 3rd option, you then have the question of where is the best place to put the .jar files you want to link to. There are two options that make sense to me.

1. The best place to put non-core tasks required by your build (for a Flex project) is in ${project_home}/libs/ant. This allows you to check your tasks into a repository along with your other referenced files (like .swc files).
2. Optionally, for the flex tasks you could reference the .jar file directly in the sdk folder. Use this option if the version number of the SDK doesn’t matter. If it does matter, use the first option. I use this option in my snippet below.

Linking to the official Flex ant tasks

Here’s a sample of my flex task definition along with some path definitions that point to various parts of Flex. I said this was a no B.S. guide so if you paste this snippet into your build script, you should be able to use the Flex tasks.

Using the tasks

Now we have the <typedef> in place and we can actually create a task to compile something. Again, I’m not going to go into all the details of what targets are all about or go into all the details about the flex compilers. There are plenty of other tutorials about that. Instead, I’ll show you a basic target to build an mxml file that is adequate for 95% of projects. Note: you may need to edit the properties defined in these scripts so that they point to the right paths for your project.

The toughest part about using these tasks is the seemingly arbitrary words that they expect for the attribute names of some tags (like using path-element in the <source-path> tag but dir in the <library-path> tag). Now the same but this time building a library SWC.

Making an incremental build

By default, FlexBuilder uses incremental builds when compiling your source code (except for clean builds). This is a very useful feature of the compiler because it saves time by only compiling the parts of your code that have changed since the last build. You can create an incremental build simply using ant by defining a second task that adds a flag for incremental building like so. Note that allows you to run other targets from within a target.

What about ASDocs?

Even though there are tasks for asc, compc, mxmlc, and generating HTML wrappers, they didn’t bother to include an asdoc task (actually, they did in Flex SDK 4.0.0). But that’s okay! As I hinted at earlier, you can still use the task to run this (as you can for all the other commands) and not only that, it’s way easier to set up than the official flex tasks! In fact, the only reason that I can think of to use the flex tasks is that they would automatically use the windows or mac version of the executable depending on your platform. Here’s an example for asdoc.

That concludes part 2. In Part 3, I’ll talk about working with version control systems in ant.

After spending hours wrangling with my ant build script and finally making everything work correctly, I am convinced of two things:

1. ant is a very powerful tool for compiling code but it can also do so much more.
2. The support for ant for flex online is abysmally frustrating.

So, I’d love to share with you some of the tips I’ve picked up after tweaking my script to the point where it finally worked!

Introducing ant

First of all, let me introduce the basics of what ant is. I couldn’t really say it better than the thousands of nameless editors of WikiPedia.

Apache Ant is a software tool for automating software build processes. It is similar to Make but is implemented using the Java language, requires the Java platform, and is best suited to building Java projects.

The most immediately noticeable difference between Ant and Make is that Ant uses XML to describe the build process and its dependencies, whereas Make has its Makefile format. By default the XML file is named build.xml.

Ant is an Apache project. It is open source software, and is released under the Apache Software License.

So in short, ant lets you use an XML based script to run a series of commands typically used to build software projects. It was originally designed to be “for Java, in Java” but it’s popularity and ease of use has created interest beyond the Java community. For flex, ant can be used for compiling ActionScript and Flex projects into SWFs, creating SWC files, generating documentation with ASDocs, and other actions associated with compiling.

There are a lot of great tutorials online that can cover the basics of how ant works so I’m not going to go into a general overview in this article. Instead, I’m going to try to focus on some of the practical aspects of getting a build set up when working with Flex. However, here are some links to the official ant documentation some helpful tutorials for the basics:

Ant Basics tutorial

Another basics tutorial (this time for Flex)

Official Flex documentations

Ant Folklore

After the jump, I’ll get into some of the ways that ant can be useful for Flash and Flex projects.

Applications for Flex users

Is ant right for you? It depends. For most cases, using the standard Run and Debug functions in FlashBuilder or Flash will be completely sufficient. However, if you work on a large development team or on a project with a complicated build process, it might save the group a lot of headache. Here’s a list of situations where I think Flex ant tasks can be helpful.

• Whenever your project requires you to make adjustments to the standard build process. For example, when you need to add additional flags to your compiler string.
• For Flex projects that are distributed widely, e.g. open source projects, where the configuration of the users’ dev environment is unknown. Build scripts allow users of various versions of FlexBuilder, FDT, or Flex SDK users on different operating systems to all be able to compile a project with more or less the same settings.
• If running or building your project requires you to configure options in the command line or to run a local server.
• For building release versions of an app and for deploying your app. For example, compiling, zipping and copying an app to a server using FTP.
• When you’re a total nerd and you want to use ant just so you can say you did it.

Beyond Compiling

One of the main benefits of using ant is that I think many people are unaware of is that it can be used for many things beyond running compilers. For example, in KitchenSync, I use a build script to create a temp folder, compile a SWC file into the temp folder, create an SVN export of the source folder into the temp folder, zip the source and SWC and name it with the current version number, then delete the temp folder.

There are loads of core tasks that are already defined within the ant library. They handle all types of common actions in the command line. There are even additional optional tasks that add higher-level functionality like copying files to a server using SSH or validating an XML file. Finally, additional tasks can be added simply by creating a new Java class that is a subclass of org.apache.tools.ant.Task. You probably won’t do this yourself, but there are a number of third-party programs that have created ‘plug-in’ tasks for ant such as SVN.

Once Flex projects became larger and more complex, many users began to look for more customizable options and began using ant. A couple of years back, Adobe released some official ant tasks which can now be found bundled in every version of the Flex SDK. However, as I said before the documentation of exactly how to get these tasks running is vague at best.

In part 2, I’ll talk about the details of getting flex ant tasks running.

• Part 1
• Part 2
• Part 3
• Part 4

XML-Schema (.XSD extension) are documents used to describe the format of XML files. They are similar to DTD (Document type declaration) files but much more powerful.

While working on some XML documents for a Flash site, I stumbled across the XML-Schema editor for Eclipse. The editor shows the XSD as a graphical representation of the model that you’re editing that looks similar to a UML class diagram.

Here’s a great article on how it works.

Benefits of using XSD

As I said, XSD allows you to define the format of your XML document but with much more detail that DTD.

• XSD allows you to type your data (integers, strings, booleans) so that you can better predict what format the xml will be
• It allows the creation of custom types which gives it an object oriented aspect
• You can use all kinds of restrictions for what kind of content can appear within a tag including the number of elements, whether values are required or not, you can even use regular expressions to limit the acceptable values. This is very nice when you’re working with a 3rd party who is generating the XML data.
• Using an XSD file can allow you to automate the validation of an XML file’s format

Once you’ve created your XSD file, you can use the new XML document wizard to create an XML file that links to your schema file. The wizard will automatically populate the XML document with valid data! Furthermore, as you edit the XML file you will get warnings and errors if you go outside the formatting requirements defined in the XSD. For example, if you define a tag <description> as having a maximum length of 128, you will see a visual error if your tag contains more than 128 characters. It’s a great way to forsee problems as you write them.

I hope in the future to write some kind of tool to parse XML based on an XSD file in flash. Apparently, Adobe had created an undocumented Flex feature to validate XML against XSD. Via Misprintt

Installing the XML extensions

Unfortunately, the editor is not installed by default and nstalling software in Eclipse is not very intuitive. I’ve done my best to describe the process here but if you need further help, check this entry.

1. Open Eclipse or FlexBuilder
2. Go to Help>Software Updates… ( > Find and Install for Eclipse 3.3)
   
3. Make sure you have the Europa or Ganymede update sites in the list of update sites:

   Eclipse 3.4 users:
   http://download.eclipse.org/releases/ganymede/
   
   http://download.eclipse.org/releases/europa/site.xml

4. Select the XML and XSD extensions in this screenshot. In Eclipse 3.4 you can search for them, in 3.3 you will have to look through the packages for them manually.
5. Restart Eclipse after the install is complete

Before I begin, I must stress to you, if there is any way you can avoid downgrading your code, you should avoid it! If it’s a matter of making two systems communicate, there are countless reasons that it would be better to upgrade your code from AS2 to AS3. There are even ways to host your AS2 code in an AS3 wrapper. In my case, an important requirement (that the deliverable absolutely must be AS2) was left out of the original scope of work due to a misunderstanding but anything that doesn’t cause project stoppage should be considered carefully.

I must also preface this article by reminding the reader that there is no 1-to-1 conversion from AS3 to AS2 (nor the other way around). There are loads of features added to Flash Player 9 that simply don’t exist in Player 8. Some things you’ll be able to convert with a simple find and replace. Some things you’ll need to re-create in AS2 or re-think completely. Some things you just won’t be able to do. This article only covers the stuff I ran across while converting my files and is by no means comprehensive. However, I hope it gives you a good starting point to work from.

Converting the document class

Since you’re a smart, cool AS3 programmer with a good sense of humour, I know you use a document class in your FLA files or a main application class for your FlexBuilder project. Right? Good. Of course, AS2 does not support document classes and all code must be run from the timeline. You have a couple of options here. You could move your document class to the timeline and remove the class specific portions of the code. Perhaps a quicker and easier solution is to modify your document class to take a reference to the root. So you have something like this on the first frame…

var documentClass:MyDocumentClass = new MyDocumentClass(this);

Just keep in mind that your document class will need to store a reference to the root that’s passed in as well as make references to things that were on the stage. For example…

public function MyDocumentClass(mc:MovieClip) {
   this._mc = mc;
   this.thingOnStage = _mc.thingOnStage;
}

Cleaning up syntax errors

The first step to take once you can compile your code is to run it and fix each compile time error one at a time. To save you the trouble of some of the more common ones I found, I created this list of common syntax problems.

Search and replace:

• void -> Void
• int and uint -> Number
• DisplayObject, DisplayObjectContainer, Sprite -> MovieClip
• public class -> class
• internal -> public
• protected -> private
• override -> (nothing)
• mouseEnabled -> enabled
• [obj] as [type] -> [type]([obj])
• [obj] is [type] -> [obj] instanceof [type]
• const -> var (or optionally, to implicit getter)
• Add underscores before MovieClip variables. e.g.: x, scaleY, alpha -> _x, _yscale, _alpha including:
  • alpha -> _alpha
  • x,y -> _x, _y
  • scaleX,Y -> _xscale, _yscale
  • mouseX,Y -> _xmouse, _ymouse
  • visible -> _visible
  • currentFrame -> _currentFrame
  • totalFrames -> _totalframes

Add:

• import statements for classes within the same package (not required in AS3)

Remove:

• import statements for AS3 packages (e.g. flash.display.* )

Convert:

• _xscale, _yscale, _alpha – Convert from decimal to integer (0.2 becomes 20).
• Convert Timer to setInterval
• Convert Loader to MovieClipLoader
• Remove package declaration but copy the package name and put it before the class name. Also remove closing } from the end of the file.
  e.g. :

  package com.mysite.package {
  	public class Foo {
  	 	//...
  	}
  }

  becomes

  class com.mysite.package.Foo {
  
  	//...
  
  }

Other tips

Events are a huge part of AS3 development and Player 9 supports a fully event-driven development style. Unfortunately, AS2 is heavily lacking in this department and while events can be recreated in AS2, it lacks method closures and bubbling that make AS3 so nice. To downgrade, I did two things. First, I recreated the event dispatcher in as2 and second, I made heavy use of event callbacks and the Delegate class.

com.mimswright.events

In order to change as little of the event code as possible, I looked back to previous AS2 projects where I had used Danny Patterson’s EventBroadcaster classes. These classes worked roughly the same as the EventDispatcher class in AS3. I took the liberty of brushing up the code and making it look as much like the AS3 EventDispatcher as I could. I’m making it freely available for use.

as2eventdispatcher

event callbacks

Most of the events you’ll probably be using must be triggered by callbacks in AS2. That is, you define a function that gets called when an event takes place like

onMouseMove = function ():Void {
   //do something
}

Keep in mind that in AS2 there are no method closures as there are in AS3. That is, a function isn’t necessarily executed in the scope that it exists in. In even simpler terms, a function doesn’t know what object it’s associated with. Because of this, code such as button.onRelease = object.handleClick; executes the handleClick function from the button context and my not work properly. Fortunately, AS2 code can make use of the mx.utils.Delegate class – specifically, the Delegate.create() method. This artificially maintains the context in which the function was supposed to be called. So your code should look like button.onRelease = mx.utils.Delegate.create(object, object.handleClick);

I hope this has been a helpful start for you poor souls who are faced with the challenge of down-converting code. Good luck to you and feel free to add your experiences to the comments.

This version check is very simple. It checks a version number in the client code against a version number of the library (or external classes) when the main class of the library is initialized. It is also completely optional (so average users don’t need to mark up their code with version numbers).

Here’s an example:

Say you normally initialize your library using:

MyLibrary.initialize();

Which calls the initialize method:

public static function initialize():void {
   // initialize library here
}

If the external code changes unexpectedly (say through an SVN update) this could cause problems that are difficult to trace. The solution is to modify the initializer to match the client code version with the initializer version.

public static const VERSION:String = "1.6";
public static function initialize(versionCheck:String = VERSION):void {
   if (versionCheck != VERSION) {
       throw new Error ("The version check failed! This library is version " + VERSION + ". Update your code or GTFO!");
   }
   // initialize library here
}

And when you run the initializer, use the version number you’re expecting.

MyLibrary.initialize("1.6");

Some things to notice with this approach:

• I used a string instead of a number for the version number so that it would allow for sub-sub version numbers and other markers, e.g. “1.6.24 beta r545″
• Because there is a default value for versionCheck in the initializer, providing a version number is optional. Using MyLibrary.initialize() will still work and throw no errors.
• Unfortunately, there is not much you can do if the version numbers don’t match except to warn the client that the external code has changed. Still, I’ve found this to be very useful.

The code for my initializer in its entirety after the jump…

From KitchenSync.as

/**
* The current version of the library. Use this to verify that the library is the
* version that your software expects.
*/
public static const VERSION:String = "1.6";

/**
* Flag noting whether the engine has been initialized.
*/
private static var _initialized:Boolean = false;

/**
* Initializes the timing core for KitchenSync. Must be called before using any actions.
*
* @param frameRateSeed must be a DisplayObject that is added to the display list.
* @param versionCheck a string for the version you think you're using. e.g. 1.2 This is recommended
*                                         but not required. It will throw an error if you're using the wrong version of KS.
*/
public static function initialize(frameRateSeed:DisplayObject, versionCheck:String = VERSION):void
{       

	if (_initialized) {
		throw new IllegalOperationError("KitchenSync has already been initialized.");
	}
	if (versionCheck != VERSION) {
		throw new Error ("Version check failed. Please update to the correct version or to continue using this version (at your own risk) put the initialize() method inside a try{} block.");
	}

	// Initialization code omitted

	_initialized = true;
}

You’re having an awesome birthday bash and you send out an email to all your closest friends… that is, all your closest friends except ‘Ed’. Now you’re faced with the embarrassing situation of having to invite your friend Ed post-invitum. But don’t fret, here’s a simple solution that will save you loads of embarrassment!

Go from to

Step 1. Find the original email

Did you send a copy to yourself? Good! If not, check your sent folder. Not there? Ask your mom to forward the invite back to you.

Step 2. Forward to yourself and BCC your friend.

Click on the forward button. This time send it to yourself! In the BCC field put the name of the person (or people) you forgot. BCC stands for “blind carbon copy” and the names on this list won’t be listed so they’ll ony see your name listed.

Step 3. Delete “fwd:” from the subject line.

That’s a dead giveaway that you’re a loser and a fuck-up who doesn’t care about his friends.

Step 4. Remove the quote formatting.

You know the blue line that runs down the left side of the text that you’re forwarding? That’s the quote formatting. It may also appear as a “>” or some other symbol. Taking that stuff out is the last step in making your email look fresh.

If you’re using Mac Mail, just highlight the quoted text and press Command + Option + ‘ (apostrophe) until the blue line disappears.

Also make sure you remove the text that says “Begin forwarded message:”! Duh!

Step 5. Make sure it looks right and send!

If done properly, your email will look exactly like a brand new email and your friend will never know that you don’t really like them that much!

Take this FLA animation.

As you can see, there is a simple animation using a guide layer and labels on the key frames.

The following SWF uses KitchenSync to control the same ball animation. As you can see, the duration and easing functions of the animation can be controlled. You can even animate backwards!

See it in action.

The source that controls this is here.

package {
	import flash.display.MovieClip;

	import org.as3lib.kitchensync.KitchenSync;
	import org.as3lib.kitchensync.action.*;
	import org.as3lib.kitchensync.action.tweentarget.*;
	import org.as3lib.kitchensync.easing.Bounce;
	import org.as3lib.kitchensync.easing.Cubic;
	import org.as3lib.kitchensync.easing.Linear;
	import org.as3lib.kitchensync.easing.Oscillate;

	/**
	*	Demos the TimelineController which controls the animation of a MovieClip's timeline.
	*/
	public class FlashIntegrationTest extends MovieClip
	{
		protected var test1:MovieClip;

		public function FlashIntegrationTest()
		{
			super();
			// initialize kitchensync.
			KitchenSync.initialize(this, "1.5");

			// add a movieclip from the library
			test1 = MovieClip(new AnimationTest1());
			addChild(test1);

			// define the start and end frame with strings or ints or FrameLabel's
			var startLabel:* = "start";
			var endLabel:* = "end";

			// set up the TimelineController tween target.
			var tweenTarget:TimelineController = new TimelineController(test1, startLabel, endLabel);
			// Animate the ball with a linear ease.
			var tween:KSTween = KSTween.newWithTweenTarget(tweenTarget, "1s", 0, Linear.ease);

			// animate the ball backwards with a bounce tween
			var tween2:KSTween = tween.cloneReversed();
			tween2.duration = "4s";
			tween2.easingFunction = Bounce.easeOut;
			tween2.addTrigger(tween);

			// animate the ball with an oscillator
			var tween3:KSTween = KSTween.newWithTweenTarget(tweenTarget, "10m", "1s", Oscillate.sine);
			tween3.easingMod1 = 0.3;
			tween3.addTrigger(tween2);

			// start the animations
			tween.start();
		}

	}
}

Pretty cool huh? We’re creating a new TimelineController and setting the boundaries of the animation then passing it to a new KSTween object. Each of the three tweens use different parameters and are triggered by the end of the one before it.

You can download the entire thing and play around with it.

Part The First, In Which There is Much Hemming and Hawing

First, allow me a word of philosophical introduction. None of these concepts is very complicated, and even if you’re unfamiliar with the terminology, you are likely to have programmed something similar to them yourself. However, ingesting them conceptually and being able to use them in an encapsulated way makes code you write more high-level, and thus more powerful and more succinct, and to me, more beautiful. For any given programming language, some concepts are encoded in the language itself, but all other concepts must be built on top of the language. For example, the idea of objects is built into ActionScript 3.0 with keywords like new and class, but a concept like a loading queue is built using the language. For every language there is a line where this distinction is drawn, making for interesting languages like JavaScript where you are free to simulate Object Oriented programming in your own way with your own syntax by using closures. However, there is no Turing complete language – which is to say, no language you’re likely to use on a computer – for which there is a line defining things you simply cannot build. And the point here is that the distinction between things the language provides and things you build yourself is only the syntax, and how it runs. Furthermore, perhaps I am biased to say so, but I believe that OOP gives us fairly good syntax with which to define our own ways of doing things. What I’m coming to here, is that you can make a language smarter – and make it look natural doing it – and in this I take great joy.

So we come to my series of topics for some intermediate computer science topics. My articles have this in common: They cover features that could have been in the language, but since they aren’t, we can create our own versions which are no less, or only slightly less, useable and readable. By encapsulating these concepts in objects rather than solving them differently in different places, we are freed from again thinking of that specific problem, and code which relies on the concept becomes beautifully concise.

If you are a student of design patterns, you may well read this introduction and think that I will be writing a series of articles on patterns. However, I am reluctant to call these topics patterns. Perhaps this is because their use was understood far before patterns, or because I learned of them far before patterns. Or perhaps it has something to do with the fact that you can build these structures once and use them, so that they are more like utilities. However, if you want to call them patterns, go ahead. I think patterns serve the same purpose. They are ways to organize ideas in a higher level than the syntax of the language itself; and indeed some languages have no need for some patterns because the pattern is behind that invisible line of “things you can do inside the language.”

So, You Mentioned Semaphores…

At any rate, today’s topic is the humble semaphore. Semaphore is one of those glorious Computer Science words that makes me feel good about having spent 4 years at a prestigious university. Actually there are two categories of such words: inscrutable names for simple things, and inscrutable names for quite difficult things. Semaphore is one of the former. (NP-Complete is one of the latter.)

A semaphore in CS-speak is just a lock. Let’s not forget that semaphores are also signals made with flags in two arms to transmit information at a distance. It’s quite probable that the original meaning inspired the name for a lock, so let’s use it as an analogy.

These objects are quite old and venerable, because once our hardware and software was slow and not quite so parallel as it is now, and we used locks as a solution. Let’s say you have an old 15MB hard drive in your computer. Process A wants to write some data to the disk. Process B also wants to write some data to the disk. With nobody watching, they both go ahead and start writing merrily away. If you’re lucky, everything goes fine. If you’re not, they both end up writing to the same spot on the disk and one, or both, gets hosed. So venerable old operating systems put in a gatekeeper, and that’s your semaphore. Instead of saying

disk.write();

You now check with the gatekeeper.

while (disk.isLocked())
{
	wait();
}
disk.lock();
disk.write();
disk.unlock();

Okay, so in our imaginations let’s picture a little man with bronzed skin and zinc on his nose, sitting on his tall chair on the disk, and he signals by crossing his arms with two flags: “Sorry buddy, disk is closed for business right now. Some other fella is using it.” You check up later and he traces out the path of a circle, one hemisphere with each arm, from top to bottom: “Coast is clear, go ahead!” I guess semaphore kinda works as an analogy. But it’s really just easier to call it a lock.

No matter what you call it, a semaphore has only one purpose: prevent concurrent access.

What Are They Good For?

Thankfully we don’t have to lock down the entire disk when we’re writing data nowadays, though the physical limitations of the device really do prevent us from writing two bits of data to two locations at the same time. Operating systems are smarter than this now and will do all the queueing, and indeed often journaling, of disk writes for you.

However, we run into plenty of other situations where we still lock things down unequivocally while in use. For instance, some tools will lock a database from being accessed while writing to it.

You might want to use a semaphore for…

1. preventing actions which interfere with a process in motion
2. objects that can’t be used by two simultaneous clients
3. processes that take multiple steps over a period of time

And here’s the thing… they’re pretty useful in websites too. I usually want to prevent any kind of navigations when a transition is in progress, or when the next section is loading. You want to prevent input into a form while a form is submitting. Because web programming is so event-driven, asynchronous, and animation-heavy, it often makes sense to lock actions or objects for a short period of time.

Does It Really Need Its Own Class?

But wouldn’t a simple “locked” member variable do the trick, you might ask? Well, you can do it that way, but you can also add some useful features to the basic implementation of a semaphore and suddenly it becomes a lot more powerful. For instance, you could allow multiple reservations. You could track who has a reservation on the shared resource. You could broadcast an event when an object becomes available or unavailable. Here I will present two implementations of a semaphore. First, the abstract base class, so that we can use either implementation at our will.

Abstract Semaphore

package com.partlyhuman.semaphore
{
	import flash.events.EventDispatcher;

	[Event(type="com.partlyhuman.semaphore.SemaphoreEvent", name="available")]
	[Event(type="com.partlyhuman.semaphore.SemaphoreEvent", name="unavailable")]
	public class Semaphore extends EventDispatcher
	{
		protected var _description:String;
		public function get description():String {return _description;}

		protected var _owner:Object;
		public function get owner():Object {return _owner;}

		public function Semaphore(owner:Object = null, description:String = null)
		{
			_owner = owner;
			_description = description;
			initialize();
		}

		protected function initialize():void
		{
			throw new Error("Abstract Method");
		}

		public function get locks():int
		{
			throw new Error("Abstract Method");
			return 0;
		}

		public function get isLocked():Boolean
		{
			throw new Error("Abstract Method");
			return false;
		}

		override public function toString():String
		{
			return "[Semaphore " + description + "]";
		}
	}
}

And the semaphore events,

package com.partlyhuman.semaphore
{
	import flash.events.Event;

	public class SemaphoreEvent extends Event
	{
		public static const AVAILABLE:String = "semaphoreAvailable";
		public static const UNAVAILABLE:String = "semaphoreUnavailable";

		public function SemaphoreEvent(type:String, bubbles:Boolean=false, cancelable:Boolean=false)
		{
			super(type, bubbles, cancelable);
		}

	}
}

A Basic Implementation

This implementation merely uses a counter. Straightforward, but once you start using semaphore objects to lock your navigation or your input fields, you will start to see how this simple object can untangle your state logic.

package com.partlyhuman.semaphore
{
	public class SimpleSemaphore extends Semaphore
	{
		protected var _locks:int = 0;

		public function SimpleSemaphore(owner:Object = null, description:String = null)
		{
			super(owner, description);
		}

		override protected function initialize():void
		{
			_locks = 0;
		}

		override public function get locks():int
		{
			return _locks;
		}

		override public function get isLocked():Boolean
		{
			return (_locks > 0);
		}

		public function lock():void
		{
			if (_locks++ == 0)
			{
				dispatchEvent(new SemaphoreEvent(SemaphoreEvent.UNAVAILABLE));
			}
		}

		public function unlock():void
		{
			_locks--;
			if (locks < 0)
			{
				throw new Error("Semaphore Asymmetrically Unlocked!");
				locks = 0;
			} else if (locks == 0) {
				dispatchEvent(new SemaphoreEvent(SemaphoreEvent.AVAILABLE));
			}
		}
	}
}

An Alternative Implementation

In this implementation, you get a receipt for your reservation. If you happen to need to hold on to a shared resource through a multi-step process that involves many objects, you might end up with a lot of dependencies. This implementation solves the problem by allowing you to pass around a lock object. Any code with a reference to the lock can release it, without requiring a dependency on the source of the lock itself.

package com.partlyhuman.semaphore
{
	public class Lock
	{
		protected var owner:TokenSemaphore;

		public function Lock(owner:TokenSemaphore)
		{
			this.owner = owner;
		}

		public function release():void
		{
			owner.releaseLock(this);
		}
	}
}

package com.partlyhuman.semaphore
{
	public class TokenSemaphore extends Semaphore
	{
		protected var tokenPool:Array;

		public function TokenSemaphore(owner:Object = null, description:String = null)
		{
			super(owner, description);
		}

		override protected function initialize():void
		{
			tokenPool = new Array();
		}

		override public function get locks():int
		{
			return tokenPool.length;
		}

		override public function get isLocked():Boolean
		{
			return (tokenPool.length > 0);
		}

		public function getLock():Lock
		{
			if (locks == 0)
			{
				dispatchEvent(new SemaphoreEvent(SemaphoreEvent.UNAVAILABLE));
			}

			var lock:Lock = new Lock(this);
			tokenPool.push(lock);
			return lock;
		}

		internal function releaseLock(lock:Lock):void
		{
			var index:int = tokenPool.indexOf(lock);
			if (index == -1)
			{
				throw new Error("TokenSemaphore: a lock was released that could not be found");
				return;
			}

			tokenPool.splice(index, 1);
			lock = null;

			if (!isLocked) dispatchEvent(new SemaphoreEvent(SemaphoreEvent.AVAILABLE));
		}

	}
}

Conclusion

Using semaphores in your code is a great way to avoid complicated state logic. You can move the logic of tracking usage to the semaphore object, and handle the results of locking or unlocking only when it has an effect. Though a simple concept, using it as a tool in your toolkit can make your code beautiful and concise. And you can design additional functionality into your own implementation. For example, I will soon explain a semaphore which binds to an asynchronous token... or you could write a semaphore which actually queued up requests.

Let me know what you think, and see you soon with the next installment!

Why Bundles Will Give You a New Brain

Eight years ago, I weighed 500lbs. I was getting really high every day. And I was washing my dishes in the bathtub. But thanks to resource bundles, I own a mansion, I’ve got a summer home in Maine, I got an awesome boat, I got a jet pack, and I got a sweet lookin’ wife.

What’s a resource bundle? It’s a set of values that you externalize from your source code in a properties file. And it can be swapped out at compile time or, with Flex 3, at runtime. Think of it like a style sheet for values. Most of the time, these values are text. But without too much hassle, you can use resource bundles to parameterize all types of data.

Resource bundles are probably most useful, and most commonly used for, localization. Localization (pardon the didacticism) is the process of making software comprehensible for multiple regions with different languages or ways of writing. Sometimes you’ll see this term written L10n. For example, in porting your “Hello, world” application for a Japanese audience, you’d probably make it say something like “今日は、世界” instead. Resource bundles are perfect for supporting multiple locales.

This obvious use case, I’m afraid, might have prevented many of you from looking into resource bundles. If resource bundles are for localization, and you’re building a site that doesn’t need to be localized, you might well overlook their benefits, as I did for some time. However, here’s some of the benefits of using resource bundles — even if it’s just one single bundle.

Using resource bundles, you can give every application you write a copy deck. If you’ve worked with almost any client ever, I’m sure you’ve had to make a copy change. Who wants to go digging through source code to find that string? Put all your application’s copy in a resource bundle, and you can not only make these changes with ease, you can deliver source code that anyone can modify easily. (Copy decks are a necessity when using translation services as well.)

You can use resource bundles to store configuration values such as paths, numbers, Boolean flags, debug mode, overrides, etc. You can use a resource bundle instead of a configuration file or static constants.

You can even use resource bundles to reskin applications. Flex lets you parameterize embedded images in resource bundles. Alternately, if you load images at runtime, you can parameterize those URLs in a resource bundle. So, if your code references resources instead of direct embeds, you can change the look of your app by swapping out the bundle with all the image embeds!

Even if you don’t use resource bundles for any sort of behavior, language, or appearance toggling in your application, bundles are a fantastic way to separate code and content and organize related sets of content.

In brief, resource bundles will make your life easier, your program modular, and your project structure tidy!

What a World With Resource Bundles Looks Like

Pretty soon I’ll show you the specifics of how to set up your project to use resource bundles. But before we get into technicalities, let me describe a few formats. There’s a few ways you can use resources, and there’s the property file format to cover as well.

Ok, again pardon the ultimately pedantic example, but let’s say you have a hello world app.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Label text="Hello, world!"/>
</mx:Application>

You clearly wrote this application for an English-speaking audience. And that bias exists in your code. It’s completely tied to your source file! Shame. If you wanted to write a Spanish version, you’d have to go right in and edit your source code:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Label text="¡Hola, mundo!"/>
</mx:Application>

But, with resource bundles, this is what the one, true, final and never-changing source code could look like:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Label text="@Resource(key='message', bundle='copydeck')"/>
</mx:Application>

That’s one way, and indeed my favored way, of accessing resources from a resource bundle. This is going to look for the key message inside the bundle called copydeck.properties, and place its value in the text attribute of this Label instance, thus setting the text. Right now it looks like a lot more to type, but trust me, once you have a site or app with hundreds of lines of text, you are really going to appreciate how this makes your code concise and puts the text all together where it should be!

Note that you can use this @Resource directive in MXML in more places than just text attributes. You could use it to set tooltips, style properties, sizes, all kinds of things!

So let’s take a quick look at this outrageously simple properties file. This file format is really really easy.

#locale/en_US/copydeck.properties
message=Hello, world!
message-size=30

#locale/es_MX/copydeck.properties
message=¡Hola, mundo!
message-size=40

Here we see two copies of the properties file, made for two locales (American English and Mexican Spanish — locales are not just specific to the language but the region as well, but that’s another story). There’s pretty much only three things to know about properties files.

• Key = value. Do I need to explain this? Don’t sweat the whitespace.
• Comments are whole lines that begin with #.
• Properties are one line long unless you end the line with a backtick (\), in which case you can continue on the next line.

In reality, there are alternate formats for the first two rules, but only use that if you really have to be different. There’s something to be said for the naming convention of the bundles. The directory structure I’ll explain a bit later, but know that en_US and es_MX are locale codes, combining a language code and a country code. The name of the file before its .properties extension is going to yield the bundle name itself.

Now, you can skip the whole step of specifying the bundle name by having one properties file per class file, and naming the properties file in parallel with the name of the class using it. If you do this, you can omit the bundle='whatever' attribute of the @Resource directive, but I advise against this. I advocate that you split up your resource bundles by purpose. For example, one recent project I worked on uses a bundle for copy and a bundle for skinning. Another recent project uses one bundle for copy and another for stylesheets.

So I hear you, you’re one of those hardcore doods who uses Flex but prefers to code in AS3. That’s cool, I’m down with that. Or maybe you just have something more interesting to do with those values coming out of resource bundles (configuration variables perhaps). There’s some nice ways of accessing values from resource bundles in code. Maybe looking at this will get you started:

package
{
	import mx.containers.Canvas;
	import mx.controls.Label;

	[ResourceBundle("copydeck")]
	public class View extends Canvas
	{
		public function View()
		{
			super();
			var label:Label = new Label();
			label.text = resourceManager.getString("copydeck", "message");
			label.setStyle("fontSize", resourceManager.getNumber("copydeck", "message-size"));
			addChild(label);
		}
	}
}

If you’re in a class that doesn’t have its own reference to the ResourceManager, like Canvas here does, you can equally well use ResourceManager.getInstance(). Further, there are lots of other cool typed accessor methods you can use. Keep in mind that any bundles you reference in AS3 only must be explicitly included by using [ResourceBundle] metadata tags.

For more information about intermediate techniques like embedding assets and loading/swapping resource bundles at runtime, check out the very good section on localization in the Livedocs.

The Petty Particulars of Putting it to Practice

Now, I’m not going to leave you hanging with just some code examples. There’s a few things you need to know about structuring your Flex projects to take advantage of resource bundles. It’s really not that complicated, though, so not to worry!

First, you should pick a place for your resource bundles to live. Even if I’m only ever making apps for my United States English locale, I still like to make a locale/en_US folder, and place all my properties files inside there. I recommend you do the same.

Now here’s one tricky point. This directory must be one of the source directories in your Flex project. The compiler has to be able to crawl to those properties files, and it stays away from any place you haven’t specified in your build path. Again, even if I only have one locale ever, I like to keep this parameterized. Assuming you used the directory structure above, step one is to add the following directory to your build path:

locale/{locale}

The play-by-play, if you need it: right-click your project, choose Properties. Choose ActionScript Build Path on the left column, choose the Source Path tab, click Add Folder… and enter locale/{locale}.

Finally, Flex Builder is going to get this locale variable from somewhere, and that’s from the arguments sent to mxmlc. Simply add the option

-locale=en_US

to your compiler arguments, or of course, substitute the locale in use. This value will replace the {locale} variable in the source path, and switch mxmlc to use the copies of the properties files in the correct location for the locale (or skin, or whatever…).

Again, the play-by-play. Right click your project, choose Properties. Choose ActionScript Compiler on the left column, and add the option just mentioned to any others that your project requires (if any).

Conclusion

That’s all it should take to get you started with resource bundles! I hope that I’ve convinced you that resource bundles are a fun, safe, and effective way to separate your code and your content, whether your application will be localized and skinned or not! Separate your copy from your code. The next person to touch your code will thank you. If you use MXML with external CSS files and external resource bundles, you might achieve some sort of ultimate code separation enlightenment.

Did I miss anything? Run into any problems? Leave me a comment!

Hey KS Fans,

KitchenSync version 1.0.1 was released last week. This version is just a patch that fixes a few minor issues. Here’s the change log for this version.

===== v1.0.1 (2008.02.04) ======
Fixed Cubic.easeOut bug.
Made getters for Tween's toValue and fromValue.
Added source code to main download.
Added metadata for events.
Updated docs and added summaries to all wiki pages.

I received some feedback from people who were having trouble setting up KitchenSync for use with Flash CS3. I didn’t know this before but you cannot use .swc files compiled with the Flex SDK in a .fla file (WTF, Adobe!) Also, some people were confused by having to use SVN to get the source. To help solve these problems, I’ve added the latest source code as its own download.

I’ve also written EVEN MORE documentation including help for downloading and setting up the source code.

Finally, if you’re using KS, drop me a line or post to the mailing list. I’d love to hear any feedback you may have!

Download Source!

StateDemo.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:local="*" currentState="{ENGLISH}">
	<mx:Script>
		<![CDATA[
			// define the state names as constants
			static public const ENGLISH:String = "English";
			static public const FRENCH:String = "French";

			/**
			 * When the "make breakfast" button is clicked, display the steps
			 * you'll need to follow to make breakfast.
			 * Imagine that you'd need to implement all of these steps as functions
			 * and that there are several more languages to support.
			 */
			protected function onBreakfastButton(event:Event):void {
				if (currentState == ENGLISH) {
					output.text = "Fry eggs" +
								  "\nFry tomatoes" +
								  "\nToast bread" +
								  "\nMake tea";
				}
				if (currentState == FRENCH) {
					output.text = "Tartiner du beurre sur baguette" +
								  "\nMettre le yaourt dans un bol" +
								  "\nTranche les fruits" +
								  "\nFaire cafe";
				}

			}
		]]>
	</mx:Script>

	<!-- Define the changes to the view in the <mx:states> tags -->
	<mx:states>
		<mx:State name="{ENGLISH}">
			<mx:SetProperty target="{breakfastButton}" name="label" value="Make Breakfast" />
		</mx:State>
		<mx:State name="{FRENCH}">
			<mx:SetProperty target="{breakfastButton}" name="label" value="	Préparer des petits-déjeuners" />
		</mx:State>
	</mx:states>

	<mx:VBox>
		<mx:Button id="breakfastButton" click="onBreakfastButton(event)" />
		<mx:TextArea id="output"  height="100" width="250"/>
		<mx:HBox>
			<!-- Swap states using these buttons -->
			<mx:Button label="English" click="{currentState = ENGLISH}" />
			<mx:Button label="French" click="{currentState = FRENCH}" />
		</mx:HBox>
	</mx:VBox>
</mx:Application>

Compiling this code gives you the following…
View SWF

The problem

While there’s nothing inherently wrong with this application, there could be complications when trying to make changes to the logic. First of all, the onButtonClick() handler has to provide different functionality based on the currentState. The states themselves need to add labels to the breakfastButton. Imagine what would happen if you expanded this application to support 15 languages or to create lunch, dinner, and teatime. Things could get out of control fast!

The Solution – applying the state design pattern

The state design pattern allows you to separate out state specific functionality and defer the execution of methods to those state objects.

I’ll combine the state pattern with the view states by making a currentLogicalState property of the application. This setter will also automatically set the currentState based on a name stored in the currentLogicalState. This is easier done than said…

1. Define a logical state interface

My logical state interface only needs to have one getter for name so that we can associate it with a view state.

ILogicalState.as

package
{
	public interface ILogicalState
	{
		function get name():String;
	}
}

package
{
	public interface IBreakfastMakerState extends ILogicalState
	{
		function get breakfastInstructions():String;
		function get breakfastLabel():String;
	}
}

package
{
	public class EnglishBreakfastState implements IBreakfastMakerState
	{
		public function get name():String
		{
			return "English";
		}

		public function get breakfastInstructions():String
		{
			return "Fry eggs" +
				   "\nToast bread" +
				   "\nFry tomatoes" +
				   "\nMake tea";
		}
		public function get breakfastLabel():String {
			return "Make Breakfast";
		}
	}
}

package
{
	public class FrenchBreakfastState implements IBreakfastMakerState
	{
		public function get name():String
		{
			return "French";
		}

		public function get breakfastInstructions():String
		{
			return "Tartiner du beurre sur baguette" +
				   "\nMettre le yaourt dans un bol" +
				   "\nTranche les fruits" +
				   "\nFaire cafe";
		}

		public function get breakfastLabel():String {
			return "Préparer des petits-déjeuners";
		}
	}
}

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:local="*"
	initialize="onInitialize(event)">
	<mx:Script>
		<![CDATA[

			// define the logical states as constants
			static public const ENGLISH:IBreakfastMakerState = new EnglishBreakfastState();
			static public const FRENCH:IBreakfastMakerState = new FrenchBreakfastState();

			/**
			 * keep track of the current logical state and when the currentLogicalState changes
			 * update the currentState using its name property.
			 */
			protected var _currentLogicalState:IBreakfastMakerState;
			public function set currentLogicalState(state:IBreakfastMakerState):void {
				_currentLogicalState = state;
				currentState = _currentLogicalState.name;
			}

			protected function onInitialize(event:Event):void {
				currentLogicalState = ENGLISH;
			}

			protected function onBreakfastButton(event:Event):void {
				// rely on the logical state to handle the logic of preparing the breakfast.
				output.text = _currentLogicalState.breakfastInstructions;
			}
		]]>
	</mx:Script>

	<!-- Define the changes to the view in the <mx:states> tags -->
	<mx:states>
		<!-- Name each view state using the name of the logical state -->
		<mx:State name="{ENGLISH.name}">
			<!-- Change the label using a value from the logical state -->
			<mx:SetProperty target="{breakfastButton}" name="label" value="{ENGLISH.breakfastLabel}" />
		</mx:State>
		<mx:State name="{FRENCH.name}">
			<mx:SetProperty target="{breakfastButton}" name="label" value="{FRENCH.breakfastLabel}" />
		</mx:State>
	</mx:states>

	<mx:VBox>
		<mx:Button id="breakfastButton" click="onBreakfastButton(event)" />
		<mx:TextArea id="output"  height="100" width="250"/>
		<mx:HBox>
			<!-- Swap logical states using these buttons -->
			<mx:Button label="English" click="{currentLogicalState = ENGLISH}" />
			<mx:Button label="French" click="{currentLogicalState = FRENCH}" />
		</mx:HBox>
	</mx:VBox>
</mx:Application>