Summary

New job. New city. New house. Moving tomorrow. Offline for a week or two. Don’t say anything important while I’m gone. (Sorry FATC, especially Reflex: no breaking announcements or innovation allowed. =)

1. Job

I am now no longer working for Adobe. I have started a new job with Dedo Interactive, Inc., as a Flash/Flex/ActionScript/AIR developer and also as an active collaborator with the UX design group. As Danny and Jonathan have already described, this is an exciting opportunity with a group that’s pushing the boundaries of hardware and software solutions. It’s also exciting for me to be a “regular developer” like everyone I hang out with and pretend to fit in with at conferences. Of course that’s where my roots are — in being a Macromedia/Adobe customer first before being an Adobe employee — so I’m just going back to the place that I’ve tried my best not to leave anyway.

2. Location

Since Dedo is located in Plano (N. Dallas) Texas, naturally it seems that I need to be located there too. Danny has been really great about letting me start as a remote employee. Nevertheless, I am typing this while mostly surrounded by cardboard boxes, as well as a few too many things that I should have already packed into cardboard boxes. In approximately 32 hours a moving truck will pull up to my house and load everything up. Then I’ll pack my family into a minivan and drive for many hours and days until we get to our new house. (Just signed the mortgage papers today — ack!)

3. Family

Fortunately, my family has agreed to accompany me on this crazy journey. I feel sad for my three young children. They’re obviously not happy to leave their friends and school and the life that they’ve known for the last three years. (My youngest doesn’t remember anything before California, and my middle child barely remembers anything else, in spite of the fact that they were both born in Indiana.) I’m grateful to have a wonderful wife and special children who make the hard times worth it, and who make the good times good.

4. Blog, Twitter, open source projects, conferences, etc.

Frankly, I have no plans to change what I’ve been doing with any of those. I’ve never been the most regular blogger or twitterer, and my projects don’t get updated as often as I’d like. That probably isn’t going to change with a new job and a new city. But the vast majority of my work on them has been on my own time anyway, so the fact that I’m no longer an Adobe employee shouldn’t make that situation any worse. In fact, the owners of Dedo said that they’re pleased with my community involvement, and want it to continue. I’m definitely still using AIR, ActionScript, and SQLite in my work, so I keep finding new things and ways to improve my projects.

5. Blah blah sentimental stuff

Adobe is a great employer, and a great company. In spite of all the negativity and mud-slinging that’s happening right now, I can say that I never felt bad or guilty about working for Adobe. On the contrary, I am proud to have worked for Adobe. I feel like Adobe is a good, ethical company that tries to make business decisions that lead to mutual benefit for partners and customers. (Don’t bother sharing your experiences to the contrary. I’m sure I could tell you plenty too. In spite of that, this is my opinion of the company and employees overall.)

In addition to my great employer, living and working and associating with the community in the San Francisco bay area has been a tremendous experience, and I consider myself very fortunate for it. I’m definitely sorry to leave, especially because of the great opportunities (being near Adobe HQ), the great community (I’m looking at you SilvaFUG), and the great weather =)

To all of you who I’ve met and become friends with over the last 3 years, farewell, and I look forward to seeing you online and at conferences of the future. I only regret that I didn’t get to come to one last meeting and tell you goodbye in person.

Meanwhile, I’ve been amazed to learn how many talented and community-oriented developers call the Dallas-Fort Worth area home. I’ve already attended one users’ group meeting and plan to attend many more. I look forward to getting to know you better.

As I’ve been preparing to move, I’ve been trying to go through my many boxes that I haven’t touched since the last time I moved across the country. I was a little astounded to find so many of my college (and even a few high school) notes, papers, textbooks, etc. among my possessions. I’m getting older and more cynical now, plus we have to pay the movers by the pound, so I tried to get rid of as much as I could bear. I was amazed at how much I’ve forgotten from what I once knew. (Some of my academic papers were quite impressive to me — and it was astounding to find my 2nd year Hebrew notebook and later my calculus notes, and consider the fact that I wrote all the scribblings in there. =) I also couldn’t help but think over the many people I’ve met and known and worked with in Houston (where I grew up), Salt Lake City (where I did my undergraduate), Bloomington Indiana (grad school and my first “real” job), and of course most recently the bay area. It’s quite astounding to consider the path that life has led me on, and how I’ve ended up where I am today.

The next 360|Flex conference is coming up quickly — March 7-10, 2010 in San Jose, California. As I’ve been preparing for the conference and reading some of the things other people are saying about it, I’ve been reminiscing about past 360|Flex (and other) conferences I’ve been to, and about how much they’ve impacted me professionally and personally. (Hint: a lot.)

But I’m not here to talk about the past. (Or about what I’m presenting at the conference, since I’ve already mentioned that.) Instead, I’d like to talk to you about this 360|Flex, and why I’m excited to attend and what I’m looking forward to most. These fall into two categories: Sessions I’m looking forward to, and people I’m excited to meet (or see again).

The sessions (in schedule order)

I combed over the whole schedule, and there is literally not a single time slot that I’m not looking forward to. Except the ones where I have to choose from two or three awesome-sounding presentations. Frankly, what I’m not looking forward to about 360|Flex is that I’ll have to choose not to attend some sessions that I’m really anxious to see.

Sunday

Sunday afternoon: Joel Hooks: Hands-on development with the Robotlegs AS3 framework (I’ve mentioned I’ll be helping with this, but I’d definitely attend if I wasn’t)

Monday

Keynote: Is this Deepa’s first keynote, now that she’s a Flex Product Manager and not an engineer anymore? She spoke to my users’ group last week talking about Flex “next” (i.e. after 4). I have no idea what she’ll talk about here, but I’m looking forward to it!

Monday 1: Already there are too many to choose…Michael Labriola (Flex components), Chase Brammer (analytics) or Richard Lord (“Designer Last” architecture)?

Monday 2: Drew McClean and RJ Owen - Rules engine with AS3 and Hamcrest (time to find out what the buzz is about), although if I was doing more video work I’d definitely hit expert David Hassoun’s session (OSMF), or maybe I should broaden my horizons/prepare for the future with Bryce Barrand (How to find and keep top developers)

Monday 3: Again, I can’t decide…Garth Braithwaite on skinning, or Jesse Warden on Robotlegs and Gaia?

Tuesday

Morning panel discussion (“Principles for RIA design”): Don’t discount this because it’s early. Keith is a great facilitator (he’s a co-manager of my local users’ group) and from the things I’ve heard, there will be lots of great ideas shared in this session.

Tuesday 1: Alas, I’m speaking in this slot so I’ll miss Deepa’s Flex 4 talk and Aaron Pedersen and James Polanco’s Flex 4 lifecycle talk. Will anyone notice if I just skip out and go to their sessions instead?

Tuesday 2: Jacob and Tyler Wright (and Ben Stucki, I think!): “Reflex: Rethinking Component Design.” I got to hear about the ideas behind this component/layout framework in conversations at the last 360|Flex conference, and I’ve been dying to try it out since then. Revolutionary stuff will appear here!

Tuesday 3: Yet another tough choice: Elad Elrom on TDD, Randy Troppman and Adrew Westberg on GPS in Flex, or Aaron Hardy on Queue and Cache?

Wednesday

Keynote: always fun and informative — hear the behind-the-scenes of the conference, and win prizes too!

Wednesday 1: Why do they have to make it so hard to choose! Renaun Erickson (“AS tips for iPhone games”), Jeff Tapper (don’t even know but always extremely valuable), or Sim Bateman (“Getting Git”)?

Wednesday 2: I think I may go to the dark side for a bit, and learn more about Silverlight from Jun Heider. But Nate Beck’s “Flexible games” looks mighty tempting too…

Wednesday 3: Eric Fickes with Silverlight, part 2, Shashank Tiwari on multi-touch, or Andy Powell on UX? John and Tom, you’re making this so hard!

Wednesday 4: (at least) two presentations worth sticking around for: Matt Guest on Flex text with TLF, and Huyen Tue Dao on Greenthreading

So yes, I’ve realized I’m going to have to make two clones of myself (at least) in order to attend all the sessions I want to see. And then I’ll have to merge them back together somehow. I’ll get back to you on how that one turns out…

The people

Richard Lord really nailed it when he said that the best part of conferences, especially smaller ones like 360|Flex, is getting to meet and talk with and throw ideas around with other developers. I’ve learned some good things in the sessions at past conferences, but by far my best memories and most valued times are the ones I spent between sessions and evenings/nights kicking around ideas with others.

These are my “conference friends” (and a few “users’ group friends) who I’ve met at conferences and always look forward to hanging out with again. I’m sure you know their names, and like me you may wonder why they’re actually willing to talk and hang out with someone like me =) But I’ve never gotten any attitude from these (or other) “superstars” that I’ve met in person at conferences. That’s reason 1 I love the Flash/Flex community — these people welcome ideas, and are just excited to meet people and share:

• Renaun Erickson
• David Hassoun
• Jun Heider
• Doug McCune
• Clint Modien (C’mon Clint, you know you want to be there)
• Tom Ortega (his last 360|Flex as an organizer!)
• Andy Powell
• Todd Rothe
• Ryan Stewart
• Ben Stucki
• Bryce Barrand
• Jac Wright
• Tyler Wright

And these are the people who I’ve learned from whose work I’ve admired online, who I’m hoping to meet and get to know “in real life”:

• Sim Bateman
• Garth Braithwaite
• Joel Hooks
• Kevin Hoyt
• Richard Lord
• Jesse Warden
• Yakov Fain

And the best part is, there are plenty of others that I will meet, that I don’t know (or even know of) yet, but who will be on my “conference friends” list for the next 360|Flex =)

It turns out that my thinking on that topic isn’t going to become anything in the Adobe documentation. So I’ve sort of just been sitting on my ideas with the idea that someday I’ll probably share them.

Which brings me to this post.

Aside: upcoming presentations on multi-screen development

This is really a side note to the main ideas here, but I thought I’d mention it since it’s the reason I actually stopped to write this. In one of my mind-wandering moments this morning, I realized that at the upcoming 360|Flex conference (San Jose, March 7-10) I’ll be involved in two presentations that are directly related to practical aspects of building multi-screen apps:

• As part of the pre-conference free training, Joel Hooks and I are doing a four-hour training on using the Robotlegs micro-architecture. (Joel is the main speaker, fortunately, because he’s one of the core Robotlegs developers and the main “evangelist.” I’ll be helping out, to try and help save his voice and maybe to help find typos. =)

  If you’re wondering what a Robotlegs session has to do with multi-screen apps…keep reading, it’s explained below.

