Author Archive: Christian Cantrell

Writing a Secure Plugin Architecture for AIR Applications

If you’ve ever wondered about plugins for AIR applications, I just published a article called Extending AIR Applications With Plugins which hopefully should answer most of your questions.

The trick to writing a plugin architecture for AIR applications isn’t really so much plugin management (installing, loading, deleting, etc.) as it is plugin security. Plugins that are privileged enough to be really powerful also have enough power to be potentially dangerous, so before an end user installs one, he or she needs to know not only who wrote it, but also that the plugin wasn’t somehow modified prior to installation. That’s where code signing and validation come in.

The sample plugin architecture I wrote addresses both plugin management and security. The article contains plenty of background on plugin security as well as sample code for an application called "Pluggable SearchCentral" which you can see in action below:

For more on how to write your own secure plugin architecture, see Extending AIR Applications With Plugins.

Important Development Workflow Change in AIR 2

If you’re an AIR application developer, and you tend to run an installed version of an application at the same time that you’re developing it, this post contains important information on how your development workflow will need to change for AIR 2.

In AIR 1.5.3, we made some changes to the way that AIR files are signed. Previously, publisher IDs were computed using developers’ certificates, and were associated with applications at install time. When running the same application from ADL (which is what you’re doing when running or debugging from Flash Professional and Flash Builder), unless the -pubid flag is passed in, the application runs without any publisher ID. The result was that you could run an application from ADL while running the installed version of the same application simultaneously.

Starting with AIR 1.5.3, publisher IDs are specified rather than computed. If no publisher ID is specified (which is the default), the application is installed without a publisher ID. Since ADL typically runs applications without a publisher ID, and since only one instance of an AIR application can run at a time, the result is that if an installed version of an application is running, you cannot use ADL to launch the same application. In other words, you cannot run and develop the same application at the same time. (For more information on the changes we made in 1.5.3 and the reasoning behind them, see Oliver Goldman’s post, Upcoming Certificate Renewal Changes in Adobe AIR.)

This new behavior isn’t technically a bug since the previous behavior was not so much intended as it was a convenient byproduct of the signing and installation process. That said, we realize this is an important workflow for many developers (including myself), and we plan to re-enable it in the future. In fact, not only should you be able to run and debug the same application at the same time, but we intend to actually support the workflow this time.

Explicitly implementing and supporting this workflow has two advantages over the previous behavior:

  1. We can make sure we never "break" it in the future. (When things just kind of work accidentally, you never know when they might stop working.)
  2. We can make it even more comprehensive and useful than the previous behavior. (We have some good ideas we’re currently considering, but feel free to post suggestions here.)

In the meantime, if you find that you really need to be able to run and debug the same application at the same time, I’ve found that the best work-around is to change your application ID in your application descriptor file. For example, I’m currently working on an application called MailBrew which I also usually have running in the background. The installed application ID is com.christiancantrell.mailbrew, but while developing it, I change the ID to Not only does this give me the workflow that I’m used to, but it also allows my test application to use a different application storage directory, encrypted local store, etc. Just make sure that you change your application ID back before building a release version since if you don’t, updates to your existing version will not be allowed. (Note that you can also use third-party tools like Apache Ant to manage this switch for you.)

We apologize if this change negatively affects your development workflow, and we intend to not only re-enable the old workflow, but to also make it better than it was before.

Better SDK Overlay Instructions

We noticed that some developers were having trouble overlaying the AIR 2 beta SDK on top of the Flex SDK in Flex Builder and Flash Builder. Looking into the reports a bit further, we discovered that our instructions were not quite accurate. I just updated the AIR 2 release notes with more detailed instructions, so hopefully that will clear things up.

If they’re still not clear, let us know via the comments and I’ll clarify further. Also, we are looking at ways of making this process much easier in the future. Thanks for bearing with us in the meantime.

Share News with ShareFire

My colleague Dan Koestler and I just released a new version of ShareFire (formerly known as Apprise), a news aggregator written for Adobe AIR. ShareFire has several useful features, but what really differentiates it is the ability to share news stories with friends over various social networks right from the application. We currently support sharing via email, AIM, Twitter, Facebook, Delicious, Digg, MySpace, and Newsvine. Another nice feature of ShareFire is that it has been localized into 16 languages which you can switch between dynamically (without having to restart the application or download other versions).

The source code for ShareFire is available on Google Code as well as all the libraries it uses:

  • as3corelib: Contains general utilities for things like date parsing, and working with various file formats.
  • as3localelib: Utilities for helping to localize your Flash applications.
  • as3nativealertlib: Library for creating modal alert windows in AIR.
  • as3syndicationlib: Libraries for parsing all versions of RSS and Atom.
  • as3preferenceslib: Library for managing the storage, retrieval, and encryption of application preferences.
  • as3notificationlib: Library for showing Growl-like alerts on Mac, Windows, and Linux.
  • wimas3: Code for integrating AIM into your Flash applications.
  • Adobe AIR Update Framework: A framework to assist in updating your AIR applications. (This project is now included in the AIR SDK, but it wasn’t at the time ShareFire was started.)

Here’s a screenshot of ShareFire, or for a demonstration, check out the video below. To install ShareFire, check out the ShareFire homepage.

AIR Recipes: Tips and Tricks for AIR Application Development

The Adobe Developer Connection site has a really good tool for finding handy tips and tricks for AIR application development: the Adobe AIR Cookbook. If you’re familiar with the O’Reilly Cookbook Series, the AIR Cookbook is the same idea (in fact, it’s done in partnership with O’Reilly). Rather than trying to teach the fundamentals of programming for AIR, or providing an API reference, the AIR Cookbook contains ready-made solutions for common AIR application development problems.

For example, if you just discovered that the differences in native window chrome across operating systems is affecting your application content, then you might want to read this. Or if you have a datagrid with a column of checkboxes and you want users to be able to check or uncheck all the checkboxes at once, you’ll probably want to consider this solution. Wondering about using a TCP socket from JavaScript so you can leverage a protocol not directly supported in AIR? Then check this out.

Recipes are submitted by AIR developers building real-world AIR applications which means they provide practical solutions to actual problems. Each recipe contains code snippets, so the solution to your problem might be as easy as copying and pasting a function or two, or you might just use a recipe as a hint to help you figure out how to solve your problem on your own.

You can also use the AIR Cookbook as a source of inspiration. For instance, maybe you never thought of adding undo and redo to your AIR application, or storing ActionScript objects in the Encrypted Local Store. If the code is already written and just waiting to be incorporated into your application, why not give it a try?

Anyone can post recipes, so if you have a favorite technique that you want to share with the world, please feel free to contribute. Recipes support comments, so you can contribute to existing posts, and you can even subscribe to the AIR Cookbook RSS feed to catch new recipes as they come in.

Relevant links: