The Road to Actionscript 3

In: Articles

By Jonathan Greene

Published on February 12, 2007

“So you’re an OOP guy, huh? What languages do you work in?”
“Java, C#, ActionScript…”
“Pfft, ActionScript isn’t an OOP language!”

Sound familiar? Well, while you may not have been able to convince the masses that previous versions of the Flash scripting language, ActionScript, allowed for object-oriented programming (OOP), there will be no doubt that you are a capable OOP programmer when you get some AS3 under your belt.

(For those who are unfamiliar with the term, object-oriented programming is a programming style that breaks an application into abstract data-types, or objects, which work together. It allows for greater development flexibility, code reuse, and developer collaboration than traditional procedural programming.)

ActionScript has come a long way from its initial implementation in a little application called FutureSplash. As Flash has grown and become a standard on the web, ActionScript has evolved beyond a traditional scripting language and has become a fully OOP language.

This article is not intended to be a tutorial of any sort, it’s more of a brief history of ActionScript from its beginnings to AS3.

ActionScript from play() to package{}

In the earliest versions of Flash, scripting support was limited to handling very basic functionality. Simple methods like stop() and play() were the main staples, but as Flash began to stake its claim as a viable rich media format on the web, developers started to push the limits of the language and began to require ever more powerful scripting capabilities.

New functionality was continually added to subsequent releases, but it was not until the release of Flash 4 in 1999 that scripting was implemented. Flash 4 scripting introduced variables and conditionals—huge elements in a scripting language—and enabled the creation of more interactive content. Finally, in August 2000, ActionScript 1.0 (AS1) was formally introduced with the release of Flash 5. This release marked the start of a trend in ActionScript that is now nearing fulfillment, namely, to transition Flash’s coding language from a quirky scripting language to a fully realized programming language based on the ECMAScript 4 scripting proposal. The potential for Flash to take the web by storm was already there; giving developers a more familiar language and powerful control would be the catalyst for Flash’s acceptance and creative dominance on the web.

(If you were wondering, ECMAScript is an international programming language that is viewed by many as the standard for handling events, objects, and actions in a programming language. Before it was standardized, it was known as Netscape JavaScript.)

Soon after AS1 was introduced, more robust and dynamic Flash applications began to be developed. However, AS1 was still very much a unique language with serious limitations. At the top of the list of its shortcomings was a lack of class support. Not having class support either kept developers from working in an object-oriented manner, or required them to use programmatic workarounds such as _prototype. Either way, developers were having trouble writing the clean OOP code they were used to in other programming languages. Fortunately, Macromedia was aware of Flash’s limitations and was working on a way to make ActionScript OO-capable while still supporting all of its legacy code and syntax. Within two years of the release of AS1 came the release of Flash MX 2004 (version 7.0), and with it the inclusion of ActionScript 2.0 (AS2).

AS2 was a major step toward bringing ActionScript up to par with other development languages such as C# and Java. It allowed for developers to more easily implement object-oriented design patterns and techniques into their Flash projects by including an OOP development model. While moving to a class-based approach helped developers to design their applications with scalability and re-use in mind, some tension still remained—AS2 was not a real OOP language in many people’s eyes. While it implemented concepts such as strong typing of variables and core OOP techniques such as extension and polymorphism, it still relied on legacy methods and techniques (for example, having to use this.createEmptyMovieClip() instead of new MovieClip()). Another outstanding issue with AS2 was how events were handled: Listeners were attached in various ways depending on what type of object you were trying to use. For example, a v2 component would require the addEventListener method to be used, but with different parameters than other object types that harnessed AS2’s event capabilties. Furthermore, the standard mouse events for objects such as MovieClips and Buttons could only be accessed via standardized handlers such as onPress and onRelease, and would not respond to the addListener or addEventListener methods. Considering these minor drawbacks, AS2 was a welcome addition to Flash, and helped push its limits even further than before.

as-new-and-more-complicated-flash-applications-began-to-be-deployed,-many-developers-were-overclocking<-em>-flash,-and-their-apps-were-starting-to-eat-up-resources-on-end-user-machines.-in-other-words,-co”ActionScript 1″>AS1, the AVM1 is still included in the new version of Flash Player, and you can continue to develop in AS1 or AS2. However, to utilize the much improved and much faster AVM2, you must use AS3. Why target AVM2? There are many answers, but the biggest are simple: It’s much faster, more secure, and its penetration is sky-rocketing. According to Adobe’s estimates, it has an average general speed increase of eight to fifteen percent over its predecessor. Adobe does clarify that the speed improvements are feature-based; certain features and calculations run twice as fast, while others run up to one hundred times faster. As far as Flash Player 9 penetration, heavy hitters such as MySpace and YouTube have required their users to upgrade to Flash Player 9, so this release has seen unusually fast browser penetration. Also, the Express Install feature allows users who have not yet upgraded to the newest version of the player to perform an easy, player-based installation that returns the user right back to the Flash content.

Keeping the AVM1 was a hugely beneficial decision on the part of Adobe, as it allowed for legacy content to continue to be played and developed. It also allowed for an as3<-abbr>-project-targeting-avm2-to-utilize-old-content-for-example,-to-load-an-.swf-file-targeting-avm1-.-even-with-legacy-support,-it-is-to-everyone-#8217-s-advantage-for-new-content-to-target-the-avm2.-i”ActionScript 2″>AS2, strong typing your variables (defining a variable’s type when the variable is declared) was introduced as a best-practice approach. It encouraged developers to write cleaner code and it eased debugging by allowing the compiler to fuss over cross-typing errors that could mess up an application during runtime. However, it did not increase the efficiency of the end product. In AS2, all variables (whether strongly typed or not) were considered dynamic types, meaning more memory was required to store them as the Flash Player had to allow these variables to be recast at runtime. In the AVM2, the opposite is true; only variables left un-typed will be allotted the extra memory space, while the typed variables will only be allotted the memory needed for that variable type. Since computer memory and processing power are finite resources, the more efficiently they are used, the better an application—and the computer itself—will run.

Another major change in the AVM2 was run-time error checking. In previous versions of ActionScript, if a variable was mis-typed (for example, a a variable typed as a number was trying to hold a string value), the AVM1 would cause a compiler error and would prevent the entire SWF file from compiling correctly. Using the Flash 9 public beta (the publicly available version that allows for compiling AS3 code for the AVM2) it is easy to notice that the AVM2 breaks down gracefully from such errors. If a typecasting error is detected, it throws a runtime error which will not prevent other areas of your SWF from continuing to work. (While it could be assumed the error-checking will remain the same in the upcoming Flash IDE release [Flash CS3], it is a little premature to make any definitive claims.)

Summary

There are many more great changes to the new ActionScript virtual machine, and the new Flash Player in general. However, many of them are beyond the scope of this article. Simply noticing performance increases when using the new player and viewing AVM2 targeted content have convinced me to preach its benefits (not to mention the wonderful development strides that come with AS3). If you haven’t done so, download the newest version of the Flash Player. If you are a flash geek and still have not yet worked with AS3, grab the public alpha of Flash 9 (essentially Flash 8 with AS3 support), Flex Builder 2, or the free Flex SDK and start getting familiar with AS3.

Hopefully I’ve whet your Actionscript 3.0 appetite; in the future, I hope to delve into the language itself and highlight some of its key new features, including the new display list, E4X (the new XML library), standardized event handling, regular expressions, and others.

References

• AS3 language reference
• Introducing FlashPlayer 9
• Grant Skinner’s blog
• Flash Player Download Center
• Flex Builder 2 Product Page
• Free Flex 2 SDK (software development kit)

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Flash, Programming