• On Tuesday and Wednesday, Renaun Erickson and I are giving (two separate) presentations about building iPhone apps using Flash Platform tools. My session is more of an intro into the workflow, how it’s similar to other app building, and how it’s different. (Plenty of code to look at — don’t worry!) Renaun is going to get more into specifics of building a game, as well as some more intermediate/advanced topics like performance.

Funny that I never really made that connection until this morning. I guess subconsciously I knew this is a direction I want to move in, and that’s why I’ve been focusing my learning (and hence my presenting) on these topics =)

Background

While I was partially trying to keep my thinking abstract, from a practical perspective I centered my thoughts around developing using the Flash Platform. So conceptually, what I was thinking about was the idea of making a single “app” for multiple screens, which would mean that (in the technology of the next year or so) it could be potentially take several forms:

• a browser/computer app (Flash Player)
• a browser/mobile app (Flash Player)
• a desktop app (AIR)
• a mobile (iPhone) app (Publisher for iPhone, similar to AIR)
• a mobile app for other devices (AIR)
• a TV app or widget (Flash for the digital home)

(Obviously many of these are only out in public beta, some have only been vaguely publicly acknowledged, and others may or may not ever exist as actual Adobe products =)

One app, or many?

Back when I started thinking about this, there seemed to be two main camps. One group was a strong advocate for the “single source” idea: you would build one SWF or one AIR app and distribute that same app on any platforms (desktop/mobile/TV). Obviously a key element to that, especially for desktop/mobile apps rather than browser apps, would be having code that detects screen size and device capabilities and adapts the UI to the device.

The second group felt that it was more likely that developers who are creating an app for multiple screens would actually create multiple apps (from the perspective of the IDE). The apps would obviously share some code, visual assets, etc., but would be different enough that they’d be created separately and distributed as separate file types. (In the case of apps created for the iPhone, of necessity this has to be true, at least in terms of the publishing part.)

Since I try to be pragmatic about things unless I have a really good reason, I favored the second viewpoint. However, I acknowledge that in some circumstances the first approach might be used. As always, I think that developers are going to use a mix of approaches.

For example, suppose I’m building an app and I want to create a version for desktop computers, a version for the iPhone, and a version for other mobile devices. Personally I see this not just as an issue of “porting” the app from one platform to another. I think that each device has its strengths, and more importantly, each device is used for different purposes and in different contexts. If I’m building an app for a device, I should definitely be taking that notion of context into account as I’m designing the app. That pretty much rules out the possibility of using the exact same app (UI and everything) for both computers and mobile devices, unless I want it to run as a widget-type app on the desktop.

Also see: Adobe Flash Platform contextual applications developer center

Adaptable code to the rescue

On the other hand, that doesn’t mean that developers will always create completely separate projects. For example, suppose I’m creating an app for iPhone, and another for another mobile device. Or perhaps I’m using the Publisher for iPhone to create an iPhone version of my app and an iPad version. If my app is a game where I can more freely discard the conventions of the platforms, perhaps the only platform difference I need to consider is the difference in screen dimensions and pixel density. In that case, it’s quite possible that I can .

Even for a more line-of-business or productivity app, one of the key ideas in Slider, the future Flex mobile framework, is to (as much as possible) abstract away platform convention differences. For example, if iPhone usually puts the back button on the top, and another platform puts it on the bottom, and another platform puts it in a menu, and another platform has it assigned to a physical button on the device, then Slider might have a “back” event that you can hook into, and you can make your app perform the necessary “back” tasks regardless of platform.

Design patterns to the rescue

And, of course, in some situations you’ll almost surely need to create different versions of apps for different screens. For example, suppose you’re building a desktop Twitter client and a mobile Twitter client. Chances are good you’ll put some functionality into the desktop version that doesn’t go into the mobile one — such as previewing images, or maybe Facebook integration. On the other hand, adding a feature like automatic location tagging would make lots of sense in the mobile version, but not so much in the desktop one.

As I was thinking, many months ago, about the idea of efficiently creating different versions of the same app for different devices, a thought hit me like a ton of bricks. This is exactly the use case that the oft-mentioned “separation of concerns” is designed for:

Over several years, various “micro architectures” and “application frameworks” have emerged and waxed and waned in popularity. Many of these architectures are modeled around the “Model-View-Controller” design pattern (or its many variations).

One of the key benefits that these architectures claim is that it helps you keep the pieces of your application separate, without explicit links and dependencies between them. I’ve looked into and even tried out several of these over the years. One example that is frequently used to describe the notion of separation of concerns, which I always struggled with, goes something like this:

Suppose you’re creating an app, and you build the user interface and the other logic like server communication and data processing. If you use MVC/separation of concerns, then it’s really easy to just rip out your whole user interface layer and replace it with a new one.

They usually lost me with that one. As much as I tried, I couldn’t imagine a situation in which I’d want to build my app and then just rip out the UI and replace it with a different one note 1.

Until now.

Suddenly I had discovered, for myself at least, a real-world use case for the separation-of-concerns-so-you-can-swap-out-the-UI argument. If I’m building an app for the desktop and mobile, I’d like to be able to reuse my code where I can. At the same time, some functionality is only going to apply to one app or the other, so it’d be nice to be able to plug it in cleanly. Oh and by the way, the user interfaces are going to be different, so being able to swap those out is an absolute must.

I’d always liked micro-architectures in general, if only because I like knowing that I’m building my app using some pattern or structure that is based on developers’ real-world experience. It’s much nicer than trying to invent it myself and having to deal with all the pain points they’ve already gotten over. Now that I am imagining a world where I create multiple versions of the same app, with similar functionality but different user interfaces, suddenly micro-architecture patterns have become indispensable in my mind.

Conclusion

These are only just a few of my thoughts about the future world of multi-screen, contextual applications. Like Lee Brimelow, I believe that going forward building multi-screen, multi-context apps is going to be a much more common scenario. From my perspective as someone who thinks a lot about user experience design, and trying to optimize tools for the task and context, I think this is one of the most exciting aspects of the current technology revolution. I’ll definitely continue to share my thoughts and ideas in the future (hopefully more practical ones, too, not just abstract ones like this =)

Notes

Note 1: Just to be clear, I’m not trying to sound negative about MVC or micro-architectures/frameworks. Most of them provide many benefits, many of which are also related to the idea of separation of concerns, such as making code easier to test, making code cleaner, reducing boilerplate code, providing structure so that teams or developers who inherit a project can get going more quickly, etc. Swapping out the view layer is just one little benefit they mention. (back)

In one sense, it’s a big bunch of companies partnering with Adobe to make it so that interactive content can be accessed on mobile phones (using Flash Player and eventually Adobe AIR, surprise, surprise). And the content isn’t supposed to be just available, but fully available, using the full capabilities of Flash Player. What? Full Flash Player running on a mobile device? Nobody’s ever complained about that, right? =)

But this isn’t just an announcement of a partnership to think about what may come someday in the future. As part of all of this, Adobe is doing some concrete things today. There are a few things that Adobe’s releasing/changing. The most notable of these to me is that Adobe’s changing the license restrictions on the SWF format (as well as FLV and to allow it to be used not only for creating authoring tools, but players as well. From the FAQ page (emphasis mine):

Publication of an unrestricted SWF file format has long been requested by the Adobe Flash developer community. The longstanding publication of the SWF specification has fostered a vibrant ecosystem of companies and developers who create experiences with Adobe Flash technology and by removing the SWF licensing restrictions we are allowing that growing ecosystem to use the file format for any purpose, including the ability to playback SWF content.

As you may know, for years Adobe (and Macromedia before them) published the SWF format specification, allowing other companies to create tools that generate SWF files. That’s why there are all those “build Flash for free online” sites and packages that hosting companies offer. That’s why Nicholas Cannasse was able to create the awesome MTASC ActionScript 2.0 compiler back when the only way to compile ActionScript was through the Flash authoring tool. Heck, even Adobe used to try to compete with Flash authoring with their LiveMotion product. (Try being the operative word. After all, Macromedia wasn’t dumb. They’d develop Flash version X and Flash Player version X simultaneously, release them both, and only then — a few months later, really — publish the SWF spec. At that point competitors could start working on a competing authoring tool. For people who were targeting a very different market that was okay, but for anyone trying to go head-to-head with Flash? No chance.)

Anyway, the license allowed all of that without any royalties or anything. However, there was a big restriction on the license — if you ever looked at the SWF spec, you could not create an alternative SWF player (i.e. a Flash Player competitor). There’s a compelling reason for this — even though the player has always been free for desktop computers and hence not a direct source of revenue, Macromedia knew that it’s greatest strength was in its “write once, run anywhere” capability. Every web designer knows how horrible it is to try and design a page to look even mostly similar in all browsers — let alone exactly the same. By restricting the creation of alternative SWF players, there is much less chance of alternative “mostly but not completely” compliant players showing up on users’ computers.

Of course, that’s in the past now. As of today the license restriction has been removed, and anyone who wants to can look at the SWF spec and, if they choose, use that knowledge to create an alternative SWF player. (Gnash team I’m looking at you!) In my opinion, for those groups this is the next best thing to Flash Player itself being open-sourced (and maybe better, since that would put them out of a project). While this does have exactly the negative potential I mentioned above, it’s a big deal for device manufacturers. If they bet their future on Flash Player, they don’t want to be stuck if Adobe goes out of business or decides to throw away Flash to focus more on their PostScript printer driver business =) It’s a risk, and I’m crossing my fingers that we don’t get splintered Flash Players all over the place. As others have said, there are some benefits that hopefully outweigh the risks. Fortunately, Flash is a pretty big brand, and Adobe’s definitely not releasing their trademarks on Flash, Flash Player, etc. So anyone who makes an alternative SWF player will not be able to call it Flash anything. (Unless Adobe decides to create a certification program for alternative players or something like that — something which I didn’t see mentioned at all in the project pages.)

For Flash/Flex/AIR developers, honestly I don’t think this project opens any doors immediately, but I think it does have a lot of promise for the future. Currently, it’s pretty hard to create Flash content for a mobile device. You basically have to create a separate version for every device. Many of the devices have Flash Player burned on the ROM, so that player can never be upgraded. If you want to target one of those devices you’re stuck on Flash 4 (tell target lives forever!) When a new version of Flash Lite is released, it takes months before it is added to devices and those devices get into stores and users’ hands.

