Have you ever wanted to buy something that you knew you’d have to find a use for it after you got it home?
Well, the iPod is an awesome example of that. In ‘02, I knew that I really wanted one but couldn’t really explain its value to my wife. Well, thankfully she didn’t need to hear about its value and surprised me with a 10GB iPod right before a week-long vacation.
I quickly found a use for it (albeit after the fact). Pretty much every day since I’ve had my iPod nearby to entertain/distract/focus me during work hours… Clearly millions of other people have seen the value in the technology since.
Adobe’s AIR is kind of the same way for me. I know it’s great and it’s going to be very relevant in the next 5 years, but I haven’t proved it with anything tangible. I actually am a lot further down the path of understanding its value than I was when an iPod was handed to me, but I have yet had the opportunity to prove it with an AIR project of my own.
First, the value. Flex itself brings the best way to bulid browser-based RIAs. But AIR allows Flex to see its full potential as Flex on AIR is now a way to build fully-featured, client-side applications. AIR can also allow for the deployment of HTML/Ajax based apps, but I prefer Flex.
Here’s what AIR gives you that Flex does not:
- The ability to take a Flex application offline. AIR even provides APIs to easily determine the state of connectivity.
- Access to client-side resources like storage and devices. You can upload files using a browser-based Flex app, but you can’t write files and read directory structures, etc.
- Closer integration of Flex and HTML. The browser is no longer a container, it can become a component within your Flex application. This gives you full access to the DOM. Also, not possible in a standard web browser
So, I am a huge fan of what AIR can do and an even bigger fan of where it can go. But all of my ideas for an AIR application are either super lame (like the majority of my ideas) or way too complex to bite off in an hour-long session of let’s-see-what-fun-can-be-had-with-AIR.
But then, finally, a managable idea was handed to me. I was on-site last Wednesday working with a client who wanted to use Dapper to scrape a bunch of data off of existing web pages and pump it into their inventory system. Having never seen Dapper, and having built several screen scrapers from scratch, I really liked the idea. And I still think the idea has merit, but we decided that with the low number of screens to scrape and the eventual end-users of this tool, Dapper may not be the way to go.
The guy I was working with then had a really cool idea revolving around Google Notebook’s FireFox plug-in. And we were getting even closer to our usability goal.
Finally, it hit me that an Flex/AIR application might do the trick. The UI would consist of empty fields on the left-hand side and then a large HTML container on the right. The user could highlight the content on the web page and click a button in the Flex app which would pull the selected HTML (using JavaScript) into the Flex fields.
My proof of concept (an HTML container, a button and an alert box that displayed the selected text) took 15 minutes to build. That’s from no AIR project to a distributable AIR file. It was also a pretty useless application.
But when I resumed the next day, it took only 45 more minutes to present a usable interface including a feature that pulled all of the images out of the HTML page for selection inside of the Flex app.
That illustrates the third feature of AIR, tight Flex-HTML integration that’s easy to leverage. And it also demonstrates the fourth feature of AIR… it’s really, really easy to build an AIR application. 1 Flex Application .SWF file + 1 .xml AIR descriptor file = all you need.
Now, on to taking this Scraper utility to the next level…