I think this is a very important development–Flex is awesome, but difficult to skin out of the box.  These extensions should help make an already killer development framework infinitely more sexy, which is really all that matters (of course!).

So enough of this.  Grab the extensions, and also check out Flex 3 if you haven't already.

A little over a week ago, Adobe officially released Adobe Integrated Runtime (AIR) 1.0 along with Flex 3 .  While I've looked into a AIR a bit in conjunction with Flex apps, I've not really gone beyond that.  

However, with the official release, I decided to take another look.

What is AIR?  As the full name explicates, it is a runtime that can be used to, um, run programs on your computer, mobile device, etc.  So as with Microsoft's .NET framework, AIR allows developers to create programs that can be packaged up and installed on these devices.

However, unlike Windows-only or Mac-Only (or Linux-Only) programs, AIR is ambivalent about the OS.  As long as the client machine has the runtime installed, any application developed in AIR can run on it.  This in itself is really cool, and takes the bite off the exclusivity of OS platforms.

But the coolest part about AIR is that you can leverage different technologies when building applications.  For example, a while ago I built an extremely simple Countdown application using Flex 3.  Easy enough.  

But what if I don't want to use ActionScript 3?  No problem!  Using the HTML, CSS and Javascript skills I already have, I can create an app using ONLY THESE TECHNOLOGIES without any need to learn a whole new language.

Although I really like Flex 3 (and hope to get into a lot more in the future), being able to use regular web technologies to create desktop apps is extremely sexy to me, and will take half the time to develop an application than it would if I were to wrestle what is a still foreign language like ActionScript 3.0.  

But Wait!  That's not all!  AIR platform overcomes some of the weaknesses of standard web-based technology.  For example, in all of my SPRY javascript examples, I generally build datasets from xml data returned from ColdFusion.  Why do I do this?  For one, sometimes the data I need is in a database, and ColdFusion is my means to grab it out.  But most importantly, I use ColdFusion because if I need to return xml data from a remote data source (such as another website), javascript alone cannot do this because the browser security model will not allow client browser cross-scripting.  While this is not a problem for a web-based application (because I can use CF to grab the data, parse it, and pass it back to SPRY), it cannot be transferred to the desktop because not everyone has ColdFusion installed on their computer (although they should…), among other things.

To overcome this, AIR incorporates the concept of "sandboxes."  There are two forms, the Application and Non-Application sandboxes.

The Application sandbox is where the heart of AIR lives, and is tightly restricted because of the level of contact that AIR's

APIs have with the client machine, such as memory resources, file systems, etc.  So trying to do remote scripting in the Application sandbox will be met with angry AIR error messages.

To get around this, you can use the Non-Application sandbox.  Here, remote calls can be easily made, and even functions defined in the Application sandbox can be exposed to use in the Non-Application sandbox.  In short, whereas in the past I could not build a Spry data-set directly from a remote RSS feed, now I can.  So there.

What's that, you say?  You want some more awesome features?  You got it!  AIR comes bundled with a native database–SQL Lite.  

You know what that means–yes, now you can use AIR's javascript-esque API's to create and manage databases and database content.  To me, this is one of best features of AIR, for it removes entirely the need for an external, addon application framework just to interact with a database.  Rather, I can simply gather form data (or Cookie data, or whatever), parse it out with javascript, and use AIR's APIs to create SQL Lite databases that will store the data on the client's machine.  That's pretty flippin' cool, and opens up a huge world of possibilities in my mind for what I'd like to do with AIR in conjunction with my web-based apps.

So yeah, anyway, I'm finding that AIR is extremely cool.  Over the last week, I began development on a little test project (a blog manager) that is, if nothing else, a good training ground for exploring what AIR can do in conjunction with simple HTML, CSS and Javascript.  When I am at a stopping point, I will post it here so that everyone can let me know what they think of it.

A little over a week ago, Adobe officially released Adobe Integrated Runtime (AIR) 1.0 along with Flex 3 .  While I've looked into a AIR a bit in conjunction with Flex apps, I've not really gone beyond that.  

However, with the official release, I decided to take another look.

What is AIR?  As the full name explicates, it is a runtime that can be used to, um, run programs on your computer, mobile device, etc.  So as with Microsoft's .NET framework, AIR allows developers to create programs that can be packaged up and installed on these devices.

However, unlike Windows-only or Mac-Only (or Linux-Only) programs, AIR is ambivalent about the OS.  As long as the client machine has the runtime installed, any application developed in AIR can run on it.  This in itself is really cool, and takes the bite off the exclusivity of OS platforms.

But the coolest part about AIR is that you can leverage different technologies when building applications.  For example, a while ago I built an extremely simple Countdown application using Flex 3.  Easy enough.  

But what if I don't want to use ActionScript 3?  No problem!  Using the HTML, CSS and Javascript skills I already have, I can create an app using ONLY THESE TECHNOLOGIES without any need to learn a whole new language.

Although I really like Flex 3 (and hope to get into a lot more in the future), being able to use regular web technologies to create desktop apps is extremely sexy to me, and will take half the time to develop an application than it would if I were to wrestle what is a still foreign language like ActionScript 3.0.  