So a lot of this is about Adobe and other companies working together to make it so that you can use the same code, targeting a player with the same capabilities, no matter whether you’re creating content for a PC or a mobile device. For example, part of the plan is to create a set of “device porting layer APIs for Adobe Flash Player.” In the words of the FAQ, these are “device-specific abstractions of Adobe Flash Player that enable it to work on different operating systems and devices.” Another notable part of the plan is to make it so that the player can be updated just like it can on a PC. Goodness knows I often wish I could update the Flash Player on my Wii!

Plus, the fact that Adobe’s no longer restricting who can create SWF players, and no longer charging royalties to device manufacturers who include Flash Player in their devices, means it will be cheaper, easier, and safer for companies to include Flash Player on their devices, meaning a larger market for content.

Anyway, I was pretty surprised by all of this, and happy for the potential future growth that this could lead to. Adobe’s once again making a big bet, and the payoff will be great for all of us if it works out.

Since the majority of the time when someone’s using an Array in ActionScript, they really want all the elements to be the same type anyway, this is a really great addition and I think it will be used heavily. The Vector class allows (requires) you to specify the type it will contain at compile time — both for variable declarations and when creating instances. In both cases the syntax you use is a “type parameter” suffix .<T>:

var names:Vector.<String> = new Vector.<String>();

The type parameter syntax is part of a separate EcmaScript 4th edition proposal. Sadly they couldn’t make the syntax identical to that for generics in C# (and I believe Java does it the same way), which is almost the same but without the initial . (period). (For an interesting read, take a look at the history of the various options the committee members considered for representing type parameters.)

Anyway, because you specify the type at compile time, the idea is that the compiler can do the type checking for you for adding and getting elements from a Vector instance. In addition, since using Array (and the runtime type checking and type casting that array access involves) has always been a bottleneck in ActionScript performance, I expect that performance improvements can be expected. (Okay, I’ve heard anecdotal reports around the office of much better performance for Vector than for Array.)

Francis Cheng (who’s on the EcmaScript committee) has a couple of nice articles about the Vector class and type parameters, so I won’t bother recreating everything he’s written. Definitely worth a read (like everything he writes).

As an (almost) final note, I should point out that I haven’t seen anything indicating that type parameters will be generally available in “Astro” — just Matt’s announcement about the Vector class specifically.

And finally, on a personal note, I’m excited because I get to do the documentation for the Vector class. It’s always fun getting to write about new features that are personally valuable. And this is one that I’ve definitely been interested in for a while!

For some reason, the final time that I saved this post before publishing it, my changes didn’t get saved. So if you saw this soon after it was posted, and wondered why it didn’t really talk about SQL changes, and why it had some messed up headings…that’s why. Sadly I’m sure I can’t recreate the text as well as I wrote it the first time. But here’s my best effort…

First of all, allow me to clear something up. I am aware that Adobe AIR 1.0 shipped almost exactly a month ago, so this shouldn’t be news to anyone who’s actually interested in it. I intentionally held off on publishing my thoughts (and a description of changes since beta 3). As a rule, I never post anything in the week or so following a big product announcement — there are so many “me too” posts about the product, and so little actual different thoughts or original ideas, that I don’t want to clog up the aggregaters by adding to the hubbub (the “MXNA firehose” as I’ve heard JD describe it).

That’s not a complete excuse, of course. The truth is also that I’ve just gotten busy with a lot of post-launch cleanup activities, and of course moving ahead on future projects (Flash Player 10 and AIR 2.0), so I’ve neglected this post for longer than it deserved.

And now, lest I postpone it any longer, here are a few bits of news and opinion from my corner of the Flex/AIR world:

• Local SQL database changes
• What does “finished” really mean?
• Go right to the source

Local SQL database feature changes

Wait a minute — didn’t I say a couple of months ago that as of beta 3 AIR is API frozen? Indeed that was the intention, and with one small exception it’s true. And that was the first thing that came to my mind when I read the notification (shortly after beta 3 was locked down) that some changes to the SQL functionality had been checked in to source control. But I was correct before — the API hasn’t changed — just one particular behavior has.

The specific change is with how the runtime treats column data types in database tables. In betas 1-3, AIR was consistent with the “default” SQLite behavior:

the type of a value is associated with the value itself, not with the column or variable in which the value is stored…. All other SQL databases engines that we are aware of use the more restrictive system of static typing where the type is associated with the container, not the value.

In order to maximize compatibility between SQLite and other database engines, SQLite support [sic] the concept of “type affinity” on columns. The type affinity of a column is the recommended type for data stored in that column. The key here is that the type is recommended, not required. Any column can still store any type of data, in theory. It is just that some columns, given the choice, will prefer to use one storage class over another. The preferred storage class for a column is called its “affinity”.

So under the “affinity” system, if in your CREATE TABLE statement you specify that a column stores INTEGER data, and you write an INSERT statement that stores a String instance in that column, the runtime allows it. (I initially wrote “it works just fine” but that may not be true — since your application may be assuming that values retrieved from that column are always integers.) When I first read about this behavior when we were reviewing the spec for the feature, I recognized that it was different than what I’d done before, but I figured it was okay — I’d just have to be extra careful when inserting values into the database, and enforce the data types myself by convention even if the runtime didn’t enforce them in practice.

However, the feedback we got from developers was that this doesn’t really match what they’re used to from typical web app database code (which likely uses databases such as Oracle, SQL Server, or MySQL). As a result, in the final release, the declared data types of database columns are more strictly enforced. If you declare a data type for a column, then attempt to store a value that isn’t an instance of that type, the database will try to convert the value to the appropriate type (for example, turning a number into a string, or parsing a string to see if its text is actually a number). If the value can be converted, then the converted value is stored; otherwise, the runtime throws an error. (For more details, see the column affinity description in the documentation.)

Personally I’m pretty happy with this solution. It’s still a bit more flexible than the databases I mentioned before — usually they won’t even try to convert a value, and will just choke if the data type doesn’t match. But I think that the way it works in AIR 1.0 is consistent philosophically (and actually) with the way data types work in ActionScript 3.0 where values can be strongly typed or weakly typed at compile time, but either way at runtime the type must match.

So, what do you do if you were one of the people with more SQLite experience than other db experience, of who otherwise preferred the old behavior? Well, there is still a workaround. If you don’t declare any data type for your columns, you can store data of any type without causing errors. This isn’t the same as the previous behavior, but based on some anecdotal observations I’d guess that developers who intentionally mix data types in columns are less likely to declare a column data type, in any case.

Also, as a side note, I decided to keep the term “column affinity” in the documentation even though the behavior changed. I did this for a couple of reasons: 1) Developers who’d been reading the docs were probably familiar with the term now, and 2) the data types still aren’t strictly enforced, in the sense that the runtime attempts to convert values before storing them (just as a default SQLite implementation does). For example, just about anything can be stored in a TEXT column without an error occurring. So in that sense, the data type specified in a CREATE TABLE statement is still somewhat of an “affinity” rather than a traditional strictly enforced data type.

What does “finished” really mean?

Not too many years ago, my definition of a “release version” of software was different than it is now. I knew that any software, no matter how much it is tested, is bound to have some bugs in it — it’s just not possible to ship software of any notable size without making a mistake somewhere. However, I had enough faith in big software companies that I assumed that when a company declares a product to be a “release” or “shipping” version, that it at least doesn’t have any bugs that they know of.

I’m not sure when I realized that this view is far from reality. I suppose it was probably with the first private beta I was involved with, though maybe it was before that.

In any case, I hope I’m not shocking anyone’s sensibilities when I point out the reality, that even though Flex 3 and AIR 1.0 have shipped, they do have bugs — and Adobe even knows it! The recent openness of Flex, in particular the introduction of the public Flex bugbase, makes this reality much more transparent. A quick search on the Flex SDK project, looking only at bugs (as opposed to feature requests), shows 309 “open”, “in progress”, “community”, or “new” issues. And that’s not even taking into account “deferred” bugs, such as SDK-14339 “WindowedApplication doesn’t update/show menu when it changes during runtime”.

While Adobe AIR doesn’t have a public bugbase, that doesn’t mean it’s any more free of bugs. Try calling the NativeMenu.display() method on a PowerPC Mac running OS X 10.4 and you’ll see what I mean (hint: the menu appears at the mouse cursor rather than at the specified coordinates).

So what does “release quality” software really mean? Well, it means that it doesn’t have any bugs that are “showstopper” issues, or that are “really bad.” Yes, I’m intentionally using non-specific terms here. The reality of life is that if Adobe (or any software company) waited to release software until all known bugs are fixed, the software would never get released. So instead, they use a process that’s sort of like this (I’m generalizing and also stating this based on my own observations, not on any review of actual process or guidelines within Adobe):

1. The decision makers figure out a date by which the software should be done. (I’m not talking about at the beginning of a product cycle — I’m starting somewhere in the middle.)
2. Throughout the process, bugs are reported. Any time a bug is reported, it is investigated and a decision is made as to whether resources can/should be allocated to fixing it. The criteria for this decision are generally based on how severe the bug is (whether it crashes the software/computer, causes data loss, is a usability issue, etc); how hard it is to fix; how much time it will take to fix; how likely it is that someone will run into the bug; whether or not there’s a workaround; etc.
3. As the product moves closer to the release date, the threshold for whether a bug will be fixed goes up — the closer the software is to the release date, the more severe and less difficult to fix a bug must be in order for it to get fixed.

This can be frustrating for people who file bugs, like me. Often, due to workload and general stability issues, it’s not practical for me to start writing the documentation for a feature until it’s fairly stable and close to finished. But that means that when I do find bugs, there’s a good chance it’s too late in the process for the bug to get fixed in time for the product release.

Ah, tradeoffs.

Go right to the source

Now that Flex 3 has shipped, the Flex 3 source code is available in the Flex Subversion (SVN) repository. I’ve actually been accessing it there for a while — internally we made the switch from Perforce to Subversion around the first of the year. I was pretty worried at the time, because I had never used SVN before. The majority of the Flex 3 work was already done at that point — they were just in final bug fixing mode. We still had about a week before our content had to be locked down, so I was working furiously to try and finish up some work I was doing on the Flex AIR components. I wasn’t too excited about the prospect of switching source control systems in the middle of that crunch. Fortunately, SVN turned out to be pretty straightforward. (In case you’re wondering, I use TortoiseSVN). It’s actually been good for me to learn SVN at work — it made it easier for me to move some of my code projects over to Google Code (a few that are already there, and a few more that I’ve started but not posted on my projects page yet). So overall I give SVN thumbs up, and I’m happy that the Flex source code is available that way.

