Foundation for a great AIR application with Flex

After having used MDM Zinc for a few years to create RIAs or “desktop flash applications" I was very excited to see an Adobe wrapper for the flash platform. I think Adobe has done a good job with it and an excellent job supporting it with various add-ons such as the update framework, the Badge installer and the lesser known Side Car installers (more on all these add-ons in my final two posts in this series). Right now I want to list a few things that I think can really help make a good AIR app that is easy to maintain as well.

1. Use a “SystemManager class” where you make all your AIR specific calls.

This will make it much easier when you (or your client) decide to make a web based version of the app or if you are already maintaining web and AIR versions.

PlaybackManager.as (responsible for loading files, stopping, pausing, etc...):

var songURL:String = SystemManager.getInstance().getAudioUrl(fileVO.file)
sound1.load(new URLRequest(songURL));

SystemManager.as (responsible for handling file paths and basically anything that's dependent on AIR):

private var audioDirectory:String = "content/audio"
/* or we could use air to reference the application storage directory
* private var audioDirectory:String = File.applicationStorageDirectory.resolvePath("content/audio").nativePath;
*/
public function getAudioUrl(fileName):String{
return audioDirectory+"/"+fileName;
}


2. Make an icon and give your app a name

Air and Flex gives you all those nifty settings in the –app.xml file so use them. This includes application title, window titles, installation directory and icons. For more information see this page on livedocs.

3. Get a security certificate

If you are building an AIR app for commercial distribution you should probably sign up for a security certificate. You can create your own certificate through FlexBuilder but it will not look as official during installation and will give a higher warning level to the end user. For more information see this page on livedocs.

4. Set up an update feature before the first release

In my next article in the series I will go over updating and I just want to stress the importance of adding this feature early. This really should be the first feature you build since it will make it so much easier to fix bugs or add important features after the first initial release. If you omit it you have no easy way of pushing it to your users.

5. Let users know what version they're using

If you want an easy automatic way of displaying the current version of the app you can tap into the “-app.xml” to retrieve the version number of the app. I found this method in the sample files from Adobe's Update Framework (more on that later) and I find this more reliable than me remembering to update a version number somewhere on the UI.


private function setApplicationNameAndVersion():void {
var appXML:XML = NativeApplication.nativeApplication.applicationDescriptor;
var ns:Namespace = appXML.namespace();
lblAppVersion.text = appXML.ns::version;
lblAppName.text = appXML.ns::name;
}


6. Have a strategy on how you save data

Something that is a little different from other wrappers I have worked with is that after installation you can’t save any data to the applicationDirectory so you should plan to either save data to the applicationStorageDirectory or creating your own custom directory in the user’s document directory. I'm as gulty as the next guy when it comes this, but don't forget about the built in sqllite feature.