Skip to main content

Books: ActionScript 3.0: Visual QuickStart Guide

I finished reading ActionScript 3.0: Visual QuickStart Guide. All-in-all, it wasn't bad. I needed to learn ActionScript quickly, but not extremely deeply, and it helped me do that.

This is the first time I've read a visual quickstart guide. The book was only about 300 pages, and each page was cut in two columns. The inner columns have code, and the outer columns have prose. Hence, there's only about 150 pages of prose. The code tended to be very basic and very redundant. Unsurprisingly, the author was a non-software engineer who learned how to code in ActionScript. I sort of expected that. The book wasn't perfect, but I definitely recommend it if you're a software engineer who needs to learn ActionScript in a hurry.

That's enough for the book review. Now, let me say a few words about ActionScript. First of all, ActionScript 3.0 is a compiled language. ActionScript started life as ECMAScript, but by the time they hit 3.0, it had morphed into a pleasant mix of JavaScript and Java. It has static types like Java, but you can do a lot of the same tricks that you can do in JavaScript, such as treat objects as hashes and use closures. Like JavaScript, ActionScript revolves around event handling. Anyway, as I said, I think ActionScript 3.0 is pleasant.

Now, let me cover a few of the things that were interesting enough for me to write down while I was reading the book.

ActionScript 3.0 has three types of numbers: int, uint, and Number. Numbers are floats, and match the same number type that JavaScript has.

One way to think of Flash is as a programmable version of Photoshop optimized for animated gifs. That's pretty much how it started life. Over time, they added layers and timelines. These days, ActionScript is a full featured language. Early on in the book, I couldn't understand how this graphical environment and this programming language worked together. Now I understand that Adobe Flash CS 4 is basically something like a paint program with a timeline that you use to create movies. ActionScript is bolted onto the side of it so that you can control things programmatically. However, early on, the most important use of the programming language was simply to control the timeline of the movie. (I could be getting some of this wrong since I've only been coding in ActionScript for a few months.)

Using the open source Flex SDK, you can compile Flash from the command line. You can even shun Adobe Flash CS 4 entirely and code everything in Vim. Although there are rather nice Flash IDEs, I felt less out of my element by sticking to Vim. See my other three posts: Linux: Installing the Flex SDK, Vim: Editing ActionScript, and Linux: Installing the Debug Version of Flash on Ubuntu.

Whereas in Java you might write "FooBar fooBar = new FooBar();" in ActionScript you write "var fooBar:Foobar = Foobar();". I think I have a mild preference for ActionScript's syntax.

There is a widget hierarchy in ActionScript. As you go down the hierarchy, the widgets gain more behavior such as being able to accept events or being able to contain other widgets. MovieClip is pretty far down in the hierarchy and is used for almost everything. MovieClip doesn't actually have anything to do with playing videos. It's just a widget that can handle events, contain other widgets, and live in its own timeline.

In C, to cast an int, you might write "(int) n", but in ActionScript, you write "Number(n)".

TextFields in ActionScript do support HTML, but its very weak. They also support CSS, but that's pretty weak too.

"someArray.forEach(someFunction);" works.

Just like JavaScript, you can write 'if (typeof(s) == "string")'. However, to test what type of object you have, you can also write 'if (someObj is MovieClip)'.

Use "for (var i:String in someObj) { trace(someObj[i]); }" to loop over the indexes of an object.

Use "for each (var value in someObj) { trace(value); }" to loop over the values of an object.

Use "navigateToURL" (mentioned on p. 205) to make the browser go to a new web page.

The way you dynamically load data from a web site varies wildly depending on whether you're loading sound, a DisplayObject, or data. I'm pretty sure these things were built by different engineers at different times.

In summary, if you're familiar with JavaScript and Java, ActionScript will seem extremely straightforward. I managed to code quite a bit before picking up a book at all.


bsergean said…
I've written a build system for Flash Builder at work and I'd love if we could to open-source it. It takes a list of flex projects (.swc and .swf) as input (in an XML file) and build them, resolving the dependancies and building in parallel (clean build).
jjinux said…
jjinux said…
By the way, how would it compare to Ant, since Ant seems to be pretty standard for Flash?

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p