If you’ve been following my posts on AIR and the SQL database functionality, you may have noticed a trend: every time there’s a new beta, I tend to go silent for a few weeks beforehand as I try to get things finished up with the documentation. Well, here we went again — another period of silence, another AIR beta.

The marketing team kept things pretty low-key with announcing this new beta, especially compared to previous rounds. I’m not sure of all the reasons for that, but there are a few that are important and helpful for you to know if you’re developing AIR applications:

• AIR is now API-frozen — as of this beta, there shouldn’t be any changes to the AIR apis. In fact, the goal was to have as few API changes as possible between AIR beta 2 and AIR beta 3, as things get closer to being locked down. Naturally, if we find a big security issue that requires us to change an API, we’re going to consider it — but aside from that, things are now the way they will be for AIR 1.0 (phew — it’s been tiring for me to update apps every beta, and I’m sure it has been for you, too).
• Along with the new AIR beta, Adobe also released a beta of a new product code-named “BlazeDS”. This very cool offering is a free, open-source, slimmed down LiveCycle Data Services — basically it includes the RPC Components (“Flash Remoting”) functionality as well as the Messaging functionality. In addition, we’re releasing an official specification for the AMF format. While the format was (for the most part) reverse-engineered long ago, I think it’s great to have something official for all the other open-source offerings like AMFPHP, Fluorine, etc. to work from.
• Along with beta 3, Adobe created the “Adobe AIR Marketplace” where developers can post apps for people to download and try out — basically an extension of the
• Flex 3 beta 3 is officially the last Flex 3 beta before Flex 3/AIR 1.0 (second paragraph, also in the FAQ PDF). ‘nuff said =)

Of course, following the trend of my going silent before each beta, you can expect that to be magnified as we continue leading up to AIR 1.0. There have been a few things each beta that I wanted to do but had to put off until later — but of course, this time there isn’t any “until later” — so it’s now or never!

Talking specifically about the local SQL database functionality, there were only a few changes this beta, but they’re pretty significant and maybe even a bit sneaky so you’ll want to pay attention to them:

• Specifying synchronous and asynchronous execution: Synchronous database execution was added to SQLConnection in beta 2. At that point, to specify that a SQLConnection’s operations were synchronous rather than asynchronous, you had to specify a true parameter in the SQLConnection() constructor. Now, however, the SQLConnection() constructor doesn’t accept any parameters. Instead, you specify the execution mode when you open the connection to the main database. To specify that you want to use synchronous execution, you call the SQLConnection.open() method; to specify async execution, you call the new SQLConnection.openAsync() method.

  The most important thing to note surrounding this change is this: if you’re migrating an app from beta 2 to beta 3, you may be changing the behavior of your app without even realizing it! If you want a connection to be synchronous, you’ll know you have to change things because the code won’t compile (SQLConnection() no longer accepts a parameter). However, if you want you connection to be asynchronous, then if you don’t change anything the code will still work but it will actually use synchronous rather than asynchronous execution. If you have a long-running query and it’s freezing the UI now, that’s probably the reason — the exact code you used previously to specify asynchronous execution (no SQLConnection() parameter, and open() to connect the db) now is the way to specify synchronous execution. If your code doesn’t cause any errors, you might not even notice immediately because the SQLConnection and SQLStatement events are still triggered even in synchronous execution — so your “success” event listeners will still get called (but error listeners won’t — the operations will throw exceptions instead).

• There were a couple of changes to the SQLError class and related classes: The SQLError.code property was removed (because it already inherited errorID from Error) and the details property was added, providing a more detailed error message in certain cases. Along with this, the SQLErrorCode class was removed entirely (tragically — I spent a fair amount of time hammering out those error descriptions with Jason, the engineer for the feature).

I think that’s it, but please let me know if I’ve forgotten another change!

In the mean time, In addition to the SQL database stuff I’ve been doing more with another part of AIR that I’ve previously been working on as I’ve had time — the AIR-related Flex components. This release includes a new one, the FlexNativeMenu component, which is pretty slick. Watch for more on this in the (hopefully near) future!

If you attended the North America MAX 2007 conference or tried to keep up with the news that was pouring out, you probably know that in the day 1 keynote address Emmy Huang and Justin Everett-Church demoed three new features of “Astro” (the “next version” of Flash Player):

• An improved text engine, allowing new capabilities like bi-directional text, re-flowing column text fields, and more.
• The ability to create custom graphic filters, rather than being limited to the built-in set in ActionScript.
• “Postcards in space” 3D transformations that can be applied to display objects to position/rotate them in 3D space.

I think there’s something funny about these three features and the way they’ve chosen to implement them. I didn’t really notice it when I first watched the demo video (no, I wasn’t at MAX), but later it jumped out at me as I was reading some of the responses to the demo in the PaperVision 3D email list, and even more so as I listened to the video interview that Lee Brimelow did with Justin Everett-Church later during MAX, in which Justin clarifies and expands on the three Flash Player features that were described. If you don’t want to jump away to watch the video (although it’s really good for understanding the new features) here’s a transcript of the most important statements Justin makes relating to my idea:

(:29) Justin: “[Astro’s ‘3D effects’ and PaperVision 3D] are kind of fairly different from each other…3D effects is kind of ‘3D for the rest of us’. If you wanted to try and use the 3D effects to do more complicated things there may be some APIs that might help you but you know PaperVision’s an excellent solution, you’re just not going to replace one with the other, they’re going after different objectives.”

(2:40) Lee: “There was a lot [of buzz] around filters and the ability to create your own filters, and we heard ‘Hydra’ mentioned. So what exactly is it? Is it a new programming language?”

Justin: “So Hydra is a new language, it’s a pixel shader language. The Hydra language itself is very consistent with other pixel shader languages…the port between [Hydra and other pixel shader languages] is really easy.”

(4:10) Justin: “So our new text layout engine is really a group of hooks in the Flash Player that are lower level than we’ve ever had before. On top of that we’re building a series of components so they will do things like multi-column flow, inline HTML, bidirectional text, ligatures, lots of complex [?] sorts of things. But those components are developed in ActionScript 3.0 and will be deployed as part of your application. The hooks that are there are going to be exposed to developers so if you want to build your own component, if what we do isn’t exactly suiting your needs then you’ll be able to build a first-class text control.”

Notice that, based on the way Justin describes it, the idea for the improved text engine is that the actual functionality provided by Flash Player/ActionScript is very low-level, and Adobe provides components that give the higher level functionality we expect from a standard text field object (as well as additional enhanced versions).

Think about that for a moment.

Imagine if the flash.text.TextField class, the display object that’s used any time text is displayed in an ActionScript app, were actually a component on top of some lower-level API — and non-Adobe developers could freely write their own version of the TextField class, using those same low-level APIs.

By the same token, imagine if the built-in filters (the flash.filters.* classes) were actually “components” or library classes written on top of some lower-level API. (In fact, I think that’s how lots of developers see them, especially since they all derive from the flash.filters.BitmapFilter base class — with the notable issue that developers can’t create their own BitmapFilter subclasses and use them in ActionScript.) So imagine if you were allowed to create your own BitmapFilter subclass, and Flash Player would use it along with any of the Adobe-provided filters.

Yes, obviously the low-level aspect of the filters involves writing them in Hydra, not in ActionScript, and I really don’t have any idea how that’s all going to get hooked together. Just bear with me — I’m trying to describe big concepts here, not small details =)

Can you see what I’m getting at? That’s exactly what’s happening with two of the three new Flash Player features that were presented at MAX — Adobe is providing a low-level API, much lower than what most developers are going to need to use, and then they’re also providing components or libraries that will be the standard tool that most people will actually use. I think that’s an interesting approach, and one that the advanced developer community is going to really latch on to even while it doesn’t cause any pain or extra work for the typical developer.

However, compare that to the 3D (or 2.5D, as it’s often called) functionality that was shown at MAX. As Justin says, it’s intentionally a high-level API — 3D “for the rest of us” — compared to projects like PaperVision 3D that are working to provide full-fledged 3D modeling, textures, virtual world capabilities, etc. The PaperVision community isn’t so thrilled about this. Naturally they don’t think the player needs a high-level 3D API — they see PaperVision as providing the high-level API, and they’d much rather see the player provide new low-level APIs and/or improved processing power that allows them to do more, better with their higher-level APIs. (I’m paraphrasing and probably mis-describing this to some extent, since by I am by no means a 3D expert or even intermediate-level developer.)

As another aside, it occurs to me that the idea that Flash Player APIs are “high level functionality provided by the Flash Player team written in ActionScript” isn’t actually new. It’s a well-known fact that a notable amount of the Flash Player functionality is actually written in ActionScript and not in C++ or C or assembler code. In those cases the only difference between the built-in functionality and an external ActionScript library that you or I write is that the ActionScript code comes pre-installed in Flash Player and doesn’t have to be part of a SWF file download. An interesting historical note related to this is the history of the XML class (the old-school one that lives on as flash.xml.XMLDocument). The XML class was introduced in Flash Player 5, and in that release it was written entirely in ActionScript and consequently suffered from some speed issues in how it parsed XML. The ActionScript developer community (Branden Hall, I believe) wrote an alternative implementation known as XMLNitro that was faster than the built-in one. Back then in ActionScript 1, it was fairly straightforward to “redefine” methods of the built-in classes so that the player used your own ActionScript code instead, so that’s what many people did to get faster XML parsing. Funny, isn’t it, that with the newer constructs added in ActionScript 2.0 and ActionScript 3.0, we’ve also lost some functionality — namely the ability to overwrite built-in functionality with our own code. That was definitely a low-level capability that was previously available in Flash Player.

