Archive for August, 2010

An Updater Framework for Native Application Installers

In an earlier post about native application installers, I mentioned that implementing an updating mechanism for applications that use this deployment option is currently an exercise for the user, as the updater framework included in the AIR SDK does not support native application installers.

Fortunately, Adobe Platform Evangelist Piotr Walczyszyn has written just such a framework. If you are adopting native application installers, it’s worth a look.

With respect to my earlier comments about securing these updates, it’s worth noting that secure use of Piotr’s framework currently requires hosting HTTPS downloads for the installers.

API Tip: File.nativePath ≠ File.url

Recently we’ve seen a number of developers get tripped up on code similar to this sample:

// Don’t copy; this code is wrong
myURLLoader.load( new URLRequest( myFile.nativePath ));

This code is wrong: myFile.nativePath returns a file path, but the constructor to URLRequest expects a URL. It’s easy to make this mistake for two reasons:

  1. In ActionScript, both file paths and URLs are of type String. Thus, the compiler cannot determine that one is being used in place of the other.
  2. Sometimes, especially on Windows, this code works anyway. This is a side-effect of some too-lenient URL parsing code in the runtime.

Taken together, these two issues make it easy to write incorrect code that works on Windows and yet fails rather inexplicably when run on Mac OS or Linux. Fortunately, the fix is easy: substitute myFile.uri for myFile.nativePath, and all will work as expected.

// Correct version of the code
myURLLoader.load( new URLRequest( myFile.url ));

An Update on HTTP Content Encoding in AIR Applications

In keeping with my recent HTTP theme, I want to provide an update on a change to HTTP content encoding supporting in AIR 2.0.3, which has just been released.

The HTTP protocol permits server and clients to agree on encoding a document for transfer. For text and XML documents, this can significantly reduce transfer time, as they typically compress well.

Prior to the AIR 2.0.3 update, AIR supported gzip and flate encodings only on Mac OS and Linux. On Mac OS, this was a result of using the default OS HTTP stack, which supports those encodings by default. On Linux, which has no default HTTP stack, we implemented direct support for these options.

On Windows, the capability was not available because AIR uses the OS HTTP stack, but Windows did not support these encodings prior to Vista. Therefore, AIR could not depend on this capability being present and did not enable it. Developers could work around this by managing the HTTP content encoding header themselves and performing the decompression in ActionScript, although that’s not a particularly fun option to implement.

As of the AIR 2.0.3 release, we’ve added support for gzip and flate encoding for all versions of Windows, thus bringing it to parity with Mac OS and Linux. This change applies to all applications using the 2.0 (and later) namespaces. Applications using the 2.0 namespace will automatically benefit from this change when run on the 2.0.3 and later runtime; there is no need to re-publish.

Single Sign-On and HTTP Cookies in AIR Applications

[3-Jan-11: Please see More on sharing HTTP cookies with AIR applications for an important follow-on to this post.]

Consistent with our philosophy that an AIR applications should behave like any other application on your device, AIR leverages the underlying operating system HTTP stack when making HTTP requests. A while back, I write about how this enables the use of OS facilities TLS client authentication.

Sharing the system HTTP stack also enables the use of HTTP cookie-based single sign-on mechanisms across both multiple applications and between AIR applications and the users browser. Assuming all parties use the shared HTTP stack, this will work by default. AIR applications can individually disable managing cookies in this way via URLRequestDefaults.manageCookies.

It should be noted that not all applications use the shared HTTP stack. Firefox is a notable exception, which unfortunately means that cookie-based single sign-on between Firefox and AIR applications (indeed, most desktop applications) does not work. Also, on Linux, AIR uses its own HTTP stack because there is no default OS stack available.