But Wait!  That's not all!  AIR platform overcomes some of the weaknesses of standard web-based technology.  For example, in all of my SPRY javascript examples, I generally build datasets from xml data returned from ColdFusion.  Why do I do this?  For one, sometimes the data I need is in a database, and ColdFusion is my means to grab it out.  But most importantly, I use ColdFusion because if I need to return xml data from a remote data source (such as another website), javascript alone cannot do this because the browser security model will not allow client browser cross-scripting.  While this is not a problem for a web-based application (because I can use CF to grab the data, parse it, and pass it back to SPRY), it cannot be transferred to the desktop because not everyone has ColdFusion installed on their computer (although they should…), among other things.

To overcome this, AIR incorporates the concept of "sandboxes."  There are two forms, the Application and Non-Application sandboxes.

The Application sandbox is where the heart of AIR lives, and is tightly restricted because of the level of contact that AIR's

APIs have with the client machine, such as memory resources, file systems, etc.  So trying to do remote scripting in the Application sandbox will be met with angry AIR error messages.

To get around this, you can use the Non-Application sandbox.  Here, remote calls can be easily made, and even functions defined in the Application sandbox can be exposed to use in the Non-Application sandbox.  In short, whereas in the past I could not build a Spry data-set directly from a remote RSS feed, now I can.  So there.

What's that, you say?  You want some more awesome features?  You got it!  AIR comes bundled with a native database–SQL Lite.  

You know what that means–yes, now you can use AIR's javascript-esque API's to create and manage databases and database content.  To me, this is one of best features of AIR, for it removes entirely the need for an external, addon application framework just to interact with a database.  Rather, I can simply gather form data (or Cookie data, or whatever), parse it out with javascript, and use AIR's APIs to create SQL Lite databases that will store the data on the client's machine.  That's pretty flippin' cool, and opens up a huge world of possibilities in my mind for what I'd like to do with AIR in conjunction with my web-based apps.

So yeah, anyway, I'm finding that AIR is extremely cool.  Over the last week, I began development on a little test project (a blog manager) that is, if nothing else, a good training ground for exploring what AIR can do in conjunction with simple HTML, CSS and Javascript.  When I am at a stopping point, I will post it here so that everyone can let me know what they think of it.

Well, Adobe has made inroads to solving this issue with the development of their now Labs-interred Thermo.  Thermo is basically the designer's Flex.  Designers can import Photoshop files (and hopefully Illustrator…) into Thermo and begin creating working examples of functionality and animations in Flex.  For example, graphical text boxes can be point-and-click converted to real, manipulateable input boxes; lists of items can be converted to real data-driven lists; and so on.  

The purpose of this, of course, is to bring the design and development community closer together.  Instead of the designer simply handing a flat PSD file to a developer with illegible notes about what they would like the final product to look like (e.g., transitions), the designer can herself create a mockup of the functionality in Thermo.

But the best part is that they can then pass the prototyped version of the application to their developer.  Because all that has been done is managed in clean, well-formated MXML, the developer can spend time dealing with more precise logic and data-manipulation.  

In the final analysis, Thermo seeks to save PSD files from the inevitable doom of a necessary, but ultimately worthless step.  With Thermo, the PSD can become the actual graphical backbone of the application, which was, after all, its initial purpose.

Check out this video which shows some of this .

All this time, I have flirted around with Adobe's Flex 2, an incredibly rich platform for developing ActionScript 3.0 applications.  While I have played around with it from time to time (basically, when I get a new computre–the trial period is only 30 days), I have not really gotten into significant development…until now.  

One of the issues with Flex is that, like javascript, it has not native way to interact with a database.  For this, one needs an application server of some kind, or to create myriad XML files to store data.  Now I've always known that Flex could integrate nicely with ColdFusion, allowing the developer to access independant ColdFusion components to leverage processing logic and database interaction.  However, I did not know how ridiculously simple it was.

So one might wonder what the big deal is. So Flex can easily connect to ColdFusion–so what?  Well, a major issue is Flex Builder's built-in components.  Using Builder, I can create, for example, a slick form–including rich text editor–to create a blog post–all in about, oh, 90 seconds.  In HTML, that would take me a while, especially trying to get the CSS to behave on the form fields (urghh…).  So now, instead of tearing out my hair trying to build and style a form, I'm already done and I can concentrate on creating validation rules.

But what is especially great about Flex and ColdFusion together is that accessing the component's methods is hauntingly similar to how one would do it in ColdFusion natively.

Consider the following example:

The way I see it, the "RemoteObject" that I create is alot like my "cfinvoke" tag in ColdFusion–I point to a partcular component (here "source"), define the method (here "createPost") and finally pass in any arguments that I need to (here the "arguments" Array).  The best part about this, however, is that in all of this, I have not had to use a postback; I've not had to reload the page; and if I wanted (and probably will do) I could fade out this form to reveal some other bit of content in its place.  All seamless, all clean and user-friendly.

Now, if only I could find the $500.00 bucks I need to license it…hint, hint…