Interestingly, even in modern (i.e. post Adobe-Macromedia merger) history this idea of “low level APIs with higher-level components on top for normal use” isn’t completely new in “Astro”. One obvious precedent is the Flex framework; however, the example I’m thinking of is part of the Flash authoring tool. Historically Flash authoring was released simultaneously with new versions of Flash Player, and consequently there were always new authoring tool features that corresponded to new player features (obvious example: the filters and blend modes that were added in Flash 8 to Flash authoring as visual tools and to Flash Player as ActionScript APIs). Interestingly, however, in Flash CS3 there were some authoring tool features that were added that didn’t have a corresponding player API. Specifically I’m referring to the “copy motion as ActionScript” feature that allows you to select a tween sequence on the timeline and copy it “as ActionScript” — the animation becomes ActionScript code that you can paste somewhere and use to re-create the animation programmatically. What I think is notable about that authoring tool functionality is that the pasted code doesn’t work as-is via a player API — rather, it requires some external ActionScript libraries that were included with Flash CS3 (the fl.motion.* and fl.transitions.* packages). So the functionality underlying that feature of Flash CS3, one of the headline features of the product (created by none other than Robert Penner), was completely independent of the core Flash Player APIs and was instead provided by an external library.

Think about it this way: the Flash authoring tool team wanted to include functionality that wasn’t provided in core Flash Player ActionScript. It was specifically a “high level” type of functionality — simple scripted animation. Other people have written their own APIs to do the same thing, using the ActionScript “low level” APIs (display object properties, enterFrame events, etc.) and the Flash authoring “high level” approach does the same thing — it provides a library of code to simplify a certain task, so that users can easily create the effects they want, within the limitations of the high level library. I see this as another existing example of this idea of core ActionScript providing low-level functionality, with third parties and also Adobe providing high-level functionality in the form of ActionScript libraries that build on top of that low-level functionality.

Now, going into the future, there is a new Flash Player feature that allows the player to cache certain Adobe-approved code libraries, so the user downloads them once and then they’ve got them for every future site they visit that uses the same library. We’ve heard that the Flex framework is going to be the first such “cacheable” library. However, if this feature had existed earlier it could obviously have been used for the ActionScript classes that are used to support the Flash CS3 simplified animation (“copy motion”) functionality. For that matter, the Flash CS3 UI components could be given the same treatment and be available as a cacheable library, although that might be less necessary by virtue of their “intentionally lightweight” design.

While I really can’t say for sure, it seems like it’s not a stretch that the new text components would be distributed this way, especially since, as Justin points out, “those components are developed in ActionScript 3.0 and will be deployed as part of your application.”

I think that, going into the future, this is a potential direction I can see Flash Player and ActionScript moving in:

• Flash Player/core ActionScript provides low-level APIs
• Adobe provides components or libraries written in ActionScript that provide high-level-enough (“medium-level”?) functionality such that most common use cases and functionality are provided for. Probably these components/libraries are external, player-cacheable code libraries rather than part of Flash Player itself.
• Third-party developers can likewise create their own components and libraries that either build on the Adobe-provided components/libraries or provide alternate implementations.

Of course, the obvious exception to this way of working is the new 3D effects, which are very high level and are essentially the end user functionality, rather than providing low-level building blocks on which Adobe and/or third party developers can build more robust libraries.

What do you think of this future? Does it sound good, or scary? I’d love to hear your thoughts on this one…

Disclaimer: While I am an Adobe employee, I actually had very little knowledge of these “Astro” features until watching the MAX keynote presentation. I had heard general descriptions of some of them, but certainly nothing like the level of detail that was given by Emmy and Justin in the keynote and follow-up interview. Likewise, since then I haven’t gotten any additional “insider” information about these or other future Flash Player features. Obviously some of what I say in this post is speculation about the future, and I readily admit that it is indeed speculation and nothing more — I don’t have insider knowledge on this, and I might be completely wrong about all of it. =)

If you’re interested in a summary of the talks, I’m afraid I didn’t do that. (But I highly recommend viewing the presentations:

• Grant Strake on moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes comparing various Flex application frameworks

What I’ve written here is primarily just thoughts that I wanted to save for myself; things that maybe I don’t think about as often as I should, or things I want to remember about the audience of Flex and other Adobe developer products. Because I’m interested in the developer community, much of the focus is on points about the developer community that I sometimes need to remind myself of.

Grant Straker

The first speaker was Grant Straker, talking about his company’s choice to use a homegrown framework, and eventual decision to migrate it to Cairngorm instead. His company (Straker Interactive) has a RAD product (“ZoomFlex,” I believe it’s called) that bundles ColdFusion and Flex to create apps quickly — you use wizards to define data structures, and the product generates database structure, backend ColdFusion, and front-end Flex code for apps using that data. (The idea is that developers then take those Flex files and customize the front-end forms, style the app, etc.)

Here are some interesting thoughts/points I picked up:

• Originally they chose not to use Cairngorm for the underlying framework for their generated code. The reason: while there are some developers who build big, fancy, complex enterprise apps, there’s also a group of developers who “just want to know what they need to know to get their job done” — which often means build basic CRUD apps as quickly and easily as possible (e.g. web-enabling existing databases, spreadsheets, etc.). This latter group was/is more in their target audience.
• Code can be written in different ways — they try to generate code so that it’s clear and obvious what it does, and so that it can be easily extended by developers of varying levels of experience (key: don’t assume a high level of experience).
• In retrospect, he wishes they had just stuck with Cairngorm in the beginning. Now, 1.5 years later, there’s a large community, examples, documentation, etc. making it easier for a less-experienced developer to learn enough Cairngorm that they can understand it and use it.
• I was really amazed by how much code they are able to generate for developers. I’ve read some things about code generation tools, but I’ve never tried them out (due to the organizations I’ve worked for, and perhaps due to my personality as a developer who likes to have “control” of the code). However, I’ve definitely seen the down side of that, which is that I end up writing a lot of redundant or very similar code (especially for data access and manipulation). The “alternative” approach certainly has some attractions…
• Part of what they include is a library of pre-built UI components. The process of migrating these components to Cairngorm has been challenging at times. One of the principles of many frameworks including Cairngorm is that the user interface code is separate from the “model” (the underlying data). However, some components by nature lend themselves to having knowledge of their underlying data (e.g. their video player component) so figuring out how to structure those components is complicated.

Luke Bayes and Ali Mills - Evaluating application frameworks for Flex

Luke and Ali came into this presentation with no background in any of the major frameworks (other than the Flex framework). This is good because they didn’t have any biases, but it means they may have some non-best-practices too.

This was a great talk, but there was a lot of info in a short time so again, I’m not going to bother trying to write detailed notes. I highly recommend watching the recording.

However, once again in this presentation (in particular in the discussion afterwards) some of the same ideas came up. Luke in particular expressed a reluctance to have a prescriptive framework, because he doesn’t want to be “told how to code.” That opinion resonated with most of the audience there — but at the same time, everyone also acknowledged that the audience at a user’s group presentation isn’t really an accurate representation of the broad Flex developer community (especially the even broader community of developers who are considering Flex or who will be Flex developers in the future). If the Flex community is going to continue to grow, and be more accessible to new developers, it would be very helpful to have some prescriptive application frameworks that give people a predefined, standard architecture within which they can build their app (in the same way that Flex’s components provide user interface elements and layout elements that give developers a big head-start in building an app, compared to straight ActionScript or Flash).

What is the “next frontier” of Flex developers? Is it the “VB developer”1 (the “behind-the-firewall” corporate developer). If so, then to support that group of developers we’re going to need prescriptive frameworks that are easy to get into (“accessible” in Luke and Ali’s terms), that do as much work for you as they can, but that still don’t get in the way as an app grows in complexity.

At the same time, more advanced Flex developers may not want such a framework, and they certainly aren’t going to want to have to carry along the “baggage” (meaning both prescriptive architecture imposed on them, and literal baggage in download size) that would come along with such a framework if they’re not using it.

Personally, I think that’s an extremely important point for both Adobe and third-party framework developers to keep in mind going into the future.

“VB Developer” is my name for a developer who works in a medium-large corporation or organization, perhaps coding apps for a group within that organization, who doesn’t really want to learn everything there is to know about Flex (or their language of choice), or become a “guru,” but rather just wants to build their app and make it work nicely, but do so as quickly and painlessly as possible. Yes, the name “VB developer” is rather dated, since at this stage in history most such developers are doing web-based apps, probably using ASP.NET or J2EE in a large, standardized org or perhaps PHP or Ruby in a smaller or more independent group.

Note: This post won’t make as much sense unless you read Tim’s post first. So I’ll pause for a moment while you go read it — don’t worry, it’s not nearly as long as this one =)

As suggested by John Dowdell in the comments on Tim’s post, the biggest reason why SQLite isn’t mentioned by name in the documentation is a somewhat complex matter involving the timing of when the feature was developed, deadlines for when the documentation had to be done in order to include it in the beta release, and the timing of when Google Gears was announced.

Background: Development schedules, marketing announcements, and the realities of human limits

If you don’t mind, I’ll start off with a bit of background/context on the timing of the local SQL database feature being developed and the agreement with Google.

Note: Admittedly I’m making educated guesses on the timing described here, based on things I observed but without actually being involved in the conversations between Adobe and Google.

Before any sort of agreement about synchronized APIs and common code had been reached, perhaps before it had even started, Adobe, and presumably Google, had both separately developed most of their respective implementations of database functionality based on SQLite. Naturally, at the point that they agreed to make their APIs agree with each other, both companies could have chosen to postpone releasing their implementations until the final, synchronized API was finished. Not surprisingly, both companies felt it was more important to get something out to developers sooner (even if it wasn’t the “synchronized API”) rather than later when things were final. From a public visibility perspective, Google made their announcement first, so they have the benefit of being perceived as the “original” and I expect many developers expected the AIR API to be identical when it was released (about a week and a half later, it’s important to note).

I wasn’t involved in any of the planning or discussion surrounding the AIR-Google Gears “synchronized API” decision, and in fact I didn’t know anything about it until I read the public announcements. (If you can, imagine my reaction when I read that the APIs were going to be aligned — since I had just finished the API reference documentation the previous week! =) The fact that I wasn’t involved in the conversations doesn’t bother me and makes sense to me — there wasn’t really any compelling reason why I should have been involved in those conversations — but obviously that had a direct impact on my ability to anticipate the consequences of that announcement while I was writing the documentation. By the time the announcement was made, it was too late to go back and change the documentation, and definitely too late for us to actually change the API.

With that background, let me address some of the specific points that Tim raises. He asks the question, “why doesn’t Adobe’s AIR dev guide mention SQLite?”, and gives three points about why he isn’t pleased that SQLite isn’t mentioned:

1. “It stinks”

