Adobe AIR 2.0 Preview

October 20, 2009 — 9 Comments

Adobe announced last week details for the forthcoming 2.0 version of their Adobe AIR (of which I’m a big fan). It’ll be released in beta format by the end of 2009, with the official release in the first half of 2010 (theoretically). The updated AIR 2.0 will be able to make use of mounted mass storage devices, like flash drives and cameras, will be able to communicate with native applications running on the computer, should have improved performance, and more.

For more on Adobe AIR, you can check the official Adobe AIR Web site, read this review (of AIR 1.5), or see my book on developing AIR applications using HTML and JavaScript.

If you enjoyed this post, then please consider following me using your favorite social media, the RSS feed, and/or by subscribing to my newsletter. Or go crazy, and buy one or more of my books . Thanks!

9 responses to Adobe AIR 2.0 Preview

  1. Cool, to be honest I am still trying to find a reason to use Adobe AIR 1.5 – a desktop CMS sounded like a good idea but if you are on the net and have a browser you really dont need to use an AIR app. There are still no “killer AIR apps” (tired of all those twitter examples and apps). What have you developed for Adobe AIR Larry?

    • Thanks, Jason, for the feedback. I’ll start my reply by saying that I’m not a salesman by any sense of the word, which is to say that I just don’t have the gene in me to try to convince people of things. If you don’t see/have a reason to use AIR, then there you have it. Also, with so many options out there, I’m not sure that I personally believe in the “killer app” theory. So those caveats being said, I’ll say again how much I like Adobe AIR. I think the desktop CMS is a great example, in fact, any application that ties into a Web site makes a lot of sense. Yes, many of these can also be done in a browser, but then you’re limited to only working online, and possibly with a fast connection, and you have to support multiple browser versions. Plus, for a lot of people, they’re more accustomed to using a desktop app than a Web browser for certain kinds of things. For example, I’ve made several Web-based admin interfaces for CMS sites, using a customized TinyMCE or FCKEditor. But the user still has to be online to use these, they have to upload all the media, which takes some time, I have to make sure it works in whatever browser they may use, and there’s lots of logistics for browsing the server, which can be a pain, and a potential security concern. But when I turn that interface into a desktop app, all of those problems can go away. Plus you can improve the security (only you can change the site and only using this application which only exists on your computer…). I think this is a very common and legitimate use of the technology. I’ve also used it for my own internal purposes, creating software that I previously would have run using PHP on a local server but can now do as a stand-alone application.

      And if you just want to see some useful things other people are doing with AIR (non-Twitter related), check out this list of Adobe AIR apps for designers or any of the showcase apps Adobe has on its site. But again, if you’re not into it, no big deal as far as I’m concerned. There’s enough other stuff out there to be into and enough people into AIR, so it’s all good. Thanks again, Larry

  2. That’s fair enough, if you don’t have a use for a technology there is no point trying to think of a reason to use it for the sake of using it. I have seen that sitepoint post and the showcase.

    “Plus you can improve the security (only you can change the site and only using this application which only exists on your computer…)”

    Had not thought of that aspect before.

  3. I have many years experience dealing with Browser Compatibility issues I have to say that “issue” is fast becoming a thing of the past. IE6 is almost out the door and almost everyone who was using IE7 is now on IE8. There are and always will be some issues but there are very easy work-arounds and many tools to make the process quicker to debug. Flex keeps flogging this dead horse as well, it is beyond annoying for someone like me to read. Browser issues are not that bad, you would have to be either a bad CSS coder or have employed the wrong person if they are still an issue for you.

    The case for Adobe AIR does not need to be made for me, I think it is a great technology and even tried to sell the idea for our client portal to the boss today. (Will be continuing to bring up the idea.)

    The best example application that comes to mind for Adobe AIR would be a booking system that allows you to take online bookings and bookings from a shop front.

    I have always wanted to make desktop applications, Adobe AIR enables me to do that with the skills I’ve been using for years. You can make your own desktop dashboard… hrmmm!

    • Yeah, I can tell the browser compatibility argument annoys you! I completely agree with the idea that a good CSS/HTML/JavaScript developer knows how to work around the problems but I strongly disagree that this is becoming a thing of the past. I just wrapped up a site and spent way too much time getting it to look and behave properly in IE 6 (yes, 6) and Google Chrome, with its 2.5% share. I think that dealing with browser compatibility will ALWAYS been an issue, but it is a manageable one. Just like writing a desktop application means you have to account for different operating systems, which is again do-able, but a pain. Although much less so with Adobe AIR!

      Thanks again for your input!

  4. Haha, it’s just that I have been reading a lot of Flex books and articles recently and it’s the same story and they are very bashful of the issue but the intensity I believe is no longer warranted. The issue won’t stop you from having a great “web 2.0″ application.

    IE6 can easily be your pawn. All you need is a IE6 only style sheet for a few things. After a few years (and many questions from team members) you can notice trends and know what IE6 is thinking (or what it isn’t thinking). Just recently I have changed roles from primarily implementation work (cutting up website designs to HTML/CSS) to now development (PHP). Previously I had to cutup 2 websites a day and they had to work in IE6 and above. Average time spent on debugging was 15-30 mins and most of that was for PNG 24 CSS-only hacks. My whole career I’ve given special note to pixel perfection, it was a good habit to start off with. Many of my old freelance clients requested it. For me personally, it’s just part of the process and not a road block that’s only solution is Flash.

    Have you done any “development time comparison tests” with Adobe AIR and traditional C/C++? e.g. built the exact same application using both technologies? What about HTML/CSS n PHP vs Flex n PHP? It can be difficult to get accurately I know, due to the fact most of us have been using the older technologies longer than the new shiny ones. But it would be interesting to get your experience Larry?

    • I will agree with you about the intensity and that it’s gotten much better than it used to be. I just started using Adobe’s BrowserLab tool for cross-platform checks. It’s very nice (I’ll blog about it separately).

      As for straight-up, apples-to-apples comparisons, I have not performed any (nor would I see the need to for my sake). I’ve primarily used C/C++ for command-line stuff, I’m not expert on using it for GUI apps, although I have used GTK on and off for years. I can’t imagine developing a GUI app in C/C++ is even remotely as fast as using AIR, which is to say I’d be inclined to always use AIR, unless the AIR application couldn’t do what I need it to (due to restrictions in the runtime) or the resulting application was too large to run efficiently as an AIR program. And the cross-platform requirement would make me lean more towards AIR, in those situations. Again, no hard data here, just thinking about what I would use today if called upon.

      As for HTML/JavaScript/CSS and PHP vs. Flex and PHP, I’ve only written the same application in both one time and that’s a hard example to consider because I did all of the hard work and thought and back-end PHP and debugging in HTML/JavaScript. That took a while, like off and on for a couple of days. But then I created the Flex version, with a couple of added features, in a couple of hours. I was stunned by how much faster it was, but I had done much of the legwork already. My inclination would be that for relatively simple things, the two options are comparable, but as the example becomes more “rich” and has more features and more data going back and forth, Flex clearly wins out. It also depends upon how much JavaScript you’re using and whether you’re using a framework there or not. Like populating a table using PHP and HTML is so simple. Populating it from an Ajax request, making it sortable by clicking on headers, etc., takes a bit more effort. Doing all that with a framework isn’t that bad. Doing all that in Flex is really quite easy.

      Hope that helps and thanks for the continued conversation!
      Larry

Comments are great, but I'd strongly prefer any requests for assistance get made in the support forums. Thanks!