Rants of a Robert Penner Flash MX Disciple
So Robert Penner looks like just like any other young man from Canada, tracing his lineage back to Europe. He’s looks like just another skinny kid—nothing like Martin Luther. But the man is inspiring. I am a self-declared disciple of the philosophy outlined in the first chapter of his book, Programming Macromedia Flash MX. It is in this context that I make my declarations:
Realistically Maintainable Flash MX Sites
I want to build realistically maintainable Flash MX presentations/applications. I use the words “realistically maintainable” to encapsulate my frustration with previous versions of Flash, which were really designed for a determined refugee from Adobe Illustrator, Quark XPress or Macromedia Director (or, even Authorware). Such people worked much harder than I ever voluntarily would to publish their compelling motions and interactions on the web.
These people may have been paid very well to sift through pages and pages—and stages and stages—of static content, so why should working in Flash be any different? When I see a Flash Movie file full of blank frames, I see hard such work. When I see a Movie with hand-built motion tweens, I see more hard work. When I don’t see a Flash SWF file because the browser I happen to be using totally sucks, I see a lot of hard work down the drain. So as much as I would like to be thought of as a hip, cool interactive web designer wearing Elvis Costello glasses, I have steadfastly avoided investing my web life in Flash until I was able to achieve some semblance of the following ideals:
ActionScript Automation of Designs Previously “Hand Built”
I want to write code that automates things in Flash that would take way too long to do by hand. As my father (and my father’s father) says, “You work work: don’t let work work you!” Automation by ActionScript programming is the key to working smarter, not harder in Flash. Version 5 of Flash was the first time this key concept was taken seriously. Flash MX takes this even more seriously. The foundation of my toolkit consists of examples of how ActionScript can automate many of the tedious tasks that had to be done “by hand” in Flash (using the Timeline). These examples include:
- Slowing down, speeding up and/or delaying perceived Movie Clip playback without having to insert blank frames by hand.
- Creating a simple motion tween without building a tween by hand.
- Preloading and displaying JPEG images without having to import them into Flash by hand.
- Fading one Movie Clip into another without building a tween by hand.
- Using a Movie Clip as button to simultaneously simplify the design and increase the complexity of interactions.
- Creating complex motion tween thanks to kick-ass code from Robert Penner.
Working with a Mature Design Time Interface
I want to write my Flash ActionScript code in an editor as “good” as Microsoft Visual Studio .NET. Knowing that billions of U.S. dollars were behind VS.NET, I will settle for an editor as functional as Macromedia HomeSite, originally from those Allaire folks that gave us Cold Fusion—and now Macromedia’s Cold Fusion MX. Macromedia Dreamweaver MX is very, very close to this ideal but I still wish for the following:
- To be able to delete a line of code with a keyboard shortcut without having to resort to an extension.
- A more sophisticated Find/Change feature that at least matches the one in Macromedia HomeSite.
- The ability to switch focus from one pane to another with “obvious” keyboard commands.
The code editor in Flash MX is promising beta material—but this thing can’t do simple things like preserving indenting after a properly placed carriage return and returning focus back to the editor while switching among applications. I also cannot stand having to reposition the Library window every time I open it. I understand that maintaining state in these user interfaces must be extremely complex. So I don’t expect much relief outside of Microsoft soon. Hey, Microsoft is good at something folks—not even Darth Vader is 100% evil. I think they did a swell job bringing the document editing experience in Visual Studio and in Office to the masses—and, when it comes to Knowledge Base documentation and online help, they have no serious rivals. Macromedia is years behind and/or one acquisition away from catching up.
Implementing Data-Centric Solutions for Quick, Easy Ongoing Maintenance
I want to implement more data-centric solutions in Flash so that ongoing maintenance of my Flash-based “web parts” will be easier. Now that “real” classes can be built in Flash MX, I have a tool that I can really, really use. Coupled with the #include directive (introduced in Flash 5), I can create and edit classes in Dreamweaver MX and “register” them with movie clips via the Linkage… command in the Library. I am now able to hobble something together similar to a central “include folder” on a web server where common routines and classes are kept for all web applications.
Just one version earlier, in Flash 5, you might have blown 40-something bucks on Brendan Dawes rapping to you about creating empty movie clips and writing code per instance of said empty movie clip. In Flash MX, using blank movie clips packed with code is not quite out of the picture but, using class definitions between #initclip and #endinitclip directives, you have the option of writing that code once (for all instances) and storing it in a Library (to be called from the Library at design time or runtime).
Way down here in this paragraph, you might notice that I have not mentioned XML, talking about data-centric solutions. Well, flippantly speaking, I am more impressed with the loadVars() object (method?) new to Flash MX (so new as to not be documented in the application help files but can be found online) than the “processor intensive” XML reader (is it really implementing SAX?). This version of the toolkit, however, does come with an XML-related item—in fact, it is an XHTML item, demonstrating the multi-purposing of data (see below).
Passing through the Door’s of Penner Perception
Thanks to the first six chapters of Programming Macromedia Flash MX I have seen the light! There are some key concepts that I glean from the material that I need to discuss immediately:
ActionScript Classes
Lines of code that define a Flash MX ActionScript class begins with setting a variable, your class name, equal to an anonymous function. It is good programming practice to attach your class explicitly to the _global object with the following form:
_global.MyClass = function(){
//constructor function statements...
This anonymous function is the constructor of the class. Because the constructor function is of the Function() object, it contains the prototype property (of type 'object'). The prototype property is then used to define additional anonymous functions that serve as the methods of the ActionScript class. This is why the prototype property is often regarded as “the glue” that holds a class together as it allows a set of anonymous functions to be grouped together under one constructor function. Following the form above, we have:
MyClass.prototype.myMethod = function(){
//method function statements...
where the call to MyClass.prototype.myMethod shows our prototype property literally “gluing” myMethod to MyClass.
The properties of an ActionScript class “formally” come from anonymous functions of the prototype property designed to be “getter/setter” methods that are used in the prototype.addProperty() method. “Informal” class properties are defined by badly scoped variables and the this.propertyName syntax. ActionScript does not protect what can be called “private” properties as of this writing.
The _global Object
Flash MX native classes and instantiated objects are stored in the _global object. The following table summarizes the contents of the _global object:
| Flash 5 Classes | Flash 5 Objects | New Flash MX Classes | New Flash MX Objects |
Array
|
Cookie
|
Button
|
Accessibility
|
Boolean
|
Key
|
Camera
|
ASBroadcaster
|
Color
|
Math
|
Function
|
CustomActions
|
Date
|
Mouse
|
LoadVars
|
Stage
|
MovieClip
|
Selection
|
LocalConnection
|
System
|
Number
|
Microphone
|
System.capabilities
|
|
Object
|
NetConnection
|
System.security
|
|
Sound
|
NetStream
|
||
String
|
SharedObject
|
||
XML
|
System.Product
|
||
XMLNode
|
TextField
|
||
XMLSocket
|
TextFormat
|
||
Video
|
The implication is that:
trace(_global.Array == Array)/*returns true*/;
or
trace(_global.Stage == Stage)/*returns true*/;
It may be good programming practice to “fully qualify” Flash classes and objects in your code to remember just how important the _global object is.
The Difference between Flash Objects and Classes
The Flash objects summarized in the table differ from built-in classes in that they do not have a prototype property:
trace(_global.Math.prototype)/*returns undefined*/;
or
trace(_global.Stage.prototype)/*returns undefined*/;
This implies that Flash objects do not have constructor functions. This also implies that these objects do not necessarily inherit from the Object() object. We can suggest that this is the case for Flash classes by using the __proto__ property in an equality:
Object.method = function(){
return this.prototype;
Function.method = function(){
return this.prototype.__proto__;
trace(Object.method() == Function.method())/*returns true*/;
The return statement of Function.method() shows that it contains some “unknown” instantiated object, its __proto__ property. When trace() returns true we may conclude that the prototype property of Object and the __proto__ property of this “unknown” instantiated object of Function are pointing to the same place in memory. It would follow that when this.prototype.__proto__ != undefined inside our method, we have discovered evidence of inheritance.
The information provided by Bryan D. Wilhite at kintespace.com is provided “as is” without warranty of any kind. In no event shall Bryan D. Wilhite or any of his affiliates be liable for any damages whatsoever including, but not limited to, direct, indirect, incidental, consequential, loss of business profits or special damages due to material published by Bryan D. Wilhite or any of his affiliates.