Of course, what I’ve said up to this point suggests that, were it not for the Google Gears announcements, Adobe might not have ever announced that we are using SQLite. I can’t speak for alternative futures, of course, but I think it’s possible that Adobe would never have mentioned SQLite in the documentation. Does that “stink” as Tim suggests? Is it discourteous? I can definitely understand the sentiment behind those expressions. I’m a firm believer in “credit where it’s due.” When I wrote the documentation, I certainly didn’t mean it as a discourtesy or to minimize my opinion of the value of SQLite that SQLite was not mentioned. I think SQLite is a great tool, and I’m very glad it exists, and that the authors have been so generous with the license.

On the other had, as Tim notes, Adobe has no legal obligation to acknowledge that they included source code from SQLite. Nor does Adobe have any obligation to acknowledge that a significant part of the documentation on the SQL dialect was adapted from the SQLite documentation, because the authors were even kind enough to secure public domain releases for the documentation — although I will readily admit that I did in fact adapt portions of the SQLite documentation — which was very helpful because it saved me a lot of duplicate effort!

So, were we intentionally trying to hide the fact that it was SQLite? No, although we chose not to advertise the fact either, for a few reasons:

• Our intention was to provide sufficient documentation so that a developer wouldn’t have any need to look at the SQLite documentation. (In fact, due to the short time frame for getting things done, one idea that was considered and rejected was just to point developers to the SQLite documentation for the first beta release.) With that decision made, we realized that there wasn’t any absolute need to make reference to SQLite.
• In many respects, the choice of SQLite was originally considered to be an “implementation detail” — something that developers didn’t really need to know or care about. Obviously in the wake of the Google Gears announcements, there is now more reason why it does matter (to some developers) that Adobe chose to use SQLite.

• In fact, when you get down to it, the choice of SQLite could still be considered an “implementation detail.” After all, consider what happens in the future when AIR version 5 or 10 is released. What if SQLite is no longer the best choice for an embedded database? Should AIR developers be limited by the fact that AIR is absolutely tied to SQLite? As long as the API continues to work, and the older file-format databases are supported, and older applications continue to run, how much does it matter whether the embedded database is SQLite or something else?

  Obviously that’s not a highly likely scenario. From a practical standpoint, even if another database engine were used, it would be pretty involved to ensure backwards compatibility, both with the API and especially with the supported SQL dialect.

In summary, when the time came to decide whether to explicitly mention SQLite in the documentation, it came down to this. As we all know, it’s common practice in the software industry, including at Adobe, that when a certain aspect of a feature is considered an “implementation detail” and “not important to developers,” that aspect of the feature isn’t described in the documentation. Sometimes developers find out anyway, either through their own experimentation, or through experience, or whatever. Even if Adobe didn’t announce that the AIR local database engine was based on SQLite, it’s highly likely that it would have come out sooner rather than later. That’s fine — developers can choose to use the knowledge they acquire, and Adobe can choose to change things that aren’t documented.

As I’ve said, at the time the documentation was being written and finalized, the word I was going on was that the fact that the engine uses SQLite is an implementation detail. I gave some thought to whether we should explicitly mention that the database uses SQLite — certainly there were advantages and disadvantages either way. The issue was discussed by me, members of management, and the lead engineer for the feature. In the end, however, for the reasons listed above, and without any knowledge (at least on my part) of the very-soon-to-be-forthcoming Google Gears alignment announcement, we decided that the priorities fell on the side of not stating that the database uses SQLite.

Having said all that, as a result of the announcements relating to Adobe AIR and Google Gears, it is public knowledge that Adobe is using SQLite. Although it may not make sense to anyone but me, that announcement “changes the balance” of priorities in my mind, so in fact at this point I agree with Tim that the benefits of mentioning in the documentation that the database uses SQLite (giving credit where it’s due, and guiding developers to other SQLite tools that might help them) outweigh the potential downsides of stating it in the documentation (the unlikely but can’t-rule-it-out-completely possible future case in which we no longer use SQLite for the underlying database engine, and the possibility of distracting/confusing developers who read the SQLite documentation and find something that’s not supported in AIR and wonder why).

Even as I write this, I acknowledge that my stated set of reasons, and this description of trying to find the best balance between the tradeoffs of “officially” disclosing information versus “officially” keeping information “undocumented” sounds very fuzzy. And I agree that the value of giving credit to the authors of SQLite is a compelling reason for stating in the documentation that AIR uses SQLite. I’m afraid I can’t completely communicate how fast and furiously we were working to get this feature (and the associated documentation) done for the beta, and consequently how we tried to make the best choices we could in a limited time frame. And again, without the smallest clue of the then-forthcoming Google Gears announcement.

Fortunately, as Tim points out, “this is all beta, of course, so it can change.” So, Tim, allow me to tell you that your feedback has helped us to realize that the value of giving credit to the authors of SQLite outweighs any potential drawbacks, and I will shortly be adding explicit mention of the fact that the runtime uses SQLite for its local SQL database functionality. A week ago I asked for feedback on the SQL documentation, and while this wasn’t exactly what I had in mind, it is nonetheless appreciated and hopefully it’s clear that it has been taken into consideration.

2. “It’s unhelpful”

Tim makes the suggestion that it would be helpful to “set out exactly how AIR’s SQLite differs from the standard build.” I think that sounds like a useful suggestion; I’ve made a note to research the topic and see how difficult it would be to compile that information, and how we could usefully incorporate it into the documentation. I admit that the thought didn’t even occur to me (which doesn’t surprise me — I have some good ideas sometimes, but I certainly don’t ever have all the good ideas =).

Although I acknowledge that it sounds like an idea with merit, the devil’s advocate in me impels me to admit that specifying how AIR’s SQLite implementation is different from other SQLite implementations isn’t as much of a priority as some of the other tasks that I’ve got in the lineup. It turns out that there were several things that I wanted to write, and we just didn’t have time to get them all in for the beta release. Since the SQLite library is designed for use as an embedded database, and the target audience (developer-wise) for AIR is developers with web development experience, chances are the majority of the target audience for AIR hasn’t ever programmed for SQLite. That means that documentation comparing AIR’s implementation to other implementations will probably only be useful for a minority of AIR developers — which unfortunately is something that we have to take into account when we’re scheduling the “features” that are chosen to be included in the documentation.

Nevertheless, I do think that it’s a good suggestion, and in some ways I think that it will be useful to more advanced developers whether they’ve used SQLite or not, so I’ll see what I can do.

3. Skepticism that the AIR and Google Gears APIs will align

Hopefully my earlier background information has made it clear that the reason the APIs don’t align right now is really a matter of scheduling, engineering effort, design effort, and a desire on the part of both companies to get their technologies into the hands of developers, and not any sort of conspiracy. I will say that I know for certain that the effort to align the APIs is still going on.

“A big hole in the AIR sandbox”

Tim makes a side note at this point, that the difference between the AIR approach to SQLite and the Google Gears approach has some security implications. This is an important point, so I’ve written a separate post in which I’ve discussed why the two systems use different models, and how to address some of the potential security issues.

Summary: Tim’s wish list

Going back to Tim, he concludes with a “wish list” of three things he’d like to see happen in the AIR documentation and implementation:

• Proper credit for SQLite in the docs.
• Use the Gears code - full text search could be very useful - and deliver on the promise of aligning the API.
• Failing that, set out exactly how AIR’s SQLite differs from the standard build.

I’ll consider these one at a time:

Proper credit for SQLite in the docs

As Tim and I have both mentioned, SQLite is in the public domain, so in fact from a legal definition Adobe is already giving “proper credit” (that is, no credit required) for SQLite. I’m certain that’s not what Tim had in mind, and I’ve also mentioned that I believe it’s worthwhile to give credit to the authors of SQLite. As I’ve also said, I’m planning to add in at least a couple of prominent places a statement that AIR uses SQLite for its database functionality. If that’s not what you had in mind, Tim, please let me know.

Use the Gears code - full text search could be very useful - and deliver on the promise of aligning the API.

I’m 100% certain Adobe is not going to “use the [Google] Gears code,” at least not wholesale — the two products have already been developed in isolation much too much for that to work (in my opinion — but of course I’m not the engineer). Nevertheless, I agree that full text search could be very useful — I would love to see it make it in to AIR as well — and as I’ve said here and also last week, Adobe and Google are continuing to work on aligning their database APIs.

Failing that, set out exactly how AIR’s SQLite differs from the standard build.

This statement is actually a bit misleading, I think, since I’m certain Google Gears doesn’t use a 100% “standard”, out of the box SQLite build. (For that matter, I’m not sure what a “standard” SQLite build would be, since the whole point of SQLite is to be an embedded database, built into another product, and not to stand on its own.)

All that notwithstanding, as I’ve mentioned I have now assigned myself the task of researching the changes that we’ve made from what someone who’s used SQLite in another product might expect, and (time permitting) to add a section to the documentation describing those differences.

Conclusion

I realize this whole post is long, and meanders quite a bit, and probably doesn’t show the degree of concrete explanation (or completely serious consideration) that might be desirable. I believe that we made the decisions we made for good reasons, using the information we had available at the time. I’m also glad that we’ve only released a beta and not the final version yet, and I’m glad that Tim’s post caused me and others in Adobe to sit up and take notice, and reconsider some of our decisions in light of the new information that’s become available since the time when we previously made them.

And once again, if anyone has thoughts or suggestions about the AIR local SQL database documentation, please don’t hesitate to share them. I’ll try not to post an essay in response to each one =)

Book summary

This book obviously covers ActionScript 3.0, the (as of this writing) most current version of ActionScript. ActionScript 3.0 is used in Adobe Flex, including Adobe’s Flex Builder tool; it is also the language used in the not-yet-but-soon-to-be-released Adobe Flash CS3 (a.k.a. “Blaze” or version 9). However, since the book was written primarily while Flex was in beta, and Flash was not even released as a public alpha, all the recipes that involve the IDE refer specifically to Flex Builder. The book is written and organized in the O’Reilly “cookbook” format, where each chapter includes several “recipes” written as a problem, a solution to the problem, and a discussion/explanation of the solution. I think of books like this as “task-based reference” books — they’re meant to be used like a reference, that you can look up something you want when you need it — but they show how to accomplish a particular task rather than showing how to use a particular language element. That way, if you know you want to do something in particular (e.g. “simulate rolling dice in ActionScript”) but don’t know which methods or properties you would use to accomplish the task, you can just look it up in the book and it will tell you.

What I liked best

There are several aspects of this book that offer a lot of value. The ones which stood out most to me are:

Coverage of specific use cases and more advanced functionality

