So, with Apple preparing to hold an iPhone Software Roadmap event this Thursday, people are eagerly anticipating news about how Apple will handle an SDK for the iPhone environment.

Many developers were frustrated–and many web developers had our curiosities pleasantly piqued–when Apple initially announced that “software” would be available for the iPhone in the form of Ajax web applications. Naturally, many of the disappointed folks were irritated because the web platform is something that they’re entirely unfamiliar with, probably having backgrounds in Objective C or something similar; probably a minority were disappointed because their target application legitimately could not be powered by HTML and Ajax.

That said, it is indeed a very thought-provoking concept: Using web technology as your application environment. As most web developers will attest to, there honestly isn’t that much that a typical application does that cannot be accomplished with web technology. With the advent of Ajax frameworks, applications built with web technology can have very similar responsiveness and dynamics of a “classic” application. Especially when you remove the burden of cross-browser compatibility, in the iPhone’s case.

But with the iPhone/iPod Touch scenario, it is irritating that the application has to reside in Safari and has to be loaded off the web. It almost feels as if Apple was trying to push something that wasn’t…quite…ready. Something like AIR!

AIR accomplishes everything that Apple was suggesting for the iPhone environment, but for the desktop. Use web technology, but write a “compiled”, stand-alone application that really doesn’t even have to use the web. Use HTML. Use Ajax. Use Flex and Flash. Have a nice encapsulated application on your desktop. Especially when you throw the Flash technology into the platform, it is now a very capable environment for a large variety of applications, without being constrained to the browser. Wouldn’t it be great if that same cross-platform environment, AIR, worked on the iPhone as well?

Oops, Flash technology isn’t currently supported by the iPhone. That is actually another source of contention. And the AIR environment does lose some of its punch without Flash and Flex, even though its HTML/Ajax implementation can do a very decent job with most typical applications.

Steve Jobs has made it clear that he likes the idea of web technology powering iPhone apps. Now, consider some of the facts. Apple announces the iPhone SDK will be released in February, and then fails to deliver. Meanwhile, Flash still isn’t found on the iPhone, and Adobe “invents the wheel” by getting web technology to drive native apps through its work with AIR. Is there a common theme with these events? Perhaps something like: Are Apple and Adobe working together to get the much-needed Flash technology onto the iPhone and, subsequently, releasing an SDK that uses AIR technology, with hooks into the iPhone system just like AIR currently has hooks into the Linux, Windows, and Mac OS X desktop operating systems?

It wouldn’t be the first time Apple has had to wait for its partners, or take the heat for them. For instance, Apple has clearly been taking a lot of heat for many factors of the iPhone that are clearly not in Apple’s interest, but in AT&T’s.

And this scenario would fit the circumstances around Adobe’s development of AIR. Adobe has been working on AIR since well before the iPhone was released, but AIR wasn’t officially released until February 25, 2008. Even if Apple and Adobe were working closely together, there just hasn’t been enough time for AIR to get released and hooks to be developed to provide iPhone-specific functionality in AIR. Adobe has understandably concerned itself with its own business first. With that done, attention can turn to Apple to support them in concluding their own business.

Of course, this prediction is a reflection of my own desires as much as it fits the circumstances. As a developer that uses Adobe technology including Flex and AIR, and an Apple enthusiast for more than 20 years, I would love to see things happen this way. Undoubtedly we will have a clearer idea of Apple’s iPhone development roadmap after this Thursday.

As if the thought of an “iPhone AIR” isn’t confusing enough.

With AIR development looming on my horizon, it’s nice to see SQLite database apps popping up. Now there is even a SQLite Manager plugin for Firefox!!

I’d say its most clunky aspect is data entry, but otherwise it’s very decent.

Okay, sorry for the dorky play on words. In addition to AIR getting an article from Oliver Goldman over at Dr. Dobb’s, the AIR app called Spaz–one of the AIR Developer Derby winners–and its developer, Ed Finkler, got some attention via an interview over at Ars Technica’s Infinite Loop journal.

Spaz gets more time in the Twitter limelight, and Ed talked up the benefits of AIR. Good job, Ed! I haven’t had a chance to read the whole interview yet, but look forward to reading it soon.

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.