Aral Balkan

By all outward appearances, 2005 was a very successful year. I got to fly around and present at such wonderful conferences as FlashForward and Spark Europe and hang out with my friends on the Flash team in San Francisco as part of the Lego summit and share in the excitement of the Flash 8 launch in person. Practical Web Projects magazine called me one of the three top Flash developers in the world (and I can think of a dozen other developers more worthy of the title at the drop of a hat) and my training courses consistently received glowing reviews. And last, but definitely not least, OSFlash exploded on to the scene and ballooned into an amazing resource on open source for the Flash community. In other words, by all outward appearances, 2005 was a very successful year.

Unfortunately, there are two events that took place towards the end of the year that stop me from celebrating –- one of which will forever define the year as one of the saddest moments in my life. You see, in October, my love of six years –- the person I was closest to in the world –- left to pursue her own dreams. It was a blow, unlike any I have ever experienced. I'm usually proud of my ability to take hits and plough on. I guess I'd never been broadsided by an ocean tanker before because I'm only now realizing that it completely took me out of commission for a couple of months and I'm only now recovering. I realize now that the decision was probably the best one for both of us but it doesn't make it any easier to come to terms with. The loss of someone so close to you is a pain I cannot begin to explain in words.

To make bad worse, at the same time -– and against my better judgment -- I took on a development project, subcontracting for a client with a small company here in the UK. After redesigning the failing application completely, moving it from Flash to Flex, CF to J2EE (to enable us to use complex Value Objects without hacking around CF), putting together a stellar development team (including my good friend and genius developer, Darron Schall) and developing at breakneck speed, the client informed us half-way through –- in place of a thank-you -- that he couldn't pay us. Learn from my mistake: If this happens to you: Stop. And sue. Instead, I naively tried to help and offered to discount our rates substantially and we ended up working for six more weeks before being told again that we wouldn't be paid. I won't go into any details here but suffice it to say that lawyer's letters have been sent and my thank-you for saving this project has been a net financial loss.

I'm so disenchanted with third-party development because of this last project that I'm not going to be doing any more of it. Instead, in 2006, I'm going to concentrate on my training courses, including a new line of online courses, on consulting and on presenting at the various conferences I've been invited to. The only development I will be doing from now on is on my own products. The hassle of developing for third-parties is definitely not worth it –- life's too short.

So 2005 hasn't been the best year for me but I can say this much: 2006 is going to rock!

Those of you on the OSFlash list may have noticed that I was a little distant in the past few months: Well, no longer! I'm back and I am entirely psyched about supporting and growing our wonderful community.

2006 is going to see my new line of training courses which I will be working night and day on to make into the best ActionScript, Flash and Flex learning materials ever. And, as always, you'll find me in the corridors of some conference, passionately defending the importance of development process, Agile Methodologies and User-Centered Product Development

I can't wait to see you all at FlashForward Seattle and Flash In The Can and, I'm sure, this year's Spark Europe (Stewart, when're we doing the next one – the last one rocked!)

Here's to an exciting 2006… let the party begin!

