My Love for Adobe AIR Fades

Like a High School romance I believe my love for Adobe Air has fallen by the way-side. Like many of you I saw the huge potential of Flex Apps on the desktop, all the cool amazing things I could do and all of the amazing new capabilities. I was drooling to write my first AIR apps after MAX Vegas...

Then reality hit me after recently being charged with creating several Adobe AIR applications; 1 large and 2 small ones. I love flex, I love ActionScript, I even still really like the Air Runtime. AIR truly allows you to do some things with the client side computer that will never be possible via a web browser. The local database, file extension capabilities and encrypted file store are a few. Also you can run larger applications faster and you can easily write agile “sometimes-connected” applications.

What is the reason for my waning love affair? It's really very simply: capabilities!

Adobe has tried so hard to lock down AIR to avoid the possibilities of someone writing a malicious program that they have turned it into a small shadow of what it COULD be.

ZERO ability to make system API calls
Inability to load DLLs and other Libraries
No registry functionality
Can't launch outside/non-air applications
Horribly locked down and inflexible install process/package
Piss-poor uninstall capabilities

These are just a few of the things that have come to erk me over the last few months with AIR. The more I look at what I can't do with Adobe AIR, the more I realize that there just is absolutely no need for me write an AIR App unless it HAS to support “sometimes-connected” and I can't take the time to write it in anything else!

I understand that every technology has it's place and application; however I think AIR is missing a massive massive market by willingly or even striving at making it's self so ham-fisted just to play it safe. People write malicious VB, C++, C# and so on applications all the time. You don't see any calls out there from the masses: “Oh my god don't download that application, it was written in Visual C++ and might do bad things”!

My few months of working with Adobe AIR has left me feeling the same way about it as I do about Apple and their asinine rules surrounding the iPhone. Adobe can still fix this though, they can still add in the capabilities that I think should have been there from the start. Until then, I will continue to simply use Flex where it kicks-ass the most: the web!

Comments

David wrote on 09/22/09 11:03 AM

I have the same perspective about the limits of Adobe Air, but i found a smooth solution to access dlls, improve installation (or first time run), registry accesss, even complex system api's in windows.
I use Adobe Air for connected applications and multiplatform requirements. And Northcode SWFStudio for the "advanced" issues.

And other wonderful of Swfstudio is the packing inside exe, you can bundle dlls, other exes, and many stuff, extract dynamically, run it, downloading exes, and a long .etc of powerful functionalities.

And comparing to zinc o other similar proyector, this is the best documented of all.

You may think i'm a salesman jaja, but really northcode solve that issues (the only thing is, just work on windows, but mac does not have registry jeje)

Rick Winscot wrote on 09/22/09 11:13 AM

As you say, the current rev of AIR is quite restrictive and doesn't allow for low level system access much beyond the file system.

So... I have a question for you. Do you feel that in order for AIR to be taken 'seriously' Adobe will need to re-wrap the Win32, Mac OS, and Linux (pick your flavor) system API?

If you said "YES!" I wonder if you've had a chance to take a look at some of the incredible tools that have hit the mainstream this last year - namely: Merapi, Alchemy, and Pixel Bender. If you require tight system integration - at this point and time you're going to have to cross that bridge on your own... but there is a clear path.

Russell Brown wrote on 09/22/09 11:20 AM

@Rick: I know there are some other options out there, I was even a beta tester of Merapi. Unfortunately sometimes those bridges are difficult to worth with within the constraints of enterprise licensees and distribution.

At the end of the day though, the fact is that Adobe AIR should be able to talk to JAVA or System API's all by it's self. I shouldn't have to cross that bridge on my own for something so absolutely simple and trivial. Getting something as pathetically simple a Machine Name should not require an outside application

Ryan Stewart wrote on 09/22/09 12:34 PM

Hey Russell,

Thanks for the feedback. We've heard this a lot, so the main focus of AIR 2.0 is more native integration. We want to free up people to do more with the runtime while also maintaining as much cross-platform functionality as possible.

Stay tuned for MAX, hopefully some of the new functionality will make your life easier.

=Ryan
Ryan@adobe.com

Matthew wrote on 09/22/09 12:40 PM

Well, it sounds like a number of your concerns will be answered with AIR 2.0. Here's the first news of AIR 2 coming from the Flash At The Beach conference:
http://www.flashmagazine.com/community/detail/flash_on_the_beach_2009_day_1/

As Ryan Stewart mentions, it looks like a lot more info and perhaps a beta or a preview will be available shortly at MAX 2009.

Rob Christensen wrote on 09/22/09 12:52 PM

Ryan said it well -- we will be sharing additional information on AIR 2 and other related projects at MAX this year. If you are not able to attend MAX, please be sure to visit the Adobe AIR team blog for more information.

http://blogs.adobe.com/air/

Also, please drop me an email if you are interested in our prerelease program.

Product Manager, Adobe AIR

Russell Brown wrote on 09/22/09 1:49 PM

Well then I'm looking forward greatly to AIR 2.

I haven't seen it really talked about else where much, but uninstaller improvements would also be fantastic. I have one app now that makes heavy use of local storage, yet on uninstall, they are all left behind. More options in the *-app.xml for this would go a long ways towards feeling more 'professional' (not to be derogatory).

