Slashdot Log In
Actionscript: The Definitive Guide
from the make-it-work-in-lynx dept.
| ActionScript : The Definitive Guide | |
| author | Colin Moock |
| pages | 672 |
| publisher | O'Reilly & Associates |
| rating | 9 |
| reviewer | Brian Donovan |
| ISBN | 1565928520 |
| summary | Complete and authoritative. Check the author's site book site (http://www.moock.org/asdg) for sample chapters and code. |
What it is, why you'd want it
Actionscript, the programming language that's been supported in the Flash player and authoring environment since Flash version 4, is exhaustively described in a new title in the Definitive Guide series from O'Reilly. Written by widely-recognized web developer Colin Moock (http://www.moock.org) and edited by Bruce Epstein (author of Director in a Nutshell and Lingo in a Nutshell), the book lives up to the hype.Moock divided Actionscript: the Definitive Guide (A: tDG) into 3 sections. "Actionscript Fundamentals" covers the language itself (variables, the Actionscript datatypes, how to declare and use functions, etc) in a way that's accessible to newbies without boring everyone else. "Applied Actionscript" is shorter and has a more conversational tone, explaining how to externalize your code, the ins-and-outs of making smart clips, using text fields as form fields in your movies, and debugging. The "Language Reference" is basically the Actionscript Dictionary from the Flash 5 Actionscript Reference Guide (ARG, pronounced "arrgghhh," similar to the noise that one inevitably makes when forced to refer to same) on steroids. In fact, it would almost be worth the full price of the complete book all by itself. Code is sprinkled liberally throughout. Included are four appendices (resource urls, a keycodes reference, Flash 4/Flash 5 backwards compatibility advice, and a table listing the differences between Actionscript and Javascript/ECMA-262).
What I liked
Although some constructs present in both Javascript and Actionscript (like the arguments object) that managed to go completely unmentioned in the ARG are discussed, the "Actionscript Fundamentals" section is not a retread of the basics of the ECMA standard. There's a whole chapter on events and event-handling in Flash, including a comprehensive treatment of movie clip events. The chapter on OOP in Actionscript is the first real discussion of object-oriented Actionscript programming that I've seen outside of a few posts to a Flash programming mailing list. The detailed coverage of the stacking order of movies and movie clip instances is priceless -- Figure 13-4, "The complete Flash Player movie clip stack" is the clearest visual representation of movie and movie clip instance stacking available.In the "Applied Actionscript" part of A: tDG, I got the most mileage from the discussion of the different methods of pulling code out of movies and making it more reusable (import from file, #include, shared libraries, and smart clips). Most of that material was already available in separate tech notes at the Macromedia web site (and, to a lesser extent, in the ARG), but it's great to see it brought together in book form.
When I got to the "Actionscript Language Reference," I did a quick page count. It weighed in at 50 pages lighter than the "Actionscript Dictionary" in the ARG, but manages to be more complete and more useful. This could be due to the fact that the pages in A: tDG are covered with text while the "Actionscript Dictionary" pages sport oversized inner margins and whitespace galore. Code is plentiful here, since the entry for practically every Actionscript object or class includes an example script fragment that is generally longer and more useful than the corresponding snippet (when one even exists) in the ARG. Where it's warranted, bug information is included, identifying specific problems with the implementation of the specific Actionscript element in the Flash 5 Player (pinpointing differences in behavior between builds when differences exist) and suggesting workarounds where possible -- the sort of feature that saves coders mountains of frustration of the "it's 4am and I'm tired?why isn't this working?!" variety.
The bottom line
I would have liked to have seen more space devoted to optimization/performance (somehow, code optimization got lumped in with file size considerations in the "The Bandwidth Profiler" section in Chapter 9: "Debugging"), but if it sounds as though I'm nitpicking here, it's because I am. For anyone working with Flash who is interested in taking off the training wheels and developing in "expert mode," this book is a must-have."
You can purchase this book at Fatbrain.
Re:Flash is a dead end (Score:5)
Flash can be useful (Score:3)
I have a friend who does a lot of hardcore Flash work. (He's apparently enough of an expert that some folks asked him to narrate an instructional video on the subject.) He's convinced that Flash can do what client-side Java was once pushed for: Highly specialized UIs for specialized goals, using more fine-grained control than you can get through HTML.
I would be unconvinced, except I had seen something he had done: It was a site that let users design their own Nokia cellphone faceplate. It was a basic painting program using a faceplate-shaped painting surface, and then you could save your design and order it. The Flash app was integrated with an industrial painting machine, which would actually spray out a copy of your faceplate, and then you'd get it in the mail in a few weeks.
Flash is so commonly misused that it's easy to assume it's an entirely worthless technology. But in the right hands, it seems like it can be very useful.
Will it teach me to do things like this ? (Score:3)
Kung Fu Fighting in Flash
Re:Flash is a dead end (Score:5)
The Flash file format is open.... go write some perl that can generate Flash files and go nuts bundling... oh wait, someone already did write open source perl that can generate Flash files.
I have seen some really bad ugly animated GIFs. We should not use the GIF98a format EVER, since you can make ugly, useless things with it. Heck, I've people use the BLINK tag and design really ugly HTML pages... we should get rid of that too!
Yes, Flash makes it easy for any idiot to make really bad, annoying sites. Then again, FrontPage, Dreamweaver, and GoLive do the same for HTML.
Good Flash can be an expressive design media, bring animation to the Web (try doing an animated cartoon with sound in GIF89a =) and with Flash 5, can lead to very powerful web-based apps that interact with live data form a variety of sources... check this thing I did for the intranet of my last job:
http://www.eskimospy.com/contentPages/phone.html [eskimospy.com]
It's Flash that pulls XML data from the company database (tho this "public" version uses a flat file with fake data) and generates this on the fly, telling you who's in the office with the colored desks and where people sit... this whole thing took me less than one day to design and code, and was live less than 12 hours after I thought of the idea. Sure, You could do it in Java (but in less than 12 hours?) or DHTML (with 4 code-bases and 11209771207 hours of testing in every browser on every OS to make sure it works) but this was easy to make, and even the Linux crew in the programming dept. are happily using it today.
Is Flash over-used and usually poorly done? Yes. Should Flash be blamed for people not having a clue how to use it? Nope. Don't shoot the tool, shoot the people who use it when they shouldn't be.
Have a nice day.
PS: This is a site I love that I think expresses your frustration perfectly: Skip Intro [skipintro.com]
It's not because you can, that you should (Score:4)
why this shouldn't be used too much
that forcing a surfer through an entry-tunnel to access a website is Bad Practice (tm)
and that most sites are actually being visited for their content, rather than their flashy look (no pun intended)
A very interesting point of view on this subject can be found in Phillip Greenspun's Guide to web publishing [arsdigita.com]. Phillip even practices what he preaches on photo.net [photo.net].
Re:physics vs. other stuff (Score:3)
Java, without question. Java has a real GUI toolkit that behaves in ways people expect of GUI toolkits. Flash is all about looks, but usability of user interfaces written in Flash leaves a lot to be desired. From a programming point of view, I also prefer Java: it's not as easy as Flash programming, but ultimately, it's more powerful and you can do a lot more in Java.
But, yes, Macromedia very much would like to take over the applet space with their product. And by providing something that looks spiffy and is easy to get started with, they may well succeed, no matter how many corners they cut.
thanks for the example (Score:4)
Let's see, when I go to that site, it says "Loading and parsing XML... please be patient." and then it just sits there. There is no error message and now way of figuring out what's wrong.
When I open it in IE5, I do indeed get some kind of nifty looking display, something that would look swell on a set for StarTrek or The Matrix. Trouble is, it isn't very useful. It ignores my font preferences, so fonts are way too small for my display. The scrollbars don't look like scrollbars. The whole thing doesn't resize. I can't print it. And instead of responding instantly when I click somewhere, it animates. Let's not even talk about accessibility for people with disabilities. In fact, I have seen a number of sites that attempt to use Flash as some kind of "responsive" and "interactive" UI, and they all share the same problems.
So, thanks for the example: you have provided an excellent example of why Flash is a bad standard to use for writing web-based applications. You presumably invested a lot of time in building this thing, but while it looks nice, what you wrote ends up being considerable less useful and less user friendly than straight HTML and images.