A user on the Adobe AIR forums recently requested that we change the default behavior of AIR applications running on Mac OS so that they don’t exit when the last window is closed. This changed behavior would, of course, be consistent with the majority of Mac OS applications.
Contrary to what you might suspect, the current behavior was not an oversight on our part; nor was it a result of porting a Windows design to Mac OS. (We have several individuals on our team with significant Mac OS experience and I assure you they wouldn’t stand for that kind of thing.)
The decision makes more sense if you think about it in light of some observations about actual AIR application development:
- Although the default behavior of Windows applications is to exit when all windows are closed, many developers want to write Windows applications that keep running in this case.
- Although the default behavior of Mac OS applications is to keep running when all windows are closed, many developers want to write Mac OS applications that exit in this case.
- An application running without windows open is often a stumbling block for developers coming up to speed on the platform because, when they try to launch the application again, nothing happens by default.
From this one can, I claim, reasonably conclude that defaulting to platform-specific behavior in this case is not worthwhile: most applications either want to keep running on all platforms or exit on all platforms. Second, to ease that developer stumbling block, the default had better be to exit. Thus, NativeApplication.autoExit defaults to “true” on Mac OS, Windows, and Linux.
Any chance we’ll change this in a future release? Not likely. Although patterns of development change, to insure forward compatibility we’d have to keep the current behavior for old applications and introduce the new behavior only for new applications. Even just the switch would introduce yet another thing for developers to learn—and another potential stumbling block. In practice the cost of changing an API’s behavior is quite high, and I don’t think this change would make the cut.
There’s one important code signing feature that didn’t make it into my recent article on code signing in Adobe AIR: the ability to switch to a new certificate.
You can use this feature to transition from a self-sign certificate used during initial development to a CA-issued certificate purchased later. You can also use it switch between certificates issued by different CAs, or even to switch identities if say, your company is purchased by another.
The feature is straightforward to use: First, package a version of your application using your new certificate. Then, sign it a second time (using the “-migrate” option to adt) using your old certificate. The second signature covers the first, so the original signer is effectively granting permission to the new signer to take over the application’s identity. Note, though, that both certificates must be valid for some overlapping period of time in order to make the transition.
Without this feature switching certificates is disruptive for the end user: the version of the application signed with the new certificate is handled as an entirely different application than the old one. The application can’t even update itself from one to the other, as the Updater API will refuse to see them as related.
With this feature the transition is much smoother, although there are still a couple of rough edges. An application can use the Updater API to update to the new version when using this feature. However, the application’s publisher ID will change during this update, which means that:
- The application’s local connection name will change,
- The application will no longer have access to its old encrypted local store, and
- The application’s application storage directory will change.
Regarding the storage directory, it’s worth noting that you can still access the old one via the File API; you just can’t get to it via File.applicationStorageDirectory.
See also help on the Adobe Developer Center.
The latest Adobe AIR beta for Linux is now available on Adobe Labs. If you’re developing AIR applications, please give it a try. Developer feedback is invaluable in preparing software for release.
It’s been my experience that successful developers make use of the resources available to them. Sure, it’s great to have the ability to figure everything out on your own. But realistically, it’s best to save those skills for when you need them.
Among a variety of resources for Adobe AIR developers at the Adobe Developer Connection is the Adobe AIR Cookbook. The cookbook provides recipes for solving challenges commonly encountered when building applications. That should leave you more time to work on the unique aspects for your application.
Many of these recipes come from the community—itself another great resource. For the next few weeks you may have added incentive for contributing to the cookbook yourself: a shot at winning prizes. Deadline is September 26th, 2008. See Michael Koch’s announcement for details.
Ever wanted to know the ins-and-outs of the Adobe AIR code signing implementation? It’s a complicated subject with big implications, but the details aren’t necessarily intuitive and are frequently misunderstood. Dr. Dobb’s Journal has published an article on code signing in AIR, authored by this blogger.