@Rob: I will be in contact, thanks!

Andrew wrote on 09/22/09 2:06 PM

I certainly understand the dangers of locking down a tool to the point of it not being useful, but I'd like to comment on something very important about your criticisms:

# ZERO ability to make system API calls
# Inability to load DLLs and other Libraries
# No registry functionality
# Can't launch outside/non-air applications

Implementing ANY of these would make AIR Windows only. Neither Mac OS nor Linux have a registry or anything like it, and any kind of locally installed library, system call, or application binary is obviously going to be platform specific. Personally, my real love of the AIR platform is the practical portability of it - unlike the merely theoretical portability of languages like Java, Adobe has done an amazing job of integrating the AIR runtime environment into each target platform in an intelligent way.

# Horribly locked down and inflexible install process/package
# Piss-poor uninstall capabilities

I can only speak from an end user's and not a developer's perspective, but I was actually quite impressed with the level of integration that AIR provides with uninstallation.

In Windows, you remove AIR applications using Add/Remove programs, just like other programs. In Linux, you use your distribution's build in package management tool. In short, you uninstall AIR applications just like you'd uninstall any "normal" application, no matter what platform you're on.

I'm curious why my experience has been so different in this regard.

Russell Brown wrote on 09/22/09 2:21 PM

There are great qualities for something to be portable across all platforms. However: If you need to remove massive amounts of abilities in order to be portable, who cares!

In my case I have say 10-12 thousand computers on site. Every single one of them runs windows. In my case I have to write a custom bridge in order to get the functionality I need out of Adobe AIR. This does nothing but a disservice. There are lots of people in my shoes as well who are programming for a known quantity.

Just because I as a windows shop can't use MAC abilities doesn't mean they shouldn't be exposed for those who run mac worlds.

This would leave Adobe AIR as portable if programed to do so. I don't want someone else to determine what my programming abilities are... I say open it wide open!

If I want to alienate a group of computers by my programming that should be on me, not on Adobe. Give me the ability, but don't force my hand either!

read my above comments on uninstall, but the fact that install and uninstall are completely locked down to AIR related files only is not cool. I know there is a way on start-up to detect first run after install/update, but more importantly cleanup is severely lacking.

Andrew wrote on 09/22/09 3:42 PM

"If you need to remove massive amounts of abilities in order to be portable, who cares!"

As someone who works extensively in Linux and Mac environments as well as in Windows, I care a great deal.

I appreciate the ideal, but making platform transparency an optional component of a runtime is effectively the same as removing platform transparency altogether. Programmers won't code for platforms they don't use if you don't make them - the beauty of Air is that they don't HAVE to. As long as you work within Air's constraints, the cross-platform compatibility comes for "free". And the constraints that Air imposes for this benefit are very reasonable.

I'm not disputing that your need for integration with the internals of Windows is legitimate, but I don't think Air is the correct tool for your needs. Platform transparency is the point of AIR, and there are other tools available for platform specific purposes.

Tim wrote on 09/22/09 7:03 PM

Why not just poke a hole in the AIR runtime to allow native calls to be made to a DLL/shared library/JavaScript interface. This could easily be abtracted inside AIR to the point where it looks the same on every platform. If you use that feature you risk tying yourself to a platform. Problem solved. Apps can still be "secure" if they don't use this native interface and everyone wins.

andy matthews wrote on 09/22/09 8:28 PM

Flash magazine just talked about AIR 2.0
http://www.flashmagazine.com/community/detail/flash_on_the_beach_2009_day_1/

It addresses some of your main concerns. I actually read that blog post after reading yours.

Andrew wrote on 09/23/09 9:27 AM

"Why not just poke a hole in the AIR runtime to allow native calls to be made to a DLL/shared library/JavaScript interface."

That's very similar to what Internet Explorer did in the 90's with ActiveX. While I think ActiveX is a very useful tool in a corporate intranet setting, it's done more harm than good on the public Internet, rendering websites broken for everyone who's not in an IE-and-Windows environment.

Maybe the solution is a special version of the Air runtime for intranet environments, similar to how Sun makes different versions of the JRE for different environments. I think it's important, though, that Adobe avoids letting Air get tied too tightly into particular platforms.

Adrian Parr wrote on 09/24/09 11:11 AM

You can see Mike Chambers' slides from Flash on the Beach 09 here ...

http://www.slideshare.net/yagizgurgul/advanced-desktop-development

Or you can download the presentation as a PDF file from here ...

http://www.mikechambers.com/blog/files/presentations/fotb2009/advanced_desktop_development.pdf

Brett Kromkamp wrote on 10/04/09 5:21 PM

I am developing a combined Adobe Flex and AIR application to manage and organize knowledge, based on topic maps: http://www.quesucede.com/page/show/id/polishedcode. Furthermore, the actual topic map engine was developed with ActionScript 3 and uses SQLite as a backing store (for object graph serialization and de-serialization).

My Love for Adobe AIR Fades

Comments

Write your comment

Categories

Monthly Archives

Feeds