Two years ago I started a project called RaceTab, as a meet manager for track & field and cross country races.  For the first two versions of that free software I have developed it using Microsoft Visual Studio .NET and it's been pretty great.  I love Visual Studio for what it is and use it exclusively for the software I write for the service industry.  It is truly a joy to develop in with its easy layout creation and intellisense, among other things.

But one major weakness:  it is not cross-platform.  Sure, sure there's Mono, but the average person can not get that going and some of the best things like the My namespace (Visual Basic .NET) are not available or at least are limited.  So since the most common question I get is "When is the Mac version coming out?" (and I got tired of answering: "NEVER!"), I have decided to develop the next version using Adobe Air.

What is Adobe Air?

In short, it is kinda of like Microsoft HTA 2.0 (for those of you old enough and geeky enough to know what that is!!!).  It allows you to take your HTML/CSS/Javascript skills and use them for a desktop application.  You are essentially developing a web page that runs locally and has access to the local file system like a desktop application.

What about Google Gears?

This is the most common thing that other developers have said to me when I tell them that I'm going with Air.  Because of Google's clout, more people seem to know about Gears.  While they are similar in concept, they are really not the same.  First of all, the approach is totally different.  Google Gears is primarily a way to make your web page available offline.  It runs in a browser and has some cache and a local database to store data so that when you are offline you can still function.  When you get back online it syncs that data back up.  So your program is still living on the web... it is still a web page first.  Adobe Air on the other hand does not run in a browser and does not start with the concept that there is a server you are running off of in offline mode.  It is a desktop application first.

What can Adobe Air do?

You can read and write to the file system.  You can create desktop shortcuts, associate file types with it, create task bar items, create native program toolbars, native file save/open dialogs, etc.  Pretty much everything that you can do with a .NET application.  Usually you are going to work with a SQLite database to store the application data and Adobe Air ships with built-in functionality to converse with it.  You have access to all of the same javascript language that you are used to on the web, but it has been extended with additional features for the desktop functionality. 

It is built on top of the Webkit (think Safari and Chrome) codebase so it renders HTML beautifully.  A really really wonderful change from developing for the internet is... YOU ONLY HAVE TO WORRY ABOUT ONE BROWSER!  Since everything is viewed through the eyes of Webkit, you just have to make it look good and work in that browser.  No more hours of testing.  That also means you can use Webkit-specific CSS and Javascript without feeling guilty about it or doing hacks.  Webkit has some nice things like rounded corners in CSS that you should check out.

What sucks about it?

I guess Adobe was trying to make things secure.  So they put this thing in a little sandbox, which is fine.  But they also implemented some security features which are very frustrating at times.  You try to do some innerHTML calls or other write functions to make the page dynamic and interactive and BLIP... Javascript security error.  They were concerned with essentially code-injection attacks I guess and so disabled certain abilities.  That means sometimes you have to find creative work arounds and also means that it breaks many of the cool javascript library tools and controls from Dojo, Ext, and others.  I found even the libraries that claim they support Air aren't easy and you have kind of hack workarounds still to get it to go.  I HATE THIS, ADOBE!

It's good that they thought of the users, but they need to trust the developers.  We are not developing web pages.  We are developing applications.  And if you create Air with that premise then you need to treat it like an application.  Microsoft doesn't put limitations on .NET applications... it's up to the developer of the application to be smart (and not malicious themselves of course) and the user to only install applications they trust.  Adobe, I feel, kind of treats us like children in this case.  I hope they lift these restrictions.

Where to Start

Start out on the Adobe Air web site and start reading.  There is some good documentation online, but not enough of it.  So I actually went out and picked up a book.  It was the only Air book at the bookstore so it wasn't that I necessarily researched and looked through them and picked out the best one, but I did buy Adobe Air for Dummies and it is decent... although it wouldn't have been my first choice if they had all of the ones I saw on Amazon at Borders.  Oh well.  It helped me though.

Get Coding and Best Practices

The first thing you should probably decide on is what Javascript library (or libraries) to use, because you will need them!  If you don't use one then your interface is going to be pretty flat.  It's nice that it's like a web page, but you want to make it more like a progressive web page or a web-desktop hybrid application.  Standard HTML tools just don't let you do that... so get yourself a library.

Which did I choose?  Actually after experimenting with a few different ones and being frustrated with them for various reasons (the biggest reason being that certain features didn't work with Air's security constraints), I decided to write my own.  I am still early on in my Air development, but I will probably release my Javascript platform on this site at some point.  I am calling it "My" (inspired by the Visual Basic .NET My Namespace) so I address things like My.Air.Database and such.  It has tools for file management, database connection object, and also non-Air specific things like DOM tools and user interface dialogs and such.  I think it's going to be a good project that people will like, taking my background from a number of technologies and melding them.

Okay... next... each "screen" in the program is going to be an HTML file.  I view this like a form in Visual Studio.  So what you want to do is have three files for each screen:  the html file, a javascript file, and a CSS file.  Name them all the same and put them in the same directory.  Visual Studio does this, even if you don't see it, to separate the design for the code.  We are doing the same thing... the content and structure are the html file, the CSS file does the design, and the code is exclusively in the js file.  Don't get tempted to put ANY javascript code in that html file.... no, not even onclicks.  I don't even have any href values in the html.  All actions the form takes should be defined in javascript.  All design elements should be defined in the CSS.  Period.

That does not mean of course that you can't have a master stylesheet as well that does some common styling elements across your entire application.  Totally.  Do that too.  But keep the separation of structure, design, and logic separate and you'll be happier in the long run!

Another definite "do" is to utilize namespacing and javascript objects.  Don't take the easy route and just do your typical javascript functions.  Do it right now and keep your application clean for later.

Alright... that's it for now.