Thoughts on developing with the Adobe AIR framework
Having developed a few Adobe AIR applications now (Memory, facedesk, GMDesk), and having talked to some people of the Adobe AIR Team, I thought it was time to express my feelings on what it’s like developing with Adobe AIR.
My idea is to list the things I like respectively the things I think need improvement or I outright dislike. The not-so-god parts is probably most interesting, since it contains a few things which would refrain me from using Adobe AIR.
It should also be mentioned that this is written out of the perspective as a HTML and JavaScript developer.
What’s good
Cross-platform functionality
Installing AIR applications on different platforms, both through the installer badge (I’ve only used the beta AIR Badge) and from an .air
file has worked great. I’ve tried it on Windows Vista, Windows XP and Mac OS X.
Once installed, it looks and behaves exactly the same (with an exception I’ll get to later on).
Getting started
Environment setup
Once I decided to get started, it was very easy to develop one’s first test application. Following these steps, found in the good, but overall sparse, Developing Adobe AIR Applications with HTML and Ajax, anyone should be up and running within a very short time:
Personally, I use TextMate and Remy Sharp’s AIR TextMate Bundle to develop Adobe AIR applications. Haven’t tested Adobe’s Flex Builder, but it seems very interesting.
Hello World, AIR-style
After that, I went through the Creating your first HTML-based AIR application with the AIR SDK, which helps you setting up the necessary files, and then explains how to test the application, create an installation file and how to manually create certificates.
Good stuff, and as you know, as soon as your first Hello World is out the door, there’s nothing to beat that feeling of accomplishment and being on the path to great things! π
JavaScript access to Flash objects and the native system it’s installed on
From within JavaScript, and especially if you use the included AIRAlias.js
file, you have very easy and complete access to everything exposed to an ActionScript Developer. This is great, and offers a way to create truly compelling things.
Hand in hand with that, you can very easily access the user’s computer and write/read files etc.
Adobe AIR Developer Center for HTML and Ajax
The Developer Center is filled with articles, explanations and good links. Probably a good start for most things you might be looking for.
Adobe AIR Marketplace
The Adobe AIR Marketplace is a good place to have your applications seen, and get a first round of users.
What isn’t good
At this time, however, I have to bring up my main problems and objections:
Certificates
The way the application installer is presented to your end users is in a dialog which uses certificate technology to detect if the publisher of the application is trust-worthy. If the certificate isn’t issued by such an authority, but rather a home-brewn one, the dialog will have two scary looking icons and a text which is bound to discourage anyone (at least most people) from installing the application.
I do understand the reasoning behind this, but the implications are terrible! As it is, only companies have the right to get certificates (or re-use already existing ones), meaning that no private developer will ever be able to deliver an application that seems to deserve any trust. Just imagine how this is a showstopper for all kinds of people wanting to deliver great applications on a promising platform, but the platform itself tells the end users that it isn’t safe to install it.
While the certificates are there to protect the end user, Adobe has to, some way or another, step in and relieve the developers from the burden of proving that the application is ok. I mean, Apple will offer that possibility with iPhone App Store, and Adobe could definitely add that to Adobe AIR Marketplace.
My suggestion is that any application released to the public should get the opportunity to go through an approval process with Adobe, to get Adobe to vouch for the application’s integrity and security. If this means that it has to be submitted to the Adobe AIR Marketplace, getting a green light, and then getting ready for the public, so be it.
But as it is now, the situation is unacceptable for any developer not being part of, or running, a company,
Updating procedures
Pushing out automatic updates to the end users isn’t as easy as it seems nor as it should be. I’ve created a script to automatically update AIR applications, inspired by others, but it was far too much work.
I’d suggest that the Updater
object should itself have a method that just takes a URL to an .air
file, compare those two, and present a dialog to the end user telling them there’s an update and offering them the option to retrieve it right away or later. This could very easily be done by comparing the version number (given that it is number-based) in the application descriptor file or just plain datestamps of the .air
files themselves.
For those who want to create more elaborate updating schemes, fine, give them any possible option. But for most people who just want the runtime to do this for them and help them out, it has to become easier.
Lagging version of WebKit
The web browser in Adobe AIR is based on the WebKit rendering engine, which is fine (although it’s not my personal favorite). It is very fast, and things generally look ok. There’s a debugger available, AIR Introspector. To be honest, I haven’t used it much, but right off the bat I’d prefer Firebug any day.
What might become a risk, though, is that the version in Adobe AIR is very much prone to constantly be one version after the latest release of the Safari web browser (based on the same rendering engine). While I understand that Adobe might need to tweak it, this will lead to a situation similar to the one with Firefox and Mozilla web browsers being one version ahead of the Netscape releases; a situation no one wants.
Preferably, the Safari Team and the Adobe AIR Team should synchronize their releases, or there should be an option to push out a certain version of WebKit to your application users. Developers don’t want to get more worried about how certain features work in just a specific framework’s version.
Web browser sniffing
This really isn’t Adobe’s fault, but since it uses WebKit, it will render the pages the same as Safari. However, in the navigator.userAgent
and navigator.appName
properties only the text “WebKit” is available, and no trace of Safari.
While that is actually correct, many web sites use web browser sniffing; think Google, Facebook etc. Generally, this is a bad practice and those instances should have been based on object detection instead (except for the few times where web browser detection is unfortunately a necessity).
So, while Adobe is doing the right thing, the real world isn’t really adapted to it. And, it would be much easier for Adobe to have talks with at least some of the most popular web sites to find a common ground, or to add something like Safari to its value (although it would be incorrect), than just hoping everyone in the world creating web sites will start writing better code. But, as long as the situation stays like the current one, Adobe AIR will offer a Safari-cloned web browsing experience, but it might not always get that treatment.
I think that creating any kind and sort of mash-ups is an important factor for gaining popularity for both the involved web sites and the Adobe AIR framework, and I do hope Adobe will look into what they can do here.
Even more focus on “regular” Web Developers needed
There is a pretty good focus on Web Developers working mostly with HTML and JavaScript, but still, there seem to be way too many examples and talks about the ActionScript way. Understandable, since most people who work for Adobe or write for them have a solid ActionScript background, but there are a lot more “regular” Web Developers out there than ActionScript Developers.
Just imagine winning the bulk of them over!
Form fields
I really don’t know why, but form fields look dog-ugly in Adobe AIR applications. Especially select
elements seem to have gotten a beating by the ugly-stick. And what’s even worse, it doesn’t have a system-native look in any of the operating systems.
To me, this is a capital error. Aside from just looking bad, it’s about user recognition and how easy-to-use and familiar the experience is to them. Also, with select
elements, they seem to get an extra space at the bottom of them when running applications on a Mac, while at the same time not having that space in Windows.
Really, when in Rome…
Conclusion
Adobe AIR offers a very promising future for creating great Rich Internet Applications. The certificate situation has to change, and some of the above-mentioned issues need tending to; at the moment, it is apparent that it is a 1.0 release, and a number of things can definitely be made easier or just plain better. It’s a good start, though, and if Adobe listen to developers, this can become something really good!
One possible alternative to the certificates would be to allow private developers to put their name into the Publisher field (ie. Publisher: Robert Nyman) but with a slightly softer warning (perhaps a yellow yield sign with the text "The publisher of this application has not been certified"). At least that way, as an end-user, I can link robertnyman.com (where I got the app) with "Robert Nyman" the publisher and feel a little better. As it stands now "Publisher: UNKNOWN" scares the sh*t out of me and I start second guessing what I'm installing.
Good to see you've been in discussion with the AIR developers. Keep up the good fight.
The part about individuals not being able to get certificate is news to me. Curl, the RIA platform I use and work on, doesn't require certificates because it quarantines the applications to the point that they are allowed to access the local hard drive but cannot access anything outside their own allocated section of disk space. In other words, the applicaitons are not capable of doing harm so a certificate is not necessary – you can however use certificates if you wan to.
Good write up,
Richard Monson-Haefel
VP of Developer Relations
Curl, Inc.
<blockquote cite="Robert">Preferably, the Safari Team and the Adobe AIR Team should synchronize their releases
Nooo! The rest of the world shouldn't have to wait on Adobe to get up to speed. They're still lagging behind on getting their Creative Suite to run properly on OS X … slowing down WebKit development just because Adobe can't keep up is not a good idea.
These days most browser vendors are pushing the boundaries and are doing great work on bringing new options and better browsers to the table. Doing synchronised releases with Safari and Air would slow things down to a crawl.
Oh, and an interesting read as always π
Hi Robert,
Wow, great blog post! Thank you for taking the time to write about your experiences with AIR. Let me respond to a few of your points.
1. Certificates
Fair points, but let me explain a bit more about the rational behind this design. It's important to keep in mind that Adobe AIR is a desktop application runtime that provides API's that can, for instance, read, write and delete from the local disk. Unlike Curl, as Richard pointed out, AIR is not limited to a particular section of disk. This is by design in the same way that other desktop applications powered by C++, .NET or Java can have access to the local disk (generally speaking, access is limited to the privileges of the account of the user running the application).
With increased power comes the responsibility to inform users prior to installation whether the application has been signed with a certificate issued by a certificate of authority or not. We do not prevent applications from being distributed that are signed with a "self-signed" certificate. However, as you've pointed out, the installation experience in the self-signed case presents more cautionary feedback so that the end user makes the best decision possible given the information available. When an application has been signed with a certificate from a CA, the installation dialog looks, you could say, less risky.
This approach was tested with and heavily influenced by end-users and developers for over a year. While an approval process from Adobe is an interesting idea, unfortunately, it does not scale well. It would likely require that someone read the code line by line.
I do hear your point though and you're definitely not alone. We're thinking about these scenarios. Please feel free to contact me if you have feature requests. Our team reads every request that comes through our feature request/bug form as well. See http://www.adobe.com/go/wish/
2. Updating procedures
Great point and we're about to release a framework on our Labs website built by an internal team to make this significantly easier. If you are interested in joining our prerelease to gain early access, please let me know and I'd be happy to sign you up.
3. Webkit
I would definitely encourage you to take advantage of the Introspector.js included in the SDK. To use it, simply include the introspector.js in your application and hit F12 to invoke it once your application is running. Make sure to uncomment it once you release a version of your application that you intend to share with your customers. I think you'll find the experience similar to other tools you're used to using. If you have thoughts on how to make it better, please let me know.
Also, rest assured, as major updates to AIR are released, we'll be upgrading to newer versions of Webkit.
4. More Focus on "regular" web developers
This is great feedback and we're always striving to do better. I thought I'd share a couple of links with you in case you haven't had a chance to explore these yet.
Adobe AIR AJAX Developer Connection
http://www.adobe.com/devnet/air/ajax/
Adobe AIR Ajax Quickstart applications (source code + apps)
http://www.adobe.com/devnet/air/ajax/quickstart/
Adobe AIR Sample Applications (scroll down a bit for source)
http://www.adobe.com/devnet/air/ajax/samples.html
Free Adobe AIR book (tons of examples)
http://ajaxian.com/archives/adobe-air-free-book-d…
5. Form Fields
Ahh, great point. You can style these form fields using CSS, but I understand what you're saying — it would be better if these defaulted to looking like system controls.
Again, thank you for the feedback. Please contact me if you're interested in joining our prerelease program or have other questions. We have some exciting announcements we'll be sharing soon.
Thanks again!
-Rob
Sr. Product Manager, Adobe AIR
Aaron,
That's an interesting option, and the very least they should do. But if they really want to spread Adobe AIR, I think they need to step up and take care of the certification process for developers.
Richard Monson-Haefel,
Thanks!
Hmm, interesting. To my knowledge, Adobe AIR applications have complete system access, and there's no way to fine-tune it; hence, some kind of verification is good, but I think the burden on developer gets too hard in this case.
Morgan,
Thank you.
Mmm, yeah, I think you're right. But then, as a developer, to be able to auto-push WebKit updates to Adobe AIR applications would be a feasible solution then.
Thanks – great suggestions. I'm going to send this article out to the team internally here at Adobe.
A few things:
1. If you'd like some Flex training materials like a book and DVD, I'd be happy to send them to you. Just email me.
2. Right now there are free certificates available to developers who upload their applications to the AIR Marketplace. Visit http://www.adobe.com/cfusion/exchange/index.cfm?e… and check out the link in the right hand side ("Get complimentary code signing certificate"). Not a long term solution, but good for now.
3. Re: Update mechanism. You wouldn't want applications having to download the complete AIR file every time – a better solution would be to point to the XML descriptor file on a website, and check against versions. Developers would have to upload both the AIR and XML file, but it would be a much smaller size.
Mike
Mike,
Thanks for your comment!
1. I'd love to! I'll get in touch with you. π
2. I'm sorry, but I wouldn't really say that that's good for now. Only 135 1-year certificates are given away through a deal with Thawte and also, as far as I know, only organizations are eligible to receive those certificates. This is far, far from sufficient.
Certificates have to be free and and easy-to-get for any personal developer if you ever want Adobe AIR to gain mass-adoption.
3. I was suggesting that it would perform an update if the <code>.air</code> file pointed to was of a later date or version, not every time. I also suggested checking the application descriptor file, but read out of the <code>.air</code> package, if possible.
Hi Robert,
I wrote a fairly lengthy response last night and was hoping to confirm that it went through OK as it has not yet appeared. If you have not get it for some reason, please let me know and I repost it.
Thanks,
-Rob
Product Manager, Adobe AIR
Rob Christensen,
Ah, thanks! Sorry for that, apparently Akismet for WordPress thought you were spamming me (probably due to the number of links in your comment).
I've just marked it clear, so it appears above now. I'd like to reply to it here:
1. With certificates and offering security and trust for the person installing the application. we're definitely on the same page. There has to be some security measures here to achieve that.
The problem is, though, that a) Certificates can be a hassle to get, and almost impossible as a private person, and b) certificates cost a lot, meaning that you'll miss out on small but great utility apps people will be creating.
I do acknowledge the problem for Adobe with having to manually go through each line in a program, which isn't possible. But perhaps you can start some kind of Adobe AIR Certification Program where developers can go through any tests, training and signing of legal waivers you want, so you then in return can offer them "true" certificates?
2. Sounds interesting!
3. I do think I need to give the Introspector some more time, to be completely fair here, so I might get back on that one.
It sounds good that with "…major updates to AIR", the WebKit rendering engine is updated, but it still leaves us developers who develop for both the web and Adobe AIR applications to learn the web browser (or rather, web browser version) differences, and my take is that was one of the factors you wanted to avoid in the first place by using a well-established rendering engine.
4. I know about those, but thanks for posting them here for everyone else.
5. The styling options are very limited, almost par to none. So, I'd suggest enabling that more, to begin with, but yes, native per host system is definitely the default path to take.
I'll get in touch about the prerelease program, and let's see what we can do!
Thanks for taking the time to reply and discuss this, I appreciate it! π
Re:
3. I was suggesting that it would perform an update if the .air file pointed to was of a later date or version, not every time. I also suggested checking the application descriptor file, but read out of the .air package, if possible.
But wouldn't it have to read the entire AIR file to get that descriptor file? (Maybe there's a technical way to do this that I'm not aware of.)
Mike
Mike,
Maybe it isn't an option, technically, I don't really know, to be honest. But if not, putting out the application descriptor file on its own and have automatic updating from there sounds like the best way then.
Check out Aptana Studio. It's an IDE that makes developing and deploying AIR applications cave-man simple. Free and cross platform too!
http://www.aptana.com/
Jeff,
Thanks for the tip! Personally, I'm not a big fan of Aptana, but it's good for other people to know about that option.
[…] Thoughts on developing with the Adobe AIR framework […]
I agree wholeheartedly with Robert about certificates… Desktop programs written in "traditional" desktop languages have full filesystem and registry access, yet there's no big red box popping up saying the developer didn't cop a $300 certificate (unless the developer chooses to display such a box, of course).
If it must exist at all, the certification process needs to be cheaper and easier if there is to be mass adoption. Only developers (and friends of developers?) would see three red bubbles, a bunch of keywords like "UNKNOWN", "UNRESTRICTED", "AT RISK" and still hit Install.