Archive for December, 2008

Can One AIR Application Launch Another?

Commenter madhu asked whether one AIR application can launch another. The answer is yes, albeit indirectly.

There is no API (at least, not yet) that allows AIR applications to directly launch other applications. However, AIR applications can be launched from a web page via the AIR Browser API. (Note that applications have to opt-in to be launched in this way.) And since you can host a web page in side an AIR application, it’s possible to make this work with a couple of levels of indirection—and one click from your user.

Here’s the basic recipe:

  1. In the application-to-be-launched, make sure <allowBrowserInvocation> is set in its descriptor.
  2. In the launching application, create an instance of HTMLLoader.
  3. Write a SWF that will, on a user click, call the Browser API launchApplication() method. (You can use the sample badge SWF in the SDK for this.)
  4. Load this SWF into your HTMLLoader instance.

The click from the user is required for reasons previously discussed.

Final note: This method can also be used to enable the installation of one AIR application from another.

Changes to HTMLLoader.loadString() in AIR 1.5

For AIR applications bound to version 1.5 and later, the default behavior of the method HTMLLoader.loadString() has changed. This may impact your application; here’s the how and why of the change. (For Flex users, the following discussion also applies to setting the HTML.htmlText property.)

AIR applications are desktop applications and, consistent with that fact, AIR does not prevent you from doing dangerous things like fetching remote content and running it locally. However, it’s rare that such things are desirable and, when they are, they should be done explicitly and carefully. AIR APIs are therefore generally designed to make doing safe things easy and dangerous things hard.

Prior to the AIR 1.5 behavior, HTML content loaded via HTMLLoader.loadString() was placed in the application sandbox. This content has full access to the local machine. Whether or not this is reasonable depends on where you get the string that you load from and what that string contains. Since it’s easy for that string to come from untrusted sources, this provides an easy path for injecting untrusted code into your application.

To address this, starting in AIR 1.5, loadString() defaults to loading content into the browser sandbox. This is the safe thing to do since untrusted code, when running in the browser sandbox, is unable to operate with the same permissions as are otherwise granted to your application.

If you want the old behavior, you can set HTMLLoader.placeLoadStringContentInApplicationSandbox = true. If you do this, remember that you are taking on responsibility for dynamically loading code into the application sandbox and all of the risks that entails. Ethan Malasky’s blog has some great posts in this area. Still, I don’t generally recommend it—it’s hard to get right.

One final note: This change will not break your existing applications. The new behavior is bound to the namespace used in your application descriptor file. Applications using the 1.0 or 1.1 namespaces will operate as before. You will have to take this change into account when you update to the 1.5 (or later) namespace.

Installers Can Only Do So Much

In my response to my earlier post about why uninstallers don’t clean up user files, commenter dan suggests that uninstalling and then installing an application should erase application settings. He argues that this would at the very least help users who have applications that don’t work because, for example, the application settings have become corrupt.

The fix is tenuous at best:

  • It won’t work if the application doesn’t opt in. After all, some applications will want to save those settings.
  • It won’t work if AIR can’t determine where the settings are stored. Yes, we provide a location for that—but it’s a suggestion, and not obligatory.
  • It requires the user to intervene (uninstall/reinstall) to fix a problem the application could address for itself.

The point about corrupt user settings is valid; this can happen and effectively disable an application. And I agree, asking users to find the file containing these settings and manually delete them is unreasonable. But the truly simple fix is to code your application so that it can detect and ignore corrupt settings. Get that right, and users may never even realize something went wrong.