Christian Cantrell

« January 2008 | Main | March 2008 »

February 25, 2008

What you might not know about AIR (yet)

If you're reading my blog, I'm going to assume that you already know what AIR is. If you don't, have a look at the official AIR product page before reading any further. Rather than tell you what you probably already know about AIR, I'd like to mention a few things that people might not have realized yet.

AIR isn't just another Adobe product. It isn't just a new tool or utility. It's an entirely new way to develop, deploy, install, and use desktop applications. Entirely new. I really can't stress this point enough. In the world of software, new products are launched all the time (if you don't believe me, just follow TechCrunch for a few days — it's staggering), each with a marketing team that wants you to believe that their technology is nothing less than revolutionary. So when something completely different does come along, it's sometimes hard to distinguish. How successful AIR will be and how quickly the technology is adopted is an entirely different topic, but there is absolutely no doubt that it's new and disruptive. I could easily write an entire white paper on the importance of AIR, but for the sake of brevity, I'll focus on three main points:

• Web technology on the desktop really makes sense. When I first heard the concept of running web technology on the desktop, I was admittedly skeptical. This was several years ago when my perspective on web applications was that we were all willing to sacrifice things like usability, richness, offline support, and features for the convenience of not having to host and update the apps ourselves, and the power of having your data accessible from any computer. That isn't even close to a valid assessment anymore. Thanks to Flash, Flex, and some truly amazing work done around JavaScript and Ajax, there are many applications on the web today that completely blow away most desktop experiences. The old adage of necessity being the mother of invention helped the web transition from a handful of HTML form controls and slow page refreshes to a rich, interactive, intuitive experience. The idea of unleashing those technologies and the developers working with this technologies on the desktop started making more and more sense, especially since it finally gives the final advantages that desktop applications had over web applications to web developers: local APIs, and offline support. The one thing web apps couldn't do were things like local file access, system notifications, native drag and drop, etc., and of course, no matter how great the web application was, if you didn't have an internet connection, you couldn't access it. This is what we mean by bridging the gap between the desktop and the web. AIR lets you have the richness of the web and the power of the desktop, and you can still do things like easily update your applications and store your data remotely. And you can do it all whether you're online or off.
• Cross-platform is real. For a long time, the idea of running the same applications and getting the same experiences on Mac, Windows, and Linux was a little bit like the idea of world peace. Everyone seemed to agree that it would be great, but it never seemed all that realistic. I think it's safe to say that AIR is the first technology to really get the idea of cross-platform right. I shouldn't over-idealize this aspect of AIR, however. To be perfectly frank, there are still challenges with building 100% cross-platform applications. Menuing systems work differently on Mac and Windows, and all platforms have concepts and conventions that other platforms don't have (system tray, dock, etc.). But I have written at least a dozen fairly full-featured AIR applications since we started working on the runtime, and I have never come across a cross-platform problem that I couldn't solve. In some cases, I've had to write layers of abstractions, and in some cases I've opted to completely avoid things like menus and focus instead on making functionality better integrated in the UI (which I believe is the trend in software development anyway — look at Microsoft Office 2007, the iPhone, and many of the best Mac applications). But the extra work I've had to put into making sure my apps ran seamless across platforms was often nothing more than an afterthought, and certainly negligible compared to the advantages of anyone on almost any desktop system being able to run my app. This point was really driven home when I first started using AIR on Linux. I'm a big Linux fan, and the idea of not just being able to run the same apps on Linux that I run on Windows and Mac, but actually develop those apps on Linux as well, is incredible satisfying and liberating.
• Today there are millions of new desktop developers. The last thing I want to mention is that I feel like we just opened the floodgates on the desktop. I feel like we just did to the desktop what the printing press did to education, or what flexible emulsion film did to photography. I don't know how many web developers there are out there, but I'm guessing there has to be millions. However many there are, there are now that many more desktop developers. Take a second to think about what that means. Someone with knowledge of HTML, JavaScript, Flash, or Flex can now build applications for the web, for Mac, for Linux, and for Windows, and all they have to do is learn a few new simple APIs. (I don't want to speculate too much in this post, but there are plans to bring AIR to even more places in the future.) Not only can they developer for all those different platforms, but they can develop on all those different platforms using all the same IDEs and tools they used before, and they can get everything they need (SDKs, etc.) entirely for free. Web developers have just been given an entirely new world, and everything they want is there for the taking.

I've been in the software business for 10 years, and I've worked on all kinds of projects. I've been fortunate that I've never had to work on a project that I didn't like or believe in. But I believe AIR is the most important project I've ever had the good fortunate to be involved with. I can't wait to see what the world does with it.

Posted by cantrell at 09:38 AM. Link | Comments (6) | TrackBack | References

February 21, 2008

AIR Development on Linux

I used to use Linux every day for about four years before coming to work for Macromedia/Adobe (over five years ago). My favorite tools were Screen, Pine, Centericq, XMMS, and Vim. My window manager of choice was FVWM which was doing fast and stable virtual desktops before anyone even knew what virtual desktops were. But I had to leave all that behind when I moved over to the world of Flash and Flex development. Fortunately I had OS X to help me make the transition, but as much as I've come to love Macs, I still sometimes miss the good old days of Linux.

So a couple of weeks ago when I heard that the Linux version of AIR was ready for testing, I dropped everything I was working on and set up Ubuntu, Flex Builder on Linux, and installed AIR. I keep all of my AIR application code on Google Code, so I installed SVN, checked out the latest versions of all my projects, and started running my AIR applications completely unchanged on Linux.

I use a MacBook Pro for development now, and I have Windows XP and Ubuntu virtual machines set up. I now have complete development environments including Flex Builder, AIR, and SVN on all three virtual machines, and all of my apps run across all three different operating systems (with the exception of some apps which use features we haven't implemented yet on Linux — it's still in pre-beta).

It's amazing enough that I'm writing desktop applications using web technologies like Flex, ActionScript, JavaScript, and HTML, but to be able to deploy them with no changes across Mac, Linux, and Windows is seriously revolutionary. The idea that I can actually go back to using Linux day to day, and still be able to do AIR and Flex development is very liberating. And now wherever there are gaps in Linux applications, I can just build them myself in AIR (like Lineup, an Exchange calendaring client that will enable me to view my meeting schedule on Mac and Linux as easily as on Windows).

As I said, the Linux version of AIR still needs more work, and is currently in pre-beta. If you're a Linux user, and you're interested in getting your hands on early builds and helping us do some testing, check out this post by James Ward to find out how to get involved.

Posted by cantrell at 12:14 PM. Link | Comments (5) | TrackBack | References

February 20, 2008

Transparent HTML in AIR

I keep forgetting how to do this, so I'm going to blog it once and for all.

First of all, it's possible to have transparent HTML in AIR. I don't just mean changing the alpha of the HTML Flex component. That's one way to do it, but that's not terribly useful. I'm talking about entirely knocking out the background of an HTMLLoader (formerly know as the HTMLControl) so that you can do very cool things like custom HTML chrome. I like it because I often use the HTMLLoader to render large amounts of text in AIR, like "help" or "about" pages, so making the background transparent can let me do some cool effects and presentations.

There are three things you need to know about making HTML transparent in AIR:

1. Set the paintsDefaultBackground property of the HTMLLoader to false. This specifies whether the background of the HTML document is opaque or not. If you're using the Flex HTML component, you can do this using the paintsDefaultBackground attribute on the HTML MXML tag.
2. Make sure that your HTML document does not have a background color explicitly specified. For instance, setting background-color to anything will prevent this from working.
3. If you're using the Flex HTML component, make sure the backgroundAlpha property is set to 0 (this is the one I always forget). Also, don't mess with the opaqueBackground property.

Ok, now that I have saved cumulative years of searching and trial and error, I expect that time to be reinvested into building even more cool AIR apps!

Posted by cantrell at 09:31 AM. Link | Comments (2) | TrackBack | References

February 14, 2008

How to Make Application Icons Appear During AIR Development

If you've started building an AIR application, you probably noticed that your application icons don't appear when launching your app via ADL (ADL is the AIR Debug Launcher, and is what Flex Builder uses to launch and debug your apps). Platform specific icons are created from the PNG files referenced in your application descriptor file at install time which means they aren't available during development. It would obviously be too costly to generate those icons every time you wanted to launch or debug your code.

This typically isn't an issue because you usually don't need to see your application icons during development. However, there are times when you do. For instance, if your application uses a dynamic dock icon, it's nice to be able to see the "before" icon before seeing the "after" version. I've also found that it's nice to be able to try an icon out for a while during the development process to see how you like it over time which means it should appear every time you debug or launch your app.

Fortunately, I've found an easy way to make this work. Here's what you do:

1. Make a copy of your application icon and name it something different. One version should be referenced by your application descriptor file, and the other will be compiled into your application. (You don't technically have to make a copy of the icon, but when generating a release build of your application, Flex Builder doesn't copy over embedded resources which means your application icon will be missing. Trust me when I tell you that it's easier to create a copy and avoid this whole issue.)
2. Compile the copy of your application icon into your application using code like this: [Embed(source="assets/application.png")] public var appIconClass:Class;
3. In your application's initialization code, create a Bitmap instance of your icon like this: var appIcon:Bitmap = new appIconClass();
4. Set your icon like this: InteractiveIcon(NativeApplication.nativeApplication.icon).bitmaps = [appIcon];

This code is a little oversimplified because it doesn't take platform differences into account. A more complete implementation might do something like this:

1. Check to see what kinds of icons the client supports. You can do this with the NativeApplication.supportsDockIcon and NativeApplication.supportsSystemTrayIcon APIs.
2. Scale the Bitmap to the appropriate dimensions for the platform.
3. Set the icon(s) using the NativeApplication's icon property.

Since I usually use the Cairngorm framework, I like to create an UpdateIconsCommand which takes care of creating and setting dynamic icons for me. I also like using the as3notificationlib project to help encapsulate some of the platform differences in setting icons.

For a real world example of setting dynamic icons, see my Exchange calendaring application called Lineup (currently being updated to work with Exchange 2007). It sets icons at runtime and even dynamically generates custom icons, all in a way that works well across platforms.

Posted by cantrell at 09:50 AM. Link | Comments (5) | References