An Invisible Refresh
Why?
It took 8 months of working in fits and starts, but I've finally converted the code behind danielboyle.net to Actionscript 3, from a mix of Actionscript 1 and 2. Why? As of Flash CS3, Actionscript 3 became available. It's essentially a complete rewrite of AS1 and 2 as a strictly object-oriented language. Practically speaking, as newer versions of the Flash player become universal, and Flash itself is upgraded, the older styles of Actionscript will fall away, and if you don't know AS3, you'll be in trouble. This particular project was probably the easiest way to learn. I had no real deadline, my math worked, my assets already existed, the logic was already there, and I had a working target to shoot for. For help, I turned to Google, Kirupa.com, and Actionscript.org. I also used Colin Moock's excellent Essential Actionscipt 3.0.
This is NOT a tutorial. This is a port-mortem of my thought process, lessons learned, and results of the re-engineering of my site.
What is ActionScript 3 & Object-Oriented Programming (OOP)
The most important aspect of AS3 is the change to a strictly Object-Oriented coding environment. This was actually the biggest hurdle for me to cross. The easiest way to explain the structure is that a package groups classes. Classes contain methods and properties. Some of these are publicly accessible. Some can only be access from within the class. To be frank, I still don't understand all of the restrictions. As a better example, consider a package called "animals." That package contains the class "dog." Dog has the methods "bark" and "eat." It also has the methods "chew" and "digest," but you can't actually call them when working with a Dog. You can only tell it to eat - chewing and digesting are internal processes.
I had somewhat of a head start on this. On nearly all projects I work on (beyond basic banner ads) I use almost no timeline code. My code is stored on 2 frames. One encapsulates actual functionality into reusable functions. The other contains logic and any timeline-related code. Unfortunately, projects built in this manner tend to get fairly disorganized when you start adding code within library objects, or directly onto MovieClips and Buttons. The conversion to AS3/OOP essentially ends this. While you may (and I certainly did) end up with multiple text files containing ActionScript, the files had to follow a strict hierarchy, and were easier to search through. Also helping to cut down on unneccesary code is that only the core Classes are included in a defualt Flash export. Any classes, whether they're your own, or included with Flash (such as the TextField Class) MUST be imported manually.
There's a good deal of syntax changes in AS3. First, all variables must be declared and typed.
num = 7; //This is wrong
var num:Number = 7; //This is correct
Similarly, functions must now be typed.
function someFunction(param:String):void {
trace("This is a test");
}
Root is gone as well. That's right, not more using _root when you've gotten too many layers deep and need to get back to the main level. This wasn't a huge deal for me - I tend to make my files shallow, but if you rely on it as a crutch, you will have a problem.
It's a pain until you get used to it, but frankly, this is an absolute godsend when developing. Anyone who has done Flash development long enough knows that in AS1 and 2, you would eventually receive results that didn't make any sense. You'd pour through lines of code, only to realize your function was returning a String when it should've returned a Boolean, or you accidentally converted a Number to a String.
Another syntax change is the conversion of percentage-based properties such as alpha from a 0-100 scale to 0-1. Also, there is no longer a preceding '_' - _alpha becomes alpha.
Buttons now use the Listener model exclusively, instead of onRelease (and similar) methods. For example...
my_btn.onRelease = function():Void {
trace("This is a test");
}
...becomes...
my_btn.addEventListener(MouseEvent.MOUSE_UP, testFunction);
function testFunction(e:Event):void {
trace("This is a test");
}
MovieClips being used as buttons now required "useAsButton" and "useHandCursor" to be set to true. And if you want to pass a variable to the function, you have to create it in the button's class file and apply it prior to firing the button action. As an example...
package net.danielboyle.buttons {
import flash.display.MovieClip;
public class my_btn extends MovieClip {
public var index:Number = new Number();
public var xml:XML = new XML();
//Constructor
public function Project_mc():void{
};
}
}
my_btn.xml = "
my_btn.addEventListener(MouseEvent.MOUSE_UP, testFunction);
function testFunction(e:Event):void {
trace(e.target.xml);
}
Similarly, loading of external files is handled through the Loader and URLloader Classes, both of with are fully Event-based.
All of these changes take an adjustment period - but once it's a part of your coding habits, you'll learn to despise how AS2 would allow anyone to create properties on MovieClips and other objects on the fly, and love AS3. There are plenty of other changes in AS3, but that's well outside of the scope of this entry. Consider reading Adobes articles about AS2 to AS3 migration (available on Adobe.com.
Animation Engine
Unrelated to the AS2/AS3 conversion is a switch to TweenLite AS3. In the original interation of this design, I used mx.tween, an animation package that is part of the default install of Flash going back to Flash 6/MX. There's nothing wrong with mx.tween. It's fashionable to knock it because everyone uses it, but it's a good, basic, reliable engine, and it's fairly compact. TweenLite has some options that make it useful. It's slightly smaller, and uses less CPU power, but the real advantage is the scripting engine. It's easier to make multiple properties tween simultaneously, and you can add delays, or call functions at the beginning or end of the tween using less code. I've also used FuseKit in the past, but it is not going to be updated for AS3, and it also imposes a significant file size and performance penalty, though it is MUCH more powerful, particularly when creating longer animation sequences. FuseKit wasn't right for this project, though.
The Conversion
I started with the simplest part of the site: the blog section. Since the site is based off of XML files, I figured I should learn how to import the backbones and work with them prior to diving in to the complex portions of the site. Fortunately, this section went smoothly. XML handling is AS3 is much improved. Gone is the old xml.childNodes[i].firstChild.firstChild.nodeValue mess. Now, you can traverse the file using node names (xml.site[i].name). I also created a new class, called TextFieldUtils. This is a class I hope to expand and re-use in the future. Essentially, when the title of the most recent blog entry is too wide for the text field, it needs to be truncated, and have "..." appended. I initially had this in the main Document class file, but soon realized that defeated one of the purposes of OOP - reusable, modular code. I extended the TextField class and added the method to truncate and add a string of my choosing, creating a ‘Super TextField’.
Moving up to the resumé section, I encountered a temporary headache. How do I attach MovieClips from my library? It used to be...
for(var i:Number = 0; i<limit; i++) {
container_mc.attachMovieClip(my_symbol, "clip"+i+"_mc, depth);
}
...which becomes...
for(var i:Number = 0; i<limit; i++) {
clip_mc[i] = new my_symbol_class;
addChild(clip_mc[i]);
}
That's right - even your libary objects are now considered Classes, and if you plan on passing information to them, plan on creating an external .AS file to accompany them. You also don't create variable names on the fly, and you don't use associative arrays (_root["clip"+i+"_mc] to access them - you simply add the objects to an array, and access them that way. This was also where I first had to figure out how to attach data to buttons so I could access XML data or some other property when a button was pressed.
The Portfolio section ran into the same challenges. Fortunately, I had learned my lessons, and it was much, much simpler.
Is it better?
Well, it's definitely more organized. I have (slightly) less code to maintain, and some of it can be reused for other projects. Many things, such as the XML handling are dramatically improved, and the parts that are more complicated simply require a change in though patterns. The biggest problem is the lack of documentation. Even Moock's book failed me on several occasions. Many of my problems were due to not understanding exactly how AS3 was organized, and many of the examples I found online were wildly complex, poorly documented, or both. I don't know if it's because AS3 isn't as widely adopted as AS2 yet, but the development community really needs to make itself visible and improve the documentation and online knowledgebase.
Statistically, I not much changed. Despite the change in animation engine, performance is about the same. File size went UP slightly (5%), but lines of code when down slightly (8.5%). As a qualifier, my code in the AS3 version is much more heavily commented. If I removed all comments from both versions, I would have a SIGNIFICANTLY lower line count in the AS3 version. In any case, the AS3 version is vastly superior - it's more organized, and more easily maintaned.

Was it worth it?
Sure. Having finished it, I can definitely say that AS3 is an improvement over AS2, provided you're able to figure out how to take advantage of OOP.
