AIR and Desktop need to be better friends
I’ve been playing with AIR since its first public release and I absolutely love the product. It is an awesome tool for web developers hoping to give some desktop presence to their power users.
At the same time, it has many features that make it very attractive to traditionally desktop oriented developers as well … to name a few …
- Very easy to have a simultaneous web and desktop presence, with just one code base
- UI’s built in Flex running in AIR can easily be made to look awesome, some of the cool stuff possible with Flex is really hard to do with traditional desktop UI development technologies.
- Easier control on windows and the ability to make them look a lot cooler than traditional OS windows
- Easy to package
- Easy to use application icon support
- and more ..
But there is one big problem, AIR’s ability to talk to the desktop is very restricted …you cannot make a file launch in its default application .. you cannot control/spawn/kill other processes/threads … you cannot talk to hardware etc etc. All these things are necessities for most desktop oriented software. Its one thing to give some extra ability to your web user by taking your app to the desktop and a whole other thing to make truely desktop oriented software.
The expectations form the AIR platform are continuously growing and people have already started to expect this ability to build true desktop applications from AIR and hence I feel that AIR and Desktop need to be better friends.
That said I do understand the challenges that Adobe faces in supporting this. AIR is cross platform and supporting OS functionality on all platforms can be a hard and mammoth task but i do hope that this has a place in Adobe’s todo list somewhere.
November 25th, 2007
Those are developer desires, but they have to be paired against consumer desires. You’d think twice about installing applications that had device drivers, or ones that could control other applications on your machine.
Prioritizing developer desires over potential consumer desires is what led Microsoft to its security failures in the 1990s. Lots of people thought it would be great to execute JavaScript and ActiveX in email, for instance.
Right now, if your device drivers exposes a web connection you can communicate through server connections. But killing off other applications… that may reduce acceptance more than it increases it.
jd/adobe
November 25th, 2007
John, developer desires often echo customer desires.
November 25th, 2007
I’d also think twice before I installed an application that has access to my File I/O.
To get around the security concerns you could just have AIR notify the user the first time an app tries to spawn or kill another process.
Derek
November 25th, 2007
System Access: UNRESTRICTED
“Installing applications may present a security risk to you and your computer. Install only from sources that you trust.”
John,
The above message shows up when a user tries to install an AIR app, once he accepts, he has already done all the thinking he will ever do. There is no distinction here that tells him this is less dangerous than the .msi or the .dmg that he installed earlier.
File IO can be equally dangerous, If you cannot kill a process, you can easily go and delete all the files it is dependent on to cause an equivalent chaos.
My point is, users today know the security threat that comes with installing on the desktop and once they have allowed you to install an their desktop they expect features from your app that all desktop software have.
Let me give a simple example, recently I was developing an app that needed to launch urls in the browser, now air can do this but after the navigateToURL call its up to the browser to handle the launch …. now IE has this habit of taking new windows to the taskbar and blinking and not showing them to the user … my client hated this …. he pointed me to outlook and said outlook launches all urls in IE windows that never go to the taskbar … it was hard for me to explain to him that I do not have any control over IE while outlook does
This is just a simple example of how users start expecting true desktop abilities once they allow you to install on the desktop.
November 25th, 2007
I always say to myself that this is a 1.0 product. I`m pretty sure we`ll get all this native stuff in further versions. Then AIR will rock even more!
November 25th, 2007
I sure hope so Benz … after talking to people in Adobe I do not get that feeling though and hence this post
I’m not complaining here .. AIR is awesome !!! and I totally love it … this post is just an attempt to get such native support on Adobe’s todo list.
November 25th, 2007
As far as i understand the two top-of-the-list reasons given by Adobe why AIR is not extensible in any way are security concerns and potential platform dependencies.
Security: Mrinal already made valid points. A simple solution would be to add a Shell.exec() method to the API that allows to launch executables. If Shell.exec() would be limited to executables in the application resource directory, i wouldn’t see any security problems.
Platform dependencies: One could for example write local RPC socket servers for all supported platforms that implement all additional, platform dependent functionality which is needed. The AIR application would then just start the local RPC server via Shell.exec() on launch and then call methods on it. Easy and cross platform. I did exactly that for an AIR app i am currently developing and it works like a charm – it’s just a pain to deploy.
I bet my right arm that there will be many developers and customers who are going to complain about the lack of extensibility, and as a result go elsewhere. Is that in Adobe’s interest? Right now it very much sounds like.
November 25th, 2007
I don’t mind the socket sever approach but as Claus mentions …. in the current situation “it’s just a pain to deploy” … you need two separate installers … and the user needs to start two different executables .. the server and the air app … you can make subtle improvements to this experience but it still stays pretty much ugly.
November 25th, 2007
Some thoughts on installer solutions:
http://wahlers.com.br/claus/blog/custom-installer-for-adobe-air-applications/
November 25th, 2007
That is an interesting approach Claus, probably the best option available yet …. but even with that approach the user is going to get a disconnected experience ….. it will still not be one continuously flowing wizard that takes him through the whole installation … he will first see your installer .. then the air runtime installer .. then the air application installer … this is not how professional apps should be.
A truely professional feel can only be achieved if Adobe allows us to extend the AIR application installer … or if they allow us to install air apps silently .. without the wizards ….. i can already hear security alarms … weird
November 25th, 2007
All points above have been discussed a lot over different places (blogs, mailing-lists etc), Adobe has some reason not to do it… Developers have more reasons to ask for this feature…
I hope, Adobe would find a way (usability, HCI, security or whatever) to provide more flexibility…
Let’s keep our fingers crossed, oh no, lets write custom installers (or use one being open-sourced by Claus) and write socket-servers
-abdul
November 28th, 2007
Hey Mrinal, we definitely hear you. From what I gather the main reason it wasn’t in 1.0 was a combination of time/resources and the fact that we want AIR 1.0 to be truly cross platform. Once you introduce native code that gets tricky.
That said, the community has spoken loud and clear about native code. I haven’t seen an official to-do list for future versions, but I know Adobe is very good about listening to the community. If I have any public info we’ll keep you posted.
=Ryan
rstewart@adobe.com
November 28th, 2007
Hi Ryan,
Thank you for the reply, we all appretiate the fact that adobe pays attention to the community.
_
Mrinal
March 23rd, 2009
[...] behind AIR i.e enabling web developers to build desktop apps has been revolutionary. But, there are things about AIR that are very limiting as a developer … many real world applications need much more interaction with the desktop [...]
March 23rd, 2009
I certainly agree with the post. We would like to use AIR to develop a kiosk style application on an “appliance” type device. Essentially, the user will not have access to the machine other than the kiosk application. However, the application needs access to hardware resources. What will be installed is controlled at the factory. This is a Digital Video Recorder type product, similar to your television cable DVR. Because AIR does not allow extensions, it is proving difficult as a choice for this scenario. Hope more is coming in the future for AIR, otherwise Titanium is a choice for the runtime.
March 29th, 2009
Zinc is good then Air, becoz it provide a huge library as well as when running a compiled zinc application, you don’t need any dependency files