Posts Tagged Adobe AIR
I know this isn’t the usual content, it being introductory level, but I got to write this piece in order to try to raise the general awareness about Adobe AIR where I work. My true goal being that project managers and account directors get a better feel of AIR and push it more to the clients, resulting, in the end, that I would get to do more AIR apps (i got plenty of these little machinations). I am not sure it got the attention it deserves, so I am putting it here, where, with a little Google love it might get a bigger audience.
I’ve been playing lately with Adobe AIR and I was thinking that it might be a good idea to give you an overview of what it is to help us all grasp its full potential.
AIR is made by Adobe and is based on the Flash Player. What this means is that it can do almost all of the things that you would expect from a Flash file (.swf). The particularity of AIR comes from the fact that it doesn’t need to be embedded into an HTML page to work. An AIR application is made to runs on your desktop, just like any other application.
Let’s take a look at how an AIR application differentiates itself from a regular Flash file.
In order to run an AIR application, you must first download the AIR runtime; this is similar to how Flash files require the Flash Player. Once the AIR runtime is installed, you can begin downloading and installing AIR packages (.air files).
When offering AIR applications for download, you can use what’s known as a badge. A badge is a little piece of Flash that you put on your website that will do two things:
- First, the badge will check if the user has the AIR runtime installed. If not, it will install the runtime first.
- Then, the badge will proceed to download and install the desired AIR application.
This makes the installation process remarkably painless. For an example of a badge in action check out Agile Agenda. You will see the badge roughly in the middle of the page.
Another nice feature of Air is the fact that an application can keep itself up to day by automatically checking for new versions on a central server. If a newer version is found, the application will download the updated version of itself and install it. This is a great way to manage code enhancements and bug fixes after the initial application release or while the client is reviewing the final product prior to launch.
Just like Flash, AIR applications should function precisely the same way on all systems, regardless of operating system. This means we should see the same results on Macs as we do on PCs and other platforms.
AIR can create and interact with a local database (SQLite), as well as write and read files from the user’s hard drive. This allows developers to create applications that can function even without the need of an internet connection.
On top of the remarkable features noted above, AIR also features:
- To open a file, simply drag and drop a file over the AIR application;
- AIR applications can run in the background;
- Applications can send tray notifications, much like when a user connects to MSN Messenger;
- Applications can be included within the start menu in the same way as other common applications;
- AIR can detect whether the system is connected to the internet or not;
- …and many more.
But what is it made of?
A few notable drawbacks
While AIR has many wonderful qualities, it is not without its faults. It is not yet suited for just any type of desktop application. The current version is 1.5, which means it is still in its infancy. AIR applications can on occasion take up a lot of memory, and it can sometimes run rather slow. Accordingly, its use should be limited to building widgets and small sized applications.
However, even with these limitations, AIR is a great tool to have in your toolbox. I hope you now have a better understanding of this emerging technology.
I also have to give some love to StrategicText, because he did some editing to the text and made it even better.
The last two weeks I got to play around with AIR for the first time. I was fun, but it was also a bumpy ride. Bumpy for the fact that I had a deadline and because it seems that every step of the way there was something that wasn’t what I expected (which I guess is normal when learning something new). What I want to gather here is some quick facts and links about what you should know to get started with AIR.
First things first, you have to be able to compile a swf using AIR APIs. I think this is fairly easy to do with Flex Builder, but I didn’t want to use it. I didn’t want to use Flash either because I forsee in the future that multiple persons could work on the project at the same time and FLAs are not that teamwork friendly. My final choice was tu do an Actionscript project using FlashDevelop. What got me confused, at first, was the fact that when you want to create such a project in FlashDevelop; it is called an AIR AS3 Projector. Well once you are past that, the rest is done for you: the folder structure and the bat files to package your application. Now you can get started.
Since it was my first AIR project, there was one thing that I really wanted to do right: the Update functionality. Since an AIR application has the ability to update itself, if you do that part right, you can make mistakes on the rest since you’ll be able to send updates later. I encourage you to read this article from Adobe Development Center on Using the Adobe Air Update Framework. You will also need the applicationupdater.swc library that is inlcuded in the Adobe AIR SDK to use the update framework. Another quick thing about the update process is that will updating AIR will erase everything in the folder your application was installed to, so if you want to save stuff from previous version, you will have to move them first.
Because of the previous fact, you may want to know if it is the first time ever that the user open your application. Detecting that is easy once you think about it, but is not obvious when you come from a web background. What you do is check if a certain file (from your application) has been created on the user’s computer. If it is created that means the user has started the application at least once before. If not, it means this is the first time so you go ahead and create that file and do everything you need for the first run. I have been very vague about the file, but my guess is that every application will need to move at least a config file from the installation folder, so you use that config file to do the check. More information in the help for Adobe.
The rest of what you might want to do should go smoothly: creating a chromeless application, implementing the grag, minimize, maximise and close function is all a breeze when you consult the help files. Well I said the rest but there is still something that is not so obvious; working whit SQLite.
I am used to working whit database, before doing full time flash I also did some PHP/MySQL, but AIR/SQLite is a different beast. It is mostly details but when you add them up, it makes a pretty big bump (to refer to my previous bumpy ride). You can work synchronously or asynchronously, SQLite DATE primitive is a bit weird and you can parametrize SQLStatements. I will write another post about SQLLite optimization later.
Well that is it for now, that should help people used to AS3 find their way quickly while doing AIR development.