Some parts of ActionScript 3.0 have very obvious uses—the DropShadowFilter class, for example, has a pretty obvious use. However, there are several aspects of the language (such as the Bitmap class, the ByteArray class, the DisplacementMap filter, the ConvolutionFilter, etc.) that provide very “open-ended” functionality. There are lots of different things you can do with them, but you have to know what they are and understand some particular programming topic (like graphics manipulation or working with byte data) in order to make use of them. This book describes how to perform some of the tasks that can be performed using these “open-ended” classes. This, in my opinion, is the perfect use of the cookbook format.

In the topics where it shines, this book really shines. I was very impressed with the sophistication of many of the topics that are covered (for example, topic 4.10 “Cards”).

Supplemental code library

The book has a significant library of supplemental code (available as a free download). Several of the recipes use the code in this library to accomplish their tasks. For example, the solution to the recipe “Simulating Dice” is to “use the NumberUtilities.random() method [from the supplemental code library] to generate random numbers in the desired range.” In truth I can see plusses and minuses to this approach. It definitely saves time for the reader — if you’re on a deadline and trying to build that Dungeons & Dragons simulator then having the code already written is a big benefit. It also saves pages in the book, and avoids the need for in-depth explanations (and nearly-redundant explanations, such as those for “Simulating a coin toss” and “Simulating dice”) since all the book needs is a few lines demonstrating how to call the method in the supplemental code. However, if you’re the reader who wants to learn more, or to understand the principles behind the solution as well as the code needed to carry out those principles, you’re left feeling pretty empty. I think one possible compromise (which isn’t done) might be to have a more in-depth explanation for such sections, perhaps showing a few relevent lines of code extracted from the code library, demonstrating how the code library works and how you might adapt it or build your own similar solution.

Breadth of topic coverage

The ActionScript 3.0 documentation that comes with Flex 2 includes two main parts: the reference documentation, and a book called “Programming ActionScript 3.0.” However, due to various factors there are several topics that aren’t covered in “Programming ActionScript 3.0” in the Flex 2 release. These include topics such as working with TextField objects, filters, and bitmap manipulation, among others. The “ActionScript 3.0 Cookbook” can help to fill in these gaps because it does provide coverage of some of those “missing” topics. Admittedly, one of the reasons those topics aren’t covered in the Flex 2 documentation is because they are largely irrelevent for a Flex-only application—for example, in Flex you use the TextArea component or TextInput component to display text, rather than just a TextField component. In any case, they do get some coverage in the “ActionScript 3.0 Cookbook.” As a side note, several new chapters are being added to “Programming ActionScript 3.0,” to be released with the next version of Flash, covering many of these parts of ActionScript that aren’t commonly used in Flex, such as text fields, movie clips, more on display programming, video, sound, filters, and so on.

Room for improvement

As you may have gathered from the previous section, one way I judge a computer book is how well it supplements the manufacturer-provided documentation rather than just rehashing the same material (see disclaimer). I also think it’s important for a book to be consistent to its purpose. If it’s supposed to be a reference, it should just be a reference. If it’s supposed to be an instructional book written as a series of lessons, it should stick to that format. With a topic like ActionScript there’s no way a single book can be all these things, so I think it’s important for the book to stick to what it does best, and let other books fill in other roles.

As the preceding paragraph implies, I have some disagreements with this book in terms of its overlap with the ActionScript 3.0 documentation and its consistency with its stated goal of being a “cookbook.”

Too much redundancy with the official documentation

The question I kept asking myself as I was reading through this book is “what is a cookbook, really?” In my mind, a “cookbook” is a book whose topics are more “edgy” or involved than what you might find in the core documentation. It should cover how to accomplish specific tasks that aren’t easily figured out and aren’t found elsewhere (again, especially not in the main documentation). It should also include “hacks” or workarounds to accomplishing things that aren’t readily available using the built-in functionality of the language. After all, I can learn (for example) the syntax for writing a class or the syntax for adding a display object to the screen by reading the built-in documentation, so why would I need to buy a cookbook to tell me how? On the other hand, the built-in documentation doesn’t (and likely will never) tell me how to do more specific implementation tasks, like “simulating rolling dice” or “creating a graphical texture,” but they’re common enough programming problems that those are topics I’d expect to find in a cookbook.

Admittedly, when I first started working with ActionScript 3.0, one of the first thoughts that came to me was “I wonder what they’re going to put in the ActionScript Cookbook.” ActionScript 3.0 by itself is a big improvement over the previous version, and many of the things that used to require workarounds are really straightforward now — so I wondered what they’d do to replace all of those topics in the book. Unfortunately it looks like they didn’t do anything to replace them.

As I mentioned in the “good” section, there are lots of topics covered in this book that fit squarely in what I consider to be an appropriate cookbook topic. But there are also plenty of topics that I think should have been left in the built-in documentation rather than needing to repeat them in the ActionScript 3.0 Cookbook. Some key examples are topics related to basic syntax. For example, “Creating a Custom Class” and its related topics “Creating Properties that Behave as Methods,” “Creating Static Methods,” “Creating Subclasses,” etc. All of these topics are covered in the built-in documentation, both in a basic form and in greater depth than this book can afford. In addition, these aren’t topics that a person is going to need to look up frequently. Chances are, a person who’s new to ActionScript or who’s been using it for a while and wants to “move up” to using custom classes will need that information. However, once a person has created a handfull of custom classes, they’re not going to need to look up the syntax in the book any more—they’ll already know it or else they’ll just look at a class they created, etc. So there’s little benefit to that content being provided in this book.

Too much discussion on some topics

This is related to the previous criticism. For example, I said that I thought it was redundant for the ActionScript 3.0 Cookbook to have a recipe for “Creating a Custom Class” since that topic is covered in detail in the in-product documentation. However, suppose the publisher wants to fill up the topic list. Or suppose a person who’s “moving up” to creating custom classes has read the chapter on creating a custom class in Programming ActionScript 3.0, and has a decent understanding of the concepts, but just can’t remember the syntax. I admit that there could be some value in having a quick reference place to turn to to find the syntax for creating a custom class. However, at that point the person doesn’t want to read through four pages of explanation about creating a custom class — they just want to see the recipe solution and copy it into their own code. Unfortunately, this book could do that, but it doesn’t. Rather than just give a nice model of a custom class, it spends four pages talking about it. The section on display programming is even more bulky — while they might justifiably have had several one-page-or-less-each recipes on things like “adding a display object to the display list,” “removing an object from the display list,” “reordering objects on the display list,” etc., the book spends 14 pages talking about what the display list is and how it works. That’s nice, but it’s not the point of this book in my opinion. The built-in documentation has even more thorough, detailed explanations about what the display list is, what types of objects can be used, etc. If the cookbook wants to do its readers a service, it should trim that fat, which would make it easier to find the specific method name or syntax — a quick resource to turn to for those “I know I’ve seen this before but I can’t quite remember how to do it” sorts of questions.

Conclusion

In summary, I have mixed feelings about this book. When it’s good, it really shines—the sections that go into more depth or into a more advanced topic than Adobe’s ActionScript 3.0 documentation are really valuable. However, a significant part of the book is redundant with the documentation, doesn’t cover it in as much detail as the built-in documentation, but covers it in so much detail that the benefits of the “cookbook” format are lost.

Book details

• Title: ActionScript 3.0 Cookbook (On Amazon.com) (Publisher’s page)
• Authors: Joey Lott, Darron Schall, and Keith Peters
• Publisher: O’Reilly
• Copyright year: 2007
• ISBN 10: 0-596-52695-4
• ISBN 13: 978-0-596-52695-5

Disclaimers

1. As a contract employee, I helped write the Flex 2 ActionScript documentation, including one chapter and parts of other chapters in “Programming ActionScript 3.0” as well as a handful of samples for the ActionScript language reference. I now work as a full-time employee for Adobe, and one of my current roles is as lead writer of “Programming ActionScript 3.0” for the Flash version 9 release—so I obviously I am not unbiased about the Adobe-provided ActionScript documentation.
2. I received this book at a heavily discounted price in exchange for writing this review. While it’s impossible to remove myself from that detail completely, I have tried my best to make this an unbiased review. Want to know how to get discounted books in exchange for making reviews? Contact your local Adobe Users’ Group.

Anyway, if you’re interested in this topic, the following links may be useful to you:

• A Slides (with lots of notes!) and example files/code (271 KB .zip)
• A recording of the presentation, in case you want to actually hear what I had to say =)

As always, feel free to add a comment or contact me if you have any questions or thoughts.

1. You are no longer allowed to use the private (or protected) access modifiers on class definitions.
2. You are no longer allowed to define multiple classes within a package block in a single .as file — essentially, a single .as file will have one public class, and the file’s name must match the class name — which makes it easier for the compiler to find classes, I imagine.

Point 1, no more private or protected classes, seems to be pretty concrete (i.e. it’s part of the ActionScript 3.0 syntax). Frankly I don’t really mind this — the notion of a private class doesn’t really make sense (if it’s private, no other class can access it, after all). In the example I wrote, I used the private modifier because the compiler required it, in order for me to keep all the classes in a single .as document. I think when I first wrote the example, with public alpha 1, I used inner classes (classes defined inside other classes), but inner classes were removed from the syntax before the public betas were released.

Interestingly, point 2, that you can’t have multiple classes defined in a package block in a .as file, seems to be a limitation of the Flex compiler (that is, mxmlc) rather than a part of the syntax of ActionScript. First of all, as many people figured out, you can still have multiple classes defined in a .as file — you can just only include one of them in the package block, and the others must be defined outside the package, and cannot have any access modifier specified. Because they’re defined outside the package, these special classes are available to any class defined in the .as file, including the public class defined in the package block, but are not accessible to any other class. So you can still abstract out certain functionality to other classes, as you might do with a private inner class, but there’s just a difference in where it’s defined.

However, as I said, the rule about only having one public class per package block is (at least from what I can tell) only a limitation of the Flex compiler, not a part of ActionScript 3 syntax. Using the Flash 9 Public Alpha’s compiler, you can define a .as file with multiple classes defined in a single package block, and it compiles and runs just fine. You also don’t have the restriction that class names must match file names, or that files must be in a folder structure corresponding to their package structure. In fact, you can even have multiple package blocks in a single .as file, as long as the packages all appear before any classes defined outside of packages (I’m not sure if that’s a bug or intentional behavior).

Here is a file that demonstrates all of the variations that I have tried so far. Put the contents of this first listing in an external .as file — from what I can tell, the file’s name must match the name of one of the public classes it contains (e.g. I called my file “PubClass.as”).