We had some extra time during my recent Best Practices Flash and Flex class and, at the request of the class, decided to cover FAMES. As part of this, we downloaded the latest Swfmill, which has support for linking classes to clips directly in the SWFML file. I thought we might as well use this new functionality as it is cleaner than littering your code with Object.registerClass statements. Little did I know at the time that this little addition would actually result in a huge shift in workflow. Much head-scratching later, I was able to come up with a workflow that is actually much simpler to work with than the current workflow. The problem is that currently it does not work with FAMES (Flashout, the "F", doesn't currently support this workflow) so you will have to use the command line for the time being.

Before we look at this new method, though, let's review the original method for working with Swfmill that has been popularized both here and elsewhere:

The Skeletal Injection Method

The original way of using Swfmill and MTASC together involves injecting a Swfmill Skeletal SWF with code. I'm calling this the Skeletal Inject Method. In this workflow, the skeletal SWF created by Swfmill only contains library assets and the only way to create an entry point into the application is to use a static main() method and compile using the –main attribute in MTASC.

The steps for creating a Flash application using the Skeletal Injection Method are:

1. Describe a skeletal SWF with library items using Swfmill's Simple (swfml-s) dialect (eg. skeletal.xml)

2. Use swfmill to compile the skeletal SWF (eg. skeletal.xml -> skeletal.swf )

3. Create an ActionScript 2 class with a static main() method and compile and inject it into your skeletal SWF using MTASC. If you want to link movie clips in your library with classes, you need to use Object.registerClass to do so in your class. You can, of course, also choose to assimilate _root and do all sorts of wonderful things along the way.

Pros:

• The original way, so you most likely know it
• Quick workflow that is currently supported by visual tools such as Flashout and AsAlter
• Intuitive
• You can still use it!

Cons:

• Have to use Object.registerClass in code to link movie clips to classes
• Use of static main() method as entry-point doesn't feel natural for Flash applications
• Contains quite a few steps

The Natural Entry Point Method

The Natural Entry Point Method involves the use of at least two SWFs in your application. The first one is your main Application SWF and the second is a Classes SWF that contains the compiled code of your classes.

Your Application SWF contains your library, including any forms (movie clips that you link to classes using the new class attribute of the Swfmill <clip> tag.) Unlike the Skeletal Injection Method, which only contains a library, your Application SWF has to actually place a form (movie clip) on the Stage to provide a natural entry point for the application.

Instead of keeping your classes in the main application SWF, you keep them in a separate Classes SWF and import them into the main SWF as an external asset (at compile time).

In the next section, you will recreate the particles sample application which was previously constructed using the Skeletal Injection Method using the Natural Entry Point method instead.

Prerequisites: You will need to have Swfmill and MTASC installed and on your path. This example uses the command line (you don't need FAMES or other GUI tools to complete it.)

Natural Entry Point Example

Download the source files (NaturalEntryPointExample.zip; 106kb)

First, create the main application SWFML file, application.xml. The listing for this shown below:

<?xml version="1.0" encoding="iso-8859-1"?>


<movie width="320" height="240" framerate="30">


	<background color="#ffffff"/>


	


	<!-- 


		The Application and Particle classes have been


	    compiled into the classes.swf file, which we


	    import as an asset. This makes the classes


	    available for linking to our movie clips. 


	-->


	<clip import="classes.swf" />


	


	<frame>


	


		<!-- 


			The Library contains the Application form, linked


		    to the Application class and the EclipseLogo


		    sprite, linked to the Particle class. 


		-->


		<library>


			<clip id="Application" class="Application" />


			<clip id="EclipseLogo" class="Particle" import="library/eclipse32.png" />


		</library>


	


		<!-- 


			Place an instance of the Application form on Stage


		    to instantiate it and provide the Natural Entry Point. 


		-->


  	    <place id="Application" name="app" x="0" y="0" depth="1000" />


	


	</frame>


 


</movie> 

Let's break this down:

At the very top, you set up the movie's dimensions and background color as before.

Next, you import your Classes SWF. This file will eventually contain the compiled versions of the classes you will be using in the application.

Next, you start the first frame of the application and define a library there. In it, you create two clips (movie clip symbols).

The first one is an empty movie clip. Its Symbol ID is Application and, using the new class attribute, you are linking it to the Application class in the default package (for the sake of brevity, I did not use a package structure in this sample – in the form org.flashant.naturalEntryPointSample.*) as would be the norm for any real application).

The second movie clip symbol has a Symbol ID of EclipseLogo and is linked to the Particle class in the default package. You are asking Swfmill to import the eclipse32.png found in the library folder of your project and place it in the movie clip.

Finally, you need a way to instantiate your application and to do this, you place an instance of the main Application form (the movie clip with Symbol ID "Application" that is linked to the Application class) on the Stage using the <place> tag. In the tag, you give the Application form an instance name (not really necessary as it will contain all other objects and thus none will refer to it using its instance name) and specify its location and depth.

Now, you need to create the Application and Particle classes and compile them into the Classes SWF.

The Particle class, shown below, has not changed at all from the previous example:

class Particle extends MovieClip


{


	var vX:Number = null;


	var vY:Number = null;


	var randomness:Number = null;


 


	function Particle ()


	{


		_x = _width + Math.random() * ( Stage.width - _width );


		_y = _height + Math.random() * ( Stage.height - _height );


		


		_rotation = Math.random() * 360;


		


		var randomness = Math.random()*5;


		


		vX = Math.random() * randomness + 1;


		vY = Math.random() * randomness + 1;		


	}


	


	function onEnterFrame ()


	{


		_rotation += 1.69;


		


		_x += vX;


		_y += vY;


		


		if ( _x < 0 || _x > ( Stage.width - _width/2 ) )


		{


			vX *= -1;


			_x += 2 * vX;


		}


		


		if ( _y < 0 || _y > ( Stage.height - _height/2 ) )


		{


			vY *= -1;	


			_y += 2 * vY;


		}


	}


} 

The Application class, however, is considerably different:

import LuminicBox.Log.*;


 


class Application extends MovieClip


{


	var tfCaption:TextField;


	


	// Clips attached dynamically from Swfmill library


	var mcSpheres:MovieClip;


 


	var sW:Number = null; 	// Stage width


	var sH:Number = null;	// Stage height 


	


	// Log


	var log:Logger;	


		


	function Application ()


	{


		// Setup logging


		log = new Logger();


		log.addPublisher ( new ConsolePublisher() );


		log.info ( "Application::Constructor" );	


	}


 


	function onLoad ()


	{


		log.info ( "Application::onLoad" );


		log.debug ( "this = " + this );


 


		// Store stage dimensions for easy look-up


		sW = Stage.width - 1;


		sH = Stage.height - 1;


		


		// Draw border around the stage


		lineStyle ( 1, 0x000000 );


		moveTo ( 0, 0 );


		lineTo ( sW, 0 );


		lineTo ( sW, sH );


		lineTo ( 0, sH );


		lineTo ( 0, 0 );


		


		//


		// Create a message


		//


		var captionTextFormat = new TextFormat();


		captionTextFormat.size = 12;


		captionTextFormat.font = "_sans";


		


		var captionText:String = "Swfmill + MTASC Natural Entry Point Sample";


		


		var captionTextExtent:Object = captionTextFormat.getTextExtent ( captionText );


		var captionWidth:Number = captionTextExtent.textFieldWidth;


		var captionHeight:Number = captionTextExtent.textFieldHeight;


		var captionX = sW / 2 - captionWidth / 2;


		var captionY = sH - captionHeight;


		


		createTextField( "tfCaption", 10000, captionX, captionY, captionWidth, captionHeight );


	


		// Write caption text


		tfCaption.text = captionText;


		


		// Add ten particles


		for ( var i = 0; i < 10; i++ )


		{


			// Attach a sphere clip


			attachMovie ("EclipseLogo", "eclipseLogo" + i, 1000 + i );


		}


	}


} 

The main difference is that it no longer has (or needs) a static main() method to provide an entry point. By placing the Application form on Stage using swfml, you have created a natural entry point: Flash will automatically call the Application class' constructor.

In it, you set up the LuminicBox Logger and trace out an info message to signal that the constructor has, in fact, initialized (I've included the latest version of LuminicBox Logger in the files for this tutorial.) The really juicy stuff happens in the onLoad() event handler that gets called automatically in Flash.

In the onLoad() event handler, you first trace out an info message to confirm that the event handler has fired and then trace a debug message to confirm that the movie clip has initialized with the correct scope (things you may feel the need to do when you first try this method, as I did.) Notice that the scope is different from when we were assimilating _root using the Skeletal Injection Method – the Application form is _level0.app not _level0.

The rest of the code in the onLoad() method hasn't changed at all from the version in the previous tutorial. The only difference is that instead of the Particle instances being attached to _level0, they are being attached to _level0.app.

If you use ARP, the open-source pattern-based framework for the Flash Platform, you will no doubt have noticed how directly this applied to ARP application development in Flash and Flex: It uses exactly the same workflow.

Now that your source files are ready, all that remains is to compile them. You are going to compile the classes and create the Classes SWF in one step, using MTASC's -header argument. The -header argument allows you to specify the width, height and frame rate of a SWF and makes MTASC create a SWF with those properties and inject the compiled classes into it. (So you don't have to create an empty skeletal SWF using Swfmill.)

To do this, switch to your project folder in the command line and type the following, replacing the path in the classpath (-cp) with the path to the Flash MX 2004 classes folder on your computer:

mtasc –cp "C:\Documents and Settings\Aral Balkan\Local Settings\Application Data\Macromedia\Flash MX 2004\en\Configuration\Classes" -header 1:1:30 –swf classes.swf Application.as Particle.as

(Note: If you want to use the LuminicBox Logger in your own applications, do not copy an instance of it into each of your project's folders. Instead, keep it in a single location and add another classpath while compiling by adding a second –cp argument.)

Finally, use Swfmill to compile your main application SWF by entering:

swfmill simple application.xml application.swf

Run the application.swf and you should see the animated particles.

Pros:

• Simple, familiar workflow
• Provides a natural entry point
• Don't have to use Object.registerClass manually
• Fits in with ARP workflow

Cons:

• Have to compile both your classes and your assets/main application when your classes change (ie., not as performant as the Skeletal Injection Method)
• GUI tools do not currently support this workflow

I definitely prefer the Natural Entry Point Method to the Skeletal Injection Method and will be using it in my own projects. On the whole, it is simpler, more flexible and the workflow is identical to that used in an ARP project (although you can also use the Skeletal Injection Method with ARP projects as long as you either assimilate _root or, better yet, assimilate an application movie clip that you've placed on the _root timeline using Swfmill.)

Regardless of whether you use the Natural Entry Point or Skeletal Injection methods, the combination of Swfmill and MTASC offer a world of possibilities for Flash developers and for that I am eternally thankful to Nicolas Cannasse, Daniel Fischer and Mark Winterhalder – thanks guys for making all this possible

Download the source files (NaturalEntryPointExample.zip; 106kb)

Here are links to articles I've written for Macromedia DevNet. I hope you find them useful:

• Data Binding in Macromedia Flash MX Professional 2004
• Building an RSS Aggregator with Macromedia FireFly Components
• Building an RSS Aggregator with Macromedia FireFly Components (Part II)