Pursuit of Simplicity

A not uncommon complaint when developing for AIR is that asynchronous APIs--especially the filesystem and database APIs--are difficult to use. Why didn't we make all of these APIs synchronous? So you can write better applications.

In AIR, all ActionScript execution runs on the same thread that updates the display. If your code gets stuck for a long time doing something--like reading a file--then the display won't get redrawn until your code is done. Your application becomes unresponsive, which users hate.

To avoid this, use the async APIs. They schedule work on background threads and then notify you when it's done. They don't block the main thread, thus allowing your app to keep responding even while the work is being done. You'll get notified when the background work is done via an event.

Does this mean using the async APIs is easy? Absolutely not. In some cases, such as the filesystem API, we offer synchronous alternatives. These are a perfectly good choice if your confident that the amount of work you need to do is small and won't take long. But beware that this isn't as easy to determine as it might seem: even reading a small file can take a while if it happens to be read from a slow network drive.

You can't avoid using the async APIs forever, so I recommend also learning some techniques that make them easier to use. In upcoming posts I'll describe various techniques for accomplishing this, discuss their trade-offs, and share some code that I use to manage asynchronous operation with the runtime itself.

Posted by Oliver Goldman at 10:27 AM | Permalink

The AIR (né Apollo) beta release includes a number of great new features, including:

• Support for PDF
  
• Embedded SQLite
  
• Drag-and-drop
  
• Transparent HTML
  

...and more.

But I want to call attention to one of my favorite features: Install Badges. Yes, I'm biased because I worked on it. But if I didn't work on this stuff, this blog wouldn't be half so interesting, would it?

Install badges are SWFs which you can embed on a web page and which, when activated, trigger the seamless installation of your application. It works whether or not AIR itself is already installed; if it isn't, it'll be installed right along with your application in a single flow.

Want to see it in action? Browse to the AIR Sample Applications page and install away.

Wanted to make your own? Download the AIR SDK, which contains a sample badge in both compiled and source form.

Caveat: Embarrasingly, some debug code was left in the badge as it shipped in the beta SDK. (Well, it is a beta, after all.) So you may want to open the .fla just to remove that, even if you're not interested in further customization.

Posted by Oliver Goldman at 10:52 AM | Permalink | Comments (2)

The installer for the Apollo alpha release was made available, for Windows, as an MSI file. MSI files are the native format of the Windows Installer service. They're essentially a single-file database containing the data required to install (and uninstall) an application.

It turns out that offering your installer download as an MSI file isn't a terribly good idea. Unfortunately, we didn't discover this until it was too late for the alpha release.

The first half of the problem arises because Windows Installer remembers the name of an MSI file when an application is installed, and it requires that subsequent installations of the same product use the same file name. (Windows Installer considers two products to be the "same" if the MSI file for both contain the same product GUID.)

The second half of the problem is your browser, which likely has a habit of renaming files that you download. For example, if you download the same file twice, it might helpfully append "(2)" to your second download to avoid overwriting the first.

Taken together, these two behaviors can make it surprisingly likely that you try to install the same product twice from MSI files with different names. If you trace the behavior of Windows Installer when attempting to open the second MSI file, you'll find that it starts by correctly opening the second file, regardless of its name. Later, however, it will try to re-open that file using the original name.

This behavior doesn't seem to be well documented, although I have found a reference in this Windows Installer Team Blog entry--look for Rule #14. I'm hard-pressed to argue that it's not a bug, but maybe there's a good reason for it that I just haven't thought of yet.

Unfortunately, all of this can make Apollo's installation experience look lousy. For example, see this blog about installing Apollo.

We've addressed all of this in the upcoming beta release by making the installer download for Windows an executable. It still contains an embedded MSI file and uses Windows Installer, but no one--not you, and not your browser--has the chance to give that MSI file the wrong name. Plus, it's now got a nifty UI!

Posted by Oliver Goldman at 08:44 AM | Permalink | Comments (2)

The Apollo Alpha has been released! Old news now, but nonetheless the news with which I was planning to start this blog. Due to various unanticipated technical difficulties, the blog entry took somewhat longer to get out the door. (Better this than the other way around.)

A quick word about the alpha: Traditionally, an alpha release has been one which is feature complete but buggy. This terminology derives from the original IBM hardware design process with steps A, B, and C. [1]

The Apollo alpha is not an alpha in this sense. We are actually using an iterative development process. The alpha release is our fourth iteration. As the first to go public, marketing decided the "alpha" label was most appropriate.

So our alpha is not feature complete, and you can expect to see more features before 1.0 is done. On other hand, some of the features in the alpha have been through several iterations, should be fairly solid, and won't get too much more attention before 1.0. The filesystem API comes to mind.

Trivia note: The namespace in the application descriptor file is based on our internal iterations. You can tell that the alpha is our fourth iteration by noting that the namespace ends in "M3"--yes, we started at zero.

[1] Lohr, Steve. Go To. Basic Books, 2001. p 53.

Posted by Oliver Goldman at 10:56 AM | Permalink | Comments (1)