Archive for June, 2008
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.
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.
One of the benefits of web applications is the ability to quickly publish updates to the application to your end users. As soon as you upload the changes to your web server, your users and enjoying the latest version! With AIR, this becomes a little more difficult. What if your user is offline? Should they be able to use the application if a new version is available? AIR provides an updater API (Updater.update), which will install a new AIR file over an existing application, but doesn’t solve any of the problems mentioned above.
Enter the new Adobe AIR Update Framework. This framework was developed internally and allows you to focus on building your application, not the logic for handing updates. Using a simple API and schema for storing version information, the updater API will allow both Ajax and Flash/Flex developers to push updates with a minimal amount of work. On top of the logic for handling updates, they even provide some default UI for you to use. So, if you are trying to figure out how to handle updates in your AIR application (which you should definitely be doing starting in the first version of your app) you now have no excuse to put off that work.
Over the past few months, Mike Chambers has been working on a solution to this problem, and what he has come up with is going to be an amazing resource. The site is called toString.org and encourages developers to submit translations to the site for publishing. Mike describes the site as:
…a site that hosts books about Rich Internet Applications, with a focus on book that leverage the Adobe RIA Technology Platform (Adobe Flash Player, Adobe AIR, Adobe Flex).
Yesterday we released a ‘small’ update to the AIR runtime. In reality, this release has a few new features and many bug fixes that should relieve a few of the pain points you may have encountered in AIR 1.0. The major announcement is that we now support full localization, which includes not only the localized installers, but also the ability to develop localized applications.
Some of the highlights of this release include:
- Fully localized runtime and installers, as well as numerous API additions to support building localized applications.
- Support for certificate migration. If you have released a self-signed application, you can now use the update API to initiate the installation of an AIR application that chains to a certificate authority.
- Windows XP Tablet PC Edition support. This includes a fix that will pop up the visible keyboard when a user selects a text field in the application.
- Addition of the File.spaceAvailable API. This will allow you to determine the amount of space that is available on a volume.
- Numerous garbage collection improvements. One of the issues that was solved on Mac OS is a bug that was not deallocating memory which was assigned to the AIR application. This wasn’t a major issue; the memory could still be reallocated to other applications if needed. But now when a user goes to Activity Monitor on mac they should see the actual memory that is being used by the AIR application. There were also numerous other fixes that were made which should fix a few leaks you may be seeing.
If you are currently developing Flex applications and would like to update Flex Builder to use AIR 1.1, check out this tech note describing how you can update the AIR framework. The Flash team has also released a similar tech note describing how to update Flash CS3 Professional. And last but not least, the Dreamweaver team has released an updated version of the AIR extension.
Along with this launch, Aptana has announced updated support for 1.1. So if you are currently using Aptana to develop Ajax based AIR applications, go to http://www.aptana.com/air to get the updated plugin.
The AIR team definitely deserves a round of thanks for the hard work they put in to getting this release out the door. They barely even caught their breath after the 1.0 launch before they started working on this release. Now onto the next one!
One of the great things about the new Flex open source project, is that it isn’t just the framework that has been opened up. We have even pulled back the covers on the compiler. Today, Matt Chotin posted on the open source wiki what used to be an internal document that describes how the Flex compiler, usually known as mxmlc, is architected. So if you are looking to hack around on the compiler, fix bugs, or even add functionality, check out that link.
You may be wondering to yourself though, what can I actually do with this information? One great example is the new Flex code coverage tool called Flex Cover written by Joe Berkovitz. The tool basically adds functionality to the Flex compiler so that the bytecode it outputs contains information about what code has been executed. You can then take this information to generate a report which allows you to see which lines of your ActionScript code actually executed during that session.
So what are you thinking of using this information for? How about instrumenting the compiler to do some code optimization? Or maybe just fix that compiler bug that keeps annoying you? How about adding an entirely new feature to Flex? Now that it is all open source, go ahead and try it out!
Just a quick note that I have finally (after much, much procrastination) updated the TwitterCamp application to be compatible with Adobe AIR 1.0. While I have not added any features to the application, I have moved the source over to Google Code. The new project can be found at http://code.google.com/p/twittercamp-official/.
This project has really grown leaps and bounds further than I ever originally intended. It is a little funny how the projects I have spent the least amount of time planning and developing seem to gain the most traction. I have received numerous requests recently for new features. I am looking to add some more support for other services, such as Flickr and Brightkite, as well as updating the UI. Keep an eye on my blog for updates. As always, if you have any specific requests, please email me.