eBay has an AIR app for managing your eBay activity. Launched during MAX 2007, even though it has been around since last year’s MAX. They learned things from it.

First, recognize that desktop apps have much more power than a web app. Why doesn’t everyone do them then? Desktop apps are a lot more expensive to build! Web apps have been getting more expensive as standards of quality rise, but they’re still cheaper than full-fledged desktop apps.

eBay built a fully-functioning prototype in just 3 months. Here are some lessons learned.

1. Start with a good foundation. They started the AIR app because they had already been building web services and API for eBay. So all they really had to do is build a UI. All the web service hype from 2002 was indeed hype, but now, five years later, the concept is finally coming together in a very key and important way. These web services are a great way to connect desktop apps to the web. Store your business logic in the web services that the desktop apps can access.

2. Design takes a long time. Of the first 3 months, six weeks were spent on design alone. Why? (a) AIR offers a lot of freedom. If it was more restrictive, it would have been more straightforward. (b) They were pioneering things. There is not a prescribed manner to address a lot of the questions that come up. (c) Expectations have been raised for user experience.

3. Betas are really useful. I mean real betas, not marketing betas. They have thousands of users in the beta program and they get tons of feedback.

4. The most important AIR feature is… Freedom from constraints of the browser. No frustrating back button. No location bar.

5. Users don’t care about software platforms. A good platform, like AIR, just gets out of the way. Installation, auto software update, startup,  etc. Beta users haven’t complained about these kinds of things–the kinds of things that typically hinder Java apps or some other platforms.

Here are some notes regarding some of the APIs for AIR that were showcased at the on AIR Bus Tour in Chicago.

Window API

Multi-window support. Transparent windows. Z-Ordering. All of the various aspects of OS windows can be applied to your AIR windows. When you use transparent windows with no chrome, the arrow will click through the transparent part of images as well. Nice.

File I/O

Reading and writing of files. No problem. Can launch native file dialogs. Can handle selection, selecting multiples, directories, etc. Async and sync versions of the APIs.  Would use async API if you’re doing very heavy processing.

Database Support

SQLite embedded database. Zero setup, uses a single file. Not for accessing remote databases. This is for using a completely local database. Easily storing data in a database format, but in a local manner.  He didn’t show any examples of this.

Drag and Drop / Clipboard

System level drag and drop support is there! AIR app to AIR app, or AIR app to OS app and back again. Or to the desktop. Can use it for handling URLs, files, text, or even AS objects.  When marking something as draggable, you can assign one or many “transfer formats”. So when you drag an item to another app, if it doesn’t accept one data type, perhaps it will recognize another data type. For instance, if you have an image and a text transfer format, the receiving app may not like the image format, but it recognizes the text format, so it proceeds without a problem.

Service Monitoring

Handles the online/offline support. Will monitor the network interface for changes. Will detect not just network connectivity, but you can test access to a particular service. Do I have access to http://my.address.com/myservice?

Conclusion

These APIs work in JavaScript too because of the bridge, but it all works very well in Flex.  Daniel Dura was the presenter, and hit site at http://www.danieldura.com has a lot of AIR information.

I went to the on AIR Bus Tour in Chicago tonight. Here are my notes from the main presentation.

Enabling more powerful RIAs: Need good runtime performance. This was improved with AS3. Need good development model. Flash is scary for developers. So Flex enables developers to write Flash apps in code. Bridged gap between Flash and developers. Finally, need a desktop runtime. This is where AIR comes in. Web is great, but sometimes you need that desktop connectivity.

AIR tries to be “webby”. So, it’s cross-platform, has an easy install experience. Basically a web-enabled desktop experience. And can use Flash, but can also use your standard HTML/JavaScript skills. And can even combine Flash and JavaScript together with a bridge. So do JavaScript when you want, because it’s more comfortable, but then tap into some Flash functionality when it is needed because you can’t do it from JavaScript. Even supplies a local database functionality: SQLite. So that mentality in web development, which means an expectation to have database connectivity, can continue in the desktop app.

Timeframe. Flex 3 Beta and CF 8 Beta have already come and gone, so has AIR Beta 1. At MAX, we’ll see AIR Beta 2, and of course we already have CF 8 proper. AIR 1.0 is scheduled for sometime in the beginning of 2008, as is Flex Builder 3.

Deployment. Typical web apps just get put on the webserver and you send the URL. An AIR file is just a zip-based package similar to Java, so you could send the AIR file, but that would require that the user has the AIR runtime installed. As a solution, there is an “Express” installation that is web-based (not hard to do). You send them a link to your app, and it will install the app but also check that the user has the runtime. This addresses the issue of deploying to users who do not currently have AIR on their PC.

Once installed, the AIR app is no different than any other app on the platform it was installed in. In OS X, it appears as a Universal app; in Windows, it is a normal executable. It appears in the Start Menu or Applications folder. If it crashes, it dies on its own, it doesn’t bring down all AIR apps. And so on.

Remember http://www.adobe.com/go/air. That address will always point to all things AIR.

Add’l Notes. The FileTypes node in your application.xml file will let you specify your own filetypes that will be registered with the filesystem! So if your app generates a particular file, you can have your files be double-clickable and open in your AIR app. The AIR runtime is not just a webpage on the desktop. It really is an integrated desktop experience.

JavaScript Development. Developing AIR in HTML/JavaScript is very easy, even though you can’t do it with a built-in functionality that Flex Builder has, as long as you use the SDK stuff Adobe provides. The JavaScript bridge makes it pretty easy to access the Flash-specific functionality. The key in development is just using the ADL and ADT command-line tools that are provided for free. Point ADL to your application.xml file, and it compiles it and runs it on the spot. No problem! We wrote an HTML/JavaScript app that takes some user input and writes it to a file on the desktop in only 6 vital JavaScript lines of code.

Aptana. They recommended Aptana as a great IDE for doing HTML/JavaScript development for AIR, since it has some AIR-specific support. Good to know! I love Aptana already, so that is convenient!

This concluded the initial walkthroughs of developing AIR in Flex and JavaScript. This is exactly what I was looking for to understand the basics of AIR development, which took some of the “scary” mystery out of it.