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.

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.

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.

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

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!

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

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 .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.

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?event=productHome&exc=24&loc=en_us 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

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.

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-download

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

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

Good write up,

Richard Monson-Haefel
VP of Developer Relations
Curl, Inc.

Good to see you’ve been in discussion with the AIR developers. Keep up the good fight.