Adobe’s AIR may leave customers deflated
Adobe's Adobe Integrated Runtime (AIR) was launched earlier this month. Kevin Lynch, chief software architect, called it "the best of the web and the best of the desktop come together". Unfortunately his statement does not stand up to scrutiny.
AIR is not useless. Flash is a great multimedia runtime, designers love it, and AIR lets you take Flash applications and install them into the desktop. It does not stop there. AIR also lets you take an HTML application and install it into the desktop, because it includes an open-source HTML engine called WebKit. This is where the problems start, however. It is all a touch schizophrenic, and there are two separate AIR development kits, for HTML and for Flash. AIR actually includes two JavaScript engines, one in Flash and another in WebKit. Adobe has lost its focus and is trying to do too much in one product.
HTML applications are better kept within the browser. The AIR implementation is hobbled, particularly in its lack of support for plug-ins, with only Adobe's own Flash and PDF allowed, and the benefits are small. It is true that you get full access to the file system, but even browsers can load and save documents.
Adobe should have reserved AIR for Flash applications, but even here "the best of the desktop" is a stretch. AIR applications have no access to native libraries, which ensures cross-platform compatibility, but also means weak printing, and little integration with other applications beyond clipboard support. Considered purely as a desktop platform, AIR is poor compared to either Java or .Net, which have richer runtime libraries and greater extensibility.
Another issue is database access. AIR has a local database engine, but if you want to interact with a database server, the only option is web services, whereas other platforms have fast native drivers.
The most compelling benefit of AIR applications over browser-based equivalents is offline capability, but here Google has changed the rules with its Gears engine that lets browser applications also work offline.
If merely running outside the browser is enough, then AIR fits the bill. It will have a niche, particularly for consumer applications, but judging by the current beta it is hard to find many good reasons for enterprises to use it in place of Java or .Net on the desktop, or web applications running in their more familiar home, the browser.
source: http://www.itweek.co.uk/itweek/comment/2192884/adobe-air-leave-customers
TheWarp is Aggregated at:
Blog Listings
Add to your RSS reader:
http://mmflash-2007.blogspot.com/
http://ledgeswarps.blogspot.com/
http://thewarp2.blogspot.com/
http://fallphoto.blogspot.com/
That's my two cents. Allow air to access the OS and people will start writing all kinds of crazy things to extend it.
Right now, I use zinc for everything because Air doesnt have this kind of support -- that would change if adobe opened it up.
The moment you allow for system-specific development
you sorta kill the idea of cross-platform delivery, which to
me is one of the big bonsues of AIR. I can leverage some
OS native UI elements, but other than that, its keep
cross-platform. I can already do system-specific development
in a number of other tools.
Native-code extensibility is a tricky problem -- Shockwave saw some Windows-only sites open up, for instance -- and it's not attempted in current AIR work. If you need to get your own OS-native C onto someone's machine, you might want to look at using a Projector-like packaging instead (Zinc, etc).
... oh! I see! You just copied Tim Anderson's text that was written somewhere else. I've been engaging with him on his own blog, but he doesn't have these odd opinions expressed there yet:
http://itwriting.com/blog/
jd/adobe
You're totally right and correct.
However, the problem is there is no way to extend it right now with plugins so developers could implement cross platform solutions hardware wise, etc.
Flash has a very unique ability to make great looking interfaces. What if I want to make a touch screen system to work with a com port. I would like to have an integrated application that lets me do this and not have to resort to tools like zinc, etc. That's a BIG market btw.
People want their stuff to look good and flash does that.
If AIR wants to go farther (which is what I want) making it so developers can write their own software to extend it to the hardware, etc. I know its going to be cross platform - but what if we're only developing for a specific kind of system which is going to go out to 11,000 purchased computers. We have an exact target OS, etc. WE can then write our own software to work using AIR to go beyond the cross platform aspect and put some com port access, etc.
Im not saying lose the cross platform aspect, but allow developers the freedom to write what they need to get the job done using C++ plugins, etc. If they need to extend it, then they know that the only thing that needs modification for a different OS is the C++ they wrote.
Then you would have a killer app.
Adobe should do a survey and find out if this is right.
In my line of work Im dying for something like this and AIR would be there if it allowed extensibility.
Having adobe behind making a software dev tool which loads of plugins and features would be awesome. If adobe had 200 guys working on this full time this would totally be a killer app. WPF / WPF e cant touch the UI making ability of flex and flash. If we could extend it with air that would rock.
If you're going to target 11k platform specific computers that you control, then AIR might not be the right solution for you. If you're targeting a specific OS, and you already know Java and/or .NET, then perhaps those are better options. AIR isn't for everybody or every application, but rather a tool for HTML/Flash developers when they need their amazing Web 2.0 Killer Application to go further and do more.
That being said, you could put a light socket server on the system for the native layer you need. Write the vast majority of the UI in HTML/CSS/JS or Flash/Flex/AS3 and then tap into the socket server when low-level access is needed. A little MSI action around this little socket server and you'd be good. It's not a far stretch from what IntelliSea does as an example to control entire yachts in real time.
I think it'd be unfair to suggest that Adobe is blind to this feature request. There's no doubt we see the need, but there's really very few who have ever done native extensibility well, and are still around to talk about it (JNI is horrible and does anybody remember the phrase DLL-hell?). What would be the repercussions if in 1.0 we messed up and nobody liked our implementation? Would we be sacrificing the 80% audience for the 20% of people that want COM access? Would AIR then never succeed? What then?
Not that we would, but what features would you be willing to strip out for native layer integration? Would you lose cross-platform? Would you lose native drag and drop? Would you lose native clipboard support? Would you lose the ability to have full control over native windows (i.e. chrome, modal, always on top, etc.)? Would you lose system tray/background processing?
Notice I didn't even mention offline support... there are more features than just offline.
It easy to complain that a 1.0 release doesn't have your favorite feature. It's far more challenging to step into the shoes of the product team and figure out where the trade-off needs to be had. You do have a limited number of man-hours, and you do have a product to get out the door. What do you do? What do you do? (smile)
If you can be this vocal about where AIR falls short, I'd be interested in your ideas around how you'd change it.
Regards,
Kevin Hoyt
Adobe Systems, Inc.
Everyone makes mistakes, as do you:
1) "there are two separate AIR development kits"
These will be unified, I imagine, after the beta.
2) " if you want to interact with a database server, the only option is web services"
There are ActionScript classes for talking directly to databases.