Home > Development > features
ActionScript 3.0: Is It Hard or Not?
In parts of the Flash community, ActionScript 3.0 seems to have gained a reputation for being "hard"—particularly among those who have not yet tried the new language. Is the reputation warranted? Not in my opinion.
When ActionScript 3.0 was first released, the sheer number of new features it offered was a little intimidating. On first impression, many developers were understandably concerned that the language was going to be hard to use. A year and a half later, that initial concern seems to have developed into a widespread misunderstanding, perhaps even prejudice, that ActionScript 3.0 is harder than ActionScript 2.0 or ActionScript 1.0.
The most common laments I hear about ActionScript 3.0 are, "It’s too complicated," "It’s harder to learn/understand," and "It takes a lot more code to do things." Yet, rarely have I seen these complaints backed up by more than one or two examples. So let’s do some thorough investigation to see if ActionScript 3.0 really is as hard as people seem to think it is.
It’s Too Complicated!
I think the intuitive feeling that ActionScript 3.0 is complicated stems from the sheer number of features in the language, many of which are new. ActionScript 3.0 is certainly "bigger" than ActionScript 2.0 or ActionScript 1.0. But as developers, do we actually need to learn every detail of every feature in ActionScript 3.0? Of course not. Instead we simply learn what’s needed to get the job done. Sure, if you’re creating a sophisticated desktop application for Adobe AIR, you’re going to need a good knowledge of object-oriented programming and AIR’s application framework. But if you just want to control an animation’s timeline in the Flash authoring tool, you don’t need to know anything about the AIR framework, nor even object-oriented programming. You just need a little knowledge of timeline control functions, such as play() and stop().
There seems to be a common misconception that ActionScript 1.0 means "programming on the timeline" while ActionScript 2.0 and ActionScript 3.0 mean "object-oriented programming in externalized class files." That distinction is completely false. All versions of ActionScript have supported both timeline-scripting and object-oriented programming, and will continue to do so.
For example, suppose you’re working in the Flash authoring tool, and you want to move the playhead of the current timeline to frame 5. In ActionScript 1.0, you would add the following code to a frame script:
gotoAndStop(5);
In ActionScript 2.0, the code looks like this:
gotoAndStop(5);
In ActionScript 3.0, the code looks like this:
gotoAndStop(5);
That’s right: timeline control code in ActionScript 3.0 is the same as it was in ActionScript 2.0 and ActionScript 1.0. And there’s no reason for that to change. When you issue the command gotoAndStop(5), you’re writing valid, uncomplicated ActionScript 3.0 code.
I regularly hear people claim, incorrectly, that to use ActionScript 3.0, you have to know object-oriented programming, or every variable’s datatype must be declared, or everything has to be in packages and classes. In practice, none of those assertions are true. ActionScript 3.0 code can be placed on timelines, exactly as it was in ActionScript 2.0 and ActionScript 1.0. The code doesn’t have to reside in classes. Variable datatypes don’t have to be declared, even in the strict compilation mode. The language is designed to provide as much or as little structure and flexibility as the task at hand requires. If you prefer to program procedurally with functions and variables declared in frame scripts, you can continue to do so in ActionScript 3.0.
It’s Hard to Learn!
Surprisingly, I have actually heard university-level instructors say that they’ll be teaching ActionScript 1.0 and ActionScript 2.0 instead of ActionScript 3.0 because ActionScript 3.0 is too hard for students to learn. Once again, I think this misconception is based on the false notion that ActionScript 1.0 means programming on the timeline, while ActionScript 3.0 means Java-style object-oriented programming. ActionScript 3.0 certainly can create complex object-oriented programs. But you can also use it for all of the simpler scripts that people have been producing since Flash 4.
To determine whether ActionScript 3.0 is harder to learn than ActionScript 1.0, let’s look at a series of comparative examples showing typical code that a new programmer might have to learn. In each example, we’ll look first at the ActionScript 1.0 version, and then the ActionScript 3.0 version.
Here’s a short ActionScript 1 .0 script that waits for a .swf file to fully load before playing:
// Code on Frame 4
if (_framesloaded == _totalframes) {
gotoAndPlay(6)
}
// Code on Frame 5
gotoAndPlay(4);
And here’s the same script in ActionScript 3.0:
// Code on Frame 4
if (framesLoaded == totalFrames) {
gotoAndPlay(6);
}
// Code on Frame 5
gotoAndPlay(4);
With the exception of the missing underscores and capitalization in the variables "framesLoaded" and "totalFrames", the ActionScript 3.0 code is identical to the ActionScript 1.0 code, and certainly no harder to learn.
Next, let’s look at a very simple programmatic motion example. The following ActionScript 1.0 code animates a movie clip horizontally. It assumes that a movie clip instance named "ball" is placed manually on frame 1 in the Flash authoring tool.
// Code on frame 1
setInterval(moveBall, 20);
function moveBall () {
ball._x += 10;
}
Here’s the same script in ActionScript 3.0:
// Code on frame 1
setInterval(moveBall, 20);
function moveBall () {
ball.x += 10;
}
Again, the only difference between the preceding ActionScript 1.0 code and the ActionScript 3.0 version is the removal of the leading underscore in the variable name "_x". In ActionScript 3.0, named movie clip instances placed manually on stage can still be referenced by their instance names. Likewise, ActionScript 3.0 still supports the setInterval() function. However, the Timer class is now preferred over setInterval() because it provides better tools for starting and stopping the repeated execution of a function.
Now let’s look at a slightly more complex programmatic motion example, first in ActionScript 1.0. The code rotates a movie clip around a circle. As before, the code assumes that a movie clip instance named "ball" is placed manually on frame 1 in the Flash authoring tool.
var rpm = 30;
var radius = 150;
var centerX = 230;
var centerY = 200;
var theta = 0;
var degreesPerSecond = rpm * 360 / 60;
var now = getTimer();
var intervalID = setInterval(moveClipAroundCircle, 20, ball);
function moveClipAroundCircle (theClip) {
var then = now;
now = getTimer();
var elapsed = now - then;
var numSeconds = elapsed / 1000;
var degreeIncrement = degreesPerSecond * numSeconds;
theta += degreeIncrement;
theta %= 360;
var radians = degreesToRadians(theta);
theClip._x = centerX + Math.cos(radians) * radius;
theClip._y = centerY - Math.sin(radians) * radius;
}
function degreesToRadians(degrees) {
return (degrees/180) * Math.PI;
}
Here’s the same script in ActionScript 3.0:
// Code on frame 1
var rpm = 30;
var radius = 150;
var centerX = 230;
var centerY = 200;
var theta = 0;
var degreesPerSecond = rpm * 360 / 60;
var now = getTimer();
var intervalID = setInterval(moveClipAroundCircle, 20, ball);
function moveClipAroundCircle (theClip) {
var then = now;
now = getTimer();
var elapsed = now - then;
var numSeconds = elapsed / 1000;
var degreeIncrement = degreesPerSecond * numSeconds;
theta += degreeIncrement;
theta %= 360;
var radians = degreesToRadians(theta);
theClip.x = centerX + Math.cos(radians) * radius;
theClip.y = centerY - Math.sin(radians) * radius;
}
function degreesToRadians(degrees) {
return (degrees/180) * Math.PI;
}
Once again, except for the removal of the leading underscore in variable names, the ActionScript 3.0 code is identical to the ActionScript 1.0 code, and, therefore, no harder to learn. I’m not making this stuff up.
Moving on to another example, suppose you want to programmatically create an instance of a movie clip symbol at runtime. Here’s the ActionScript 1.0 approach:
- Right-click the movie clip symbol in the Library, and select Linkage.
- Check "Export for ActionScript"
- For Identifier, specify a name, such as "BallSymbol", then click OK.
- On the timeline, add the following code:
someParentClip.attachMovie("BallSymbol", "ball1", 0);
Here’s the ActionScript 3.0 approach:
- Right-click the symbol in the library, and select Linkage.
- Check "Export for ActionScript"
- For Class, specify a name, such as "BallClass", then click OK.
- On the ActionScript Class Warning dialog, click OK.
- On the timeline, add the following code:
someParentClip.addChild(new Ball());
The only substantial difference between the ActionScript 1.0 and ActionScript 3.0 approaches is the code used to programmatically create the movie clip instance and add it to the stage:
// ActionScript 1.0 code:
someParentClip.attachMovie("BallSymbol", "ball1", 0);
// ActionScript 3.0 code:
someParentClip.addChild(new Ball());
For new programmers learning how to "make a new instance of a symbol," I think the ActionScript 3.0 phrasing, "new Ball" is more intuitive than the ActionScript 1.0 phrasing, "attachMovie(‘BallSymbol’...)." The syntax "new Ball" expresses the concept of "making a new thing" more directly. The ActionScript 3.0 phrasing "addChild()" also nicely reinforces the concept of the display hierarchy where a "parent" movie clip contains "child" movie clips. Beyond phrasing, the ActionScript 3.0 approach offers another benefit: its class-based terminology helps new developers seamlessly transition to more complex object-oriented programming if they so choose. In ActionScript 3.0, the knowledge used to write "new Ball()" is directly applicable to all other kinds of objects, displayable or not. Once the developer has learned to say "new Ball()", then "new TextField()", "new Date()", "new MovieClip()", and "new ColorPicker()" are right around the corner. ActionScript 3.0’s consistent "new-based" display-object instantiation is less complicated than the previous collection of instantiation techniques, which included attachMovie() for Library movie clip symbols, createEmptyMovieClip() for generic movie clips, createTextField() for a new empty text field, and "new SomeClassName()" for non-visual objects. ActionScript 2.0 and ActionScript 1.0’s object-instantiation techniques were difficult for beginners to remember, and helped give Flash its reputation as a "quirky" development environment.
In general, I also find ActionScript 3.0’s new display system easier to learn than its predecessor because it has fewer limitations. In the past, new programmers learning Flash’s display system would inevitably encounter confusing limitations whose workarounds were undocumented, and existed only as Flash community lore. For example, ActionScript 2.0 provided no direct way to insert a new graphic between two existing graphics. Instead, programmers were expected to write custom depth management code that used swapDepths() to rearrange existing graphics on the display list. Likewise, ActionScript 2.0 provided no direct way to attach one .swf’s symbols to another .swf’s display list. Instead, programmers would typically place a "child" .swf inside the desired "parent" .swf and attach child symbols only within the child.
The workarounds for ActionScript 2.0 and ActionScript 1.0’s limitations have become familiar territory to Flash developers, but have been serious learning impediments for new ActionScript programmers. By contrast, in ActionScript 3.0, the display system pretty much just works, so new programmers spend less time researching awkward workarounds, and more time learning worthwhile programming techniques. In ActionScript 3.0, you can use addChildAt() to insert a graphic between existing graphics. You can also take a whole container of graphics offscreen and put it back onscreen somewhere else. And you can easily add instances of symbols from one .swf to another .swf’s display list. These things not only save time and reduce the amount of workaround code in every ActionScript program, they make good sense, which makes them easier to learn.
Let’s look at one final example comparing the learning difficulty of ActionScript 1.0 with that of ActionScript 3.0: submitting simple login data to a server. The ActionScript 1.0 code follows; note that it uses LoadVars, not loadVariables(), to send and load the data. The code assumes that there are two text fields on stage: usernameField (the login name) and responseField (the server’s response).
// Code on frame 1
var dataSender = new LoadVars();
var dataReceiver = new LoadVars();
dataReceiver.onLoad = function () {
responseField.text = this.serverResponse;
}
function submitForm () {
dataSender.username = usernameField.text;
dataSender.sendAndLoad("http://www.example.com/cgi-bin/login.pl",
dataReceiver,
"GET");
}
// Code on submit button
on (release) {
submitForm();
}
Here is the ActionScript 3.0 version.
// Code on frame 1
var variables = new URLVariables();
var request = new URLRequest();
request.url = "http://www.example.com/cgi-bin/login.pl";
request.data = variables;
var loader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.VARIABLES;
loader.addEventListener(Event.COMPLETE, completeListener);
submitButton.addEventListener(MouseEvent.CLICK, clickListener);
function completeListener (e:Event) {
responseField.text = loader.data.serverResponse;
}
function clickListener (e:MouseEvent) {
variables.username = inputField.text;
loader.load(request);
}
Frankly, I think that both the preceding examples would be hard for beginner programmers to follow. In both cases, to understand the code, the programmer must have a decent prior understanding of creating objects from classes, assigning values to variables, and registering for events. However, the ActionScript 3.0 version of the code offers several long-term benefits:
- In ActionScript 3.0, once you’ve learned to use URLLoader, you can load any kind of data, including binary, text, variables, and XML. In ActionScript 2.0 and older, by contrast, a separate class was required for loading XML (see XML.load()), and a competing mechanism existed for loading variables (loadVariables()). In ActionScript 3.0, the knowledge of URLLoader is portable to all types of data.
- In ActionScript 3.0, once you’ve learned to use URLLoader, you can directly apply your knowledge to the companion Loader class, which loads graphical assets such as .jpg files and .swf files. In ActionScript 2.0 and older, competing systems were used to load graphical assets (like loadMovie(), loadMovieNum(), MovieClipLoader). Furthermore, the ActionScript 2.0 APIs used to load graphics were unlike those used to load textual data. The lack of uniformity in ActionScript 2.0 and ActionScript 1.0 would lead new ActionScript developers to doubt their own code. I have often heard programmers ask, "Should I really use loadMovie() to load a .jpg file?" or "I want to load a raw text file, should I really use loadVariables()? That sounds like it’s designed for variables." or "When should I use LoadVars instead of loadVariables()?" By contrast, the ActionScript 3.0 loading APIs are simple and consistent: Loader is for loading graphical assets and URLLoader is for loading binary or textual data. Both Loader and URLLoader use a load() method for loading, and both emit the same load-status events (in the case of Loader, through a LoaderInfo instance). This uniformity makes the loading system in general easier to learn than it was in previous versions of ActionScript.
- In ActionScript 3.0, knowledge of addEventListener() and the built-in event architecture applies to everything in the language, from components, to network operations, to input events. Once you have learned to handle an event from one object, you have the knowledge required to handle any event from any object. In ActionScript 2.0 and older, the developer was required to learn up to four different ways to handle events, including event properties, event listeners, on() events, and onClipEvent() events.
- While we’re talking about events relative to the learning process, I think it’s important to compare Flash’s older on()/onClipEvent() system with the newer addEventListener() system. The former system provides a convenient way to attach a behavior to a visual object in the Flash authoring environment. The latter system provides a way to keep code centralized and manageable. Conceptually, the on()/onClipEvent() system was a useful development metaphor, but it never gained the full tool support it required to succeed. Too often, source code placed on visual objects became repetitive and unmanageable, leading to time-consuming bugs and difficult multi-developer workflow.
- Accordingly, the on()/onClipEvent() system has been removed from Flash CS3. I hope that in the future, Adobe will enhance the visual-development toolset enough to allow for a revival of the on()/onClipEvent() ethic. For example, perhaps code placed on a visual object should also be editable in an auto-generated class from a centralized location. Backed by the proper tool support, attaching event listeners to visual objects could be a healthy part of a productive workflow. Adobe’s new tool, Thermo seems to be moving in that direction.
It Takes A Lot More Code To Do Things!
One final ActionScript 3.0 misconception I have heard repeated online and in conversations is: "ActionScript 3.0 might be cool and all, but I just wish it weren’t so wordy! It takes so much code to do things that used to be easy!" Here are the only two examples I regularly see put forward as evidence of ActionScript’s verbosity:
1) To access a URL in ActionScript 1.0 and ActionScript 2.0, you use this code:
getURL("http://www.moock.org");
In ActionScript 3.0, you use this code:
navigateToURL(new URLRequest("http://www.moock.org"));
2) To load a .swf file into a movie clip in ActionScript 1.0 and ActionScript 2.0, you could use this code:
someClip.loadMovie("foo.swf");
In ActionScript 3.0, you use this code:
var loader:Loader = new Loader();
loader.load(new URLRequest("foo.swf"));
someClip.addChild(loader);
In the preceding two examples, the ActionScript 3.0 code is longer than the older code. But those two isolated examples don’t represent the general trend. In my own programming, I find that ActionScript 3.0 is not, on the whole, a more verbose language than ActionScript 2.0 or ActionScript 1.0. For example, in ActionScript 3.0, the code required to make a text field, a button, or a movie clip is about the same length as it was in ActionScript 2.0 and ActionScript 1.0. Here’s one example that gives the general flavor of the difference between ActionScript 3.0 code and older code:
// ActionScript 1.0 and ActionScript 2.0
someClip.createTextField("t", 1, 0, 0, 0, 0);
t.border = true;
t.text = "hello world";
// ActionScript 3.0
var t:TextField = new TextField();
t.border = true;
t.text = "hello world";
someClip.addChild(t);
Admittedly, there are 16 more keystrokes in the ActionScript 3.0 code. But I find that the new ActionScript 3.0 structures more than make up for those little differences. For example, if you want to move a text field to another movie clip in ActionScript 3.0, you do this:
someOtherClip.addChild(t);
In ActionScript 1.0/2.0, you can’t move the text field directly, so you have to write a function that makes a new text field in the destination movie clip, and then copies the original text field’s characteristics to the new text field. That’s a lot of extra code (and complexity) that you don’t have to write in ActionScript 3.0.
Likewise, things like regular expressions and events are a native part of ActionScript 3.0, but in ActionScript 1.0 and ActionScript 2.0, you have to write your own implementations or research third party implementations, at the expense of extra time and extra code.
Furthermore, there are numerous cases where ActionScript 3.0 is actually much less verbose than its predecessors. Consider E4X, the ActionScript 3.0 system for working with XML. Suppose you want to retrieve information from an XML document such as this:
<STAFF>
<EMPLOYEE>
<NAME>Marco</NAME>
<MANAGER>James</MANAGER>
</EMPLOYEE>
<EMPLOYEE>
<NAME>Graham</NAME>
<MANAGER>James</MANAGER>
<EMPLOYEE>
<EMPLOYEE>
<NAME>James</NAME>
<MANAGER>Dorian</MANAGER>
</EMPLOYEE>
</STAFF>
If you want to retrieve the second employee’s name in ActionScript 2.0 or ActionScript 1.0, you do this:
staff.firstChild.childNodes[1].firstChild.firstChild
In ActionScript 3.0 you do this:
staff.EMPLOYEE[1].NAME
var managedByJames = new Array();
for (var i = 0; i < staff.firstChild.childNodes.length; i++) {
if (staff.firstChild.childNodes[i].childNodes[1].firstChild.nodeValue
== "James Porter") {
managedByJames.push(staff.firstChild.childNodes[i]);
}
}
In ActionScript 3.0 you do this:
staff.*.(MANAGER == "James Porter")
The ActionScript 3.0 code is much shorter, and much more intuitive.
In isolated side-by-side code-length comparisons, ActionScript 3.0 sometimes wins, and sometimes loses. But in my own code I find that ActionScript 3.0’s cleaner structures produce generally shorter programs because my system logic can be expressed more succinctly, and with fewer workarounds.
I Want to Believe
By now I hope you’re getting my point: As a developer who’s been using Flash since it was known as FutureSplash, I simply can’t find any good reason to avoid ActionScript 3.0. I can still use it on the timeline for simple scripts, I still find the basics pretty easy to learn, and I don’t find it demonstrably more verbose than ActionScript 2.0 or ActionScript 1.0.
On the contrary, once I started learning ActionScript 3.0, I found programs faster to create and easier to maintain because of the cleanliness of the API and the coding assistance available in Flex Builder. Other things I appreciate in the new language (not already mentioned in this article) include:
- Much faster speed than ActionScript 2.0
- Binary sockets and binary data access
- Improved text metrics
- Programmatic access to sound spectrums
- Good integration with assets authored in Flash CS3 (see http://moock.org/lectures/ActionScriptAndFlashCS3/)
- Free compiler and development framework
- And here are 50 more: Reasons ActionScript 3.0 Kicks Ass, enumerated by Grant Skinner.
My advice? If you haven’t tried ActionScript 3.0 yet because you worry that it’s too complicated, don’t believe the hype. Do yourself a favor and try ActionScript 3.0 sincerely for a month of daily work. Then decide for yourself whether you like it. I highly doubt you’ll be disappointed.
Comments
54 Comments
Leave a comment
Stay Connected
InsideRIA Atom Feed- InsideRIA Development Atom Feed
InsideRIA Newsletter
With Colin as teacher, AS3 is very NOT so hard.
--
A Colin's reader since AS1
I appreciate this article, and while I agree with many points I can't help point out my disagreement on few things.
I do think AS3 tends to produce more code for simple to moderately advanced projects. On balance, I think the formality can help you... but I still think you'll have more code for small cases. Some of your examples are cherry-picked to support your case. Sure, E4X is just the opposite (it'll be less code).
But... say you have students who are familiar with AS1 and your goal is to teach "programming"... not so much ActionScript. I don't see the point in covering AS3.
Your examples of code in the timeline definitely proves your points--but if you're going to code like that (not typing your variables for example) why bother with AS3? You're not going to get any speed improvement, right?
Finally, the biggest concern I have as I embark on projects and have to choose between AS2 and AS3 the reason why I still don't feel 100% confident in my time estimates with AS3 is simply the runtime error exception handling. I suppose it's partially a non-issue as such errors fail silently in the regular Flash player--but the debug player displays such runtime errors. I'd like to think I could make a project that NEVER has those pop up--but from the looks of many (not all) AS3 and Flex developers it isn't so easy to catch all those errors. While this is not a great reason to avoid AS3 (and it's not what I'm saying), I do think runtime error exceptions make it a much more difficult decision than simply "it's the new version, might as well use it".
For me, I'll stick to AS2 in the cases where the project is not super complex and when there's no specific benefit in AS3 that justifies the "investment". In a larger project or one where I need some new feature of AS3/FP9, then sure I'll go for it. I do think if you're learning right now, AS3 is the best choice--if for no other reason than the fact they've gotten rid of the funk (say, the countless event models and attachMovie).
If you want to go further in discovering AS3, there are a few nice and free screencast tutorials posted by Lee Brimelow on gotoAndLearn().
Hi Colin,
I totally love AS3 and I can't think of any reason for me to do AS2 again. I'm always suggesting an AS3 rewrite to all my clients that have an AS2 code base. This always pays off in terms of easier maintenance, better structured code and the lack of messy FLA files.
While I agree with your article in general, I don't agree with your conclusion. To any programmer, AS3 will be awesome over AS2. If they take the one or two days required to readjust, they'll never go back to AS2. The problem is really not this group of users, but rather the designers and lightweight developers ("deviners"?). To them AS3 really IS harder. I'll give you a couple examples:
1. AS2 was intuitive since they could easily grasp the concept of "onPress", "onRelease" and so on.
is really not intuitive at all. In addition, the AS3 Events don't match the old ones and building good button behavior in AS3 requires a bunch of code. I use a couple button-behavior classes that are easily reusable, but hard to grasp for non-coders (60+ lines of code in a class).
2. Timeline navigation is MUCH more difficult. I know designers that can do amazing things with Flash by just controlling MovieClips, but they have no chance understanding the display hierarchy in AS3. To tell the movie on the timeline above to play, they need timeline code like this:
If this casting fails for some reason, it could potentially halt the progress of the entire movie. This is a simple example. The designers I know use much more complicated timeline scripts to achieve the desired effects. They could of course try to get their head around the DisplayList and "Object.getChildByName" but that's an error prone approach. The DisplayList has some bugs where in some occasions, you'll only be able to see the objects beneath the layer your code resides in. I've not been able to reproduce this, I just now that it hits at random. Designers really can't use that...
3. The error messages thrown by the Flash IDE suck. I think it's less than 5 of them that actually could help someone learning AS3 where to look for errors, what could be missing and so on. There's next to no "intelligence" involved, just dumb messages that tell you little or nothing.
That said, I do find it much easier to teach AS3 to beginners than it was teach AS2 to beginners. The problem here is really explaining AS3 to designers and "deviners" that already know AS2. AS3 is really not easier for them at all.
J
"Surprisingly, I have actually heard university-level instructors say that they’ll be teaching ActionScript 1.0 and ActionScript 2.0 instead of ActionScript 3.0 because ActionScript 3.0 is too hard for students to learn."
And what about Pascal or C in a first year of University without any previous programming experience? I think that AS3 is far less complicated and is more exciting to start...and as you said and I tottaly agree you dont need to know everything. You should go step by step and try to search the web, get some good books and try to find some good practices.
Only an opinion.
Paulo Moreira
http://interactividades.blogspot.com
I am currently working on my first AS3 project and I find myself using a lot of time figuring out how to do relatively simple stuff. The display list, events and the way code and movieClips communicate and interact in CS3 IDE are among the things that are causing me most problems. My old AS2 ways are seldom working and I have to figure out new ways to do things. This takes time, especially since I think the documentation could have been a lot better when it comes to explaining how to migrate outdated AS2 functionality to AS3.
My general impression so far is that as long as I work more or less entirely in AS3 the process is fairly smooth. If I, however, try to combine AS3 with movieClips in the Flash IDE like I used to do in AS2 I seem to run into trouble on every corner...
Hi Colin ....
After Reading your book , i find AS 3.0 much easier and pwerful and thanks for such great article .
Thanks for the great introduction into OOP Colin. Like many others, I have learned all around Flash authoring--actionscript, interaction, best practices, etc...from your previous work (books, website, etc...). (Phillips book--ActionScripting in Flash MX was good too).
Colin Moock's books are very thorough. A great teacher, he guides you from the beginning, and prepares you well for advanced topics.
Colin's "encouragement" inspired me to write an AS3 FPlayer 9 application that utilizes the new lightweight components. It has a Flash GUI, a PHP backend, and MySQL storage for handling data input and retrieval. It came out pretty nice (even if I say so myself). The new components are simply nice, handle thousands of records with ease, and are easily skinnable. And to top it off, I still used a lot of what I learned in previous versions of Flash--since 5--I didn't have to create the whole App by creating my own classes either. When you work in the authoring environment (i.e. drag and drop MovieClips etc.) the Flash compiler automatically creates the classes for you. The new AS3 OOP Class structure offers much more control for programmers/developers/"Software Engineers" (as some prefer to be called). However, learning the built-in classes does take some serious time for us "un-classy" people. Just open up the documentation and you see 40 million Classes/Packages in multiple frames. Ok, a slight exaggeration--but there are a lot. I imagine that, for beginners of actionscript programming, there will be some intimidated by the sheer number of classes and the steep learning curve. I am encouraged by people who aren't afraid to "make it simple" so that others like myself can learn the basics first, then apply them in more advanced situations. Having been a teacher myself, I appreciate the efforts of anyone who strives to do this.
As Colin says, the new display API, URLLoader, XML, and Event handling was not all that bad, although I had his help and the documentation to assist.
I do have one complaint though, why doesn't Adobe give us the Tree component...come on...the Tree...they took away my Tree man...other than that, the new components are Flexy.
Oh yeah, one other complaint, Flex Builder 3 goes from 250 Meg to 400 Meg when I do multiple compile/degug sessions--might as well get a workhorse computer with 4 Gigs of RAM.
Procedural or Classes....that is the question.
hey phillip,
responses below:
PK: I do think AS3 tends to produce more code for simple to moderately advanced projects. Some of your examples are cherry-picked to support your case. Sure, E4X is just the opposite (it'll be less code).
--
i tried to select a cross-section of typical examples in the article. i'm just interested in the facts; i don't really have a "case" to make, other than dispelling misconceptions about ActionScript 3.0. if you have a list of examples showing ActionScript 3.0's verbosity, please post them here.
PK: But... say you have students who are familiar with AS1 and your goal is to teach "programming"... not so much ActionScript. I don't see the point in covering AS3.
--
two responses:
1) most core ActionScript 1.0 code is valid in ActionScript 3.0. if you're teaching fundamentals like variables, functions, loops, and conditionals, the code will be the same in both versions of the language. what exact content are you referring to when you say "I don't see the point in covering AS3"?
2) i think ActionScript 3.0 is a much better language than ActionScript 1.0 for teaching general purpose programming because it's cleaner and uses idioms that are more easily transferable to other languages.
PK: Your examples of code in the timeline definitely proves your points--but if you're going to code like that (not typing your variables for example) why bother with AS3? You're not going to get any speed improvement, right?
--
ActionScript 3.0 is a scaling language. it is as simple or as complex as you need it to be. if you're just using timeline control functions, the version is actually moot. ActionScript 3.0 includes the simple timeline control that was introduced back in Flash 4 and formalized in ActionScript 1.0 (Flash 5). "gotoAndStop(5)" is valid code in all versions of the language.
PK: Finally, the biggest concern I have as I embark on projects and have to choose between AS2 and AS3 the reason why I still don't feel 100% confident in my time estimates with AS3 is simply the runtime error exception handling. I suppose it's partially a non-issue as such errors fail silently in the regular Flash player--but the debug player displays such runtime errors.
--
don't be afraid of runtime errors. learn to love them. they dutifully lead you directly to the line of code in your program where a problem has occurred. runtime errors help you fix your code, which should save you time, not cost you time. the old silent failure system in flash player 8 and older cost much more time because it required you to hunt down your own bugs (even simple ones like method name typos).
jensa:
in response to this article, I have had many private and public discussions about upgrading ActionScript 2.0 skills to ActionScript 3.0. you have identified the two most common, and most serious issues:
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
i failed to mention issue #2 in my article, but it is extremely important. i think both issues need to be solved by adobe at the tool level. specifically:
1) the on()/onClipEvent() style should be revived with new and improved tool support.
2) parent.gotoAndPlay() should be made legal with automated tool behaviour. for example, flash could add the following compile-time assistance:
-if a symbol's timeline code uses methods of the MovieClip class on a parent, and all author-time instances of that symbol have a MovieClip parent, then auto-cast to MovieClip
-if a symbol's timeline code uses methods of the MovieClip class on a parent, and any author-time instance of that symbol has a Button parent, then generate a compiler error
-if the programmer casts manually, honour that cast
i think that the major authoring-tool impediments to using ActionScript 3.0 are fixable. hopefully Adobe agrees and will do something about the above issues. ActionScript 3.0 itself isn't fundamentally "harder" than ActionScript 2.0, the IDE just needs some important tweaks to make ActionScript 3.0 more approachable to Flash authoring-tool users.
as for better error messages, i have to agree. many Flash and Flex compiler errors are arcane, and could be made much more friendly. i love clear, helpful error messages, and i hope Adobe improves their messages over time.
thanks for raising the casting issue!
colin
hi wodger,
you wrote:
"If I, however, try to combine AS3 with movieClips in the Flash IDE like I used to do in AS2 I seem to run into trouble on every corner..."
please feel free to post specific examples here so we can all evaluate the issues you are facing. undoubtedly, you are not alone, and we might all be able to provide some guidance for others facing similar circumstances.
thanks!
colin
For those of you who is till thinking about jumping on the bandwagon of AS 3 - I recommend to wait until Actionscript 5 is released.
I think AS3 is harder (much harder) than AS1 if you do it right. And of course much much better. But, if you don't do it right (treat it like AS1) then I really don't see the point. It becomes extra typing for no bug reduction, extra structure without gaining scalability, and extra errors with no improvement in code.
As for teaching though, I would go AS3 (done right) regardless. The hard part of programming is never the loops or variables, it is the organization and breaking down of your intentions in a structured clear way. This is where oop, events, the display list, etc really pressure you to do it right. Even for eventual non-programmers, the ability cleanly deal with complexity is a very valuable skill...
5 cents.
I have to agree with Colin. Although I was somewhat frustrated and maybe intimidates by the fact that some stuff (mostly event(types)s and displaylist stuff) was very much different, it is something you simply do memorize when coding AS3 for a while.
You can't expect everything to remain the same but call for improvement at the same time. And apart from that, you don't _need_ to use all the (I admit, somewhat abstract) OOP features if you don't want to. Just stick to the timeline at first if that's you comfortzone. Hey, you can even stick to AS2, I just wouldn't try to mix it to much.
And if to some extend you (rightfully ;) ) _do_ see it as an improvement, why complain about some (really: some) extra typing now and then.
Anyways, the advantages (maybe off a bit here and there since I'm not at full steam yet) I see at the moment:
* the displayList stucture (eg. no more awkward getNextHighestDepth() etc)
* easily created objects like TextField, Sprite etc.)
* closed methods (no need for Delegate anymore)
* speed
Not to mention the new features like:
* Timer
* Easier Text(Field) control
* Less messy coding (I hate each time I have to use the MovieExplorer to find someone's code)
* framelabel access
* easier drawing of shapes
And yes, the helpfiles seem somewhat exploded in fragments at first glance, but that to is just different, not that much more complicated
...
Which is probably more or less my point: different is not more compicated.
Much as I admire Colin's work, and bearing in mind how useful and authoritative I find his books, I'm afraid on this occasion I disagree with this article.
My issue with ActionScript 3 is that it lacks a middle ground. Because of this it has forced a division between designers and programmers that did not exist previously. Basic timeline control is, as Colin suggest, pretty much the same as before. However, Incorporating relatively basic interaction (even something as simple as matching AS 2's behaviours) demands a understanding of programming that was not previously required.
As someone who has grown up with programming, I can see the advantages that AS3 offers, but it needs a programmer mentality - the conceptual ability of abstracting and decomposing a task that others have described here. I love ent propagation and the display list is great when you use it. Day to day, I work mainly with artists and designers. They don't want to create complex applications but they do want to deploy basic interactions and visual transformations, and they often want to incorporate sound. A lot of Flash development falls into this category of wanting to use relatively simple programming to create emotionally or visualy sophisticated results.
Frankly, AS3 has made the step up to this level of interactive creativity harder. It demands abstract conceptual thinking rather that does not always fit easily with affective visual thinking, and I find that people with a visual arts or graphic design background are deterred by this because Flash no longer feels like a visual tool. Of course, if the step if taken the rewards are greater; but the apparent difficulty of getting there is deterring artists and designers from trying. Colin is right that AS3 is a great language for beginner programmers; it's just not so great for experienced designers. Wierdly, when these two disciplines should ideally be getting closer, AS3 is currently driving them apart.
I don't think AS3 is harder to learn than AS2 when you know nothing about it.
AS3 is a big change from AS2 and people usually complain at first when there is change. But let me tell you this, I am now working on two projects, one in AS3 and one in AS2 and I can't wait to be just coding in AS3. What you can do is so much more. The speed gain gives you a bigger margin for a lot of stuff.
I do agree that making a simple button is now harder than before, but it's really worth it.
Coming from someone who is lucky to be an abstract thinker as well as a logical thinker, I don't see a problem with AS3, but I am guilty of coding in a more familiar language. AS3 is clearly more robust, flexible and faster but it is also more complex and different enough from AS2 that I still don't feel comfortable coding strictly in AS3. Perhaps I'm just reluctant to accept the fact that every new version of Flash comes with steeper learning curves when it comes to building logic into an app, presentation or game. Having said that, I am eager to learn about and take advantage of the features introduced in AS3. By the way, thank you for writing an excellent book.
I agree with Phillip, I too am not 100% confident of estimating the time needed to create a full-blown AS3 application/ microsite. The fact is that I'm still getting my feet wet on AS3, hence I code slower than I do in AS2. Transition to AS3 in my workplace is also not as fast, given the short datelines... I'm still looking for a project that will allow me enough time to transit to it. Mean while, I'll continue my read on the excellent EAS3.
Great topic, and timely in my case.
I have been with flash sine version 3 and been doing flash development since actionscript 2.0.
I was also under the misconception that AS3 was "harder" to learn, etc. This caused a little procastination on my part in getting involved with AS3.
About 6 months ago, I had started regularly using AS3 on most new projects given to me.
There is absolutely one thing above all that stands out in AS3 compared to AS1/2: Debugging is Beautiful
Things don't fail silently, you get both compile time and run time errors, which can be cumbersome. but only to your benefit.
End result? More stable, solid applications. With the right editor (I use FlashDevelop), you actually can buld thing MUCH MUCH faster, solely based on the error reporting features in AS3.
Now, my only problem is -- I don't want to go back to AS2, AS3 is just too awesome.
I have just transferred all of my code from AS2 to AS3 since last Xmas, I can say that AS3 is easier than AS2 to learn, it just took me a few weeks to learn and transfer all codes plus great help from Colin's great AS3 book:)
I didn't have a good first experience with 3.0. I found it much more cumbersome. I can agree with some of your points about standardized ways to call files and such, but it does not seem very intuitive at all. I will need to take more of a "recipe" approach to writing it, at least for a while. That is, I won't be writing much from memory, but rather referring to a recipe for how to do certain things. Check out my blog post on the subject:
http://www.personal.psu.edu/pzb4/blogs/besong/2007/12/actionscript-30-first-impressi.html
hi ian,
you wrote:
"However, Incorporating relatively basic interaction (even something as simple as matching AS 2's behaviours) demands a understanding of programming that was not previously required."
it sounds like you're referring to the removal of on()/onClipEvent() here. i think we all agree that that's a step backward for ease of use, especially from a designer's perspective.
hopefully the on()/onClipEvent() issue can be fixed by adobe. can you identify any other specific areas that cause problems for creating simple interactive content?
colin
hi qbix,
you wrote:
"Perhaps I'm just reluctant to accept the fact that every new version of Flash comes with steeper learning curves when it comes to building logic into an app, presentation or game."
i agree, the transition from ActionScript 1.0 to 2.0 to 3.0 has required a lot of retraining. each version of Flash has also included new components, which adds to the upgrade workload. that said, I think that the language has finally stabilized, and we can expect to see more comfortable, incremental improvements from here on out. the ECMAScript 4 standard is a good indication: most of the changes from ActionScript 3.0 to ECMAScript 4 are pretty minor. generally speaking, the fundamentals of the language still look like ActionScript 3.0.
Thanks for the insight! I'm really interested in moving over to AS3, this article has re-sparked my interest in it. Your AS2 book really helped me get into code, and I've already got a copy of your AS3 book, so I don't know what I'm waiting for really... Hoping that any new projects I get involved in I can use AS3. I am sure there are more benefits than you have listed as well! Thanks again.
hi robin! nice to see you here.
some responses...
RD: I think AS3 is harder (much harder) than AS1 if you do it right. And of course much much better. But, if you don't do it right (treat it like AS1) then I really don't see the point.
--
Using ActionScript 1.0-style timeline scripting does not equate to "doing it wrong". As I mentioned earlier, "ActionScript 3.0 is a scaling language. it is as simple or as complex as you need it to be." Even if you only use a few lines of code in ActionScript 3.0, you still get lots of benefits over ActionScript 2.0, including speed, a clean display API, and much better error reporting.
The ECMAScript 4 working group has put a lot of effort into providing a simple set of language tools for use in simple situations. Their work in making the language flexible applies equally to ActionScript 3.0 and the future JavaScript 2.0. For example, not everyone uses JavaScript to build Google Maps. Often, all that is required is 10 simple lines of code in the header of a web page. Simple, ad hoc scripts are not "wrong". They are a healthy, intentional part of the language.
RD: It becomes extra typing for no bug reduction,
--
By "extra typing" do you mean "declaring datatypes" or "more keystrokes". If you mean "declaring datatypes" remember that ActionScript 3.0 does not require datatype declarations. If you mean "more keystrokes", in my examination I have not been able to substantiate that claim (counter-examples welcome).
RD: extra structure without gaining scalability
--
ActionScript 3.0 does not force extra structure on you. "Using ActionScript 3.0" does not mean "using object-oriented design patterns." You can use simple timeline scripts, with no formal object-oriented programming structure. Do you have specific examples of what you mean by "extra structure"?
RD: and extra errors with no improvement in code.
--
Those "extra errors" help developers fix problems and reduce bugs, which by definition means improved code. ActionScript 2.0, by contrast, failed silently, leading to lengthy, time-wasting bug hunts and broken code. There's one big exception here: the parent.gotoAndPlay() casting issue that's already been discussed (and which I believe needs fixing).
>I simply can’t find any good reason to avoid ActionScript 3.0
I found one: the absence of removeMovieclip() equivalent.
It is not enough to argue that the job is done with removing the mc from the display list + checklisting page 807 of your (btw excellent) book "Essential AS3".
This page 807 is really painful ;-).
This "problem" was pointed by Grant Skinner in his episode 2 of his series about memory management:
http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html
It's really a big issue when working with dynamic content, or for example when flash is used as a level editor and is not possible to predict what a mc (or a 3d part SWF file) will contain and when you precisely want to use flash as a flexible tool.
Ok, it's certainly possible to "fix" these problems with specific code managing "the possibility of being removed" (!!), but I don't know if someone finally found a simple way to do that.
Any info?
Colin, first I just want to say thank for your all your work and books. Admittedly I don't read near as much as I should, but your AS 2.0 book really helped me break into programming in AS. So thank you. Since reading your book I've become a freelance/contract AS software engineer and currently on contract as MSN. We are strictly an AS3 shop here and for a lot of reasons. When I got here the whole team was transitioning from 2 to 3. I'll be the first to admit it was intimidating. It's different. Once you get over that initial hump you realize it's a thing of beauty. Memorizing, or at least becoming accustomed to what library to import for what class was one of my frustrations and that passed in time. For each of us here, once we made the transition, none of us have any desire to look back. The event model, delegates, and having all the API conform to better OOP standards are reasons alone for me to support 3 over 2. It simply allows you to write OOP correct code easier. Sometimes more code is easier to read and maintain if you've designed and developed it well. Now sure, my perspective is from that of a Software Engineer and I write 1000s of lines of code, so I can't much speak for designers or animators. 1 line vs. more capable 3 is quite fine with me. I will say, that anyone who learns AS3 for any application is setting themselves up to have a much easier time making the transition to better written code and bigger projects not to mention become competent programmers if your learning or career take you there. So do I think it's harder than AS2? No. I find it easier to code in. Do I think it's harder to learn? Hesitant yes, but only once you really get into it because there's more to it and when you get real deep it starts to require you to have some OOP understanding. As Colin pointed out, a lot of the very basics are the same or just have minor differences. I think the biggest hang up for people is the intimidation of it. Get over that and just start to dig in and you'll be golden. Anyway, I've rambled enough and will shut up now :) Cheers to all.
Hi Colin,
I have not made the move to actionscript 3.0 yet, and I want to say from the start that your books have helped me, and thanks.
I found the examples in this article too simple to help me decide if I should move. I have been programming for 28 years now, and and have always sought out development environments for my off hours pursuits that allow me to get in and do something quickly with a minimum amount of set up and ensuing fuss - leave that for work. Actionscript has been fantastic in this respect, and I am happy to read that AS3 doesn't require having to type variables, but what about declaring classes?
Do we still have freedom to declare classes as in this example? :
function ball( color ){
this.color = color
}
ball.prototype.traceColor = function(){
trace( this.color );
}
var myBall = new Ball( "red" );
myBall.traceColor();
////******************************
And, can we still just as simply embed the above class declaration within a movieClip library instance, and associate with with the movieClip class? ( using the RegisterClass method? )
If this type of easy class creation is still available, I will jump to AS3. But if I will have to use AS 2/3 Class declaration protocols and syntax, or have to start putting everything external files, it's no longer going to be as quick and easy.
Sometimes you want have fun while to getting things done!
thanks,
Gordon
I'm new to AS3 (or any version of AS) and although I'm struggling quite a bit trying to grasp the different graphical aspects of flash, I'm liking AS3 very much.
I am still somewhat overwhelmed, but I suspect it'll get easier as the days go on. I am learning AS3 largely on my own and I've had one year of classroom experience with Java. The game design class at the college I'm enrolled in is offering this course where I work with art students and I incorporate their art into a simple game.
From a beginner's aspect, (only a week old here), AS3 may have a lot of content to digest, it is somewhat intuitive (from a Java point of view) and not all that difficult to learn or implement.
Well, it looks like I answered part of my own question, and that is no, you cannot sub class a movieClip directly inside of a library object - please correct me if I am wrong - you have to do it in an external .as file.
But this is a step toward what I consider making AS3 more difficult than its predecessors. We now have to abstract out the subclass into yet another artifice ( the separate .as file ) which is less compact and less convenient. (For this reason I never used AS2's external class file structure either.)
When we allow the class definition inside the library object, there is a concrete correspondence between object and behavior that is easy to relate to. It's like being able to create a robot that you can pop open, rewire, and then send on its way - it's something tangible. I don't really even have to know the (linkage) name of the robot to get this to work.
With AS3, I am now forced to keep a separate file to control my robot. This means now two separate entities to control - the as file and library object, and a link between them. And I'm not sure, but can I even view these at the same time in the IDE? (note that .as files are edited in a window that is separate from other scripts - also making the IDE even more complicated)
Certainly Adobe could have given us the option of creating classes in both ways, as AS2 did, without the kinds of underlying performance penalties Colin is referring to. After all, isn't that part of what a compiler is supposed to do? Make it easier on us mortals?
Again, the reason I started with AS is that, in my experience working with 68000 Assembly, Pascal, C, C++ and JAVA, Flash AS it was the most convenient environment since Hypercard for doing something exciting without having to manage linking, libraries, multiple files, and class paths, and a complex IDE. With Flash you could just start coding and go. Advanced features were there for those who needed to take advantage of them, but we weren't forced into it.
After futzing around with this for a couple of days now, I can't see how one can make the claim that AS3 is moving anywhere near the direction of "Easier to work with" in any sense of the word. Is AS3 harder? I'm not sure, but the IDE has certainly forced me to use features that I didn't want to use before.
Cheers!
ActionScript 1 and 2 was horrific for large scale projects especially if you are using the timeline. Sure it works great for all the one-off projects everyone is doing.
I don't see why anyone would teach 1 or 2. Just read Colin's book. I did and was off and running in a matter of a week.
ActionScript 3 allowed me to design and architect a very intelligent system that can scale and allowed me to graduate to working outside of the Flash IDE by using the Flex SDK to compile and document my project.
Remember, nothing worthwhile comes easy. Study and practice is my only advice. It definitely pay$ off.
Thanks for the book Colin.
hi gordon,
you asked:
"Do we still have freedom to declare classes [using prototypes]?"
--
yes, no problem. that agile style of coding is still supported. in fact, ECMAScript 4 currently has a proposal to include even more support for quickly declaring (structural) types:
type Point = { x: int, y: int };
new Point(3, 4);
as for registerClass(), its symbol-related functionality is gone. (for object-encoding, use the flash.utils.registerClassAlias() function.)
i think the new symbol linkage system is much easier to use than registerClass(): just enter the name of a class in the linkage dialog, and you're done. however, the removal of registerClass() means that you cannot dynamically reassign a symbol's class at runtime. i think that's too bad, and will advocate for dynamic reassignment at adobe.
externalizing the class might seem like a hassle, but it does make the code easier to manage, and reuse across multiple .fla files.
colin
hi again gordon:
you wrote:
"When we allow the class definition inside the library object, there is a concrete correspondence between object and behavior that is easy to relate to. It's like being able to create a robot that you can pop open, rewire, and then send on its way - it's something tangible. I don't really even have to know the (linkage) name of the robot to get this to work."
--
i agree, there's something nice to that style, but i don't think ActionScript 3.0 itself precludes similar functionality from being re-introduced in the future. i think this example is not a case of an ActionScript 3.0 limitation, but a Flash authoring tool limitation.
note that with the registerClass() approach, your robot metaphor breaks down when you want to apply the same class code to multiple symbols. the ActionScript 3.0 approach lets you reuse the same class with any number of symbols. that said, i think a good tool should offer the best of both worlds: click an "edit class" button in the library to edit a symbol's class. Flash still has lots of room to grow into a better visual development environment.
as for simultaneous symbol and class editing, you can un-dock the file windows and tile your ActionScript editor with the .fla editing window. (I personally use Flex Builder to edit code, so for me, the code is already open in a tiled window.)
colin
hi gludion,
you make a great point: in ActionScript 3.0, the programmer is responsible for deactivating display assets that are no longer in use. in ActionScript 2.0 and older, Flash Player took care of that burden automatically when removeMovieClip() was called.
this is one case where i think ActionScript 3.0 actually is harder than ActionScript 2.0. unfortunately, i also think the additional work is going to be a permanent fact of life in Flash programming. ActionScript 3.0 lets you take a display asset off the display list, hold a reference to it, and then later put it back on the display list. this new functionality comes with a new cost: Flash Player can't know when you're "done" with an asset, so you have to deactivate it yourself. hopefully in time Flash programmers will get used to putting away their proverbial toys when they're done playing with them.
summary of ActionScript 3.0 issues so far:
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
3) can't dynamically change a symbol's class at runtime (as previously possible via Object.registerClass())
4) deactivating display assets that are no longer in use takes more work.
happily, i think 1-3 are fixable, and i'll do what i can to bring them to Adobe's attention. for now, 4 is a fact of life.
colin
I'd say I fall quite clearly into the designer turned super lightweight developer, more of a flash butcher than a developer really and I'm finding to quite difficult to get into AS3, this more of a personal shortcoming and lack of time than "the fault of flash" and AS3.
I think comments by Ian earlier are spot on. AS3 to someone who is from a programming background is a good logical step forward but for a lot of people I’ve spoke to who are from a design background now feel it's time to become one or the other, going back to a sole designer or investing their time into becoming a developer, where as previously there was this middle ground of existence where you could be both. This, arguably, to some is a better way of working both skill sets set firmly in their respective camps but for many of us in this middle ground and who quite enjoy the middle ground feel it's a bit of a loss.
While I have only become involved in anything Flash-related recently (and all with AS3), I will say that it seems like, with few exceptions, that the "middle ground" developer is not required to learn anything really complex from a programmatic standpoint. The biggest challenge is where things are done differently than in previous versions of the language, but that challenge is easily conquered through some familiarization with the APIs.
Someone mentioned that the addEventListener method is harder to grasp than onclick, etc. While I would agree that the method name (and the use of static constants to indicate the desired event to be captured) is at first a little less direct than the old way, I can not agree that it is harder to grasp. It's still pretty straightforward English, and, most importantly, it doesn't require any deeper programming knowledge than was required by the old way of doing things. It just requires that the designer/programmer memorize a different instruction. Surely no person could attach any significance to a function like goToAndPlay() prior to learning about it and what it does, but most veteran Flash builders know exactly what it means and how to use it, because they once took several minutes to acquaint themselves with it.
Yes, in quite a few areas, AS3 requires you to memorize different ways of doing things that you've done before, but I firmly believe that it is for the better--both for the language and for the way Flash programs are designed. AS3 is flexible enough to allow "lite" programmers to keep working as they have (if they learn a few new things) while opening up the door for well-structured, large-scale *applications* built collaboratively by designers and programmers.
First, thank you very much for Essential Actionscript 3.0, it was worth every penny of the $71.99 Canadian dollars I paid. I read the book from cover to cover. I would be more than happy to divulge my full thoughts on the book if that is so welcome.
Nowhere can I find if you can access a variable or function of a parent in AS3 like we could in AS2. I loved being able to do in AS2:
this.parent.parentFunction(); or
this.parent.parentVariable=value;
and access any variable or function within AS2 child/parent hierarchies either up or down the hierarchy at will with dot syntax.
This to me is an example of how AS2 could be used to achieve quick and intuitive results for all.
My first impression of AS3 was that it was a real **tch but now am starting to grow into it.
Recently I asked myself whether I would have continued to learn Actionscript 3.0 if I didn't already know AS1.0/2.0. AS3 has a fairly steep learning curve compared to it's predecessor though I feel once you reach a certain understanding your skills tend to plateau and things just start to "click".
I use flash for work and now shudder when I have to revert back to AS2.0 when building banner ads. Overall I feel AS3 does have some fairly daunting elements though once you get a solid grasp of the key concepts it becomes much simpler.
thx for responding, but..you said:
>4) deactivating display assets that are no longer in use takes more work.
It seems besides taking more work, some very useful possibilities of Flash are just becoming... impossibilities.
For example, "a flash site loading external SWF developped and submitted by various contributors" seems no more possible.
I mean, it was previously possible to load any SWF in a flash "site framework" (for example: game site, flash experiments site, educational site, flash-youtube, ... etc..) and unload these SWF. "Any SWF" here means SWF that can be submitted by anyone (studios, indies, amateurs, flash-gurus, etc..).
I did'nt check all the implications of the page 807 of your book, but if the loaded SWF has started a Sound for example, the SWF may not be garbage-collectible. Even if removed from the display list, those SWF would still be present and take more and more memory.
Even if the programmers of the loaded SWF afforded "more work" and explicitly managed the possibility of being removed, it's unlikely (because quite tedious, specially when human interaction is involved) that they would check/test the removal for any state of the loaded SWF.
Aside from asking more work from all SWF developers of the world, a better approach might be to do that job from the flash framework. But... It also seems that programming a super-function recursively walking a SWF and properly "terminating what has to be terminated" is quite difficult, or perhaps impossible. I didn't tried yet.
Has anyone any info about this?
why people are so frustrated about parent.gotoAndPlay() requiring cast?
Way I see it, using parent.gotoAndPlay completely breaks idea about loose coupling between components as you are expecting certain behavior to occur inside ui element.
Behavior code should almost always be coded on separate handlers that are aware of their context, and UI elements should just pass events that are catched on top level of the user interface.
If you are a visual designer and you have been following (and trying to keep up with) actionscript for the past 4 years you KNOW that the tool is now in the hands of engineers. Objects,Classes, Listeners, Dispatchers, Private, Public, Protected, Scope? This is just non-sense to your average designer who wants to add animation to their work. goToAndStop, LoadMovieClip, CreateEmptyMovieClip, now this is the language of a VISUAL thinker. I have spent hundreds of dollars and hours trying to keep up. I spend more time looking at code than I do tweaking my design. Trying to abstract the nature of a button and build a class around it is way less fun than just drawing it on the stage, calling it a movieclip, and writing a few functions to point it at. Seriously, it's sad to see a tool that let the average designer create some basic interaction be stollen by programmers who would rather program a square than just draw one. I have to say I have been forced to become a programmer and I think my visual creativity is getting rusty. Flash used to inspire designers to do cool stuff, now it just says, "stick with photoshop dummy"
I am on a new path. I am learning AS3. I am enjoying it. I have to learn this because this is how I pay the bills. But God help the guy who has been dabbling with a bit of HTML and CSS who wants to make a simple slide show for his client. He'd have an easier time with JQUERY than flash. which is exactly where designers are turning now that flash has forgotten who made it all happen.
IMHO there should have been a code fork about two years ago. FlashDev and FlashDesigner.
Josh,
You can still draw buttons in Photoshop, Illustrator, or the Flash Authoring tool and use them as buttons. You simply add an event listener that handles the click. It doesn't require any extra programming know-how; it just requires that you, like me, have to refer to or memorize a piece of knowledge. This isn't too much to ask--you had to refer to or memorize a piece of knowledge when you first started working with Actionscript in any of its versions.
You can create your button in a few easy steps:
1) Draw it.
2) Give it an instance name
3) Write the following Actionscript:
instanceName.addEventListener( MouseEvent.CLICK, functionToExecute )
If you want the button to have different states (up, down, over), all you have to do is make it a descendant of the simple button class (which isn't very hard at all) and set 4 instance variables, upState, overState, downState, hitTestState (that last one being the area of interaction, which you can set as larger or smaller than the actual button). These are new concepts to users of AS1 and AS2, but they aren't difficult concepts to tackle. Step 3 above is still pretty close to sensible English, and you can't get much easier than upState, overState, and downState. And you can still do all of it outside of a class definition. If your button is a subclass of SimpleButton (or just a SimpleButton itself), you can set those states as follows:
instanceName.upState = upState;
It's really that easy.
Granted, many designers complaining about AS3 have legitimate concerns, but it seems like a good deal of you are upset because there have been some language changes that require you to use a different instruction to accomplish something that you've been doing.This isn't something to get upset about. Just learn the new code. No one is asking you to become a more sophisticated programmer (not that it would be a bad thing...).
The reason AS3 is becoming more programmer-friendly in the first place is because people are using the Flash platform for more sophisticated applications. Something like Pandora.com would be pretty hard to manage without getting into more structured, sophisticated programming, and that's just one website out of many that are treating Flash as a serious, portable applications platform.
Not sure why my other replies never posted... (I did reply specifically) whatever. I do think this thread has turned into "AS3 may or may not be 'harder' but it's 'worth it'". I think that, sure, if you want/need it, it's worth it. I do think that there's a middle-ground programmer who is left out... and is especially alienated if they think they need to learn AS3 to keep up.
Oh, pandora.com is Flash player 6!
I didn't say that Pandora was written in AS3; I was implying that it requires a more sophisticated level of programming than that which is typically employed by the timeline programmer using the Flash Authoring Tool.
I didn't read ALL the comments here, but here's a HUGE reason not to go AS3 yet. Uptake of the Flash Players. If I code OO AS2 code I can still do most of what I need (ok big thing is no filters for effects - it just makes you more creative for the design side of things) and ensure that coded tweened, animation and integration with back end systems is no problem.
The thing is even if 1% of users only have FP6 and your corp is turning over a billion $ in online sales a year, then 1% of a billion$ is SIGNIFICANT. Hence AS2 (proper cleanly OO coded) will be need for a long time for us for any site that impacts income. For other (unnecessary) apps/websites, sure we might go AS3 so we can use the full gamut of toys (like papervision of FP8's filters). But until more of the masses uptake the player that supports it (yes I know it's over 90%) - then it's not viable for publishing where every user counts.
:p
Show me a corporation that's doing a billion in online sales that makes a significant portion of its profits from Flash. You aren't going to lose 1% of your profits because some of your customers aren't current.
I don't agree with the author. This language is way too hard and their ARE no good teachers out there. There seems to be an assumption in all of the books and vids I've purchased that the reader has a baseline knowledge that stops authors from defining terms. I hate the language and decided on going with VB.
AS3 only hard if you have been brainwashed into learning older versions of ActionScript with all the inconsistencies and work-arounds, adn their often akward entanglement with the timeline and the Flash IDE. Once you make the leap the clean-ness and beauty of AS3 becomes apparent.
I am so switched over that I do not even to touch Flash Lite anymore, until they have come over to the 21st century :-)
It seems hard to folks who have been indoctrinated into the AS2 workflow.
I migrated to AS3 as soon as it was avaiable, and I always use a standard FLA and Main.as file which I copy for different compiles, different projects.
The Flash IDE should probably make that initial step easier.
They should probably explain that your main document class (which seems to work best extending Sprite) is basically what you use as the "stage" - and how to use a static variable, i.e. an instance() function to access it.
If Main.instance() gives me my top level sprite, then I can always have another more specific class like if I create a Drawingboard.instance() which links to that. This is equivalent to the AS2 "_root".
AS3
var s:Sprite = new Sprite();
Drawingboard.instance().addChild(s);
AS2
_root.createEmptyMovieClip("s", ......
Whatever the case may be you are going to need access to your top level Sprite object at one point or another (an in some cases, the .stage property if you want to size and position something before you add it to the display list.)
Again, I think they could make this more intuitive to the AS2 folks.
Hi
Does anybody have sample codes for webservice in FlashCS3 using actionscript3. Icannot find one. help appreciated.
Thanks
Hari
most certain AS3 is an improvement. No doubt about that. But I must admit that it is irritating that my wellproven techniques doesnt work or at the best take me hours to understand how to implement in this new framework. After ten years or so in the industry I am lazy and prefer to focus on making great games for small kids. The programming is just a tool for me, and I pretty much have used the same technical concept /framework since AS2 arrived (I started with Lingo back in 96 and moved on to AS when it was mature : )
I have just spent (waisted) a workday with trying to figure out how to create movieclips from my arrays.
I often organize my stuff in arrays and keep references to my clips as Strings.
In As2 it is simple to construct and combine strings as references to library assets. attachMovie accepts strings. But in As3 I just can't find a way to make the machine interpret my string as a 'name of a movieClip'
the 'new MovieClipName()' doesnt give me a way to use a string. I have tried all the trix I knew from AS2 but nope. At last I found some very strange: getDefinitionByName and it seems to get the job done. I dont know If there are any cons???
anyway this is an example where aFrameClip could be a stringvalue stored in a complex array describing state, name of clips, etc.
private function attachTheFrames (aFrameClip:String)
{
for (var prop in grid_mc) {
grid_mc[prop].removeMovieClip ();
}
delete clipList;
var noc = 5;
var nor = 3;
var c = 0;
clipList = new Array ();
for (var i = 0; i for (var ii = 0; ii var clip:String = 'c' + i + 'r' + ii + '_b_mc';
grid_mc.attachMovie (aFrameClip, clip, grid_mc.getNextHighestDepth (), {col:i, row:ii, state:"front"});
clipList.push (clip);
grid_mc[clip]._visible = false;
grid_mc[clip].gotoAndStop ('init');
grid_mc[clip]._x = (grid_mc[clip]._width + 3) * i;
grid_mc[clip]._y = (grid_mc[clip]._height + 11) * ii;
}
}
}
cheers to Colin - I ' ve been with you since your first AS-book. Keep up the good work.
/ Lasse
Very timely and interesting article. On the whole I like AS3 but I agree wholeheartedly with the point Colin makes about half way down that the two AS2 structures that should be re-introduced in some form are ...
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
In general, object orientated programming only really has significant advantages over other structuring for larger projects where there are many moving pieces and you want to isolate code. OO is not some magical higher evolution of programming structure. For smaller projects, from a practical point of view, setting up a full object communication structure is a big fat waste of effort.
Adobe is pushing AS as a Rich Media Application development language and so I can understand and appreciate the new rigor in AS3 - but I think in their rush forward they need to remember that most Flash projects are fairly small.
In particular, the joy of flash was being able to quickly put together fun projects without having to worry about an unnecessarily rigorous structure. It was also great for prototyping and playing around with ideas. This is why it flourished.
Adobe denies this heritage of Flash at its peril. I'm a fairly hardcore programmer but there are many times when I've cursed Adobe for removing elements of AS2. And the ones I've cursed most are:
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
They are the bedrock of small fun AS projects prior to AS3. 1) allowed the quick addition of interactivity to graphical, drawn elements. 2) allowed easy controlled animation of those elements.
If I'm putting together a quick button-driven interactive animation (a big part of Flash output) why on earth would I want to deal with higher OOP structures just to add a button that starts an animation in the containing movie? I wouldn't - and no reasonable person would.
I'm all for moving AS forward but the removal of 1) and 2) was a bad mistake that I urge Adobe to remedy as soon as possible.
Oh! and point 4):
4) deactivating display assets that are no longer in use takes more work.
I believe this could be AS3's Achilles heal ... if you thought Flash devs wrote memory hungry, inefficient Flash code when there was automatic garbage collection, I'm not looking forward to see what happens when people forget they're now responsible for it themselves.
But - one thing I don't understand:
Colin, you say:
this new functionality comes with a new cost: Flash Player can't know when you're "done" with an asset, so you have to deactivate it yourself.
Why couldn't Adobe just re-introduce a removeMovieclip()-like method that TELLS Flash that you are 'done' with an asset?
Come on people. Just by reading the comments, most of you are experienced developers......you should be used to it by now. Adobe wouldn't be Adobe if they didn't periodically do something with Actionscript to screw with our heads. I could do things with AS2 that I am finding nearly, if not entirely impossible with AS3. I just accept it and move on to learning all new ways to fool Flash into doing what I want it to do.