AIR does not have a CFML engine. ColdFusion cannot be packaged within AIR apps. Traditionally, we use CF to generate the UI. However, in AIR, typically the UI is pre-designed and packaged. How does ColdFusion fit in, then?

Use ColdFusion apps directly, use ColdFusion as the data provider, or use ColdFusion as the data provider and as a UI provider.

To use a CF web app directly, just wrap it in a frameset. This is so kludgy, I can hardly stand it. But it will work to put your web app in a desktop app at some basic level. I suppose it could be handy since it hides the URL, it can make a more kiosk-ish look. Could also be useful if part of your app is a normal app, but part of it should mimic the web app exactly and you don’t want to rewrite anything.

Better to use CF as a data provider.  ColdFusion is best at connecting with other systems, connecting to remote DBs, etc. Then communicate with web services, XML, flash remoting, JSON.  There is nothing new here, at this point, you just build typical connectivity that AJAX or Flash would use.

Flash remoting would probably be the best when using Flex. Provides a handy proxy-like access to your CFC.  Web services can also be done very easily with Flex.

Now, how about HTML/JavaScript (AJAX) in AIR? CFAjaxProxy, XMLHttpRequest, or plain HTTP (CF returns the data in XML, JSON, or text).

CFAjaxProxy. Makes a CFC available inside AIR app. Creates a JS proxy for a CF component. So on the CF side, you use cfajaxproxy, point it to a CFC, and instantiate the CFC in JS. Now, some initialization code is required. It is generated by the cfajaxproxy tag. So just copy the literal HTML/JavaScript generated by cfajaxproxy, and drop that into your HTML for AIR (just change the URL to the CFC to be the absolute URL; cfajaxproxy will write it as a relative URL).

It wouldn’t hurt to just write some basic AJAX code on the web, using cfajaxproxy, and then copy that to your AIR HTML.

Now what about taking your apps offline? Well, you’ll need to identify what is going to work offline, and store offline data (either to the filesystem or to a local database). Decide how the app will go offline: Modal (distinct offline/online mode, user driven, easiest to implement), or modeless (seamless offline/online mode, most of data is stored locally, better user experience but more work for the developer). Then, synchronization strategy: Manual sync, background client-driven sync, or server-driven sync.

Synchronization and online/offline management can be improved. They will describe more at the sneak peak session. Code samples will be at his website, http://coldfused.blogspot.com.