Home >
Note: this article continues the discussion started by Colin's earlier Inside RIA article, ActionScript 3.0: Is it Hard or Not?
Adobe has made some impressive progress transitioning Flash from plug-in to platform over the past couple of years. The foundation is now in place: there's a proper programming tool (Flex Builder), a desktop runtime (AIR), and a mature language (ActionScript 3.0). Adobe is even working on its own line of killer apps—a prerequisite for any platform. Photoshop Express, Buzzword, and AMP are already live, with surely more to come. Meanwhile, Flash Player's evolution continues at a dizzying pace. Astro, a.k.a. Flash Player 10, is set to introduce basic 3D, high-performance graphics effects, dynamic sound generation, and a new text engine that supports right-to-left and vertical text layout. (And there was much rejoicing.)
But despite all the talk of GPU blitting, pixel shading, and ligatures, a non-negligible percentage of the Flash community is rightfully asking: is Adobe still committed to the simple, agile authoring practices on which Flash was founded? It's a rational enough concern. After all, Flash built its success on "ease of use." Some 11 years ago, the tagline on the Flash 2 box read: "The Easiest Way to Create Fast Web Multimedia." Originally, Flash was purpose-built for people who wanted to make things move without years of animation training, or who wanted to create interactivity and programmatic behavior without a degree in computer science. A decade of loyalty later, those same people—call them the "everyday Flashers"—are now wondering how, or even if, they fit into Adobe's new platform strategy.
Although the general concern over Flash's ease of use is natural, much of it is based on fear, not facts. Despite doomsday predictions that Adobe is abandoning its core Flash user base my impression is that Adobe thinks very highly of the "everyday Flashers." In fact, if the new tweening model and inverse kinematics support in Flash are any indication, Adobe's Flash team seems thoroughly committed to improving content-creation workflows. Approachable authoring experiences, however, take time to develop and refine in the context of new features. In fact, for some kinds of content, the most approachable authoring experience might one day have nothing to do with the Flash authoring tool. As the Flash platform evolves, it seems logical to expect a variety of content-specific authoring tools to emerge, from both Adobe and third parties. Adobe is already developing at least one such tool for the Flash platform, codenamed Thermo.
But for now, huge numbers of Flashers still have to get their work done in the Flash authoring tool as it stands today, taking the good with the bad. More than a year has passed since Flash CS3 was released to widely positive reviews, but many Flash users are still frustrated by some of the workflow changes introduced by ActionScript 3.0. The truly problematic changes are relatively few, but together they have a deep effect on the typical Flash user's daily job.
In the spirit of working toward solutions, and of giving a formal voice to the collective grumbling of everyday Flashers, this article provides a guide to The Charges Against ActionScript 3.0. The list of accusations follows; mostly it applies to the Flash authoring tool, not to Flex Builder.
- The removal of on()/onClipEvent() from Flash CS3 makes creating simple interactivity hard.
- Getting rid of loaded .swf files is hard.
- Casting DisplayObject.parent makes controlling parent movie clips hard.
- The removal of getURL() makes linking hard.
- The removal of loadMovie() makes loading .swf files and images hard.
- ActionScript 3.0's additional errors make coding cumbersome.
- Referring to library symbols dynamically is unintuitive.
- Adding custom functionality to manually created text fields, to all movie clips, or to all buttons is cumbersome.
- The removal of duplicateMovieClip() makes cloning a MovieClip instance (really) hard.
Note that the title of this article, "The Charges Against ActionScript 3.0," is something of a misnomer. In many cases, ActionScript 3.0 as a language is accused of crimes it has never committed. Many of the problems in the preceding list are best solved not at the language level, but at the tool level. For example, the ActionScript 3.0 navigateToURL() function is clearly an improvement over its predecessor, getURL(), but navigateToURL() is also more difficult for nonprogrammers to use. The solution is not to revert to the inferior getURL(), but rather to provide an easier workflow in Flash for adding hypertext links to buttons. A new "link" tool could provide a Flash 4-style menu interface for creating links while completely obscuring the underlying ActionScript 3.0 code. Or maybe the time has come for someone to make an entirely new application for building simple Flash websites and animations. Such a tool could even be written in ActionScript, and deployed as an AIR app. But I digress...
The following sections describe the preceding charges, their possible solutions, and suggested courses of action for both Adobe and the Flash community. If you're affected by these issues, I'd like to encourage you to take the actions suggested. Also feel free to add to this discussion by leaving a comment below. With any luck, collectively we might be able to affect Adobe's future decision making.
For the record, I should point out that despite the issues discussed in this article in my opinion ActionScript 3.0 is vastly superior to ActionScript 2.0 and ActionScript 1.0. Growing pains aside, ActionScript 3.0 is the language of choice for any Flash-platform project. Now, on to the charges.
Charge #1: The Removal of on()/onClipEvent() from Flash CS3 Makes Creating Simple Interactivity Hard
The Accused: Flash CS3
The Verdict: GUILTY
Before the release of Flash CS3, you could add interactivity to movie clips and buttons using the on()/onClipEvent() visual-coding system. For example, imagine an animation whose final frame has a Replay button. When the button is clicked, its parent timeline starts playing at frame 1. In Flash 8, here are the steps you'd follow to implement the Replay button's functionality:
- Select the button.
- Enter the following code into the Actions panel:
on (release) { this._parent.gotoAndPlay(1); }
In Flash CS3, in an ActionScript 3.0 .fla file, here are the equivalent steps:
- Assign the button an instance name, "replayBtn".
- Select the frame containing the button.
- In the Actions panel, define a function to listen to the button's MouseEvent.CLICK event:
function replayBtnClickListener (e) { gotoAndPlay(1); }
- Still in the Actions panel, register replayBtnClickListener for the button's MouseEvent.CLICK event:
replayBtn.addEventListener(MouseEvent.CLICK, replayBtnClickListener);
The Flash CS3 approach makes development harder for inexperienced programmers in four different ways. First, it requires an understanding of function creation and function references. Second, it uses a more complicated event name for the mouse click ("MouseEvent.CLICK" versus "release"). Third, in the Flash 8 scenario, the button can be moved or copied from one place to another while retaining its code; in Flash CS3, the button and code have to be moved separately. Fourth, the on() approach creates a listener and automatically registers that listener in one phrase of code, whereas the ActionScript 3.0 approach separates the listener creation and registration. To be fair, ActionScript 3.0 actually also supports inline listener creation and registration:
replayBtn.addEventListener(MouseEvent.CLICK, function (e) {
gotoAndPlay(1);
});
But ActionScript 3.0's inline syntax is less intuitive, is more prone to error, and leaves the program with no reference to the listener.
The preceding four issues are not trivial. Flash CS3 is sorely lacking a reliable, clean, visual system for assigning interactive behavior to graphical assets on stage. Nevertheless, I don't think that on() and onClipEvent() should be reintroduced. Here's why: first, although they are convenient and easy to understand, excessive use of on()/onClipEvent() can easily lead to a messy, unmaintainable .fla file. Second, on()/onClipEvent() introduces its own syntax for event handling, which complicates the language needlessly. Third, on()/onClipEvent() doesn't even do a good job at providing an "easy-to-use" tool for creating interactivity. To use on()/onClipEvent(), the Flash user still needs to learn the on() syntax itself, and has to remember (or look up) the available events ("press", "release", etc.).
But if resurrecting on()/onClipEvent() isn't the right thing to do, what is?
What Should Adobe Do?
Adobe should reintroduce a visual system for producing interactivity—but should modernize it. Get it right this time. Make a system that's even more helpful for nonprogrammers than on()/onClipEvent(). Make it write real ActionScript 3.0 behind the scenes, and let users move objects and behavior together (or choose not to, at their discretion). Here's just one idea: if a user clicks on a button, give her a list of supported events in a pull-down menu. Let the user choose the event and provide the "response" by selecting from a group of actions (go to URL, stop timeline, etc.). At compile time, change the response code to real ActionScript 3.0 code in the button's container class. And let the user see that code at author time via a central code viewer for all buttons in the .fla file, with the option to navigate to individual buttons.
Regardless of the actual interface, the Flash authoring tool needs its visual-coding system back. I firmly reject the notion that because ActionScript is becoming more powerful we should all "grow up" and learn to use MouseEvent.CLICK and event listeners. Such nonsense is programming egotism. What we should all do is use the right tool for the job. Simple content should be easy to build.
Does Adobe agree? At the grass-roots level, definitely. The Flash authoring team is very much in touch with their users, and the on()/onClipEvent() issue is well known internally. In February 2008, I met with Richard Galvan (the Flash authoring tool product manager), and he assured me that the topic of visual coding is considered significant. Unfortunately, "doing things right" takes time. Reviving on()/onClipEvent() in its old, insufficient form would be comparatively easy. But conceiving of, implementing, and testing a new and improved ActionScript 3.0 approach isn't trivial. Mr. Galvan couldn't commit to any time frame for an improved on()/onClipEvent() feature, but we both agreed that Adobe ought to build one. Hopefully, he'll be able to help convert that intention into action within the next version or two of Flash.
What Should We Do?
As a community, we'll need some patience while Flash evolves. Flash Player might be at version 9, but as a whole, the "Flash platform" is realistically only at version 1. During the Flash Player 9 time frame, Adobe released ActionScript 3.0, Flex 2.0, and AIR 1.0. That's a lot of new technology. Things will improve over time, particularly if the community voices its needs strongly. If you want your buttons back, post a comment at the end of this article. Adobe has a history of listening to sincere petitions for improvements in Flash (see the MovieClipLoader, Failure to Unload, and Make Some Noise campaigns).
In the meantime, I'm looking forward to Thermo, which will have a visual coding system. Mr. Galvan pointed out that Flash will naturally be in a good position to learn from Thermo's successes and failures, so it's worth giving feedback on that product even if you don't intend to use it regularly. And remember to keep an eye on labs.adobe.com, where Adobe previews its new tools.
Charge #2: Getting Rid of Loaded .swf Files Is Hard
The Accused: ActionScript 3.0
The Verdict: GUILTY
Prior to ActionScript 3.0, when a parent .swf file loaded a child .swf file, it could subsequently remove that child by calling removeMovieClip(). Calling removeMovieClip() stopped the child's events and play heads, which typically allowed it to be purged from memory (i.e., garbage-collected). In Flash Player 9, there is no removeMovieClip() equivalent. Instead, to remove an .swf file from memory in Flash Player 9, the programmer must manually deactivate and dereference it, ensuring that:
- The parent .swf file has no references to the child .swf.
- Flash Player has no references to the child .swf.
A parent .swf file can, of course, remove its own references to the child, but it cannot guarantee that 1) the child has not created a reference to itself in the parent (normally by registering a listener), and that 2) Flash Player itself has no references to the child .swf. Flash Player will hold a reference to the child if the child has registered for input or system events, or has active processes running, such as a sound playing or a file downloading. Hence, to remove a child .swf file, the programmer must follow these steps:
- Manually deactivate the child's active processes.
- Manually remove the child's system and input listeners.
- Manually dereference the child.
Although nice in theory, the manual approach poses several practical problems:
- Manual deactivation of the child (i.e., removing its event listeners, stopping sounds, stopping timelines and timers, closing network operations, etc.) can be a lot of work, adding complexity and development time to a project.
- Manual deactivation of the child is error-prone because the child might have dozens or hundreds of active input-event listeners, network connections, animations, and timers to track and disable. If the programmer forgets to unregister just one Event.ENTER_FRAME listener, the child .swf will never be purged from memory.
- Adobe currently does not publish an authoritative list of things to deactivate before a child .swf can be purged, so developers are often left guessing when their content fails to be removed from memory.
- Parent .swf files that load child .swf files from third-party sources cannot guarantee that the third-party child will deactivate itself properly. Hence, building applications and sites that aggregate third-party content is hazardous in Flash Player 9.
What Should Adobe Do?
In the short term, Adobe needs to:
- Publish a list of everything that needs deactivation in a loaded .swf file before that .swf can be purged from memory. Until such a list is published, I'll maintain one on my blog—but my list is, by definition, insufficient because it is neither official nor exhaustive.
- Update the ActionScript Language Reference, adding a warning to every item in the API that requires deactivation when used in a loaded .swf. For example, under Sound.play(), Adobe should add this warning: "An .swf file that starts a sound cannot become eligible for garbage collection until that sound has stopped playing."
- Institute an internal documentation procedure guaranteeing that the preceding two publications are kept up-to-date as new features are added to each Flash runtime.
In the long term, Adobe needs to invest the engineering resources required to develop an API for deactivating a child .swf, and perhaps also for brute-force purging of a child .swf from memory. Such an API will be hard to get right and hard to maintain, but I think it's required if Flash is to retain its status as an agile, approachable platform. Flash's current success is partly based on its low barrier of entry for content creators. Presumably, then, adding helpful tools that keep the platform approachable is worth the effort.
Fortunately, thanks in part to the efforts of Grant Skinner, who recently championed the need for better unloading, Adobe is already actively exploring the issue of display-object deactivation and garbage collection. Flash Player 10 beta already includes a fix for a serious garbage collection bug reported by Mr. Skinner (.swf files with timeline code can't be garbage-collected). Flash Player 10 beta also provides a direct API for requesting garbage collection, in both the debug and release versions. Further, according to Flash Player engineer Werner Sharp, Adobe is investigating whether it's feasible to add two new deactivation features in future Flash runtimes:
- A general deactivation method for halting a child .swf file's active processes. This feature has partly already come to fruition; see unloadAndStop() in Flash Player 10's release notes and the additional information provided by Mr. Skinner.
- An API for loading an .swf file into a "content sandbox" (a term originally proposed by Mr. Skinner). When loaded into a content sandbox, the child .swf would be prevented from accessing both its parent and the stage, thus preventing the child from creating references that would prevent it from being garbage-collected.
Together, the preceding two experimental features would drastically reduce the effort required to manually purge a loaded child from memory.
In addition to the changes already being explored, I'd like to see Adobe bring back the ability to completely remove all content from Flash Player before loading a new .swf file. That is, ActionScript 3.0 needs an equivalent for this ActionScript 2.0 code:
loadMovieNum("newContent.swf", 0);
For more thoughts on deactivating and purging loaded content from Flash Player, see the following resources:
- My interview with Flash Player engineer Jim Corbett (the relevant discussion starts at around 25:30)
- Grant Skinner's article, Failure to Unload: Flash Player 9's Dirty Secret
What Should We Do?
Until an .swf-deactivation API becomes part of Flash Player, developers creating loaded content should:
- Learn to know and love the .swf deactivation list. Every child .swf file should supply a custom-made deactivate() method that must be called before the parent dereferences that child.
- Consider loading .swf files from a separate subdomain so that their parent and stage access is limited (thanks to Mr. Skinner for recommending this technique).
- Use Flex Builder 3's profiler tool to track every application's object usage, memory consumption, and performance.
Charge #3: Casting DisplayObject.parent Makes Controlling Parent Movie Clips Hard
The Accused: Flash CS3
The Verdict: GUILTY
Since movie clips were introduced in Flash 3, child movie clips have been able to control their parent timelines. For example, the original "actions" required to play a parent timeline looked like this:
Begin Tell Target ("../")
Play
End Tell Target
In Flash 5, those actions were replaced by object-oriented code that looked like this:
this._parent.play();
In Flash CS3, the underscore was removed from "_parent", so the code now looks like this:
this.parent.play();
However, if you try that code in Flash CS3, you'll get this error:
1061: Call to a possibly undefined method gotoAndStop through a reference
with static type flash.display:DisplayObjectContainer.
Why? Because the datatype of the "parent" variable is DisplayObjectContainer, not MovieClip. To make the code work, this.parent must be cast to the MovieClip datatype, as follows:
MovieClip(this.parent).play();
The preceding error message and its resolution are perfectly logical to computer scientists—but completely confounding to most animators. Ironically, it is the animators, not the programmers, who typically need to control timelines. Flash 3 let nonprogrammers control parent timelines with ease. Flash CS3 broke that long-standing tradition. Something has to be done. Animators want their easy timeline control back.
What Should Adobe Do?
At the very least, Adobe should enhance the Flash compiler so that it inserts an automatically generated cast wherever feasible, allowing error-free access to a parent's variables and functions. Here's how the automatic insertion could work:
- First, check whether all author-time instances of a given symbol have the same type of parent; if so, cast to that parent's class wherever necessary
- For symbols whose instances have incompatible types of parents, wherever irresolvable references to parent functions or variables are made, generate a nice, nonprogrammer-readable error.
- If the programmer uses a manual cast, honor that cast instead of attempting to insert one automatically.
In the future, Adobe should also consider adding GUI tools for assigning common behaviors to both parent and child movie clips. The current Script Assist feature is too cluttered to be useful for simple interactions.
Of course, it's easy to ask Adobe to "add GUI tools for creating simple interactions," but it's hard to actually design and implement them. Making the right GUI tools available to the right audience in the right contexts is something of a software-industry Holy Grail. And it's not as though the Flash team hasn't clearly tried to add nonprogrammer tools before (see normal mode, designer view, slides, and behaviors). But I think there's still room to explore.
What Should We Do?
Submit the following Flash feature request via Adobe's wish form:
- Product Name: Flash
Product Version: CS4
Request: Easy Parent Timeline Control
On a movie clip timeline, please allow error-free access to the parent's variables and functions by adding an automatic cast wherever feasible.
You might also want to leave a comment on Richard Galvan's blog.
As a brute-force workaround to the parent casting issue, developers can consider turning off strict error-checking mode by unchecking Strict Mode, under File→Publish Settings→Flash→ActionScript 3.0 Settings→Errors. Note, however, that disabling strict mode also suppresses all compile-time type checking, and is not recommended for projects with nontrivial code.
Charge #4: The Removal of getURL() Makes Linking Hard
The Accused: ActionScript 3.0, Flash CS3
The Verdict: ActionScript 3.0, NOT GUILTY; Flash CS3, GUILTY
In ActionScript 1.0 and 2.0, the code required to make a link to http://www.oreilly.com looked like this:
getURL("http://www.oreilly.com");
In ActionScript 3.0, the equivalent code looks like this:
navigateToURL(new URLRequest("http://www.oreilly.com"));
The ActionScript 3.0 code is a little more verbose, but it also provides more features and has a cleaner API for sending variables to the destination URL. Nevertheless, some developers miss the convenience of getURL(). Fortunately for them, it's easy to re-create getURL() with a little custom code. Example 1 shows how. It contains an ActionScript 3.0 getURL()-equivalent function for loading a URL into a browser. Note, however, that unlike the real getURL(), Example 1's version does not support sending a movie clip's timeline variables to a server-side application. If you need to send variables to a server in ActionScript 3.0, you should use navigateToURL()'s much cleaner variable-sending API.
Example 1: An ActionScript 3.0 getURL()-Equivalent Function
package {
import flash.net.*;
public function getURL (url:String,
window:String = "_self"):void {
var u:URLRequest = new URLRequest(url);
navigateToURL(u, window);
}
}
To use the preceding getURL() replacement, copy the code into a file named "getURL.as" and then place that file in the root of your program's classpath. If you're not familiar with the classpath, just place getURL.as in the same directory as your .fla file (Flash CS3) or in your main source directory (Flex Builder). Once the file is in place, you can use getURL() like this:
getURL("http://www.oreilly.com");
getURL("http://www.oreilly.com", "_blank");
What Should Adobe Do?
From a language perspective, Adobe has done the right thing already. ActionScript 3.0's navigateToURL() function is cleaner than the legacy getURL(), and it provides more features. However, from a tool perspective, there's work to be done. For the benefit of newer programmers and nonprogrammers, future versions of Flash authoring should provide a simplified GUI for creating hypertext links in Flash content.
What Should We Do?
Programmers: learn to use navigateToURL(), particularly when sending variables. Some keystroke-frugal coders will want to use a simple pass-through function such as the one shown in Example 1.
Nonprogrammers: wait for Adobe to introduce new workflows for creating simple interactivity. Tell Adobe you want easy-to-use linking tools by submitting the following Flash feature request via Adobe's wish form:
- Product Name: Flash
Product Version: CS4
Request: Easy Links
Please make an easy-to-use tool for creating hypertext links. The current navigateToURL() function is too hard to use.
Charge #5: The Removal of loadMovie() Makes Loading .swf Files and Images Hard
The Accused: ActionScript 3.0
The Verdict: GUILTY (but there's a workaround)
In ActionScript 1.0 and 2.0, the code required to load a file named "animation.swf" into a movie clip looked like this:
theClip.loadMovie("animation.swf");
In ActionScript 3.0, there is no direct way to load an .swf file into an existing movie clip. Instead, the file must be loaded by a Loader object, and then added to a parent movie clip (or any other DisplayObjectContainer object). The code looks like this:
var l:Loader = new Loader();
l.load(new URLRequest("animation.swf"));
theParent.addChild(l);
The ActionScript 3.0 code is more consistent with the rest of the ActionScript 3.0 API, and it offers more control over the load operation, security, and loading events. Nevertheless, many developers miss the convenience of loadMovie(). Fortunately for them, it's possible to create a loadMovie() equivalent with a little custom code. Example 2 defines a custom function, loadChildAsset(), that offers most of the convenience of ActionScript 1.0/2.0 loadMovie() function. Note, however, that loadChildAsset() is not exactly the same as the original loadMovie(); instead of replacing the target, it makes the loaded asset's Loader object a new child of the specified parent. The loadChildAsset() function also returns a Loader object through which the load operation can be halted. Finally, loadChildAsset() can be passed listener functions for handling load events such as Event.COMPLETE and ProgressEvent.PROGRESS. (Note that as with any load operation, developers should not access the loaded asset until Event.INIT has occurred.)
Example 2: The loadChildAsset() Function
package {
import flash.display.*;
import flash.events.*;
import flash.net.*;
public function loadChildAsset (parent:DisplayObjectContainer,
url:String,
completeListener:Function = null,
initListener:Function = null,
progressListener:Function = null,
ioErrorListener:Function = null,
method:String=null
):Loader {
// Create the Loader and URLRequest objects
var l:Loader = new Loader();
var u:URLRequest = new URLRequest(url);
u.method = method ? method : URLRequestMethod.GET;
// Add the Loader object to the parent
parent.addChild(l);
// Output a warning for any error messages
l.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR,
function (e:IOErrorEvent):void {
trace("Loading error: " + e);
});
// Register any supplied event listeners
if (completeListener != null) {
l.contentLoaderInfo.addEventListener(Event.COMPLETE,
completeListener);
}
if (initListener != null) {
l.contentLoaderInfo.addEventListener(Event.INIT, initListener);
}
if (progressListener != null) {
l.contentLoaderInfo.addEventListener(ProgressEvent.PROGRESS,
progressListener);
}
if (ioErrorListener != null) {
l.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR,
ioErrorListener);
}
// Start the load operation
l.load(u);
// Pass the Loader object reference to the caller so the caller
// can stop the load operation if desired
return l;
}
}
To use the preceding loadChildAsset() function, copy the code into a file named "loadChildAsset.as" and then place that file in the root of your program's classpath. Here's how you can use loadChildAsset() in a timeline script to load a file named "animation.swf" as a child of the current movie clip:
// Load a movie as a child of the current movie clip
loadChildAsset(this, "animation.swf");
Here's how you can use loadChildAsset() in a class file with listener functions for responding to load events:
package {
import flash.display.*;
import flash.events.*;
import flash.net.*;
public class SomeApplication extends Sprite {
public function SomeApplication () {
loadChildAsset(this,
"child.swf",
childCompleteListener,
childInitListener,
childProgressListener,
childIoErrorListener);
}
public function childCompleteListener (e:Event):void {
trace("The file finished loading.");
}
public function childInitListener (e:Event):void {
trace("The file has been initialized.");
}
public function childProgressListener (e:ProgressEvent):void {
trace("Part of the file loaded.");
}
public function childIoErrorListener (e:IOErrorEvent):void {
trace("The file could not be loaded.");
}
}
}
What Should Adobe Do?
In creating ActionScript 3.0, Adobe purged the language of its many inconsistencies and limitations, and established a cleaner, more feature-rich API. But in some specific cases, Adobe also purged the language of popular, easy-to-use tools such as loadMovie(). Over time, Adobe should carefully and selectively strive to reintroduce equivalents for those tools.
What Should We Do?
For now, developers looking for convenient .swf-loading tools will have to create and share custom functions, such as Example 2's loadChildAsset(). The best ideas from the community should eventually be integrated into the core Flash runtime APIs.
Charge #6: ActionScript 3.0's Additional Errors Make Coding Cumbersome
The Accused: ActionScript 3.0
The Verdict: NOT GUILTY
ActionScript 1.0 and 2.0 were notorious for their lack of runtime errors and runtime datatype checking. Trivial datatype errors went unreported at runtime, forcing programmers to manually diagnose even routine problems such as misspelled variable names and missing function arguments. ActionScript 2.0 thankfully introduced datatype checking at compile time, but continued to let datatype errors go unreported for dynamically typed variables, parameters, and return values (all of which are commonly found in small scripts and rapid prototypes).
For example, consider the following erroneous ActionScript 2.0 code. It mistakenly uses the variable name "tex" instead of "text" when attempting to display some text on-screen.
someClip.createTextField("t",0, 0, 0, 100, 100);
someClip.t.tex = "Hello world"; // Oops! Should be "text" not "tex"
When the code runs, ActionScript 2.0 does not generate an error. Instead, ActionScript 2.0 creates a new variable named "tex" on the TextField object, and assigns it the value "Hello world". As a result, the programmer is effectively stranded. No text has appeared on-screen, and there's no error explaining what went wrong. The program might have a serious logical failure or a simple typographical mistake; the programmer has no way of knowing for sure without painstakingly examining the code line by line. ActionScript 3.0, by contrast, is very vocal about errors. It dutifully informs the programmer when it cannot execute some code. For example, consider the ActionScript 3.0 equivalent of the preceding erroneous code:
var t = new TextField();
t.tex = "Hello world";
In ActionScript 3.0, the TextField class is not dynamic, so when the code runs, ActionScript 3.0 generates the following error:
ReferenceError: Error #1056: Cannot create property tex on flash.text.TextField.
at Test()[c:\data\someProject\src\Main.as:10]
The error not only describes what went wrong ("Cannot create property tex"), but also indicates exactly where the program failed (line 10 of Main.as). As a result, the programmer can fix the error in a matter of seconds. ActionScript 3.0 reports all datatype errors, both at compile time and at runtime, so programmers can focus on logic rather than wasting time on typographical mistakes.
What Should Adobe Do?
Adobe has already done the right thing by increasing the number of errors reported by ActionScript. Now the company needs to focus on making the errors more readable for average programmers. Many ActionScript errors are too generic, or too filled with ECMAScript-specification jargon. Furthermore, the short error explanations provided in the documentation are insufficient. For example, consider the following error message from the preceding section:
Cannot create property tex on flash.text.TextField.
The message is technically correct, but it focuses on the runtime's point of failure rather than the programmer's probable intention. The error effectively says to the programmer, "You're trying to create a dynamic instance variable on a TextField object, but that's not possible because the TextField class isn't dynamic." The focus of the error message implies that the appropriate solution is to make the TextField class dynamic, thus allowing "tex" to be legally created. Of course, the programmer isn't trying to create a dynamic instance variable. The programmer simply supplied the wrong variable name for "text". The runtime should be smarter in this situation. It should account for the mistaken-variable-name case, as shown in the following potential rewrite of the error message:
Cannot assign 'Hello world' to variable 'tex' on an object of type
flash.text.TextField. Variable 'tex' does not exist and cannot be dynamically
created because TextField is sealed. See http://www.adobe.com/go/aserror1056.
The hypothetical linked page in the preceding error message would describe the problem in more detail, and give examples of typical causes and fixes for the error. Here are a few more examples of errors that are too arcane:
- 1061 Call to a possibly undefined method %s through a reference with static type %s.
- 1118 Implicit coercion of a value with static type %s to a possibly unrelated type %s.
- 1119 Access of possibly undefined property %s through a reference with static type %s.
- 1151 A conflict exists with definition %s in namespace %s.
What Should We Do?
As developers, we should all learn to love errors. Error messages are a programmer's best friend. They don't waste time, they save it. They're not trying to be frustrating; they're trying to be helpful.
Programmers who feel intimidated or frustrated by ActionScript 3.0's new errors should consider the following analogy: suppose you're getting off a train and the person next to you notices that you left your hat behind. Would you want that person to tell you that you forgot your hat and show you where to retrieve it? Or would you prefer to start searching for your hat only once you realized it went missing? ActionScript 3.0 would tell you about your hat; ActionScript 2.0 wouldn't. (Of course, until Adobe improves its error messages, ActionScript 3.0 might appear to be screaming at you in ancient Latin, but at least you know something's wrong.)
Error messages are a natural, routine, healthy part of programming. They help you fix the obvious errors in your code so that you have more time to focus on building features and diagnosing logical problems. The more error messages a language gives you, the more time you have to get your real work done. Remember, also, that ActionScript error messages appear in the debugger versions of Flash runtimes only. The general public won't see them.
For help deciphering ActionScript 3.0's error messages, see Adobe's compiler error reference.
Charge #7: Referring to Library Symbols Dynamically Is Unintuitive
The Accused: ActionScript 3.0
The Verdict: GUILTY
Imagine you're a Flash user who has created an .fla file with 10 movie clip symbols, named "Animation0" through "Animation9". You want to display an instance of all 10 symbols at runtime. In ActionScript 1.0 and 2.0, the code you would use to create the instances would look like this (note that, for brevity, the code does not use type annotations):
for (var i = 0; i < 10; i++) {
parentClip.attachMovie("Animation" + i, "instance" + i, i);
}
The equivalent ActionScript 3.0 code looks like this (again, type annotations have been omitted for brevity):
var Symbol;
for (var i = 0; i < 10; i++) {
Symbol = getDefinitionByName("Animation" + i);
parentClip.addChild(new Symbol());
}
The ActionScript 3.0 code has several benefits over the ActionScript 1.0/2.0 version. The first is API consistency: the code for dynamically referencing a symbol is exactly the same as the code for dynamically referring to a class. Second, no instance name is required; child movie clips do not need instance names because they are normally accessed by reference. Third, no depth is required; ActionScript 3.0's depth management system automatically creates depths for objects on the display list. Nevertheless, for typical Flash users the ActionScript 3.0 version of the code is less intuitive than the ActionScript 2.0 version. The ActionScript 2.0 version uses the terminology of the Flash authoring tool, which is familiar to Flash users. It says, "Add a new 'Animation0' movie instance to parentClip." The ActionScript 3.0 code uses the terminology of formal object-oriented programming, which is unfamiliar to many Flash users. It says, "Give me a reference to the class named ‘Animation0,’ create a new object from that reference, and make that object a child of parentClip." For many Flash users, when it comes to dynamically referencing a symbol ActionScript 3.0 no longer speaks their language.
Fortunately, as shown in Example 3, it's possible to create an attachMovie() equivalent with a little custom code. Example 3 defines a custom function, addChildFromLibrary(), which adds an instance of the specified symbol to the specified parent, at the specified depth (optional).
Example 3: An ActionScript 3.0 attachMovie() Equivalent
package {
import flash.display.DisplayObjectContainer;
import flash.display.DisplayObject;
import flash.utils.getDefinitionByName;
public function addChildFromLibrary (parent:DisplayObjectContainer,
symbolName:String,
depth:int = -1):DisplayObject {
var Symbol = getDefinitionByName(symbolName);
if (depth < 0) {
return parent.addChild(new Symbol());
} else {
return parent.addChildAt(new Symbol(), depth);
}
}
}
To use the preceding addChildFromLibrary() function, copy the code into a file named "addChildFromLibrary.as" and then place that file in the root of your program's classpath. Here's how you can use addChildFromLibrary() to replace attachMovie() in the earlier "10 animation symbols" example:
for (var i = 0; i < 10; i++) {
addChildFromLibrary(parentClip, "Animation" + i);
}
Like attachMovie(), addChildFromLibrary() uses terminology from the Flash authoring tool, and should therefore be more intuitive for Flash users.
What Should Adobe Do?
Fundamentally, Adobe made the right choice introducing symbols-as-classes in Flash CS3, and then providing a consistent way to dynamically reference both a regular class and a class linked to a symbol. However, getDefinitionByName() is not particularly approachable for less-experienced programmers. The addChildFromLibrary() function suggested in the preceding section shows at least one way to make dynamic symbol instantiation easier to understand. The question is whether Adobe should add such a function to the built-in MovieClip class. For now, I think not. Blindly adding helper functions to MovieClip could easily lead to the kind of clutter found in ActionScript 1.0 and 2.0, where MovieClip had an inconsistent variety of instantiation methods: createTextField(), createEmptyMovieClip(), attachMovie(), and duplicateMovieClip(). The MovieClip class (or, more precisely, the DisplayObjectContainer class) should not become a factory for creating all possible types of Flash content.
That said, Adobe should monitor ActionScript ease of use closely in Flash authoring and address the key Flash-centric issues carefully as the language matures. For example, to make dynamic symbol instantiation easier to understand, perhaps the Flash API should include a factory method, makeInstanceFromSymbol(), as a simple wrapper for getDefinitionByName(). The following code shows what makeInstanceFromSymbol() might look like:
// Signature
flash.utils.makeInstanceFromSymbol(symbolName:String):DisplayObject
// Implementation
public function makeInstanceFromSymbol(symbolName:String):DisplayObject {
return new getDefinitionByName(symbolName);
}
// Example Usage:
parentClip.addChild(makeInstanceFromSymbol("Animation" + i));
The makeInstanceFromSymbol() method would give "everyday Flashers" a more familiar syntax for dynamic symbol instantiation, without introducing inconsistency into the existing display API.
Whatever Adobe eventually does to make getDefinitionByName() more approachable, it should remain frugal when considering any addition to ActionScript's APIs. Adding too many "convenience functions" leads to language bloat, which ironically could make ActionScript less intuitive, not more intuitive. By providing a strong, consistent set of low-level tools, Adobe can patiently watch the successes and failures of community code libraries, and incorporate only those features that a) truly address the needs of most Flash users, and b) cannot be solved easily or well by third parties.
What Should We Do?
Unfortunately, until Adobe adds a Flash-centric function for dynamic symbol instantiation, Flash users will have to use the existing getDefinitionByName() function, or use a custom wrapper, such as the addChildFromLibrary() or makeInstanceFromSymbol() function listed in the preceding sections.
Charge #8: Adding Custom Functionality to Manually Created Text Fields, to All Movie Clips, or to All Buttons Is Cumbersome
The Accused: Flash CS3
The Verdict: GUILTY
Flash CS3 does not provide a way to specify the class for text fields created manually in an .fla file. Manually created text fields, therefore, cannot be augmented using traditional object-oriented programming techniques.
For example, suppose you want to add a convenience method, selectAll(), to all manually created text fields in an .fla file. Ideally, you would add selectAll() to a custom class—say, EnhancedTextField—as follows:
package {
import flash.text.TextField;
public class EnhancedTextField extends TextField {
public function selectAll ():void {
setSelection(0, length);
}
}
}
Then, in the Flash authoring tool, you would specify that all text fields should be instances of your custom EnhancedTextField class. However, Flash CS3 provides no way to specify the class for manually created text fields. Your text fields must be instances of the TextField class, and cannot benefit from your selectAll() method. In a similar vein, in Flash CS3, although an individual Library symbol's class can be specified via the Linkage Properties dialog, there is no way to specify the class for an entire category of symbol.
For example, suppose you want to add a new method, flipHorizontal(), to all movie clip instances in an .fla file. Ideally, you would add flipHorizontal() to a custom class—say, FlippableMovieClip—as follows:
package {
import flash.display.MovieClip;
public class FlippableMovieClip extends MovieClip {
public function flipHorizontal ():void {
scaleX = -scaleX;
}
}
}
Then you'd specify FlippableMovieClip as the default linked class for all movie clip symbols. But Flash CS3 provides no means of specifying the default class for all movie clip symbols.
Likewise, Flash CS3 provides no way to specify a set of enhancements for all types of graphical assets (i.e., for all movie clips, all buttons, and all text fields). For example, suppose you want to add the preceding flipHorizontal() method not just to all movie clip instances, but also to all button and text field instances in an .fla file. Effectively, you want to augment the functionality of all DisplayObject instances. In theory, one way to achieve your goal is to follow these steps:
- Create a custom helper class—say, Flipper—for flipping display objects.
- Compose a Flipper instance into separate MovieClip, Button, and TextField subclasses.
- Specify those subclasses as the default classes for movie clips, buttons, and text fields in your .fla file.
Here's what the custom helper class from step 1 might look like:
package {
import flash.display.DisplayObject;
public class Flipper {
private var d:DisplayObject;
public function Flipper (displayObject:DisplayObject) {
d = displayObject;
}
public function flipHorizontal ():void {
d.scaleX = -d.scaleX;
}
}
}
And here's what the MovieClip subclass from step 2 might look like:
package {
import flash.display.MovieClip;
public class FlippableMovieClip extends MovieClip {
private var flipper:Flipper;
public function FlippableMovieClip () {
super();
flipper = new Flipper(this);
}
public function flipHorizontal ():void {
flipper.flipHorizontal();
}
}
}
You cannot actually follow the preceding theoretical procedure, however, because Flash CS3 provides no means of specifying the default class for movie clips, buttons, and text fields, so there is no way to perform step 3.
But even if Flash CS3 did provide a means of specifying the default class for movie clips, buttons, and text fields, a typical "everyday Flasher" would not have the programming experience required to write the proposed Flipper and FlippableMovieClip classes. The Flash authoring tool needs an easier way to add custom functionality to all graphical assets in an .fla file.
What Should Adobe Do?
Adobe should add the following features to the Flash authoring tool:
- A means of specifying the class for individual manually created text fields
- A means of specifying the default class for all manually created text fields
- A means of specifying the default class for one symbol type (i.e., all movie clip symbols)
- A means of centrally augmenting all displayable assets (i.e., all movie clips, buttons, and text fields)
Here are some thoughts on how to implement the preceding features:
- For specifying the class of an individual text field, Adobe could add a new Properties panel field.
- For specifying the default class for all text fields, or for symbol types in an .fla file, Adobe could add new fields in the ActionScript Publish Settings dialog.
For augmenting all graphical assets, Adobe could provide a central panel for specifying functions and variables to be applied to all graphical assets. The compiler could then automatically generate the appropriate ActionScript 3.0 code from the contents of that panel.
None of the preceding ideas is particularly elegant, but they provide temporary, easy-to-implement solutions and are a first step toward better linkage between graphical assets and ActionScript code.
What Should We Do?
Each code linkage issue presented in the preceding two sections has its own workaround, as follows.
Specify the class of an individual text field
Because there is no direct way to specify a text field's class, developers wishing to control a manually created text field must pass that text field to a custom helper function or to a method of a custom helper class. For example:
selectAll(someTextField)
Specify the default class for all manually created text fields
To control all text fields in an .fla file, developers can turn to an old friend, TextField.prototype, which can forcibly inject a new method into the TextField class at runtime. For example, the following code injects a custom method, flipHorizontal(), into the TextField class:
TextField.prototype.flipHorizontal = function ():void {
this.scaleX = -this.scaleX;
};
However, because the flipHorizontal() method is unknown at compile time, invoking it causes a strict-mode compiler error. To avoid the error, developers can disable strict-mode compilation, or invoke the method dynamically, as in:
someTextField["flipHorizontal"]();
But before using TextField.prototype, all developers should heed this warning: adding a method to any class via prototype is discouraged because it changes the meaning of the class at runtime in a way that the class's users cannot predict. Furthermore, prototype-method invocations cannot be error-checked at compile time. For example, the following code, which contains a typo, generates no compile-time error:
someTextField.["fliporizontal"]();
Before the error can be detected, the program must actually reach the preceding line of code at runtime.
Specify the default class for an entire symbol type
To control all movie clips or all buttons in an .fla file, developers are advised not to use MovieClip.prototype or SimpleButton.prototype. Instead, developers should create a MovieClip or SimpleButton subclass, and specify that subclass (or one of its descendants) as the linked class for all desired symbols. Laborious, perhaps, but it guarantees compile-time type checking and it promotes clean code.
Charge #9: The Removal of duplicateMovieClip() Makes Cloning a MovieClip Instance (Really) Hard
The Accused: ActionScript 3.0
The Verdict: GUILTY
Both ActionScript 1.0 and 2.0 included a handy tool for making an exact copy of a movie clip instance: duplicateMovieClip(). The duplicateMovieClip() function was used for everything from creating mouse trailers to generating dynamic patterns and implementing "rubber stamp"-style drawing tools. Many early Flash designers and artists achieved widespread recognition for creatively exploiting duplicateMovieClip(). Among them, Robert Hodgin was my favorite. His duplicateMovieClip()-based creatures in Flight 404 v4 are still mesmerizing.
Sadly, duplicateMovieClip() was removed from ActionScript 3.0, and there's no replacement.
What Should Adobe Do?
Adobe should add a new method, DisplayObject.clone(), to replace duplicateMovieClip(). DisplayObject.clone() should apply to all display objects, not just movie clips.
What Should We Do?
Custom versions of DisplayObject.clone()—particularly those that handle deep copies and runtime-generated vector graphics—are very hard to make. Developers should therefore vote for the addition of a native DisplayObject.clone() method in the Flash Player bug and issue management system. For simple duplication needs, developers can use Trevor McCauley's duplicateMovieClip() replacement function, duplicateDisplayObject(). Note, however, that Mr. McCauley's function does not do a deep copy, does not handle runtime-generated graphics, and does not allow arguments to be passed to the duplicated object's constructor method.
The Prosecution Rests
Thus ends the list of Charges Against ActionScript 3.0.
I hope this article has helped to crystallize the Flash community's most common criticisms of ActionScript 3.0. If you'd like to add your own issues and strategies to the discussion, please leave a comment below. Please also report any bugs or factual errors you notice in this article. Happy coding!
Tag Cloud
InsideRIA Conference
Learn more about the conference at http://training.oreilly.com/insideria/
Podcasts & Screencasts
Development Series
Get an overview of the tools and technologies that work together to allow developers to build Rich Internet Applications (RIAs) quickly and easily.
Facebook Application Development@InsideRIA on Twitter
Follow InsideRIA on Twitter
Man, I've been waiting for an article like this. I'm so not impressed with flash 9 cs3... it has made the workflow horrible to develop in flash, unlike flash 8 which is like second nature. I wish adobe would reconsider the changes they've made in flash 9 cs3 and fix it all for later...
I've been using flash for like 10 years now and flex, and sometimes you just cant do a project in flex because of how animation intensive it is. Thus, forced to use flash 9 cs3.... Ug.
I've been saying this about the Atlanta Flash Community for a while: Flashers were not well prepared for Actionscript 3.0 and it shows. I have user group members literally break out in a cold sweat when we show them any Actionscript 3.0 code, and no wonder. Now they're all interested in Flash Player 10 features but a lot of them do not have the skills to use those features yet. I say "yet" in hopes that Flash CS Next will help them make the transition.
I just wish that there was a way to get Flashers (i.e. the scores of people not interested in moving to Flex) heads into Actionscript 3.0 and allow them love it as much as I do.
Charge #10: ActionScript, as a whole, is moving in the wrong direction. It's trying to be like Java, when it should stay simple and be like Ruby.
There's a common theme to the charges. I realize that ECMAScript is also moving in the wrong direction, and perhaps Adobe is taking a cue from that. Perhaps.
However, the more I use JavaScript (in its current iteration) and Ruby, the more frustrating I find ActionScript 3.0. To the point where I've finally just given up on it.
super nice colin.
hopefully adobe will noticed that.
super nice colin.
hopefully adobe will noticed that.
As someone who has worked with Flash since FutureSplash was acquired by Macromedia, and as someone with both a design / animation and programming background, I agree with Adobe's decision to go with a more structured implementation of ActionScript in Flash with AS3. I believe it is a strategic move to position Flash as a viable platform for true RIA development.
There's no reason that a toolkit couldn't be written that abstracts the API to provide some of the functionality mentioned in the article. It would streamline development for designers / animators, yet maintain the architectural integrity of AS3.
It's undeniable that the new VM is harder, better, faster, stronger. The level of complexity of the API needed to increase to provide access to the host of new features--not only for the contemporary version of Flash, but also to elegantly scale for the future.
Consider even the nomenclature of the AS2 display object hierarchy. "MovieClip"? Think about how someone from a development background (not Flash) would approach the idea of an interface comprised of "MovieClips." They're not interested in frame-based animation. They don't want to play a movie. They want to draw vector graphics on the screen. So they create a "MovieClip"? I think Adobe has done a fantastic job of maintaining cohesiveness between a logically engineered AS3 API and the legacy AS2 API that anyone who has evolved as a designer / developer with Flash would be familiar with.
I believe that AS3 allows a developer to logically approach Flash as a UI platform with some amazing capabilities. I think AS3 alone may prove to be a challenge to a designer without any programming background, but this is not unmitigable with a well-written toolkit for designers. Maybe that's the core of what I'm saying--that you can go one way but not the other. You can abstract an API to make it easier for a designer to use, but you can't go the other way and take an abstracted API and make it more powerful for developers.
Specifically related to Charge #6--that's definitely biting the hand that feeds you. SOME errors are better than NO errors. I think it was incredibly cumbersome to code to AS2 for the example that was cited in the article. I agree with the verdict NOT GUILTY.
I would also like to say that I concur with the other, arguably non-AS3, issues mentioned in the article, specifically "Failure to Unload," which has caused me much grief in the past.
My intent is not to come off as a pretentious "real Flash developer" to all you "plebeian designers" or something, nor is it to slam Colin, whom I hold in very high regard, but I hope that this provides some counter-rationale.
Great post. As a full-time AS3 developer who has the luxury of using Flex Builder I don't run into these issues much. But as someone who has worked with Flash for many, many years I fully understand the concern.
Specifically to your comment "Or maybe the time has come for someone to make an entirely new application for building simple Flash websites and animations. Such a tool could even be written in ActionScript, and deployed as an AIR app. But I digress..."
I would like to plug the company I work for Flypaper Studio (http://www.flypaper.com). We have taken the code out of making simple Flash content. Unfortunately it isn't Web or AIR based (makes me sad) but it does use a lot of Flash.
:) this was the same thing we talk to colleagues about the changes to AS3. The think we do is to make some wrapper object witch gives me some of the good old functionality from AS2.
Ok, I re-read the article, and I have to concede that perhaps my previous comment was slightly a knee-jerk reaction. As a Flash platform evangelist, I really appreciated the architectural changes in AS3 vs AS2. By the time I got to the bottom and read the previous comments, I forgot that Colin's "What Should ___ Do?" commentary was really well thought through and addressed both the concerns of the designer and developer.
"But despite all the talk of GPU blitting, pixel shading, and ligatures, a non-negligible percentage of the Flash community is rightfully asking: is Adobe still committed to the simple, agile authoring practices on which Flash was founded? It's a rational enough concern. After all, Flash built its success on 'ease of use.'"
I think it is a valid concern, but "ease of use" is relative versus the audience, purpose, and power of what is being evaluated. I agree that Flash should be easy to use, but that does not mean what it did 10 years ago.
"Or maybe the time has come for someone to make an entirely new application for building simple Flash websites and animations. Such a tool could even be written in ActionScript, and deployed as an AIR app."
I wonder when the convergence between Desktop, AIR (runtimes), Browser, Flash Player will happen. I feel like the industry is so confused with levels of abstraction, we're writing browsers for various OS's, that render HTML documents, which contain Flash players, that render RIA's, or animations or whatever, which can also be deployed in an AIR runtime, which can contain a browser, etc... Forgive my rant, but I just don't see things working like this sustainably for very long. Ultimately, it will come down to a contiguous platform that will allow left-to-right-brained people to interact and produce content in a continuum of connected devices. The moment we have immediate high-bandwidth connectivity everywhere is the moment the game entirely changes, and it's almost here. But I digress...
Adobe. Please listen. Please...
In general, I'm pretty unsympathetic to charges that a programming language should be made so that non-programmers can use it. (Instead, I believe it should be made easier for programmers to use.) However, I think that some of the things you've pointed out are simply NOT more difficult, only different. Just because people are used to doing something one way, does not make it "more intuitive" or "easier." Sometimes, the familiar way is actually less intuitive, as I would argue in the case of the "on()" construct.
As you say yourself, the on() construct for clip events requires learning an entirely new syntax. What is "release" in this line? It looks like a variable. For that matter, what is "on"? On the other hand, every programmer will be able to recognize the familiar method-call syntax of addEventListener. So I can't say that I understand what you mean by "Simple content should be easy to build." What exactly makes addEventListener more difficult than "on (blah) {} "? For that matter, what makes any of the things you highlight here "harder"? Is it just that you have more to type? Or that they aren't the same as they used to be?
In fact, most of the complaints I hear about AS3 are not related to the language or even the tools (concerning which there are certainly a ton of valid complaints), but to object oriented programming itself. I realize that OOP is a mindset that some may not have naturally, but once the basics are understood, something like adding functionality to all instances of an object might not seem like such a good idea. In addition, things that might have made the language seem "hard" before (adding listeners) seem consistent and logical.
As I said, I agree that there are a ton of valid complaints about the flash API. Extending TextFields would be a nice addition (though I take issue with your statement that "manually created text fields, therefore, cannot be augmented using traditional object-oriented programming techniques." -- TextFields can be wrapped/decorated!) However, I think it's important that when compiling the list of desired improvements, our qualifications are a little deeper than "this is too hard." As you point out in the article, most perceived omissions in the API can be overcome by some custom utility classes. Would it not therefore make sense to try to focus our lobbying powers as a community on those things that we cannot address ourselves? For example, the lack of method overloading is absolutely crippling to anybody trying to author useful interfaces. (Perhaps this is why the flash API contains so little of them -- another big issue.) Otherwise, we seem doomed to fall into the same old debates -- debates that have already been argued and decided long before ActionScript.
I fail to see how it is Adobes responsibility to make programming so easy that anyone can do it, especially at the cost of language power. I wouldn't ask the Illustrator team to create tools that help me as a programmer draw beautiful curves even though I don't have the eye-hand-coordination that it takes to maneuver my tablet pen gracefully enough.
I'm not saying that's the subject of Colins article, but those who originally fired off the accusations that this article (and the one about wether AS3 is hard or not) often tend to lean towards that mentality.
Give designers better control over the timeline without writing any code at all, and stay on this path, onto which the development of AS3 was the first step.
@Austin:
Why not make the parts that are heavily animation oriented in Flash CS3, and then load them into a pure ActionScript project in Flex Builder. That way, you won't have to use Flash CS3 all the way (as you seem reluctant to doing so) but you still get to take advantage of it's animation capabilities.
I find this discussion very interesting. and I really like the idea of one of the true Flash/AS heros spearheading a community movement to effect change in the tools!
But I have to say, as a Flash-dabbler, I have struggled with Flash and AS for years! For me, a similar list of charges could have been written with each new version of Flash/AS. As a former VB programmer I was totally spoiled by an IDE that knew what I wanted to do most of the time. When I went to Flash/AS it was (and is) a nightmare trying to remember or look up the complex, detailed instructions for every simple step I wish to take. Improvements to the IDE could bring so much joy to me!
I have gotten by but it is always very painful. And I wish that it weren't so painful; I would LOVE to LOVE working in Flash/AS!
Great article. The IDE is very good regarding it is the first version that supports AS3.
Any way people use flash because it promotes a good balance between developers and art/graphic designer in a wide range of applications, so Adobe should be very concerned about these limitations.
Some of your charges are a bit 'AS2ish' . I have taught both AS2 and AS3. My conclusions are:
- the learning curve is a lot different:
in AS2, students start coding and doing funny things very fast, but when projects start getting more complex they tend to block;
in AS3, students struggle to understand the basic concepts and they feel a lot disappointed at the beginning, but later, after they get used to it, they develop faster, easier and in a more logical way.
- students who already knew AS2 have more difficulty learning AS3 than students who never saw Actionscript.
- students who were used to the AS2 way of coding are normally snippet coders: they solve problems by googling, copy pasting, and hammering code until it works. Students who learn AS3, after the initial rejection, tend to be much more organized, logical and they solve their problems faster just by digging the documentation
- the first reaction they have with the documentation is a "I hate this, it's worthless". After they learn the basics of AS3 they can't live without the documentation.
- students who have some background on engineering, OOP, or languages like JAVA learn FASTER than everyone else: in a matter of days they start coding AS3 like if they have done it for years.
I normally teach Actionscript to designers in a technical design school. My background is software engineering, but I try to keep a balance with the both sides of the brain while teaching to help them program as good as they design. I feel more comfortable teaching AS3 than teach AS2.
So, my conclusions are: just because we need to make more 10 characters in AS3 to make the same thing we did in AS2, doesn't mean that it's harder. It's just a different picture.
BTW, the use of the "parent" property should be prohibited... that's the biggest fight I have when teaching AS3 - I forbid my students of using "parent" on their code.
But, of course, I agree with you in some of your charges. :)
This is the single most retarded article I've read.
Moping because they are evolving the language to a true OOP programming language?
Pathetic.
I agree with the idea, but not the charges. The AS3 API could be built ALOT easier. Instantiating new TextField's with custom formats, the drawing API, these are all left at a base level. Which is great for me, as I can write my own TextField class that easily spits out TextFields just how I want them, but even so, Adobe should develop these types of classes further.
Classes should be further developers so that people can work with the drawing API like: var circle = new Circle(100, gradient(000000, FFFFFF), 9scale);
well...the article is very interesting. In my opinion AS2 was a really improuvement over AS1 but AS3 is a very bad evolution of AS2. Many of the very good features of AS2 are now suppressed and to write a single command for a simple button I have to write many lines of code that sounds strange to me. And I really dont understand the advantages of, for example, the navigateToURL() function over getURL(). AS3 is cumbersome without any shadow of doubt.
Cheers
Adobe is in a tough position. How do you satisfy two segments that have widely different views (needs) on what a programming language should be and do?
The reality is that there would be no AS3 without the adoption of AS / Flash since version 3 by non-programmers. Adobe needs to sell lots of licenses to sustain Flash development efforts on a global scale.
The reality is that the language needed to evolve to meet the requirements of advanced web applications.
For the programming professionals, the answer is simple. Learn the new language and you will quickly enjoy its benefits. While this is true, it may or may not happen. One thing that I think Adobe has been terrible at (at least over the past 15 years) is understanding that its customers do not always have the time to constantly re-learn a tool or programming language. I personally can attest to having at least 3 HTML tools discontinued forcing me to learn a new software package with substantially different interfaces, tool sets, etc... The same has happened to other software categories such as video editing apps or Mac-based apps when Apple was in trouble.
At small agencies and design shops worldwide, people wear different hats. Few have the time to fully explore a particular software package anymore. Flash attracted millions of web professionals because them get things done quickly. AS3 will do that even faster when you become proficient, but there lies the problem. Non-programmers can't build on what they have learned in the past. Essentially, their experience and knowledge feel worthless. And, this is when alternatives become attractive.
The fact that there is resistance a year+ after the launch of AS3 should worry everyone. Because without the funds non-programmers bring in, programmers will eventually lose the Flash platform. Unfortunately, this is the rule of this current game. And it is not pathetic.
Thank you Colin for elevating the issue.
P.S. Proficient programmers and other gurus can be of tremendous help by posting simple tutorials designed on helping non-programmers transition to AS3. Simple snippets like the ones featured in this article are extremely useful to AS2 users. Once a few obstacles are overcome, adoption will be easier. Let's hope.
Collin,
I couldn't agree more with what you have posted especially #6. There are some fundamental issues that Flash CS3 introduced that do make it harder for anyone coming from any previous version of Flash.
The Error messages are not one of them though. The Error messages are a fantastic help that the ActionScript provides to keep developers and designers scratching their heads rather than banging them (most of the time).
Because some errors are very cryptic and hard to understand, I have created a site documenting all the ActionScript 3 Errors with code examples and screenshots. I hope this will help developers and designers scratch rather than bang.
This article and the previous will help transitioning Flashers around the world not get the errors in the first place. Thanks again for writing this.
Curtis J. Morley
I teach as well and agree with the previous teacher's assessment.
Students learned AS3 last year and it was easier to teach and learn because of its consistencies.
For instance, data access took up half the second term in AS2 because the LoadVars syntax seemed hard for students. After teaching the first term in AS3, data access was just a lesson and they got it right away - same old, same old.
Having said that, after they got it right away, I did provide a wrapper class that reduced the 15 consistent lines to three (or a few more with error handling) You can check that out at http://falconflash.wordpress.com - looks something like this - similar code is provided for variables and XML as well:
// in your constructor for instance
var myFalcon:Falcon = new Falcon("sample.txt", Falcon.TEXT);
myFalcon.addEventListener(Event.COMPLETE,getData);
// in the body of your class make the event method:
private function getData(e:Event) {
if (e.target.error) {
trace ("sorry, error accessing text file");
} else {
trace (e.target.data); // this is your text data!
}
}
Interestingly, we did not teach students AS2. So in case they were called to code AS2 or convert AS2, etc. we needed to give them some idea of the differences. But we had to go backwards and almost all articles were written from the standpoint of going forwards so they assumed you knew the AS2. This prompted a blog article on going from AS3 to AS2 if anyone is interested: http://tinyurl.com/5zublt
Hope I did not stray from the point of the article too much ;-) In general, many of these issues is a trade-off between consistency and brevity.
Thanks for the article Colin!
I think most of us who do AS3 40hrs a week for a living just wrote our own libraries to make this stuff easy again. The control is nice but, some syntactic sugar would be nice for everyone else. I am more concerned about there being no documentation tool and having to depend on FlashDevelop for my IDE. I don't want to switch to Flex. If I have to go to flex why not just use silverlight. Flash is great because it allows me to place graphics on stage as I would in Photoshop or Illustrator. So, the power tools need to be in place as well. Write now they are missing both the simple and the hardcore. What the heck!
@Charlie
"At small agencies and design shops worldwide, people wear different hats. Few have the time to fully explore a particular software package anymore. Flash attracted millions of web professionals because them get things done quickly. AS3 will do that even faster when you become proficient, but there lies the problem. Non-programmers can't build on what they have learned in the past. Essentially, their experience and knowledge feel worthless. And, this is when alternatives become attractive."
You nailed it with this comment (and I think it is key in Colin's point). I work at a small company. I do sales, project management, accounting...oh and I also do all of the server-scripting and Flash programming for our projects! I love the job but I'll never have the time to properly master AS3. So I rely heavily on people like Colin and other Flash/AS masters to provide me with bite-sized solutions I can drop into my projects.
I hope I don't sound too lame but I'm not trying to amaze the world or blaze new trails...just trying to deliver nice, working solutions to our customers as quickly and as cost-effectively as possible!
I think the frustration with learning AS3 is having to learn it all over again. If you are like me, and program in javascript, VB, C#, AS2, SQL, Java, PHP and various other program specific tools--it just gets crazy trying to learn and work at the same time. I love Flash--all my favorite projects have been built on it.
The problem is that Flash changes the more than any other program. Then Adobe starts spitting out tools like crazy. All my other tools have been more consistant. I can maintain old projects and build my skills with new features with old and new projects. However, Flash and actionscript have always been all or nothing. A leap of faith because it is not just an upgrade, it is revamp.
Bottom line is that it is time consuming for someone like me to relearn it everytime a new version comes out. Each time I try to start a new AS3 project I think, "do I really have the time to invest in this, or should just work in AS2?"
I love the idea of AS3, but it becomes tiring having to almost start over everytime a new version comes out with new ways of doing things and new work arounds.
Just to be clear, I am not arguing that "a programming language should be made so that non-programmers can use it."
I am also not "moping because they are evolving the language to a true OOP programming language." Quite the contrary, I'm elated that ActionScript is now a true OOP language.
Plainly put, I am strongly in favour of hardcore programming tools. I love ActionScript 3.0, and I love that Flash has become a platform. It's great to see Adobe finally providing programmers with power tools, such as Flex Builder, the ActionScript 3.0 profiler, ASDoc, ANT intgration, data services, a proper debugger, a command-line compiler, the Flex framework, a public bug database, MXML for UI development--the list goes on. Adobe is doing a great job of catering to the programmer crowd, and their efforts are attracting an unprecedented number of new serious developers to Flash.
So let me reiterate (from the introduction):
==
For the record, I should point out that despite the issues discussed in this article in my opinion ActionScript 3.0 is vastly superior to ActionScript 2.0 and ActionScript 1.0. Growing pains aside, ActionScript 3.0 is the language of choice for any Flash-platform project.
==
Yes, professional programming tools are wonderful.
But in addition to programming tools, we need complementary tools for producing rich interactivity and motion graphics. Those tools must have an easy to use (yes, easy to use) scripting system. And that system should integrate well with the more powerful programming tools. "Easy to use" means:
1) simple, routine tasks can be accomplished quickly, with minimal effort
2) concepts in the scripting system must be approachable to designers and less experienced programmers
Flash authoring has, in the past, provided the tools for producing rich interactivity and motion graphics. And it *used* to have a simple scripting system. In Flash CS3, ActionScript 3.0 can mostly still be used in simple ways (see http://www.insideria.com/2008/01/actionscript-30-is-it-hard-or.html), but some common scripting tasks are now cumbersome or unapproachable. This article lists some of those tasks. It is not a plea for Adobe to simplify ActionScript 3.0 itself, nor to stop catering to the professional programmer. It simply recognizes a gap in Adobe's current tool suite. The issues are fixable. Programmers and designers can both be happy. (Even if they are the same person.)
Derek, you wrote: "Bottom line is that it is time consuming for someone like me to relearn it everytime a new version comes out."
that's a very valid complaint, but fortunately ActionScript 3.0 is the last major core language update you'll have to learn for a long long time. the core is settled, and is based on ECMAScript 4, which is designed to have a shelf life of at least a decade. sure, new player apis will be introduced, but the existing apis will remain intact. the flash authoring experience will naturally continue to evolve, but the language will be stable. now if you want to talk about new versions of the Flash components...that would fill another article.
I teach Flash to designers and all I can say is that with AS3 the threshold of entry as well as the intimidation factor became too high for design students. What they want to do is make something functional and beautiful without needing to spend weeks learning the basics. AS2 made that possible. AS3, to a huge degree, took it away.
Adobe did designers a huge disservice by making the AS3 documentation show only programmer-oriented, class-based solutions. Because of this, the AS3 docs are basically useless to beginners--who one would think would be the target audience for such documentation! Revising the docs to include a basic, procedural example on each page would go a long way to improving the Flash CS3 experience.
Charge 9 is paramount in my book. I've spent many hours trying to find a way around that little error of omission. Trevor McCauley's approach inexplicably doesn't work in some cases, leaving you with really no workaround whatsoever.
At the time of this writing, the adobe bug currently only has 4 votes - not even the number of people on a jury.
I think Adobe should first fix programming dead-ends like this before even starting on a better non-programmer GUI.
Great article!
Please also report any bugs or factual errors you notice in this article:
Charge #7: Referring to Library Symbols Dynamically Is Unintuitive:
parentClip.attachMovie("Animation" + i, "instance" + i, 0);
--> 0 should be i or parentClip.getNextHighestDepth()
Charge #8: Adding Custom Functionality to Manually Created Text Fields, to All Movie Clips, or to All Buttons Is Cumbersome:
scaleX = scaleX;
-->misses a minus sign
That is really great article. Regarding point # 7:
I would love to see feature like this:
var Symbol = new Application.Library.SomeAsset();
instead of getDefinitionByName().
Application references current app. Library points to library (similar to Properties.Resources in C#) and class in linked name for asset.
Again when asset is in some directory it could be:
var S = new Application.Library.somePackage.SomeAsset();
I think this would be most intuitive.
Again - great article.
Flash was (to me it's still) beautiful because of its coding simplicity and easy to use features/components/etc..
When I checked the AS3 documentation for the first time, i felt in a totally different world. AS3 was oriented "exclusively" for developers when Flex was too.
So what's Adobe's plans regarding that? I have no clue. Why having 2 products that can, "overall", do the same work? I also have no clue. Maybe Adobe can answer that.
I imagine that AS2 was also something out of the designers reach when it gets to developing complex animations or applications. But as someone said previously, they could've always relied on some online experts to help them reach their goal.
Add to that the fact that AS2 didn't go out of the Flash/AS1 spirit. It stayed simple and easy to use.
Even if learning AS3 draws new horizons (especially with Player 10), still it's only meant for developers. Adobe left the designers out in the cold with the release of Flash CS3; designers have 2 options:
Hey Colin
I really miss the Webservice class in CS3. you have not mentioned about that here. Its more than an year CS3 is in market yet wonder what research they are making on the webservice class yet. They removed it completely from flash and forget about that and making more research on Graphics(3D, animation, kinetics, video) is that because of ADOBE(more concerned about graphics) or to improve the sale of FLEX. Adobe is trying to bring C, C++ programmers into flash but what is the reason they cant bring the webservice back in flash. Iam eagerly waiting for a good answer form you Flash guru(teacher).
I'm a designer. I've been battling with ActionScript since Flash4. Like many, I've spent incomprehensible amounts of time learning and re-learning ActionScript. When AS3 was released I took one look at it and threw in the towel. Since then my life has been much better.
I have no doubt Adobe have made the correct decisions with AS3 and will continue to do so. It's just sad that the advances in AS3 have left so many of us floundering in it's wake.
Perhaps one day I'll re-kindle my friendship with Flash.
I think the only thing I can agree to here is unloading swfs and problems we face around it. Who would want to user onClipEvent(), enough has already been said about it.
The thing missing in Flash CS3 is a good ActionScript Editor. I use FlashDevelop but it does not exist for Macs. Flex Builder can be used but its too much for just coding, it takes ages to load, while I need something as quick as a notepad. Its more of an IDE, to which its now doing justice.
AS3 is a more mature language ActionScript has ever been but Flash CS3 cannot cope with it as it does not have an editor like Visual Studio.
This scenario is more like when Microsoft introduced VB.Net and C# while neglecting VB Script crowd. I think Adobe has to move on from AS2 as well, the way MS moved away from VB script.
Well done Colin! Using Eclipse and Flex Builder I kind of ignored those issues, especially from a designer point of view. What you clearly showed here is that it would have been REALLY easy to keep Flash IDE as a script friendly environment without renouncing to the robustness of AS3. For this reason I consider Adobe GUILTY and I'm very surprised they committed such mistakes considering the recent arrival of Silverlight.
for Francis Lukesh:
To be honest I don't use MovieClips at all in AS3, if you don't want frames just use Sprite.
For years I've watched how other people use the IDE, most of them that big mushy center of users that are designers with enough left-brain logic to handle a little light procedural ActionScript in their banner ads or presentations. They create buttons, hook up some getURLs, publish, and get out. They can handle a line or two of code attached to keyframes or directly to objects on the stage, but setting up a MOUSE_CLICK event listener? No way.
I have no doubt in the direction Adobe is going with AS3, but they're forgetting (at least thus far) what most people who purchase Flash *do* with the application.
I thought with the introduction of Flex there would be a splintering of Flash users, whereby "developers" would all go to Flex and Adobe would take the Flash IDE back to its roots to become a more robust animation / interactive utility that didn't require ActionScript skill or knowledge.
But that hasn't happened. Flex is becoming its own market of sorts, while the Flash IDE carries on trying to satisfy everyone.
Great post...
The transition from AS2 to AS3 is quite a drastic change. It's not even just "flasher/designer" versus "programmer". As many people who've programmed for years find it a drastic change. Rather, it's a philosophical change to an OOP methodology. Those who's experience lay mainly with procedural languages find themselves with many hurdles to cross. And a number of them are poorly placed (ie: could have been made easier and clearer).
I believe it is quite clear that Adobe did NOT design AS3 with it's own programmers in mind but rather sought to court the large base of Java developers. While this was probably a smart move, and it makes it very easy for Java developers to move into AS3. It makes it quite challenging for AS2 or other procedural programmers to move into AS3.
And yes, it can be over-whelming when what a programmer once did with half a dozen lines of procedural code now requires 3 pages of coding. We can debate whether this is progress or not. In some regards, yes...but I have encountered situations in which I could have resolved my issue programatically in a handful of lines of code - but am still unable to do what I want in the event based OOP model of AS3.
Anyways, this was a great and informative post, much needed for our development scene. Thank you!
***
"navigateToURL versus _getURL"
Let me also chime in that there is an added issue with navigateToURL. It doesn't work! Using "_blank" will in many browsers result in pop-up blocking. And determining what aspects come into play for any given browser is a mind-job. (For instance, wmode value can make a difference in some browsers.)
Adobe has made progress, recent Flash Player updates have resolved this issue in certain browsers. However, for others we are still relegated to using externalInterface calls. Which of course required the granting of security rights (allowScriptAccess = always). While this is possible in most cases, there are situations where a developer does not have access to the hosting environment.
The end result is having to go back and re-code the product in Flash 8/AS2 and use _getURL. This is NOT a very satisfactory solution. And as linking is the number one function of the world wide web - this is a pretty significant failure.
You can find the bug listed here...
http://bugs.adobe.com/jira/browse/SDK-12987
(looks like they've re-closed this issue, maybe a recent build finally resolves it)
Anyways, here is an interim solution that handles for most browsers.
http://thesaj.wordpress.com/2008/02/12/the-nightmare-that-is-_blank-part-ii-help/
***
"MovieClip(this.parent).play();"
Thank you, this needs to be touted more. I was unaware until more recently about this. I think the error message could be expanded to explain the need for casting.
I would really like to see Adobe expand the error explanations. Perhaps I shall create a post on error explanations and what they may mean.
There is a missing aspect to all of this discussion about AS3. I love Flash, how many people can say that about a development tool, but it is also my livelihood. I'm paid to develop in Flash and if everybody could do it then I wouldn't get paid as much. I've struggled more with AS3 then any other version of AS, but I also recognize that the struggle has made my skills infinitely more valuable. The reason lawyers get paid well is that they are the only ones who understand the law. This isn't too say that Adobe should make AS3 more complicated and arcane, just that the evolution of AS is necessary and welcomed. Plus it bugs the crap out of me when the .Net developers in my company put down Flash as mickey mousey. Love can make you jealous.
Though you say that you're "not arguing that 'a programming language should be made so that non-programmers can use it', you also state that "concepts in the scripting system must be approachable to designers and less experienced programmers." In addition, at least some of your arguments here are modifications to the language (#3, for example). Inherently, then, your request is that the language be made so that non-programmers can use it.. and that's a completely valid argument to make! As I stated above, it's simply a charge to which I'm personally (generally) unsympathetic.
I agree with a lot of things you suggest in this article -- animators could use more tools to make their jobs easier -- but I think that you lose sight of this goal with some of your points by falling back on an AS2 vs AS3 framing. As you show above, many of your complaints can be addressed with custom classes / functions like "makeInstanceFromSymbol." (I would argue that there's no need to add it to the flash API, however, because simply wrapping an already existing method "leads to language bloat...[making] ActionScript less intuitive, not more intuitive.") Other things (i.e. a visual way to add event listeners) can already be addressed with JSFL. That they are not, I think, is indicative of either the poor state of JSFL documentation for developers, the lack of organization within the community, or a lack of demand. Third parties could easily release extensions that bundle both these convenience methods and the JSFL tools -- an "animator kit" for Flash. Meanwhile, what we really need from Adobe is additional language and API improvements (method overloading & interfaces!!) and more attention towards extensibility of the IDE -- two things that we just plain can't address ourselves.
hey matthew,
you wrote:
==
Though you say that you're "not arguing that 'a programming language should be made so that non-programmers can use it', you also state that "concepts in the scripting system must be approachable to designers and less experienced programmers."
==
exactly. in making an explicit distinction between programming and scripting. programming languages don't have to be approachable to non-programmers. scripting systems do.
when i use the term "scripting system," i'm not referring to ActionScript. despite its name, ActionScript has become a programming language, and has grown beyond what i'd call "scripting" (if we're to accept the premise that Flash itself is a platform). the definitions of "programming" and "scripting" have some grey area between them, but see:
http://en.wikipedia.org/wiki/Scripting_language
http://en.wikipedia.org/wiki/Programming_language
i'm not suggesting the hypothetical scripting system be forced into ActionScript. rather, i see it as separated, though dependent and interoperating, much like MXML syntax is used to produce UI, but compiles to ActionScript.
so i think we probably agree, but just tripped over terminology. and i would *love* to see overloading. unfortunately, it was taken out of ECMAScript 4, over which Adobe does not have sole control. see generic functions (or "multimethods") here:
http://wiki.ecmascript.org/doku.php?id=discussion:generic_functions
http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2
interfaces are already part of ActionScript and ECMAScript 4. see the spec (draft 2 just released!):
http://wiki.ecmascript.org/doku.php?id=spec:spec
I have one word - THERMO.
Well, a few more...
Sure, it is now way more tricky for a designer to work in the ways they used to with Flash 4. But I bet actionscript 1 was tricky to a designer that never coded.
Flash has evolved in the ways the majority asked for. I am sure for a designer who learnt AS1 it was a pain to transition to AS2 and again to AS3. Heck they dont care about the language they just want to perform simple actions on their pretty graphics (which is where they want to spend their time). But the changes are hugely important to developers, and to be honest, Flash would be almost dead if these changes were not made IMHO. I would love to know the sales figures for each iteration of Flash over the years so we could see how many more users there are.
Onto Adobe then... I think they must be aware of this designer-developer gap now in Flash CS3, hence Thermo. If they get this right its world domination next! They should have all the types of SWF creation sorted.
Thermo for designer orientated workflow (the particullar gap I feel this article as a whole addresses), Flash for a bit of designer-developer collaboration, Flex Builder for the IDE using developers and Flex SDK for the command line addicts.
Lastly on Flex 4 framework... this I feel needs a mention as it will help bridge the designer-developer workflow. We have a team of designers and a team of developers. The designers want an easy way to make the developers stuff look pretty, the developers want an easy way to take the designers stuff and make their stuff look pretty. The changes in Flex 4 are significant in this area.
@christian That's exactly my point.
To clarify my earlier point, in how the API should have easier functions/classes to work with.
The API should add classes as easy as....
var rectangle:Shape = new Rectangle(100, 50, gradient(000000, FFFFFF), '9scale');
Instead of only...
var matrix:Matrix = new Matrix();
matrix.createGradientBox(100, 50, 0, 0, 0);
var gradient:Shape = new Shape();
gradient.graphics.beginGradientFill(GradientType.LINEAR, [0x000000, 0xFFFFFF], [1, 1], [0, 0xFF], matrix);
gradient.graphics.lineStyle(0, lineColor, 1, true, LineScaleMode.NONE);
gradient.graphics.drawRoundRect(0, 0, 100, 50, 30);
gradient.graphics.endFill();
var grid:Rectangle = new Rectangle(15, 15, 70, 20);
gradient.scale9Grid = grid;
Surely as memory/processor constraints dwindle, programming should be becoming LESS verbose, not more.
Write less, do more, quicker. Hide the complexities of common tasks in simple short terms, not have to write a hundred lines to get the simplest thing done.
To all the code snobs who think that productivity comes from complexity, should we go back to machine code and altering bits at a time in registers, or perhaps the *real* coders should go back and use 100 pages of punch cards with cut out dots to insert a simple gotoAndPlay.
Personally i prefer to make the machines work for me, not me working for the machines, which is what actionscript 3 feels like.
Wow, all these tips are really going to come in handy. I love the fact that you are proposing solutions and not just complaining like I do. An email coming from me to Adobe is not nearly as powerful as a suggestion made by the author of what is probably the best selling Actionscript book out there. Didn't you mention at one point that the Flash team at Adobe uses your book almost like a manual?
I hope they listen.
I think it is important to consider AS3 in the context all web technologies and the ever-increasing complexity of work being required of them. In that respect, the shift from AS2 was absolutely essential.
I go way back with Flash, but just so happened to spend the last several years immersed in browsers, Javascript, HTML, CSS, Java and SQL. After wrestling with all the idiosyncrasies of that mess, coming back to Flash post-AS2 is like a walk in the park.
As a designer, I can empathize with those who feel they've hit a brick wall with AS3, but I will say to them that if this is really their chosen profession, then learning AS3 (and the ilk) is the least they should do.
As a teacher, I used to joke with students how the timelines that I have seen convince me that avoiding code is WAY more difficult than embracing it. AS3 is not the enemy of good design -- it is the catalyst for it. Afterall, which would you rather work with? An okie-latch-up of bailing wire and duct tape? Or a purring machine of OOP?
All that being said, I have had many of the same thoughts as Colin -- and have built myself a few patch classes -- but I welcome the reinforcement of doing things better and trust those in the know to show me the way. I'm not so perfect (or old) that I can't change, you know.
I think the suggestion to turn off Strict Mode is a valid one when you want to help ease a non-developer into AS3. Sadly, everyone seems to hesitate when suggesting it.
The biggest problems seem to come from the fact that the AS3 compiler is stricter than the AS2 compiler. Commentors above me have said that AS3 looks scary, and that makes perfect sense to me. All the type information, casting, constants, and classes etc makes AS3 look nothing like AS2 unless you were a developer who tried to conform to strict standards back when it wasn't required.
With strict mode off, AS3 code can be much simpler and only a little less accessible than AS2 code. Use of parent without casting is possible again. The ability to use prototypes again is another useful bonus. With just those two, AS1/2 coders can almost feel at home, and I bet the learning curve will be smaller. Then, in their own time once they feel comfortable, they can choose to go to strict mode if they think it might be beneficial.
The aversion to suggesting that people can turn off strict mode bothers me. It's still a better world than AS2 development, in my opinion, and many of the old shortcuts become available again. Combine it with the shorthand code snippets Colin included above, and it only gets better for the non-developer type.
Off the top of my head, here's another thing that might make event handling easier.
addEventListener("click",
function(event)
{
});
Notice the use of the "click" string rather than the constant. Less to type there, and probably easier to remember for non-developers. Additionally, I put the function body right in the second argument of addEventListener() call. It might look a little strange at first, but it's valid code, and you will have fewer lines of code when adding event listeners than you would with the "proper" way. Personally, I think it looks a lot like the on/onClipEvent code.
If that seems to confusing, you call still pull the function outside:
addEventListener("click", myEventHandler);
function myEventHandler(event)
{
}
Sure, without strict mode, it's more likely that bugs will sneak in. However, it's no different than AS2 in that regard. The folks who don't like AS3 are already used to that problem, and I don't think it outweighs all their other gripes.
I think Adobe should have made a different decision earlier on to leave ActionScript for what it was, simple and primarily targeted at designers (Flashers). Being a programmer (+7 years of full time experience with the Flash Platform), I found ActionScript always to be a quirky programming language. Even ActionScript 3 feels like its nowhere near maturity. I believe Adobe (Macromedia at the time) should have chosen to leave ActionScript for what it was. Next to that they should have used an existing and mature programming language like Python or maybe even Java (I'm talking about the core language here not all the support libraries that come with those languages) to target a programmer audience instead of "maturing" the ActionScript language. I mean, look at what Nicolas Cannesse has done with haXe.
The font size is so small on the code (looks about 3 points) that I am having to copy it and paste it into Notepad to even see it. Is anyone else having this problem?
@Amy- I have the exact same issue... very frustrating barrier to reading the article!
I'm inclined to agree with matthew in general... I don't think Actionscript the language should cater to non-programmers... that is, not if Adobe really wants flash/AIR/flex to compete with and surpass MS's silverlight/WPF/.Net.
But I think colin's point is well made, that the TOOLS do need a lot of help, especially to compete with the likes of VS. And sure, throw in some nice wysiwyg type features where it writes actionscript for you... that's always nice for the non-programmer crowd. But *never* let there be added a feature which specifically limits my ability as a knowledgable programmer to customize code to do exactly what I think is right. That's my big pet peeve.
The fact is, AS3 does have a few limitations, but it is so many thousands of light years beyond AS2 that they're almost not even worth worrying about. Personally, I would really rather see Adobe focus their effort on the 400+ or so Flash/AS bugs (ok, so like only 100 are actual bugs and not just authoring misconceptions, but still!) in the Adobe bug system (of which I've submitted about a dozen). IMHO, those are the real show stoppers to getting flash to keep moving forward.
I also think the notion that is kicked about in this article and a few comments is a good one... maybe what we need is to have a movement of people building AS frameworks like jQuery and Dojo and Prototype have done for the JS world. That'll significantly open up the flash world to those who would rather keep a little more arm's distance from the nitty gritty of AS3 coding.
And to think, the only "forking" issue such frameworks would have is to support AS1, 2, and 3 (this may not even be possible because of compiler strictness changes)... instead of all the dozens of different browser versions that JS frameworks have to attend to.
Kyle, those are great ideas. I've been getting into jQuery and think that kind of powerful flexibility in Flash tools is a natural next step. Building AS frameworks embodies the spirit of what been said here, and gives it a good direction.
It should be pointed out that Actionscript 3, while a bit of a pain for Flash designers, is easily digestible by developers from other walks of life, since it based on ECMAScript 4. This makes it simpler for traditional developers to get into Flash, lending Flash more credibility in the developer community, and bringing its visibility to a whole new level. I have found that my more "serious programmer" friends have been able to suggest solutions in Actionscript 3, even those who have never seen Flash; once that conversation has taken place, they jump into Flash development at the deep end of the pool and become valuable resources and champions for the cause. (And there was much rejoicing.)
The positive changes in AS3 are good, and while there seems to be a steep learning curve, it bring us more into alignment with the rest of the development community; the need for Adobe to create a better visual interface for the tool is the issue at hand. While I agree with the verdict here, and the emotional response from those who feel alienated by Adobe's rather harsh change in direction, we should not confuse the desired future simplicity of the tool with the complacency of past solutions. As a community, we should help shape the solution without looking backwards, and I would ask those here who were scared away by the new Actionscript to reach out the community for support.
Colin, thanks for getting this all in one place. The AS2 vs AS3 issue reminds me of the object-level undo situation a few years ago, which was resolved by a very similar open discussion within the community. I really appreciate the "What should we do?" sections here, which place the responsibility back on our shoulders, and give us the tools to do it by contacting Adobe in constructive ways.
#8 regarding: someTextField.["fliporizontal"](); and the typo that does not return any error at compile time - a possible workaround would be to declare the string as static var in class, much as event types are.
eg. private static var FLIP_HORIZONTAL = "flip_horizontal"
so then the function call would read
someTextField.[MyClass.FLIP_HORIZONTAL]();
and could be checked at compile time
(style note: I'm not a big fan of the lowercaseUppercase function/ var naming convention as it makes it hard sometimes to distinguish between native AS methods and custom ones that's why my example is slightly different)
For me im totally sold on AS3 and hate having to look through legacy AS2 code. I will qualify that by saying im unhappy about what happened to sound events, unloading movies and duplicating movieclips but thats more to do with the player than the language and im sure they will be solved.
I think there should be a 'designers' tool for coding simple banners, websites etc, i dont want to be doing that sort of work and theres no reason a designer should need to ask me to add button functionality, but they do need a tool.
Personally i think thats the purpose of this post, wouldnt be surprised to hear about something at Max this year.
see http://www.moock.org/blog/archives/000269.html
Well, I think that Adobe is trying to lead more "real programmers" to AS3.
Making things hard will clean away all that "self-made-AS-programmers" I've met during my life :)
I think what's missing in this discussion is user experience, clients and budgets.
If you read Colins post with those thing in mind its easy to see he makes some validate points. OOP with computer languages is not a new concept, its been around a long time but, OOP alone was not able to deliver the rich lightweight UI/UX experience that Actionscript and the Flash Player provides in today's data centric world. Flash has come to represent a mashup tool, if you will, allowing both designer and programmer a meeting space for implementing clients ideas in a timely manner.
My point being, there is a disconnect with some of AS3 implementation of rich graphics in the Flash IDE and Flex which could lead to an isolation of some of the more creative users. I think Adobe agrees as well, see Thermo. Its hard to justify Flex's graphical work flow and file size for the web, if you been using flash for many years to built custom UI's. I'm not saying Flex doesn't have it strengths. It does.
As a programmer I like the improvements to AS3 but, as a designer I would like to see the improvement extended into the CUSTOM UI/UX implementation of AS3 in the Flash IDE or a mashup application something like a Flash/Thermo mix.
hey I got a great idea !
why people just don't stick to AS2 if AS3 is too hard for them
Flash CS3 still support it (just select AS2 project duh!)
Flash player 9 still run it (2 VM remember)
I mean comm'on!!!!
if you're still using this.parent.play()
and still missing on( event ) style
and all that other clungy stuff
man, sure AS3 is just too much for you
you should better stick to AS2 oldschool
well just stay old...
all this FUD and BS is only about one thing
people are lazy to change their habits
so to all those half baked programmer,
whining designer, and other lazy ass
who can not (or don't want) to learn new stuff
just stop complaining about AS3, it will not change now
and it will get worst for you when AS4 will come
yeah it will get even more complicated
but you know what it's the same thing with ANY programming language
if you don't want to invest a little time to learn it
yeah it's hard
@collin:
I don't think your article crystallize the whole Flash community, most flash develeopper I know don't agree at all, but because you got so much influence on that community nobody will confront you 1to1 on this BS because the argument is just lost, whatever collin moock will say, people will just agree and aplause.
See for something as Charge #2, this is specifically a Flash player / VM problem and have nothing to do with AS3 the language.
Also how come you can congratulate Jim Corbett about the implementation fo the DisplayObject architecture here
http://www.fitc.ca/video/2008/Toronto/
and come with Charge #3 is beyond me.
@anon- hey, let's try to remember the spirit of this post is not to criticize but to crystallize... to bring together thoughts that a lot of people have been having and give a good forum for discussion on it. There's no need to start getting nasty and accusing colin of a drone mouthpiece.
I applaud him for opening up this discussion, even though I personally disagree with a good portion of the list.
@anon- hey, let's try to remember the spirit of this post is not to criticize but to crystallize... to bring together thoughts that a lot of people have been having and give a good forum for discussion on it. There's no need to start getting nasty and accusing colin of being a drone mouthpiece.
I applaud him for opening up this discussion, even though I personally disagree with a good portion of the list.
I'm worried that next year, when ECMA 4 is finished and AS4 is finished, we'll have the same problems all over again.
Unloading aggregated content is so critical to interface design that it is inconceivable it was neglected! One of the primary tenants of object oriented design is the opportunity to treat any group of symbols and code - or group thereof - as an independent object with no strings attached. This is where memory leaks come from in most other languages, (sound continues to play etc... ). Offering non programmers the option of abandoning a symbol by evacuating it's position on a timeline, or eliminating a timeline from the main timeline and/or deleting or loading a different symbol.swf into any position taught us all the basic principles of OOP. Compartmentalization gave us power over the end product, which is end user friendly information management.
As a 'mechanical thinker', i was able to put my ideas in a concrete form using Flash4 - even got a software patent on the interface/navigation principles necessary for a 'zooming user interface' (ZUI): http://www.google.com/patents?id=Ai4WAAAAEBAJ&dq=matthews+data+objects example: http://www.2GoTo.com. It's all about variable speed panning/zooming in an infinitely large space that holds 'data objects'.
I never learned Flash5, 6, 7 or 8. Converting the code for the zoomer from Flash4 to AS3 took a couple of weeks.
So, as a nubee animator/developer taking a first pass at AS3, here's what i wish i had in the Flash AS3 IDE and couldn't find - yet/still.
Simplified code construction. Make a box on stage, define it as a button and give it a symbol name - show the states, let me draw them. Show the options for roll over, down etc. - let me target them (maybe just click on a target symbol or several and have the IDE fill in the blanks). AND show me the proper code for all the correct action calls and triggers so i can learn as i go along. This should be simple to add, maybe that's where THERMO is going.
Same request with tweens and paths - let me draw it and tweek it with general slider adjustment tools, but show the actual correct code so i can see what it is all about as i bumble my way through - please.
Errors: "Error 1632 line 12, variable is targeting non dynamic whatever" means squat. Link the darn error code to some documentation so others can explain what's going on if Adobe is too busy. Googling the AS3 error codes is impossible. All the error codes refer to more than is given by the IDE - thinkers need reasons why things won't work - in non programmer vocabulary - like "dynamic objects must be defined before using them, define dynamic properties earlier in the code to solve this problem", or something like that would guide nubees through the learning curve.
Loading/unloading... How could this happen? Originally, being visually oriented i would use a dot to keep track of code 'snippets', then learned to work with clips having no visual content. When that object (snippet) needed to be gone, it could be keyframed out of and off the timeline or deleted... whatever i want it gone - out of the player - not grinding away in the ether world of memory hogging performance killing hell. All this OOP b.s. is just that if one cannot unload an object containing some lines of code PERIOD. If flash is built using objects - let me mechanically remove the unneeded parts in one fell swoop. The consequences of arbitrary removal are far easier to work with than inaccessable lost references and out of control memory leaks grinding away on the poor end user's equipment.
Same goes for network calls. When doing tiled maps for example, when the user zooms in - a whole different set of tiles needs to load. The previous calls are a waste - STOP the mess - let me eliminate the previous calls for megs of data the end user no longer wants!!!
Meanwhile, back at the ranch - what a great group of people the Flash community is... :)
Thanks to all for working so wonderfully with each other and helping the less experienced learn these great tools - kudos to the adobe teams and Colin too!
Dave_Matthews
@Colin - You've mentioned something I have been trying to solve for years. Unfortunately, HTML / Macromedia and Adobe have all been moving targets. It wasn't until AS3, FP9 and FB3 that I felt the foundation was ready. I think Adobe could do a lot more for the visual interface but the main issue is not easier code it's NO code at all. At least not for designers. I have been working and planning a model that would do away with coding for good for designers yet give them the full range of features developer enjoy.
http://drumbeatinsight.com/projects/air.html
I wrote this article quite a number of years ago and it is some what obsolete to me. There are many more levels and hooks into it that I've added along the way. I never wanted to publish it because I wanted to be apart of it (and still do). The reason I am now is because if someone else does this and the core values were not followed it could easily go wrong and the effects would be worse.
Incidentally, it is called AIR for Anaphoric Information Representation. This means code, objects and sentences and a wide range of loose syntaxes can achieve the same effect as writing code but in a variety of ways. I'd love to one day use this system to give a robot voice commands or visual cues that the robot can understand (really the robot's software).
@Colin - BTW I've been working on a site for ActionScript style errors at http://www.actionscripterrors.com and http://www.aserrors.com that try collect all the information on AS3, Flex and Flash error messages. I have not made any announcements because I still need to validate the data and wanted to put a flex ui on it (that you would like) but haven't had the time. Anyone interested in helping contact me.
@Danny Miller (RE: ECMAScript 4) AS3 is already based on the parts of ECMAScript 4 that were finalized around the time AS3 was released. Any updates to ActionScript in the foreseeable future will be additions to what's already there. Rather than having to learn to use major changes to core functionality, we will see more functionality that didn't yet exist. In other words, optional.
Collin,
I definitely agree with you. Especially #6. ActionScript Errors are our friends. Although the errors are sometimes just cryptic enough that it takes longer to understand what the errors are than to just dig through the code and fix them. This is why I have dedicated my site www.curtismorley.com to helping people resolve the errors they get. I provide explanations that humans can understand and code examples. I have also posted that everyone visiting my site needs to read these two articles so that they can stop getting the errors and no longer need my site.
Thanks for writing this and hopefully they will listen including better error messages.
Curtis J. Morley
Nice article Colin... I'll check back when I'm done reading it all. Did you recently teach some average students AS3? That's when I really see what is easier and what is harder.
Hey, you left out a charge against Flash (not so much AS3):
The Flash IDE is nearly impossible to use for programming!
Some dude even climbed up a tree and hasn't come down until they address it:
http://www.youtube.com/watch?v=shNMZSEschg
For the past year I have felt the growing pains of getting myself up to speed with AS3.
Along with the book Essential ActionScript 3.0 http://oreilly.com/catalog/9780596526948/index.html, I found the converted AS2 samples to be a great help.
http://www.adobe.com/devnet/flash/samples/
Keep up the great work Colin.
It's tough to read so many english resource to learn AS3.I had really made a horrible hard working on the new tech.While I have been stick on tellTarget() for a long time.
The decision of continually learning FLASH technology it's really simple.In these 10~11 years.There're so many fascinating works on the FLASH platform.And it's push me to learn much more to master it.I'm pleased to learn new AS3.But while I'm doing a job for the others, AS3 is really make me rusty.
FLASH CS3 it's the first FLASH authoring application from Adobe.I have to say I had some kind of disappoint while I was using it in the very first time.The PSD/AI import it's really not important because I'm used to import them into jpg first,And the new AS3 even make me cannot make a interactive button!
The original FLASH authoring tools is becoming more and more indigestion and I think it's cannot becoming easier like before and in the future.No matter how the FLASH platform is trying to make friends with those who is unable to master the tech. I think is time that FLASH have to seperate the original FLASH authoring tools into the "FLASH EXPRESS","FLASH 3D","FLASH VIDEO","FLASH UI EDITOR""FLACTIONSCRIPT EDITOR""FLASH ULTIMATE",etc.
I hope my idea cannot be much more redicilous than itself.
Thanks to Colin and FLASH.
Colin,
Fantastic article. Your points are well researched and explained and hence incredibly well made.
As a developer I welcome the AS3 language with open arms. It's nice to finally be able to make a real flash application without ever having to open the stage. It was close in AS2, but there were still too many hacks to REALLY interact with the stage in a programmatic manner - like making objects into visible movieclips via code. Possible, but painful.
I understand the gripes of those who cant quite meet some of the new complexities. As a freelancer, my first instinct is to say "just hire a developer!" But I know that's rather inconsiderate. What I mean to say is that flash has finally grown up in such a way that you may need a designer AND a developer to put together something that truly tests Flash's limits. This should be celebrated.
We have a more powerful tool that, as you've done very well to point out, is just about as accessible as it was 5 versions ago. It's an enormous feat. I get that it's more difficult for non devs, and feel their pain. But as an ex-designer and full-time developer, I'm very excited by what we now have at our disposal.
I'm mostly excited about not ever having to open up the Flash IDE again. Maybe I still have to in order to generate a fonts swf for fonts that won't import well upon compile. Otherwise, I can do my job in Eclipse - or in any text editor - and then compile via a command line or other external tool, just as with all other languages. That deserves the utmost respect in my book for letting me get the job done well in a manner I choose.
Is there any precedence for a platform that supports two different (yet very similar) languages as you're suggesting? Where would the line be drawn between the responsibilities of ActionScript and ActionScriptScript? What would prevent the scripting language from evolving into a full programming language, as ActionScript already has or (maybe worse) branching in a completely different and competing direction? I'm not trying to be confrontational.. just wondering where this idea leads as it's fleshed out.
Also, I know I may not be the brightest bulb, but I do realize that ActionScript supports interfaces! When I said that we need "additional language and API improvements (method overloading & interfaces!!)", I was providing an example of each. The latter refers to my previous comment that interfaces are underused in Adobe's API.
Great article Colin!
I think it's fantastic that Flash (and Flex, AIR, etc) have matured to the point where it has become more of a graphics-centric, fully featured language. As an (ex)code monkey, I appreciate the newfound robustness, but I can definitely see how a large group of people are more interested in just making something cool than having to wade through a litany of objects and modifiers to get something to happen.
Coincidently enough, I'm working with a startup www.fuzzwich.com that's noticed this trend of making Flash more of a developer's tool than an artist's workspace. To that end, we're working on an online animation program Fuzzwich Animator (www.fuzzwich.com/animator, built in Flex/AS3 actually) that simplifies the animating process for people who don't want to have to deal with the Action Script side of things.
Personally, I think it will be interesting to see how Adobe copes with having to cater to two types of groups: those with both coding and artistic expertise, and those with only one of the two.
Keep up with the good articles!
The facts are (IMO), after all these years, the people controlling Flash still can't seem to decide what they want it to be, where they want it to go and how they want it to mature. For me, it was/is always hard software to really like (forget love), put faith in and grow with.
Take away the wide player distribution on the web and I wonder if it wouldn't have dried up long ago.
Add the current iPhone situation, Apple's attitude, Silverlight, etc. and I wonder if Adobe's Flash problems will continue to careen uncontrollably. So strange to me that a Flash icon like Colin has to spend so much of his time trying to rattle some fix or other out of Adobe.
I guess we can all, to the best of our respective abilities, just try to stay tuned and hope for the best.
I agree that some things are not really at their optimum, but I do appreciate the big improvements AS3 made. My problem with re-introducing stuff like on() and onClipEvent(), getURL etc, is that it works fine for 'designers/animators/hobbyists' but it made a programmers life a living hell.
Since the MovieExplorer is kind of broken, and only works for stuff that's on the stage, any dynamic app with frame/instance scripts in Library instances is terrible to debug. (like changing an url that's hidden in a on(release) script somewhere in an invisible button nested somewhere in 20 folders between 10 almost-the-same items...)
My point: all the ease-of-use stuff is great for the common users, but unless some IDE tools (the MovieExplorer and Library) are implemented in a useful (!!) way my vote goes to banning them for ever. So: feel free to make it all easier to use for common users, but please give the developers proper tools to handle the resulting mess.
I agree that AS3 definitely was a lot harder and intimidating to master, but at the same time it was extremely exhilarating to use for a programmer. The power of the new AVM, the elegant OOP infrastructure, as well as the consistent binding of Actionscript to IDE [MovieClips and Sprites] were great welcomes.
However, I've found teaching AS3 to non-programmers an extremely difficult task, as AS3 is just too much of an OOP language. You either had to learn real programming to use AS3, or either not use Flash altogether. It's a really big leap of faith, to convince someone to wrestle programming, before they can begin using the simplest form of interactivity to make Flash games etc.
This seems more of a complain about people's attitudes for the quick-and-easy Flash, than an actual problem about AS3. In a way, yes. But it is nonetheless essential for Flash to capture the designer audience once again. Otherwise, if Flash loses its popularity with the mainstream designer community, it bodes not well for the rest of us programmers as well.
As an IT developer adopting Flex as a platform for enterprise apps, I marvel at AS3, relative to the greater complexity of Java5/6 and C# 3.0 languages.
AS3 provides some of the good static type checking capability that large team enterprise app development needs, yet still enables ability to drop into dynamic programming mode if needed.
Overall as a language it is easy to learn and very expressive - yet avoids the kitchen sink complexity of a language such as C# 3.0.
Ironically, in contrast to the thesis of this article, what I ponder is all the attention that Adobe lavishes on the legacy of the Flash web script kiddies community vs. concentrating fully on the concerns that relate to Flex as a serious platform for IT shops.
There are definitely two major audiences at play these days. I certainly embrace, though, the directions Adobe has gone with AS3 language design and Flex 3 platform considerations. It's very good stuff, and easy to groc compared to other attempts being made.
Regarding
"Charge #3: Casting DisplayObject.parent Makes Controlling Parent Movie Clips Hard"
You should be able to access the .parent without casting by simply calling the parent's function like this
this.parent["functionName"](pram, pram, ...);
I agree that is not straight forward, no casting is required and is much simpler than forcing a cast, and it also works with properties
this.parent["play"]();
instead of
MovieClip(this.parent).play();
the advantage of this way is that you don't need to know what type the parent object is, say for example the object can be attached to various different displayObjects whether a MovieClip, Sprite or Shape casting to the wrong type can produce errors and then you have another level of complexity to deal with.
Having all functions work like properties is one of the strengths of a language like actionscript. It allows for neat and compacted code.
Regarding the other issues I don't really come across them. I don't use the Flash IDE that much.
The only one I probably miss is the duplicateMovieCLip() function. Besides the workarounds mentioned an experience actionscript programmer should have a problem working around the issue.. here are some ideas
1. Any DisplayObject that you want to duplicate should be have properities that control the rendering so you shoudl be able to copy over the custom properties and should reproduce the DisplayObject
for example if I want have a Sprite that loads an external image and displays it create a class calles Image that extends Sprite and is should have a custom property say image.url for the url of the image you want to load. and the when the class gets initialized it should automatically start loading the image set in the image.url property. So to duplicate the movie you copy over the properties.
2. the object above should have a function duplicateImage or what ever.
it should. return a new object of itself and have already copied the image, not reference the same image. This can be done, i just don't have the time to code this right now.
Also It seems that one cannot send arrays using URLVariables to a server side script so it should also be included in the Charges Again Actionscript 3.0.
Thank you collin writing this article. I am the copy and paste find bits on the internet multimedia designer, video, motion graphic, type, color, interactive, interface, informational jack of all trades who uses flash to make things look the way I want and move the way I want on the web while delivering rich experiences. That is all I want to make things pretty and move how I want. AS3.0 is killing me right now and all these lines of code make life suck. I want to interact with a tool for making interaction fun. painting is fun. so should making interactive environments. I buy tons of components and prebuilt things all day from places like flashden and it gives me a easy way to get shit done quick. that is how flash should be in my opinion. like a huge flashden were if you want to customize you can get in the code and edit. But really designers and artist in general need a tool to let people interact with their art and information and flash is the best thing we have. I want my gui. just let me jump to a place in time off any object on the stage. I got the as 3.0 books and try and teach myself but I continually ask myself is this really a life worth living. I just want to make interactive art as a one man team. maybe I am asking for too much
My big request list:
* Class Templates
* Dense vectors (instead of Objects)
* Threads
* Native Plugins (mainly for audio / video codecs)
* Better access to the hardware (for 3d, usb, etc...)
* Remove the keywords 'function' and 'var', they are annoyingly unnecessary
* Separate compilation
* Optional manual memory management (new / delete)
* Better Network libs (SMB:// access, FTP, bittorrent, etc..)
This is a huge list, so do with it what you can :)
Adobe has, it appears, a vested interest in becoming a market player in enterprise applications. If I were to vote for anything I would ask 2 things.
1) a decent development environment. People who come from java seem to really love current actionscript dev environments, to which I say use the only product that Microsoft ever got right for one week... Visual Studio. To the Flex Builder team especially, learn cs use visual studio for a month. You'll become so spoiled and feel like your vim > flexbuilder evolution was like a "terminal computing" > web 1.0 conversion.
2) Why in the world is there no way to load external modules in AIR? LocalConnection? LoadBytes? Are you serious? The removal of loadMovie() was no big deal and sort of makes sense to me. But the intentional (as I've learned from those close to the AIR team) removal of the ability to load external modules is already pushing large companies to stray away from Flex as an enterprise solution.
If I just can add my two cents...
An observation I made:
Since Flash hit the web many years ago, I was fascinated, stimulated and driven forward by a lot of cool, creative use people of very varied backgrounds (and programming skills), all of which would erupt from hundreds of different sites almost daily. What I loved was hanging in forums, on personal websites, and such, dissecting cool experiments (and not always involving OOP, mind you) and reading "pseudo-tutorials" written by enthusiastic Flash fans.
This time is over.
Now, on every forum, blog or Flash site I go, people are debating, pondering, cogitating: all I see everywhere is Class, Casting, Package, Implementation, Error Catching, Inheritance, OOP, Singleton this and that...
The fun is gone (for a lot of long time fans it seems).
Don't misunderstand me: I'm no stranger to programming. I have been programming interactive projects in various languages and environments since the 90's. I'm also teaching multimedia programming in Flash since Flash 5...
I'm just sad that hardcore programmers are taking over not only a tool that grew mainly because of thousand of "amateur no-so-good-at-OOP wimps", but I'm also sad that there is no serious, user firendly alternative.
Director was trashed and abandoned by Macradobe (Most of you probably didn't check, but version 11 released this spring is not only a joke, but an insult to long time users). I'm not suggesting to go back to this software: it is dead (or undead...if you prefer :-)
Nonetheless, I smile frequently when I see Flash Addicts gathered in Adobe PROMO conferences cheering announcements of new features to Flash, or Air or god knows how many zillion Adobe products. I smile because more often than not, the "fantastic" new features in question are in fact things that good old Director was already able to to (and sometimes better) many years ago...
When I listen to a lot of "hardcore" programmers, I get a funny feeling: I have a neighbor who LOVES cars more that his life. And he drools just starring at the engine of his bomb knowing it COULD go over 200mph. Of course, he'll never go that fast just to go to work or shopping. But he drools... And talk about it, and read about it, and...
Just like a lot of hardcore programmers drool at AS3...and OOP in general.
I don't want to resuscitate Director (and please don't start another sterile Flash vs Director debate). I just feel Flash should be build with a similar philosophy: like someone said earlier, simple things should be easy to do.
In conclusion, I want to point out a few things:
1) There is a gap in Adobe's strategy for software development: there is no easy to use (yet powerful) alternative to Flash (And I don't want a PowerPoint like soft, but rather a simple but powerful, flexible rich media environment - yes, a bit like Director).
2) There are tons of people for which AS3 sounds and feels like Esperanto (you know, that language that is so great that everyone should learn and almost nobody knows...) You can't seriously just tell these folks to learn all the intricacies of OOP or get lost...
3) I'm a bit skeptical when I read things like "AS3 responds to users needs". Ultimately, AS3 was develop by a bunch of hardcore programmers for a bunch of hardcore programmers. Not-so-hardore-programmers, Designers and fans where not involved (or even considered) in the development of AS3...
Sorry for the long post, but I felt someone had to write it.
BTW: Excellent article, Collin. Coming from you, concerns about Adobe and AS3 are to be taken into account.
thanks jim. both fixed.
Great article.
Slight glitch: In the very first Flash 8, AS2.0 example under Charge #1, you have:
on (release) { this.parent.gotoAndPlay(1); }Where I think you meant
In response to Todd Dominey:
You shouldn't generalize so quickly. I'm a designer and this as you say, "They create buttons, hook up some getURLs, publish, and get out. They can handle a line or two of code attached to keyframes or directly to objects on the stage, but setting up a MOUSE_CLICK event listener? No way.".
That's just crazy because out of all things AS3, listeners are probably the easiest to set up. I guess I'm just tired of hearing the whole designer / developer battle. Designers don't want to be 100% pure programmers, but at least they can do both and have that additional skill set.
It's very rare, in my opinion, to find a brilliant programmer who also is a brilliant designer (or vice versa) so let's work together and keep that mind open. :)
AS3 is quite hard in some simple things which can easily be done in AS2. Adobe should really consider to make it easier in next versions.
Coiln,
Note: In Charge #1.
Step 4.) of the AS3 equivalent, where you register the listener, the code hasn't been tagged correctly:
[code]
replayBtn.addEventListener(MouseEvent.CLICK, replayBtnClickListener);
[/code]
This may help clarify that point.
Regards
Elliot Rock
Coiln,
Note: In Charge #1.
Step 4.) of the AS3 equivalent, where you register the listener, the code hasn't been tagged correctly:
replayBtn.addEventListener(MouseEvent.CLICK, replayBtnClickListener);
This may help clarify that point.
Regards
Elliot Rock
I have been using (programming and animated) flash since version 4, actionscript was the first language I ever learned. when actionscript 3 came out I was terrified, mainly because when I opened a new flash file and typed the code I was used to typing I got multiple errors. So I read Moock's 'Essential Actionscript 3.0' and now my understanding of actinscript far exceeds what it ever was before. I also find AS3 to be FAR more intuitive than AS2 in most cases (I still occasionally find myself stuck trying to do something that was easy in 2.0). But for the most part I find myself able to program functionality in with AS3 that I could never achieve in AS2 without tons of code. Also when I used 2.0 I only did timeline scripting, and didn't even really understand what a class was. Now I don't do any timeline scripting and only classes and my code is so much more manageable. Going to AS3 actually forced me to become a better programmer and I am very glad I made the transition. Thanks Moock and Adobe.
I'm a programmer since 8 yearhs and a flash coder since Flash 5. For me AS2 was a total mess. With AS3 addChild() and new rendering tree structure I can do things never possible with AS2. But I agree that AS is becoming like Java where you have to type a lot to do simple things, so getting some ideas from languages with more compact syntax like python or ruby is welcome.
good post thanks
Just face it, AS3 was developed to work with MXML in a Flex component/control environment. The changes make total sense from that perspective. AS3 and Flex is almost an exact mirror of C# and ASP.net which enable my move from The Flash IDE to Flex with almost no learning curve.
I follow the convention of programming my Apps from a player behind the current version until they add an automatic update feature for the Flash Player.
So, for me the charges aren't really a problem until Flash 10/CS4 or on personal learning projects, or on projects that use features not available within Flash 8 player.
I do believe the charges above will be fixed in the next version of the Flash IDE.
Colin, i´m very happy about this article, i appreciate it a lot and i´m sure many, many of the flash userbase do the same (probably the vast majority).
I brought up concerns against the workflow introduced with newer flash authoring tools/language/player revisions repeatedly and although i have a programming education background and am a flash user since the first release by Macromedia i was then often just disregarded and treated like a script kiddy who just has no understanding for the fanciness of clean oop approaches.
yes, i can code oop and yes, i can do things in non visual way, but what the heck, if i want to work like that, what sense is there at all in using flash?
If i work like in C# or Java then i could aswell use those and end up with tons better performance and propper coding tools and what not all.
(And i also use other technologies when the performance/features are required and meanwhile generally more and more because i see no sense in doing things in flash the "new" (mostly a cloning attempt of java) all hyped way anyway)
I also don´t think it is a propper solution to release more and more authoring tools and say: hey, if this doesn´t fit your needs then just take that other one.
One shouldn´t have to buy/install and maintain 3 tools or more to be able to propperly work on creating flash content.
Also the more the thought is to split each part of what made up flash content creation (working with animation,code,components etc), the more cumbersome it gets to exchange assets between all those applications, its painful and a waste of time to work on animation/graphical content in Flash IDE and then work on Code in Flex Builder and hooray, here comes yet another tool for doing component based GUIS and each time it gets more time intensive to use things made in one in the other,hm, this is no propper solution.
Flash ide´s code panel should have all the coding features of a propper coding tool and all features introduced with newer AS versions should also be usable with AS1 and 2.
There should also be an option to make the garbage collector work as it did in as1/2/f8 export even when one works on as3 exported content, obviously the majority of flash users does not like the way the garbage collector forces developers to think way more about it. Its no gain to have to worry way more about if something was cleared from ram or not. If one tells the player to delete something it should be deleted. In any case.
That java does it the same way as the f9 collector is no propper argument for anyone who has seen what kind of ram hoggers many java apps are.
The 9 charges against as3/cs3 you brought up are good ones, there are many more though, like just easy access to child display objects inside other display objects got way more cumbersome.
Switch to another frame in an mc, try to access a child display object right when the framehead changed and get an error. Sure, one can wait for events before accessing child objects, but come on!?! Why make things so unusable that worked fine since flash3?!?
There is a difference between structuring things well and making things so "well structured" that the most simple things take way more time to do now,are less intuitive and more error prone.
From all flash developers i know (and that´s many ;) ) basically only those enjoy the "new" workflow who came from java or another language and basically didn´t like doing things the flash way in first place.
Thing is once flash´s language turns more into java´s or C#´s language and workflow side it has to be comparable regarding features, what can it handle, what can run well with it. Then it doesn´t look good at all for flash.
Flash always had the advantage of beeing able to do flashy things with more ease in less time, once it looses that there´s few reason left to use flash.
One argument i hear often against being able to place code in frames/on mcs or similar objects:
"Have you ever opened an old project fla and had to search for code? Good luck with that!!"
Yes, that´s right,that´s painful. But that´s the problem of the ide, not the workflow.
Placing related code in visual way onto objects its related to is a very intuitive way of working for many so it shouldn´t be dismissed. The limitations should be addressed. Example:
In unity3D one can code classes or simple scripts in seperate files. Then one has all code files nicely sorted in the project library. At the same time one can attach any amount of script files to any game object. That way one can have graphical workflow based functionality like with a codeside only made class inheritance structure.
At the same time code on any object is easily found,can be reused well and has pretty much any other advantages you´d like and many people say only is available in oop class based coding approach.
I don´t say go copy that 1:1, but yeah, have a close look there, while the rest of the technology/programming language/middleware world allows more flexibility, more ease of use and better performing results in shorter, more intuitive creation time, the "flash platform" is sadly evolving towards the opposite direction.
Your article raised some more discussion here:
http://board.flashkit.com/board/showthread.php?t=774457
I developed SimpleAS3 in response to the troubles non-developers encounter when trying to start using ActionScript 3. It simplifies many common tasks that became far more complex in the move from AS2 to AS3. Most importantly, many of AS3s strict rules are ignored. They have their place with larger projects, but simple scripting can be easier when AS3 isn't hammering the rules down your throat. SimpleAS3 is a work in progress, but I'd love to see designers, animators, and part-time coders play with it and check it out.
First of all, I would like to thank you Colin for speaking about this.
As one of the many AS 2.0 deselopers, I have found the transition to AS 3.0 excruciating (I am going through your book yet again.) One of my biggest frustrations is this continuing mentality that either you animate, or you are a programmer, which for many is just not the case.
I have used flash exclusively for interactive media and interactive training since flash 4. AS 1.0/2.0 is the language I know. Period. I am not a web dev/designer although I use an html wrapper to deliver my content. I script on the timeline with '.' syntax, I use movieclips for buttons ( I still cant believe they just didnt get rid of buttons all together with cs3 as it would have helped support the whole not coding on buttons concept) and my projects average about 500-600 lines of UI code, and 50-400 lines per interactive module because I NEED a blended solution for what I do. Its a many hat kind of responsibility. Much of what I create gets used by and customized by people with little or no scripting knowledge. aka. Unlike RIA programming, I expect and need people to modify my code. With the current incarnation of AS 3.0 its next to impossible.
Much of what you have brought up are certainly very valid complaints that I have had, and yes, for me at least, much of the issue does stem from a procedural vs. OOP transition. But, the more I learn and the more I speak with others in my position, OOP is not necessarily the best solution for what we do. The biggest difference I presently see is the fact that the pure OOP paradigm is well suited for 'flat' development. Meaning its better for heavier backend communication, and loading and unloading movies minimally with little integration of complex animation and interactivity. In that respect its essentially static from a visual perspective.
Interactive media on the other hand is not static, it has a more linear flow (not always but frequently) which can be more suited to procedural development at times. AS 3.0 leaves little room for this.
here are some of the reasons we use flash and AS 1.0/2.0 in the past:
its a blended environment with strong graphic (i havnt had illustrator loaded on my machine for 7 years), animation, and interactive scripting capability.
AS 1.0/2.0 code is relatively easier to read/learn than any other language, and is pretty forgiving in terms of scripting.
its easy to modify if designed for it.
use of external text files makes it easy to edit and allows for limited liscensing.
we do not use flash and AS:
so we can spend time trying to figure out what functionalites to import that should be a part of the program to begin with.
to manage our own Garbage Collection.
write 3-5 times the lines of code to get the same result (if possible)
to worry about things like what variables are public/private/internal/dynamic
Don't get me wrong, I am not for a second trying to say that things should go all the way back to the way they were. And I think its great that the serious RIA developers have a tool and a language they like in Flex, and AS 3.0. But to someone who has been using flash in its previous incarnations for as long as I have the changes have seemed very much like a slap in the face. Before the release of AS 3.0 Adobe has said that Flash holds 50% of the market share for e-learning development. Then make the sweeping changes they did to the event model and the language as a whole more than doubling my development time, and making it so I literally cant delegate any other development responsibility to anyone else on my team.
I appreciate the benefit of formal OOP for large scale projects. Heck, I use array based objects all the time, they are easy to add to, and easy for the others in my department to read and modify. But OOP is not the only solution, and frankly isnt always the best solution. And although there may have been amazing improvements in AS 3.0 , many of the everyday tasks that people have used it for in the past have become convoluted and unneccessarily complex for many users.
Matthew.
Thanks for this very helpful article Colin.
I am a creative with some AS2 skill, in process of shifting / updating my site to CS3 prod suite / Flash AS3.
It has been very frustrating to learn that much of my site code needs REPROGRAMMING, because of (some of the) changes you mention in your article.
In total disregard to the value of OUR TIME -- I wonder if ADOBE / AS3 coders thought to consider exactly what their changes meant to the actual FLASH working community in terms of our LOST time work hours.
Every SIMPLE BUTTON must be recoded to work properly in AS3
TRULY ABSURD WASTE OF TIME!
And a horror PAINFUL (RE)work - to all those with layer rich DEEP sites. .
GREAT IDEA Colin!!
"reintroduce a visual system for producing interactivity" THAT WORKS
SUGGESTION to that idea: MAGIC BUTTON = INSTANT BUTTON CONVERSION 2.0 to 3.0.
AGREE with you on - "What Should Adobe Do?"
WOW! Great article that drives home every complaint I've had with AS3 and Flash. Being a college student, AS3 is my first coding language and I am hating every moment of it. Putting together a simple site is cumbersome and slow, not at all what I expected from an Adobe product.
I did not become familiar with the "old" ways; i.e. AS1 and 2, but there is so much more support on the web for those two languages it makes it hard to ignore their viability and ease of use.
Colin, I took a second look at your opening statements, as well as a took a look at the Adobe labs Thermo site which leaves me with some pretty serious concerns.
According to adobe Thermo is designed to be a "no script" interactive tool that creates Flex aps.
From adobe:
"Applications created in Thermo are Flex applications that can be loaded directly into Flex Builder, providing a great roundtrip workflow for designers collaborating with developers. "
If this is the case, What do you see as Flash's role in the market? who will it be for?
Traditional developers dont seem to want to use Flash to develop, and Adobe is creating a "no code" interactive animation tool in Thermo.
There seems no point in Flash if this is what adobe is going for...
m.
How many times have I worked in a studio where I would hear a developer (frusterated designer) tell me how they used to be a designer. And yes, I am a designer. Unlike them I don't claim or even care to claim to be a developer. Well AS3 is little more than a developer's attempt at putting these pathetic, frustated, want-to-be-designers back in the loop.
Saddly when all is said and done they still won't be able to design their way out of a paper comp. What AS3 is managing to promise is that a businessman will soon have no choice than to hire both a designer and a developer. Designers will no longer be able to pull off the amazing work they used to.
xemcyw
It my experience Flash is an amazing program capable of suiting both the artist and the developer. Either can create their own brand of magic with this program. Who the user is was once brought out by by this amazing tool. But no more.
The developers won the day with CS3 but like any good marketing ploy the money makers will calm our frustrations with CS4 unti of coarse CS5 comes out.
Hey great article!
I'm one of those who "create buttons, hook up some getURLs, publish, and get out" people...
and yeah...spent days and several books just trying to figure out how to make a button that works...
OOP? I specifically looked up flash instead of learning java, python or other intimidating languages hoping that the IDE would make life easier with a reasonable learning curve (like u can get start doing pretty funky things in photoshop in under two hours, and not like 5 days for AS3...).
I was expecting the IDE to have some wizards or templates to make things easier... on this respect the timeline acts as some sort of GUI for people like us, whereby the codings etc. was at least intuitive in AS2, since concepts like frames are easily understood and visually conceptualized for us.
After prowling thru 2 books, I finally realised that AS3 makes a mockery of the existence of the timeline. Why does the Flash IDE even exist?!!! For people like me, it's practically only good only for tweening now, which is quite disappointing. And if u protest that "but AS2 legacy is provided", well, i suppose this "legacy" which is full of "disdainful crappy stuff" will still be there for us in the future versions for, say CS6, in its current pathetic form?
Also, since its now possible to easily write a whole animation easily using script alone.... Why the heck is the licensed flash IDE even still existing?? For you powerusers, there are free Flex compilers out there ain't it?
Can't adobe keep something simple for us desperate and infrequent users? --> read: i DON'T want to have to learn a whole f#$#!*&!!! programming language FROM SCRATCH just to create an interface for a one-off project that isn't even the actual content!
hi, this is a great Post, thanks. But i have to read it again and again, to gett all this infos in my brain ;-)
@i'm asking me the same, why the licensed flash IDE is still existing.. But no one knows...
Great article. I have to agree, after developing in AS3+Flash CS3 for the last year or so, I've come to the conclusion that AS3 has dramatically out-stepped the Flash authoring environment; there are just so many non-trivial no-good-workaround workflow issues. Hopefully over time those workflow issues will be addressed. But my biggest fear is that Adobe has somewhat abandoned what I loved about Flash: its hybrid designer/developer environment. Now we have Flex and Flex Builder for the programmer (not me,) Thermo being released for the designer working on RIAs who don't do any code (not me,) and an upgrade to Flash CS4 that looks to be aiming only at motion designers (not me) -- but the workflow issues for developing AS3 in CS4 are still almost completely unaddressed. This doesn't matter to the Flex programmer or the animator, but to the core Flash base who are a little of both (me) it leaves us unassured of our future. Flash used to be so much fun. :(
I'm afraid I'm one of those "plebian" designers, as someone mentioned in this post. I would google, cut/ paste bits of AS2 to achieve what I was looking for. I didn't have the luxury of an on-hand developer to run to when it got complicated, and even then, I had NO interest in learning how to program.
I'm a designer, not a computer programmer, and I don't believe the two skills are interchangeable. I found AS2 baffling, I still do, and because of that, when AS3 came out, I decided to cut my losses and stop working in Flash altogether. Without the help of a dedicated AS developer, there's no point for me. As a designer I will NEVER understand how to write code, and quite frankly I don't want to. As far as I'm concerned, it's someone else's job, a computer programmer's. And in my opinion, certainly in my case, programming ISN'T something that anyone can pick up, even given the right teachers.
That may give rise to derisory comments here, from developers or "old skool" flashers, but that's too bad. I know I'm not alone in the design community with my newfound disinterest.
Well... After reading many posts here, I think most of you are professionals or developers. So, let me bring in something from the viewpoint of a student.
First, we are no pro. We are just some kids who are hoping to create something that looks really cool. Flash (at least the older ones with AS2) allows us to do it.
This leads to my second point, time. As a student, I don't have hours after hours to learn AS3. I have no time to investigate how a class will simplify my programming in big projects. In fact, we will probably never touch any big Flash project in our lifetime. All we want is to build some mini-games that will bring fun to us and our friends.
Well, Flash was a hobby for many of us. We are just ordinary students. We are no computer scientists or university professors. We didn't use Java or C++ for a reason. And what appears to us now is that Flash is going closer and closer to Java and further and further from Flash.
As a Flash animator of over 10 years in the industry, Colin nailed it on the head here:
" Animators want their easy timeline control back."
In my studio we have suffered almost a 150% time hit in production due to the removal of Flash's non-programmer friendly features. Revisions that were once the sole province of animators are now forced onto the engineers as well. AS 3.0/CS3 has definitely been a step backwards from the art department point of view...
Good article.
I've been on the fence though as to how much adobe should scale back coding in FLA based projects. Most of my work is a combination of heavy timeline animation including importing FLVs for UI onto the timeline, and still lots of dynamic content in addition to the timeline manipulation. However, I'm all for making it easier.
Whatever Adobe does I really hope don't force all the good coding stuffs like was already done with the WebServices class - to be for Flex alone. Building everything out as Flex components is big waste of time for my workflow.
also a small correct:
You can get to the DisplayObject that dispatched the MouseEvent by using event.target; Your article says(unless I misunderstood you) AS3 can't find the object firing the event.
I am a designer, first and foremost. For six months I've battled with learning AS3. Previously, when flash was updated, features were added that never encroached on the way designers had been using the tool. Now, I can't even attach a movie to the stage easily.
The non-programmers have been told to "Shape up" for the Greater Good of Flash. Well, congratulations, Adobe. You have a more robust programming language, geared towards the future - but one which marginalises the people who have made the product what it is.
I can't believe how many people are complaining about AS3 being hard. Did you ever hear any complaints about C# or Java or whatever being "hard" - the only thing that changed is that AS3 is a programming language where AS2 was a scripting language. Perhaps all the people who are not able to learn a programming language should just stick with javascript or AS2 ?
Just my 2 cents -.-
Alex, you have to be kidding...
First, people complain about C# or Java, as well as about any other language (go to a computer programming school, you'll see). No programming language is perfect and the human mind is not working like the silicon brain of a computer: We are doomed to have some difficulties in communication...
Second, the problem here is not to have or not the will to learn a programming language... You (and a lot of others I think) have to realize that it is normal to be baffled with the so call "evolution" of SCRIPTING AUTHORING language (wich historically have been quite different than COMPILED programming languages, like C and C++), especially when you consider some simple "evolutionnary" examples:
-- Director Lingo
-- auto indent, no semicolon at the end of lines, no use of { and }
-- no overuse of ( )
-- directly associated with the instance of the button...
on mouseUp me
put "Hello World"
end
// Director Javascript syntax
// directly associated with the iinstance of the button...)
function mouseUp(me){
trace("Hello World");
}
// AS1
// directly associated with the instance of the button...
on(press){
trace("Hello World");
}
// AS2
// on a frame, in the main timeline...
this.bt_button.onPress=function(){
trace("Hello World");
}
// AS3
// probably part of a Class...but I don't want to get to that here...
import flash.events.MouseEvent;
this.bt_button.addEventListener(MouseEvent.MOUSE_UP, message);
function message(event:Event):void{
trace("Hello World");
}
No one can, in their right mind, claim that we didn't loose something with this so called "evolution" of scripting authoring languages... Things are getting more and more arcane... for no reasons...
Hell! A button is a button!
Flash can evolve and flourish as it much as it wishes. As long as people who are comfortable with Flash 8, 7, or previous versions can do what they want to do in Flash, no one is hurt.
I hope that Adobe does not force, sometime in the future, Flashers who would like to extend their Flash projects to become installable applications to learn AS3.
Colin... this is a great post / article... you have really brought up alot of great points (and provided solutions to some of the most major PITAs with AS3). Some thoughts:
I think that it is good that Flash has grown to be a "difficult' language. Years ago, when I was teaching myself PHP... alot of my friends said that they wouldn't touch the "stuff". I thought, "yeah, but that is where things are going... you have to know the tools of your trade. You have to be fluent in them. Otherwise you will be left behind."
I was always tripped up at how bizarre Flash (and esp Lingo) would create structures: nothing ever seems to follow suit. The way you did it here was different then if you did it here... even though it accomplished the same thing. Event listeners have leveled the field. If you can do it once, you can do it everywhere... in the same way. That works wonders for a learning curve!
Now, AS and Java and Javascript and PHP (and ASP) are so similar that you can float between all of them. What a great thing!
AS, Java, Javascript, PHP and ASP are not similar.
Just because they share (in part only) a cryptic syntax inherited from C based languages doesn't make them "similar"... Just compare classes and basic operations written in those languages; they really aren't that similar...
I must have missed something the past few decades... It seems the word "similar" as an extended scope now :-)
(forgive my english, I'm brazilian)
Not to add any significant insight to the discussion, I must say that you got to the core of the problem the way I see it: It´s not the innovations in the langage, but how to get access to them. I´ve been using Flash as an interactive animation tool for a decade, but since AS3 I can no longer get into a Flash project without at least a junior programming companion, and it sincerely feels like I´m the least important part of the team nowadays. Tell me about frustration! Tell me about the impacts on the jobs budgets!
AS has evolved so much, and there´s really no point in walking backwards, but I see no point as well in writing every single bit of the scripts, and structuring most of the syntax from scratch. Since Flash 8, programming a single button feature feels like using DOS, and it keeps getting worse! It´s not like we (nonprogrammers) can't learn AS3, it´s really not that hard, but WHY should we? Will it improve my drawing/animation skills (wich were consistently developed after years of hard work, like programming should be)? And won´t the language be replaced by some more flexible or robust one, if needed in CS6 (like someone up here posted)? Then, what?
If there's any petition for the focus on ease-of-use, sign me up :)
Great list, it helps clear up much of the htacess mystery and confusion that comes from creating such files.
Lucky i start learn actionscript from actionscript 3 if not then i have suffer like other
FINALLY, glad to see that a Flash veteran with a high profile was willing to say these things!!!!!! Hopefully Adobe is listening...People like myself who've been building Flash for a over a DECADE and AREN'T programmers by training seem to have been forgotten about by Adobe. But last I checked, we're the majority of developers out there.
Flash will die the way Director died if Adobe doesn't reconsider the course it's on. That has me genuinely worried for my personal future...I've hung my hat on Flash for about a decade now, and yet I wonder if 5 years from now I'll still even want to work with the software (but THEN what do I do?!)
Making the language and environment more complex raises development time, which raises costs to clients, and ultimately makes doing things with Flash less appealing. Making the application more difficult to use raises the barrier of entry to beginning developers as well, which means less copies of Flash sold. Adobe, if you're listening - making things that used to take 1 line of code take 15 lines now is NOT an improvement!
Great article. I think that the improvements in CS3 regarding performance are impressieve, and I don't mind writing some extra lines of code to obtain this. What I do mind is the steepness of the learning curve and wasting hours browsing the internet for answers which ought to be in he flash help engine.
Claus, you nailed that last part - i.e. when I got AIR all set up and running, NONE of the help documentation is even there?!?! The lack of examples within the documentation is nothing short of appauling - EVERY line, every property, EVERYTHING should at least be shown in context, with proper sytax. That will go a long way to helping users migrate from AS2 to AS3, which frankly needs to happen if Adobe is gonna move forward. We can't spend the next 10 years having half of the Flash developers out there using AS2 with the other half using AS3....
I'm gonna keep my comment simply and not apologize:
I am a designer, not a programmer. I initially learned Director to some extent in art school. Basic stuff, nothing too heavy on the programming. Then they began to bloat Director code to give it more functionality and it essentially became useless to us basic designers of interactive "things" (before the Internet became more graphically based, was only text and hyperlinks with a logo at the top of most sites/pages). So, it got to a point where the application and interface wasn't sufficient to aid me in getting what I needed to get done.
Then Macromedia announced Flash and all it's "ease of use". It was correct in it's self promotion and hit the spot where designers needed to design and not spend as much time or more coding. Then as the years progressed and more features were requested an implemented more programmers joined the bandwagon and started making their requests for features/changes. As soon as Macromedia started implementing changes for programmers Flash became more about coding than designing interactive animated "things" (I'm trying not to state "Web apps" or anything else).
Iterations later, Flash has essentially become Director for the most part as it is now more about coding than design, leaving designers YET AGAIN in the uneasy situation of giving up on design to become a programmer just to design for an hour a month or giving 90% of a project's pay to a programmer, neither is acceptable.
There are plenty of other platforms and coding languages with support/implementation for Web, CD-ROM, platform-specific (or not) application/programs for coders to code within, yet they have effectively taken over what was a designer's app and pushed out the designers.
I don't take on or try to implement any heavy-duty scripting, I'm a designer and must fight to keep it that was there is not a middle ground if you want to do print, Web, Flash, Video and 3D design. There is NO TIME to learn a whole new way of doing the same thing every other year, not if you actually have enough work coming in to make a living (which is tough for an artist).
In simple words Flash is lost unless Adobe implements some alternate interface for easily adding functionality (that has all the options AS3 allows for). I don't have time to start over on how to code a Flash project every time a new feature set is implemented, in my basic designer mind that should simply be new additions to the existing code set, not a whole new way of doing things, every other year.
Most of the comments here are by programmers that can't seem to understand that someone else's job isn't ruled by coding every minute of the day and it clearly shows why that ignorance has infected what would be a fun and easy to use application. Sure I can still use Flash for basic animation but changing out how to control timelines and other things just so I can add fullscreen functionality truly shows Adobe has willingly fed Flash to the programmers and has yet to create a new easy to use app or Flash version or mode.
Programmers make their living by creating situations that require a programmer to do more work, thus a vicious loop. It's everywhere now and until there is some unified programming language where applications can be built and kept to their original purpose without being overrun by programming changes (artful animation is not programming) then there will never be an end to this madness. "Interactive" does not imply coding but does require setting interactivity (programming).
Coders will likely read my rant and laugh. Let me give you a canvas and tell you what I want you to paint and in what style and let's see the sweat roll.
Designers should not be allowed to code! They create spaghetti code (AS2) which becomes impossible to maintain as the project grows. AS3 fixes that making Designers design and Programmers program.
" Animators want their easy timeline control back."
Agreed.
Low-level timelines stuffs isn't that easy to do in AS3 anymore, since AS3 is more suited to designing applications and structures, not scripting timeline animations. For example, designers that do AS3 may not understand that "conveniniently" adding event listeners on the timeline is detrimental to the whole application, especially when you have to remove them later, but is impossible to keep track off on the timeline, especially when movieclip references dissapear. AS3 took away timeline versaility, restricting work to static single pages (or carefully planned-structured pages) with components/classes that should only exist in 1st frame for pre-initialisation of various interactivity, to allow a page.destroy() to occur for proper cleanup, assuming the references of "hot" items are still there. How do you handle complicated nested timelines with linkage classed symbols (each having their own mouse events listeners), appearing and disspaering on the stage with blank/non-blank keyframes in the middle of frame 62? In AS2, this was an issue, but in AS3, an even bigger one. Do you mean such trivial on-the-fly hotspot areas (while a timeline animation plays) should be placed on the first frame to allow the Document class to access it (made with alpha zero), and therefore easily allow the developer to remove the listeners when it's done? Or do you trust your designer to remove the listeners on (gasp, on the timeline??). What if your page prematurely unloads/switches before reaching the point of removing of listeners? All this can become a real logistical nightmare, when last minute changes occur time and time again.
That's why , for low level stuffs, I've resorted to developing a ClickManager singleton to help things out (and hopefully reintroduce a bit of AS2 timeline sciripting back for low-level simple tasks). It uses object pools to avoid unnecessary overhead with classes instnatiating/and being destroyed() when removed from the timeline. For something as simple as hit tags, hit areas, hot spots, etc. why not create a pool for those items, and reuse it throughout the site?
Ok, for the developer's example, a "ClickManager.api.allocate(10,5,5)" is used to allocate a reusable pool of 10 clickables, 5 hot areas and 5 hotspots which is more than sufficient for a certain page (it can auto-grow by default if not enough is found in the factory). It therefore allows any on-the-fly on-stage timeline clip to be hooked up with mouse clicking functionality.. Anytime, such objects are removed from the stage when the timeline plays, it returns back in the pool automatically, to be reused again. So, your timelines can scroll in/out freely, without having to worrry that your classes are instantiating listeners and unregisering them way too many times while a complicated timeline animation plays. In fact, everything runs procedurally again as it should, which should be the case for low-level stuffs like this.
In fact, the use of seperate arbituary hit areas keep the graphics and code seperate and decoupled, rather than tying all the code in the class bundled with it's graphics and exporting a hefty linkage, you nest the hit area sprite within the graphics container, or reparent all graphic container assets to the nested hit area sprite, thus assuming that "functionality". AS3's reparenting supports that, thankfully :) So, should linkage classes be created for such items to nest such hit areas from the pool? No. In fact, just using a timeline script would suffice to simply fish out the items from the pool and make these items "clickable" by adding it in, which is much faster than instantiating a class than running the procedure). The result: hit areas are added, which provide on-the-fly functionality on the spot for any on-stage clip, without the complications of class creation and OO programming, which is only done for more complicated aspects of the application (where you woudn't expect such classes to destory anytime soon).
Garbage collection of unused hotspots in the pool is as simple as calling ClickManager.purge() by the developer when he exits out the page completely. By default, all clickables and hotspots bubble their own custom events, so developers/designers can still add listeners if they want, but it's optional, and mainly done by developers to handle higher-level stuff whenever required. It keeps things light-weight as well, especially for sites where there are many "hot-areas" appearing everywhere thorughout the animation per clip over trivially numerous areas. Why constantly reconstruct/destroy your individual classes everytime when your site has thousands of hot clickable areas appearing/disppsearing on the timeline? I also like the fact that you don't need to register a stage listener per class to detect an onReleaseOutside (or register one on the fly when a press is detected, and unregister when a release occurs), as this is already handled internally by the ClickManager when it's notified of a certain hotspot press.
Here's an example of the resulting syntax.
// Hook up on stage-movieclips
var funk:Clickable = ClickManager.api.makeClickable(funkyIcon);
funk.onClick = function(e:Event):void { // in-line functions where "this" refers to e.target
this.onClick = null; // remove clicking functionality of hotspot clickable
(parent.target as MovieClip).play(); // play parent movieclip (the funky icon)
}
ClickManager.api.addClickable(simpleBtn, doClick);
ClickManager.api.addHotspot(rollableBtn, doClick, doRollOver, doRollOut);
ClickManager.api.addHotspot(mcerBounds1, doClick, doRollOver, doRollOut, doPress, doRelease);
ClickManager.api.makeHotspot(mcerShape2, doClick, doRollOver, doRollOut, doPress, doRelease);
ClickManager.api.makeHotspot(mcerShape3, doClick, doRollOver, doRollOut, doPress, doRelease);
// All targets and e.targets refer to the nested hotspot. Access the targetted item with parent (and cast correctly to gain access to required methods).
function doRelease(target:Object):void { // similar to AS2's onReleaseOutside
var mc:MovieClip = target.parent as MovieClip;
mc.gotoAndStop(1);
mc.down=false;
}
function doClick(e:Event):void { // functions as AS2's onRelease
trace(e.target); // traces the nested hotspot being clicked
}
function doRollOver(e:Event):void {
var mc:MovieClip = e.target.parent as MovieClip;
var cur:int = !mc.down ? 2 : 3;
mc.gotoAndStop(cur);
}
function doRollOut(e:Event):void {
(e.target.parent as MovieClip).gotoAndStop(1);
}
function doPress(e:Event):void {
var mc:MovieClip = e.target.parent as MovieClip;
mc.down=true;
mc.gotoAndStop(3);
}
var hotspot:Hotspot = ClickManager.api.addHotspot(skipBtn, null, doRollOver, doRollOut, doPress, doRelease);
hotspot.onClick= function(e:Event):void {
trace(this);
(this.parent as MovieClip).play(); // play parent movieclip
removeChild(this); // remove hotspot and returns it back to ClickManager's pool (but parent movieclip continues to play)
}
hotSpot.onRollOver = function() {}
hotspot.onPress = doPress;
hotSpot.onRelease = doRelease;
stop();
As a Flash animator of over 10 years in the industry, Colin nailed it on the head here:
" Animators want their easy timeline control back."
In my studio we have suffered almost a 150% time hit in production due to the removal of Flash's non-programmer friendly features. Revisions that were once the sole province of animators are now forced onto the engineers as well. AS 3.0/CS3 has definitely been a step backwards from the art department point of view..
-----------
I think the most common complain for non-programmers/designers for AS3 is that they need to realise that AS3 isn't meant for timeline scripting anymore, but more towards development on the applicatio layer. If you need convenient timeline scripting functionality on the presentation layer, and if your development style involves heavy use of presenting interactive stuff on an animated Flash timeline, I'm afraid AS3 doesn't work well for that. Rather, from the AS3 language ground-up, developers must create an extended scripting api to hook up such functionality on that presentation layer of the timeline, one which keeps track of garbage collection, object removal, etc.stuff on the application layer itself, and so provide a scripting platform to allow non-programmers to do whatever they need, per site context, without being concerned about the application layer and the overall archicture of the site.
Some common needs are:
1) When do I call the application to initialise this page's assets to display the correct data?
2) When does this little button go "hot" while it's fading in? (ie. active and clickable)
3) When do i notify the application that this page is done and can be exited out through some cmmonly shared transition? Or do i play my own timeline animation for this?
4) This button appears and vanishes at various spots repeatly. Is there a convenient way to hook it up without using a listener that repeatly registers/unregisters itself? Can it be treated as the same class object with the same state?
5) How does this text restore itself when the playback head revisits this page? It needs to maintain the previously set state, and the same UI functionality. But this timeline is destrutible.
6) Can I type less in this tiny IDE window?
Face it. Sometimes, we need designers/producers/developres to script stuff on the timeline. But back then in AS2,various agencies would only adopt the rules of strict one-liners, function calls and play()/stop()/gotoAndStop(), etc. within such timelines, else things would go real messy. Flash had this timeline functionality, which was a problem back with AS2 then, and even more now in AS3 with the stricter language requirements.
Yet, scripting on the timeline (especially in AS2) was fast, because you didn't need to worrry about scoping availability when dealing with an external document class. And for simple tasks, we need something to help out deal out presentation. AS2 provided that means.
---------
I came up with an idea where in order for designers/producers to create timeline animations that NEVER conflict with application level document class code, you must completely de-couple the application layer (document class) with the presentation layer (the timeline), yet provide a bridge between the 2 so that designers can decide when something should interact on the timeline, easily navigate to certain locations, retrieve data from the application, etc..
The common notion:
Symbols are to be animated on the timeline. If they are to be accessed directly by the document class, designers must name them and key-place them at various key-initisation points on the timeline, so the document class can access 'em. Don't destory this classed symbol on the timeline. Use the same instance name throughout. The list goes on...
...But that's the typical flash development paradigm. Here's another model:
1) Don't link library symbols to classes at all. Let it be strictly pure graphical symbols on the timeline.
2) Your classes should not contain any hard-coded graphical asset references, even if they extend Sprite. Rather, adopt the nest-in model, where your class sprite holder (which may contain registered mouse detection listeners) being an empty shell only. Your artist/designer calls an api function on the timeline to hook up the graphical assets into the class shell, and he decides WHEN they become active, and when they deactivate, on the timeline itself through simple api calls....
3) Create a pool factory for such classes (whether non-sprite or not), especially low-level classes like invisible hotspots, hit areas, etc. where the classed shell sprite can be nested inside the animated symbol on the stage, thus hooking up contents with various common scripting functionalities. Since the class shell is found within the symbol, they can move together with the symbol that is animating on the timeline, without affecting the timeline animation directly.
6) Many of these factories can be recycable, (eg. hotspots, hit areas, etc.), so once removed from stage because the symbol disspears to a blank key frame, they return back to the pool and can be reused again. So, no need to reinstantiate classes with new Something() each time. This is especially crucial in timeline-based animation, since you have virtually little control over instantiation, removal and destruction of items.
4) Basically, your designer/producer just calls the factory methods like so: Manager.api.createHitAreaOver(mySymbol), or
var clickable:Clickable = Manager.api.makeClickable(mySymbol), etc to hook up these items and gain access to helper methods per class type.. clickable.onClick=function(){}, etc. Everything can go back to simple procedural AS2 scripting from there. You don't need to worry about them adding some rubbish event listener..or your classes doing so, particulary if you pool your classes in an Object Pool. Even your classes are so much more resuable now, since it's complete decoupled from the presentation layer.
5) Some things to take note: Because your class would need to re-parent the symbol's inner contents to the class shell sprite itself if you need to receive mouse events, make sure the items being re-parented are not running on a timeline or else you'll get display residue and problems due to restructured parenting while a timeline is playing. That's why developers' code shouldn't alter anything that exist on a designer-animated timeline because the animated timeline already contains tweens, alphas and preset positions which SHOULD not be changed by the programmer. ALso, it's better if your designer stops() all nested timelines which are meant to be run by your class,. I suggest using a sole "content' movieclip holder that houses all graphical assets and timeline animation within for the developer to make use of. So you got something like : mySymbol.content in authoring view and mySymbol.myClassSprite.content in runtime. The developer's class can simply getChildByName("content") to access the graphical content., making clear segreation over what gets done on the presentatoin layer by the designers, versus the UI layer by the developer.
6) What's more, once the symbol gets removed from the stage, garbage collection is simply a snap because the class sprite shell can safely remove itself from the parent symbol (if it's still there), (empty all references to null), remove any nested children and return back to the pool to be reused, parked with a certain ID to be reused on a 2nd hookup, or destroyed if you wish. Your api can provide means for your designer to decide whether the item can be "parked" thorugh simple one-liner timeline scripts, and reinitialised the moment it appears back on the stage.
7) Provide means to notify the application to update visual data (dispatching bubbled events can also suffice, so it's up to the developer's experience here, though direct procedural function calls may run faster compared to dispatched events)
Manager.page.setupContent("january", { arg1:4, ....} );
Manager.page.activateContent("january");
8) Discuss closely whether buttonMode can be used to determine a button's activate state, and share responsibility betweeen how timeline settings can affect the UI's state, among other stuffs...
9) Keep event model and OO to more higher-level applciation stuff for the site .
And so, with regards to Charge #8, perhaps, Adobe never actually wanted an object oriented system for their timeline-base Flash GUI, because if they did, their GUI would have been much better and users would have been able to control the class-states of various items in Builder-style and their object existence. The flash timeline wouldn't have been destrutible as we see now. Objects that dissapear on the timeline could be shifted out and reused later on the next re-visit, allowing a consistent interface between language and presentation, where items with only 1 frame could be declared as a Sprite, and marked accodingly. Not everything would need have exist on Frame1 in the timeline, and could be outside the display list, without destroying the current movieclip timeline even if somethings gets reparented en-route. From AS2 onwards, the timeline has always been the bane of application level code, because there was no real bridge between the 2. Even if a GUI was provided to set display objects to become concrete TextFields and such, all this happens in authoring time, which differs very much from runtime anyway, particularly for timeline based Flash animation.
But the Flash timeline is an artist platform. Perhaps, it may be better if the GUI is left simple as it is now, while developers find ways to bridge the two layers in a non-obstrusive way through the use of frameworks and other wrappers. And as always, this is very personal. Some people like this, some people like that.....Until Adobe can think of something good enough which can cater to all users, perhaps, they'll leave it to developing teams to come up with their own schemes of doing things.
I don't know, I had a problem before with linkaging classes to symbols, because developers have no control over HOW they end up behaving on the timeline because the timeline is a different planet, really, and it's not common for artists to create them in ways which make them impossible to keep track in the Document class, or account for garbage collection in AS3. To begin with, linkaging classes might be good, but how do you control WHEN a button's buttonMode becomes active on the timeline or an object's state on the timeline? All these are very personal things. AS3 has helped in allowing events to bubble up for the Document class to handle. And perhaps, the decoupling between timeline and application level-code is a good thing, though bridging is hard, I don't see how AS2 is better than AS3 in that respect.
As far as AS3 goes as a programming language, it's way better than AS2. But it took away scripting control, which means timeline events would have to be delegated to programmers to handle, which was the standard practice back in various AS2 studios anyway. In various ways, returning back a scripting platform for non-programmers to script various rudimentary stuff, could be done, but now it's a personal decision on the developer's team part whether various coding work can be shared between departments and their own api. Programmers/developers create a unique wheel per site, but scripters and artists don't have to reinvent it again. I guess the problem lies mainly in, reinventing the wheel, particularly long pieces of code especially on the timeline --- and in AS3, OO-based code which shouldn't be on the timeline anyway, because the timeline is essentially a very dynamic and procedural interface, while OO is static and built more for back-end stuff (with concrete fixed/variables, strict typing, etc.. Even if you need a dynamic class, you must explicitly define it to be so. How's that for scripters on the timeline?.
Perhaps, the problem with AS3 is: Programmers try to be scripters, and scripters/artists try to be programmers. AS3, with the way is done, now requires a 3 man team actually, a programmer, scripter, and designer.
I think the change from AS2 to AS3 was a step that adobe has to do no matter what. Today web development is all about interactive, websites with dropdown menus, animations, parts of webpages retrieving and sending information to the server. (i think thats what they cal RIA)
With the evolution of technologies like AJAX, javascript,... adobe had to come up with a tool to create even more complex websites than with these technologies. If flash stays at AS1/AS2 level it would be replaced in 5 years by javascript. The main advantage of AS3 is that its possible to make much bigger projects than with AS2. In my opnion the next 2 steps flash must take:
1. - implement full GPU support - this will make much better looking applications possible. Its kinda funny to see pro flash developers struggling to make 3D animation that looks like from '96. (an 1996 game like turok 1 which run on a pentium 200 is still far from possible to make with AS3 on today's core2 duos)
2. - fix the right mouse button! It is now completely useless. And i think its one of the main reasons ppl dont like flash too.
I think the change from AS2 to AS3 was a step that adobe has to do no matter what. Today web development is all about interactive, websites with dropdown menus, animations, parts of webpages retrieving and sending information to the server. (i think thats what they cal RIA)
With the evolution of technologies like AJAX, javascript,... adobe had to come up with a tool to create even more complex websites than with these technologies. If flash stays at AS1/AS2 level it would be replaced in 5 years by javascript. The main advantage of AS3 is that its possible to make much bigger projects than with AS2. In my opnion the next 2 steps flash must take:
1. - implement full GPU support - this will make much better looking applications possible. Its kinda funny to see pro flash developers struggling to make 3D animation that looks like from '96. (an 1996 game like turok 1 which run on a pentium 200 is still far from possible to make with AS3 on today's core2 duos)
2. - fix the right mouse button! It is now completely useless. And i think its one of the main reasons ppl dont like flash too.
Great article. I think that the improvements in CS3 regarding performance are impressieve, and I don't mind writing some extra lines of code to obtain this. What I do mind is the steepness of the learning curve and wasting hours browsing the internet for answers which ought to be in he flash help engine.
Hey Colin:
I bought your book December of 2007, Essential Actionscript 3.0, I know quite a few web designers and nobody at the time knew as3.0 (and I had a project that required 3.0), around October last year I had people finally asking me questions about different things, I started off with flash back in 2000 when it was version 6 I think, went from as1.0 to as2.0, now that I've been working in 3.0, I love the control it offers, I won't even look back at 2.0. Great piece. Hope you're doing well, palnning on getting your flash cs4 book. Cheers! -Aaron
As far as AS3 goes as a programming language, it's way better than AS2. But it took away scripting control, which means timeline events would have to be delegated to programmers to handle, which was the standard practice back in various AS2 studios anyway. In various ways, returning back a scripting platform for non-programmers to script various rudimentary stuff, could be done, but now it's a personal decision on the developer's team part whether various coding work can be shared between departments and their own api.
Hi experts,
I want stop a animation which is developed in AS 2.0. Now I want to stop this animation after loading in AS 3.0. I am using this code:
var loader:Loader = new Loader();
addChild(loader);
loader.load(new URLRequest("AS2Animation.swf"));
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, fileLoaded);
function fileLoaded(e:Event) {
//Here I want to stop AS2Animation
// e.content.target.stop---- it's showing erro
// What code I have to write here?
}
Thank you for the blog posting that captures a lot of my feelings on the AS3 beast that grew almost too quickly for its own good. This is a discussion I really hope Adobe is tuned into (especially the old Macromedia guys who did so well to work with the community before who are now at Adobe).
I want to take a more philosophical approach though to add my thoughts because the technical language here so far has all captured the elements pretty darn well but its a sad conversation compared to what used to happen in the Flasher's World of flashpad.net, then were-here, then the explosions of other Flash Worlds.
I began using Flash 2 when Macromedia bought FutureSplash. I was teaching Director at the time and was told to learn and write curriculum so that "Flash" could be taught. I learned it on my own and always learned it on my own through really good documentation and really good tutorials on the Help files. There was no other way. No forums, no code from a web site to copy and paste, etc.. I still work best through the Help files but I a primarily a designer from the print world so Flash enabled me to put together all types of media in a quick and designery-way that made sense.
The point of my comment is that somehow we lost our way in the Flash world. This is the first time I've seen ANY sort of divide in the Flash community. The Flash community had always been 'designery' and 'front-end developery' and they were laughed at by the 'real programmers and developers'. But they communicated together and grew a small inconsequential program into a boundary-pushing piece of software with Macromedia. Make no mistake, the community helped and Macromedia listened and made one fantastic piece of software with each growth. It ran well. The installs were small. The documentation was so good, you didn't need "the books" to learn it and that was for either side of the world....designer or developer.
Where we're at now is a divided community where we can't agree what Flash means or where it needs to go. We've lost in essence what Flash was about and the growth of Flash into an RIA 'real programmer' tool came at a cost. Adobe sacrificed those long-time users hoping the users faith would keep them around while they tried to attract the self-proclaimed real programmers. So, the 'whiney designers' do have a legitimate complaint in this. Adobe rendered all their YEARS of skill and effort useless and forced them to learn along side new programmery type people which gave the programmers the advantage. Rendering ANYONE'S skills useless can be disheartening for sure. It evened the playing field. But since programmers have a wide variety of languages and applications to switch to if they hate Flash, designers cannot. And while everyone wants every application to be an RIA, the reality is clients are still asking for banners, animated buttons, etc just as they always did. AND most times the work is so custom for each client that while some code is reuseable as classes, most times things need custom and rewriting based upon the client's request. Sacrificing ease of use in order to make a language work for Flex was a bad mistake by Adobe as certain quick tools were taken away by Adobe for those users coming from AS2 and earlier.
The benefits of such a tight community of Flash users in the old days meant there were adopted standards that worked. Flash was always Object Oriented. MovieClips have their own code which you could reuse and copy and paste and dynamically duplicate at will at any time. Programmers hated that because they "couldn't find the code" which meant they had to learn the Flash standards of the 'actions' layer always on top, init code placed on the Movie's onClipEvent function and first frame for continual code, etc etc. There was NEVER a re-useability of code issue. Classes (in external .as files) actually make it tough now for designer/developers to find the relevant code to make a small change because they have to open the .FLA, then find the symbol, find it's Class Name (decided by the 'real developer') and figure out what they have to change. Before the front-end guy/girl only had to open one file (the .FLA) and find the symbol with code attached.
Now 'designers' must readjust to programmer's mentality and OOP doesn't answer all the questions even when compared directly to Flash's Object Orientations based upon the standards Flash users came up with over the years. Using Levels to load .swfs became the 'best use' to gain control over 'one big swf' mentality. Because Levels and ClipEvents were the standard operating procedure, the 'designers' are now confused. The books help but the documentation from Adobe fails miserably. Even sometimes if you copy and paste code from the documentation, the code will still fail.
I will be honest, the failure does lie with the IDE. FlashDevelop is f'ing great especially on adding necessary import statements and code highlighting custom variables. Adobe has been sloooooooooow to make Flash work well with the language changes because they've dedicated too many resources to all the different program streams. But you have to understand the whole mentality changed on a dime and the Flash community is no longer the cohesive tight-knit community it once was.
I know this is a bit more "big picture" than the normal technical discussion. I just wanted to add that from the big picture Flash isn't what it once was and new languages and new pieces of software won't fix the problem. Designers are prepared to learn the new languages and work with Flex guys but don't make them give up all their current knowledge to do it. Plus, the fact that this blog post has highlighted the 'division' that now exists in the Flash world, I hope it can be resolved for both sides. Right now the 'designery' changes in CS4 still don't do enough to help the designer quickly build those small banners that shouldn't require a developer to code.
cheers to all
storm
While learning AS3 I would have been highly susceptible for an article like this. But today I find it just pointless.
Sure, leaving the comfort zone and learning something new can be a bit of a pain. But once you're past that you'll agree that AS3 is a lot better and not harder.
Cheers, Dan
I'm getting too old and do not get paid enough to re-learn Flash every 2 years. Plain and simple. In this economy budgets are already next to none. Now we need to hire 2 people to do what one could have easily achieved? That stinks for the bottom line, (my clients paying me for my time). Sure, its easy to say, "go read the book", but I'm already pressed for time, and money as it is. Adobe expects me to work twice as hard, (for half the pay, these days) and then find the time and money to purchase another $500 "upgrade" every year? Thats simply unrealistic in an era where more and more jobs are lost, deadlines are tighter and compatibility is seemingly next to none between the two AS's. I will do the tutorials, but I will likely never employ AS3 as I find no real use for it in the line of work we use Flash for, (simple banner ad's and small presentations).
My advice to Adobe, spend more time making the two play nice, (similar to what say, DreamWeaver does for code versus design users) and do not abandon your core users in an attempt to satisfy die hard coders. My firm neither has the time nor budget to hire them and will sooner abandon Flash all together.