package test
{
	public class PubClass
	{
		public function PubClass()
		{
			trace("PubClass constructor");
			var myExternalClass:ExternalClass = new ExternalClass();
			var myOtherPubClass:OtherPubClass = new OtherPubClass();
			var myInternalClass:InternalClass = new InternalClass();
		}
	}

	public class OtherPubClass
	{
		public function OtherPubClass()
		{
			trace("OtherPubClass constructor");
		}
	}

	internal class InternalClass
	{
		public function InternalClass()
		{
			trace("InternalClass constructor");
		}
	}
}

package package2
{
	public class Package2PubClass
	{
		public function Package2PubClass()
		{
			trace("Package2PubClass Constructor");
		}
	}
}

class ExternalClass
{
	public function ExternalClass()
	{
		trace("ExternalClass Constructor");
	}
}

I then put this code in the Actions panel on frame 1 of a FLA, in the same folder as the .as file:

import test.PubClass;
import test.OtherPubClass;
import package2.Package2PubClass;

var myPubClass:PubClass = new PubClass();
var myOtherPubClass:OtherPubClass = new OtherPubClass();
var myPackage2PubClass:Package2PubClass = new Package2PubClass();

The result looks like this:

PubClass constructor
ExternalClass Constructor
OtherPubClass constructor
InternalClass constructor
OtherPubClass constructor
Package2PubClass Constructor

Again, note that this code won’t work when compiled with the Flex compiler (e.g. using Flex Builder or the Flex Framework SDK). This only works with the Flash 9 ActionScript 3 Preview Public Alpha.

And now, for my opinion of this whole business…

Truth be known, I’m pretty sure I’ll still write all my classes in separate .as files. Why? To keep compatibility with Flex, and because I personally think it’s a better organization scheme. True, it sometimes seems a little silly to make a new .as file for a very small class, but later if that class grows, or even if it doesn’t, and you’re trying to find it, it will be much easier if it’s in its own .as file, and in a folder structure corresponding to its package. However, I know there are some people who want to be able to write multiple classes in a single .as file, and for instructional examples like the ones in the article I mentioned earlier, it’s convenient to be able to define multiple classes in a single document, so you can put them all in a code listing and just write “copy and paste all this code” rather than needing instructions about which code to place in which .as document.

http://honeybrown.ca/Pubs/BumpTop.html

It goes to a page with links to videos of BumpTop, an experimental desktop UI — which I found interesting. However, what I found even more interesting was the selection of video format/player options, shown in this screen grab:

Notice the three available options: Windows Media, QuickTime, and … YouTube?

Don’t get me wrong; this certainly isn’t the first time I’ve heard of the YouTube video sharing service. However, it is the first time I’ve seen YouTube used as a media format option. (In case you don’t know, like Google Video, ABC, AOL, and others, YouTube uses Flash Video (.flv) as the format for its video files — there is no such thing as “YouTube” video format).

So, at the risk of sounding a little like John Dowdell, I was a little disappointed that credit for the video format (and the actual player requirements, for that matter) were going to YouTube rather than Flash Player.

As I pondered this, I had a thought I hadn’t had before. Perhaps in the case of web video, Flash Player’s ubiquity and customizability has been the reason that it’s the great secret among video players. Think about the typical web video experience, say for a movie trailer web site 2-3 years ago. You go to the movie web site, you click on the link for the trailer, and what do you see: a big list of links titled “choose your video player format: Windows Media, QuickTime, Real …)” Or even worse, the dreaded “missing plugin” dialog or the puzzle piece icon.

Compare that to the experience that most people have with YouTube, or Google video. You arrive at the page. The video works. It plays in a branded skin that blends in nicely with the page (well, assuming the designer did his/her job right). Unless you right-click, you have no idea that it’s Flash…and really, how many people are going to do that?

In terms of ubiquity and customizability, I’d say Flash Player as a video player is much less likely to be recognized, simply because the end user doesn’t need to be able to recognize it in order to use it — they don’t need to worry about whether they can make the video work, because it just does. So I guess what I’m starting to wonder is, is Flash Player a victim of its own success?

Book summary

This book is an in-depth look at the topic of scripted animation in ActionScript. By “scripted animation” I mean making objects move using ActionScript, as opposed to the traditional approach of creating animation using the Flash timeline. The primary focus of the book is on creating animation for simulating real-world physics: making things move; simulating bouncing, gravity, springing, and friction; creating objects you can “throw,” and so on. Finally, an additional section gives an introduction to basic 3-D concepts and techniques. Most of the well-known and engaging Flash content uses these techniques; although they are particularly geared towards use in games and physics simulations. Since this book focuses on a specific application of ActionScript, it is definitely not a basic book or an introduction to ActionScript in general — I think that a good understanding of ActionScript syntax is essential to understand this book.

What I liked best

This book is well-written in terms of the sequence and clarity of the examples. He starts out explaining the basic principles (mostly trigonometry formulas) which underly the different animation behaviors. For the most part this is done in a clear, easy to understand way, even if you haven’t studied math for several years (like me) — all his examples are of common uses of the formula in ActionScript, and he’s quick to point out which formulas you’ll use all the time and which ones you’ll use less frequently.

I found the way he ordered the content, and the examples within each section, to be particularly helpful. Most topics build on the previous one, with clear and obvious connections between them. After a few chapters I found myself “thinking like Keith Peters” — or at least that’s how I described it to myself. For instance, at one point he explains the principle of acceleration, and how to apply it, tying it back concretely to the earlier discussion on basic trig principles. A few sections later he introduces the topic of gravity, which, he points out, is really just a form of acceleration. This made the sections easy to follow, and very shortly I was reading explanations of how to create advanced effects that have wowed me for years, and I was not only understanding the code that creates the effect, but also the underlying principles behind the code. By the middle of the book, I even found myself predicting which basic principles could be used to create other advanced effects; something that made me realize that this book not only was teaching me the basic principles and several common effects, but more importantly, how to apply the principles to create other effects which aren’t necessarily explained in detail in the book.

Room for improvement

No book is perfect, of course, as any author will likely admit. These are the most noteworthy problems I found with this book. But let me say up front that I think the book is well-written enough and in-depth enough that it is worth owning in spite of these specific shortcomings.

Narrow example domain

I can’t complain too much about this one, but the examples both in code and in concepts in the book are almost entirely focused on creating video games in Flash. However, I think it’s much more common to use these techniques for other things like user interface effects, something which (as far as I remember) wasn’t even mentioned in the book. Admittedly, the video game and physics simulation examples are certainly more clear and obvious, but I think it would have been nice to at least have a few examples of things like an animated menu, a window that flies into view, or something from a different type of application other than video games.

Unnecessary basic concepts

In the introductory portions of the book, Keith faces the typical book-author dilemma of “what should I assume is the prior knowledge of the reader.” The book includes a couple of sections introducing basic ActionScript concepts such as functions and event handlers. However, I think those sections are ones he should have just left out completely — the quick summary treatment isn’t enough to really teach those concepts well if somebody doesn’t already have experience with them, and it’s just annoying filler for the reader who does already know what those things are. I think if anyone is to the point in their ActionScript experience where they are really ready for this book, they should already have a good grasp on functions and event handlers. Interestingly, he doesn’t explain other syntactic structures like loops and conditional statements at all.

ActionScript version confusion

One of the stated goals of the way the code is written is that “it will work in ActionScript 2.0, and with few or no changes it will work in ActionScript 1 also.” I disagree with this choice; I think at this point (two and a half years after the introduction of AS2, with ActionScript 3 already in the public eye) I don’t think there’s a very good reason to cater to the ActionScript 1 audience. Don’t get me wrong; I still see job postings which specify “knowledge of AS1” as a requirement, so I know it’s not obselete, but the differences are small enough (at least for the examples in this book) that I think it would have been better to just write the examples in pure AS2, and let people who need the code in AS1 work out the differences, especially since teaching AS1 isn’t a stated goal of the book.

Unfortunately what you get instead is that the code examples contain a mx of AS2 and AS1, without any real reason for doing so (other than, I assume, because that is the author’s personal style). For example, consider this (abbreviated) code listing from the book:

init();
function init():Void
{
	force = 0.5;
	vx = 0;
	vy = 0;
	.
	.
	.
}
function onEnterFrame():Void
{
	var dx:Number = _xmouse - arrow._x;
	var dy:Number = _ymouse - arrow._y;
	.
	.
	.
}

In this example, notice that the variables in the “onEnterFrame” function are explicitly declared (using the var statement) and given a data type (e.g. Number); this means they are declared as local variables to the function, and are not available outside the function. This is good ActionScript 2.0 practice. However, in the “init” function, the variables are used, but are not declared using the var statement and are not given a data type; they are just used, which dynamically creates them in the script — an AS1 practice which isn’t good practice in AS2. The reason they are used this way is because those variables need to be available to the whole script — not just within the “init” function. However, that isn’t clear from the code — I only know that because the book explicitly says so. The intention of the code could be made explicit, and the code made pure AS2, simply by declaring those variables outside of any function. In this case that would mean adding these three lines somewhere in the code (somewhere outside of a function declaration, that is; ideally right at the top where they’re plainly visible):

var force:Number;
var vx:Number;
var vy:Number;

This happens to be an issue that I’m really picky about, perhaps more so than other people. Nevertheless, I think it’s an important one, especially since if you try to move the code to ActionScript 3, it must follow the strict AS2 rules. This means that moving into the future the reader has to do the work of figuring out how to make the examples conform to AS3 syntax, where it could have been easy to make the code work for AS2 and AS3, a better goal in my opinion than making it work for AS1 and AS2.

Conclusion

Although the book has a few shortcomings (at least in my opinion) which will require the reader to have a solid grounding in ActionScript 2.0 syntax in order to make the best use of it, overall I think it is a very well-written, easy to understand and thorough guide to the subject of ActionScript animation. Considering it comes from a Flash developer who is one of the most well-known for this type of work, I think it is a great book to have if you are interested in learning more about that subject.

Book details

• Title: Foundation ActionScript Animation: Making Things Move
• Author: Keith Peters
• Publisher: Friends of ED
• Copyright year: 2006
• ISBN: 1-59059-518-1

Disclaimer: I received this book at a heavily discounted price in exchange for writing this review. While it’s impossible to remove myself from that detail completely, I have tried my best to make this an unbiased review. Want to know how to get book discounts for making reviews? Contact your local Macromedia Users’ Group.