Saving Encrypted Data in AIR

Have you ever wanted to store a users password, you know, that little checkbox that says ‘Save Password’ on any login form. Or maybe you just want to persist a session token or other information. You could use the Local Shared Objects or even the File API, but that isn’t very secure. How do you store sensitive information that your AIR application needs to persist?

Luckily, there is an often overlooked API for just this use case. It is called the EncryptedLocalStore and is actually quite simple to use. The EncryptedLocalStore API persists data to the local system using a name-value pair scheme that is specific to each application. The name is a simple string, and the data is a ByteArray. The data is stored using both the application ID and the user information from the local system, so other AIR applications and other users cannot access the data. This API is actually hooking into the Keychain functionality on Mac and DPAPI on Windows. The data is encrypted using AES-CBC 128-bit encryption. So the main point to take away is that the data is very secure and other AIR apps or users will not be able to easily access it.

So, how do you actually use the API? Well, lets assume that we have a session ID that is a string and we want to persist in the EncryptedLocalStore. Lets also assume that the session ID is stored in a variable called ‘sessionId’. One thing to keep note of is that the data must be stored as a ByteArray, so we first need to create a ByteArray instance and add the string value to it. The code might look something like this:

var bytes:ByteArray = new ByteArray();
bytes.writeUTFBytes( sessionId );
EncryptedLocalStore.setItem( “sessionId”, bytes );

To retrieve the data, you simple retrieve the ByteArray using the getItem API, and then read your UTF string value out of that ByteArray:

var sessionIdBytes:ByteArray = EncryptedLocalStore.getItem(“sessionId”);
var sessionId:String = sessionIdBytes.readUTFBytes( sessionIdBytes.length);

To remove an item from the store, you simply call the removeItem API:


There are a few things to note when using the EncryptedLocalStore API. First, the API is syncronous and is geared towards small amounts of data. While there is no practical limit, any ByteArrays larger than 10MB might cause performance issues. Second, when debugging your application using ADL, we are actually using a different store than what is being used for installed applications. And last, when uninstalling an AIR application, the data in the EncryptedLocalStore is NOT deleted.

One last note as well, this API is available to both Ajax and Flash based AIR applications, like all ActionScript APIs.

AIR Tips and Tricks – Video, Slides, and Code

For the past few months the crew here at Adobe, along with a few other brave adventurers, spent a total of more than four weeks traveling throughout Europe educating developers in many countries on AIR. My presentation for that trip was called ‘AIR Tips and Tricks’. Below I have included a ZIP file of all the source code for those presentations along with a PDF of the slides. Mike Chambers has also posted a video of the presentation as well, which was recorded in Munich.

Apollo Multi-Window Support using Flex

One of the most exciting features of Apollo is support for applications which have multiple native windows. Currently when using Flex in the browser, you are limited to using PopUpManager or rolling your own MDI architecture. With Apollo, your application can look more like, well… a native application. Each window will appear in the task bar on Windows, have a tab and z-order, etc.

An existing issue in the Apollo alpha that you may struggle with if you are doing Flex development, is that the Flex Framework does not currently support Apollo’s NativeWindow implementation. The issue stems from the fact that now your Apollo application can have multiple stages and the Flex framework which was originally developed for the browser player doesn’t take this into consideration. Right now if you try to add Flex content, such as a custom Flex component, to a new windows stage you will get unexpected and broken behavior.

Now, I wouldn’t bring this up unless I had a solution. But before I show you that, a few caveats: a future release of the Flex Framework will formally support multiple windows. If you are looking at this article and there is currently a post-alpha Apollo release, please check the docs first to see if Flex officially supports multiple native windows. Another caveat: You will still run into a few issues and bugs when using this technique. For example, PopUpManager may not work properly in new NativeWindow instances.

On to the code (the comments should explain what is going on):

Continue reading “Apollo Multi-Window Support using Flex”

Apollo Native File Dialogs

Currently the Apollo Alpha doesn’t support native file dialog boxes (it will before the final official release.) Despite that, there is a way to get this functionality now by using existing Flash Player APIs.

I will first show how to display a file ‘Save’ dialog box which allows the user to specify the name of the file they would like to write to the disk. This will allow them to type in the name of a file that may not exist. The user can also select a file that already exists and the dialog will prompt the user that they are about to replace that file on the system.

To accomplish this in Apollo, you use the ‘download’ method on the class. Because the flash.filesystem.File class extends FileReference, you can employ this technique by using that class as well. The trick to getting the File reference without actually downloading the file is to cancel the URLRequest before it executes. See the code below for an example:
Continue reading “Apollo Native File Dialogs”