Adobe AIR has grown immensely popular over the past months. With its popularity, many new applications have been released. During this period, the following 10 issues have been the mistakes I have seen most often among developers. Hopefully, this list can help you avoid the same mistakes when building your next AIR application.
1. Making an application platform specific
Many AIR developers have a primary platform that they use as their development environment. In some cases, developers have not spent a great deal of time on other platforms, and they may not know how users on those platforms interact with desktop applications. Developers working on Windows, for example, need to have a good understanding of the user experience in respect to the Dock and the Application menu on the Mac platform, and Mac developers need to understand the user experience with the task bar and application window menus on Windows. Failure to understand these concepts can lead to applications that feel awkward and unnatural to the end user.
Consider this example: A Mac developer might place a Preferences menu item in the application menu for his AIR application. However, for the Windows version of the AIR application, he fails to add this menu item to each window menu. If the application were only tested and developed on a Mac this error might not get caught.
Some developers don't have access to other systems, but virtualization helps to eliminate some of these issues by providing the developer access to multiple operating systems on a single computer. One of the most useful tools in creating effective native applications is to have a regular user of another platform evaluate your application for both functionality and usability. By taking this extra step, you can catch most platform-specific issues in your AIR application.
2. Not including update capability in an application
One of the most important changes in the transition from the web to the desktop is the way that updates are handled. No longer does the user "come to you" to get your application, but rather you send the application to the user. Depending on how you configure your application, users might not ever have to return to your site to get the latest and most secure version of your application.
Previously, it took a little bit of work to develop an effective update mechanism for your AIR applications. However, Adobe has done most of the work for you with the Adobe AIR Update Framework. Adobe even gives you the option of using two different flavors of this framework: one includes a default user interface, and the other handles the logic and allows you to create a custom user interface that fits with your application.
Anytime you send a version of an AIR application to someone outside of your core development team, you ought to have some update mechanism in place (see Figure 1).
Figure 1. Adobe AIR Update Framework
3. Changing the application ID after an app has been released
The AIR runtime uses two factors to determine the signature of an application: the application ID and the publisher ID. These values become very important when you distribute your application. If you change one of these pieces of information, an end user might be unable to update her version with the newer version. This could result in the user installing two different versions of your application, which, in turn, could result in the update version being unable to access any application-specific data from the first installation. In either situation, the end user might get frustrated enough to not use your application again.
To avoid this situation, you need to settle on a few things when you create your application. First, you need to set an application ID in the application descriptor file. This application ID is invisible to the user and will not change. It does, however, need to be consistent. Second, you should always use the same signing certificate when creating your application. The AIR packager uses the signing certificate to determine the publisher ID. If you do need to use a new signing certificate, the AIR developer tools provide a means to do so. For more information, refer to the article "Signing an AIR file to change the application certificate" in the AIR documentation for Ajax, Flash, and Flex developers.
4. Not planning for offline support
One of the advantages of Adobe AIR is the online/offline capability for applications. Many applications might not need or use this functionality. In most cases, this will not cause any problems, unless going offline breaks the application.
Every AIR application that interacts with an online service needs to be tested while the development environment is offline. This way you can determine where you need to place warnings or disable user interface elements so that the end user understands what functionality is not available while the application is in an offline mode.
If you want to expand your application to include specific offline functionality, AIR has APIs to work with the local file system, the SQLite embedded database, and even a secure data store. By utilizing these APIs you can create applications that can easily store information on the user's computer to create a seamless offline experience. For an enterprise solution, the newest version of LiveCycle Data Services provides online/offline synchronization of data for AIR inside of Flex based AIR applications. For more information, see Christophe Coenraets' blog post: Offline Synchronization using AIR and LiveCycle Data Services.
5. Not thinking in AIR
The AIR APIs are powerful and provide a great deal of functionality to developers. However, I have often found that there are pieces of the API that some developers are not familiar with. For example, I have noticed developers trying to encrypt data in a text file instead of using the EncryptedLocalStore functionality, or storing delimited data in a text file when using the embedded SQLite database would provide better functionality.
This oversight can be extremely common in web applications that are ported to Adobe AIR. One of the great things about AIR is that many of these applications can be ported with little or no changes to the code. However, in some cases the application could benefit greatly from using some of the AIR APIs to add functionality that enhances the user's experience.
To get a better grip on the APIs provided in AIR, you can review the AIR documentation and sample applications.
6. Using custom chrome to create confusing interfaces
Custom chrome puts a lot of power in the hands of developers and designers. By using it, you are altering the way a user interacts with an application. If this custom chrome has a consistent feel with the standard operating system chrome, users will be able to interact with it seamlessly. However, if users cannot easily maximize, minimize, or close an application window, the chances of them using your application on a regular basis are very slim.
Having a single look across all platforms certainly has its benefits. Using the standard chrome will cause the application to appear different on each platform. Custom chrome gives a single branded experience across all platforms, and if it can be accomplished without confusing the user, it is a powerful tool. Some applications, such as the EBay Desktop AIR application, give the user the option of the standard or custom window chrome. As long as you approach custom chrome with caution and keep the user's experience in the forefront as you develop your application, custom chrome will be an asset. For more information, refer to Ethan Eisman's article Adobe AIR and the experience brand, Lee Brimelow's Creating custom-chrome AIR applications in Flash CS3, as well as the AIR Quick Starts for Flex, Flash, and Ajax.
7. Not using the seamless install badge
Developers sometimes assume that everyone's system is configured in a similar way to their own. This can be dangerous when distributing packaged AIR applications to your end users. First, you cannot guarantee that users have the Adobe AIR runtime installed on their computers. Second, you cannot assume that the server delivering the file will know how to properly handle packaged AIR files.
Luckily, these issues can both be handled by properly configuring and using the seamless install badges for Adobe AIR. This allows users who have Adobe Flash Player installed to download your application as well as the AIR runtime (if needed). It will then install the necessary elements. This takes the guesswork out of AIR application distribution. There are currently two versions of the badge that can be used: the original design (see Figure 2) and a new version designed by Grant Skinner (see Figure 3) that is on Adobe Labs.
Figure 2. Original install badge design
Figure 3. Updated install badge design
For more information, refer to my article, Deploying AIR applications seamlessly with badge install and to Additional Seamless Install Badge with new look and feel on Adobe Labs.
8. Not encrypting sensitive data
Many AIR applications interact with other services on the Internet. In many of these cases, the user inputs sensitive information such as a username and password to access these services. This is just one instance where secure data is stored by an AIR application. Anytime you store sensitive information for an AIR application, it needs to be encrypted.
Many developers have confused the security of different storage options within AIR. Some developers have mistakenly assumed that information with the local database is secure, but that information can be accessed by any application that can read a SQLite database. Essentially, the only truly secure way to store information with the AIR API is to use the EncryptedLocalStore class. This uses platform-specific encryption to store information, and it can (optionally) also be configured to be accessed by a single AIR application only. Some developers have created custom ways to encrypt information in local files, but in almost all cases the EncryptedLocalStore class is your best option. For more information, see Kevin Hoyt's article Using the encrypted local store feature.
9. Not preserving native interaction
Some actions span almost all applications on a specific operating system. For example, Windows users can be sure that in almost every application objects can be copied by using the Ctrl+C keyboard shortcut. In addition, Mac users expect the same behavior with the Command+C shortcut. These are the type of actions that need to be preserved so that the user can have a familiar experience when interacting with your application. If you changed the Copy keyboard shortcut to a different key combination, it would only cause confusion and decrease usability.
For example, if you are dealing with SWF content, the normal keyboard shortcuts for copy, cut, and paste are enabled in TextInput, but they are not enabled in TextArea (the default shortcuts work for all types of text inputs in an HTML AIR application). In this case, you would need to be sure that this functionality was preserved for the user by manually adding them.
When dealing with keyboard shortcuts, review other applications to ensure that if you are performing a standard action, you use the common keyboard shortcut for that specific platform. In addition, if certain items appear in application or window menus (such as Cut, Copy, and Paste) be sure that those items are present and indicate the relevant keyboard shortcut.
10. Assuming performance doesn't matter outside of the browser
Developing applications for the desktop can be a liberating experience. By breaking out of the browser, you are freed from many constraints. However, the temptation is to not worry about issues such as memory and processor utilization. These issues become compounded when you utilize resource-intensive functionality within AIR, such a
s custom chrome and window transparency. Just as with a web application, every AIR application should be tested and profiled for system resource utilization. If you are creating an AIR application in Flex Builder, you can use the Profiler to view your application's resource utilization over time.
Remember that your AIR application has the ability to slow down the entire desktop experience for the end user. Your AIR application needs to use only the amount of resources that make sense. If your application performs complex tasks, a high utilization of system resources might make sense. However, if your application performs a relatively simple task, the end user will not be satisfied with a high usage of system resources. For more information, refer to Using the Profiler in LiveDocs.
