I get to see and play with a lot of really cool AIR applications (even when they’re still being developed). Every now and then I come across an app that totally ignores any best practices or usability rules. AIR provides developers with a lot of features that could potentially annoy users if not used wisely. I thought it was a good idea to write this article. I’m not saying you shouldn’t use these features, I just want you to think about them before you add them to your application.

1. Launching your application on login

   NativeApplication.nativeApplication.startAtLogin = true;

   That’s all it takes to have your application launch whenever your user logs in to his account on his computer. However, if this is something that you set automatically without telling the user about it, you may find your application to be uninstalled faster than it was installed. There really is no reason why you should set this automatically. You can also set this on runtime. So why not ask the user if he wants to launch your application on login when he first launches the app? And why not provide a small preferences panel that allows the user to easily change this setting?

2. Always in front

   NativeWindow.alwaysInFront = true;

   Again, very easy to do and in some cases it totally makes sense to have an application stay on top but it should be the user’s decision and not yours.

3. Automatically setting the filetype

   NativeApplication.nativeApplication.setAsDefaultApplication("mp3");

   Imagine you’re building an application that can play MP3 files. Are you sure you want to automatically open your application whenever the user clicks on an MP3 file? This is also one of those things you may want to check first and we provide all the methods to do so.
   When you first launch your application, you can first check if your application is already set as the default for this filetype.

   NativeApplication.nativeApplication.isSetAsDefaultApplication("mp3");

   If it’s not, check which application is the default for the filetype you want to use.

   NativeApplication.nativeApplication.getDefaultApplication("mp3");

   This returns the path to the application registered as the default app for this filetype. You can then ask the user something like: “Hey I see you play MP3-files with QuickTime but I can also play these files. Can I set myself as the default application?”.

   Since you already added a prefs panel for setting the launch on login and always in front preferences, you can also add this one. To remove your application as the default for a specific filetype, just call:

   NativeApplication.nativeApplication.removeAsDefaultApplication("mp3");

4. Full screen applications

   I think there are only a couple of valid use cases for full screen applications (not the fullscreen displaystate but just taking over the entire screen with the exception of the menu bar). The obvious ones are video and kiosk applications. If your application fits in this category or you think taking over the entire screen is totally acceptable for your app, please do make sure that you add close and minimize buttons. If quitting your application is the only way to quickly check an email, the user may never return to your app.

5. Custom chrome

   This is actually related to #4. If you are making an application that has custom chrome, you should always add the standard close, minimize and maximize buttons. Everyone is used to having these in an application window so make sure you don’t forget to add them. These are the methods to call whenever one of these buttons gets clicked.

   NativeWindow.close();
   NativeWindow.minimize();
   NativeWindow.maximize();

   You should also be aware that because of the way custom chrome is rendered on a user’s machine, an application with custom chrome can take a performance hit.

6. Self signed applications

   What is “Joe The Plumber” going to do when he sees 2 red icons in the installation screen of the app he’s trying to install? As a rule, no AIR application should be publicly launched without being signed with a code signing certificate. We are aware of the fact that individuals can’t get these certificates anywhere right now and this is something that we are working on. Individuals can get a code signing certificate from Chosen Security. However, for companies, it’s really easy to get a cert.

I hope these “rules” will help you build better applications. I’m sure some of you can think of other rules developers should think about, so feel free to add them to the comments if you know of any.

First of all, why is signing an application important? Easy. When your application is unsigned or signed with a self-signed certificate, the user will get two red icons on the install screen. The first one is related to your code signing certificate. It’s telling you that the “publisher is unknown” which is very normal since we have no idea who actually signed this application.

When you do get a code signing certificate and sign the application with it, the icon will turn green or in some cases yellow. The yellow icon will appear when you are using the file I/O API.

So where do you get a code signing certificate? Well, maybe you already have one. If you already bought one to sign Java or Cocoa applications for instance, chances are that this certificate is 100% compatible and you can use that. To make sure, check that your certificate is a Class 3 code signing certificate and you should be ready to go. If you don’t have, there’s a number of companies like Thawte.com that actually sell these. But if you upload your application to the Adobe AIR marketplace, you may get a complimentary code signing certificate from us. More info here.

I’m mainly using Flex for AIR development but the workflow is very similar in Flash or Dreamweaver. In case of Flex, you are actually going to build a release version of your application. To do that, you click the “export release build”-button. That will popup a little wizard window. In the first window, you can specify where you want to save your .AIR file. In this case, I’m saving it on the desktop.

When you click “next”, Flex will ask you to specify which digital certificate you want to use. If you don’t have one but still want to build a .AIR file for testing, click on the “create” button. When you fill out all the details of that form, you can save that self signed certificate so you don’t have to fill out that form every time. I saved mine in my home folder. Once you have created it, you can easily reuse it by just entering your password.

If you already have a code signing certificate, you can browse to the location you saved it to use it. Click “finish” and your AIR file is going to be baked. That’s it.

If you’ve already published an AIR application, chances are you did that by using a self signed code certificate. When you installed the app, the AIR installer told you that the publisher’s identity is unknown.

If you get a code signing certificate from a company like Thawte.com and use that to sign your application, it’s obvious that your identity has been verified. The AIR installer will show that your identity is known.

If you upload your application to the Adobe AIR Marketplace now, you are eligible to receive one Thawte code signing certificate (1 year Class 3 code signing certificate) from Adobe. As this is purely available on a first-come, first-served basis and supplies are limited, you might not want to wait too long to upload your app.

Read details here and then go upload your app on the Adobe AIR Marketplace.