If the goal is indeed merely to serve the same function as the unverified/unsigned notification that Microsoft pops up for installing unsecured EXE’s then why didn’t Adobe make it look similar?

Microsoft’s unsecured-software dialogs have a familiar and non-threatening light-gray background with familiar graphical elements and text. The one AIR provides looks more like a virus warning with it’s black background punctuated with blood-red icons (hyperbole I know but the shoe fits). It’s all about presentation.

If Adobe would make it look like the unsigned software dialog people are used to seeing from unsigned executables then you’d get no complaints from me.

Thanks for the comments. One clarification I should make is that the $300/year (or whatever the cost of an app signing certificate is, since it varies) isn’t paid to Adobe and Adobe doesn’t get even a penny from that money. It all goes to whatever certificate provider you buy the certificate from.

In any case it’s obvious that the cost of a certificate is a big concern for you, and I can definitely pass that feedback on to the AIR management team. I agree with you on this point — I have a few small apps that I’ve built, and some ideas for bigger ones, but since none of them are something I expect to make money from I haven’t been able to justify the expense of a certificate (plus the difficulty of getting one for an individual developer). But it’s still disappointing to know that the apps have the warning message associated with a self-signed certificate.

I also appreciate your feedback on the site design, although I can’t promise any quick fixes in that regard. It reads pretty well (to me) on the monitors I own and use regularly, although a couple of times I have viewed it on monitors where it didn’t come across very well so I realize it doesn’t always work. Obviously I was going for basics — with more emphasis on getting a site up than on fancy flourishes. I’ve even drawn up some redesign ideas, but I highly doubt I’ll have time anytime soon to implement them. Since I’m not paid for my web site, everything I do for it is voluntary. My assumption has been that people are better served by new content and addressing questions and comments than they would be by a redesign, so that’s where I choose to spend my time. That could be a faulty assumption, of course =)

Unless you give Adobe an annual pound of flesh ($300/yr) your application install process will look like a freaking virus is being installed on your client’s machine when they install your AIR program.

No thanks. I’ll stick with SWF2EXE programs (Northcode, Zinc, Janus, mProjector).

I (and others) are certainly aware of all the requests for a synchronous API. Internally that was one of the first questions that came up, too. I’m an almost-daily reader of the Labs forums (under the name “adbe_paul”) and the ApolloCoders list (under the gmail address “paulslists”). I’m not complaining, though — that’s the reason we have those forums, so that we can see how the community feels about our work-in-progress.

Honestly, the more I’ve worked with the API, the more I find the asynchronous API to be pretty straightforward to work with. It’s different than with PHP/Java/.NET/etc., certainly, and you end up with lots of event listeners, but (to me at least) it’s consistent with remote data loading in ActionScript has worked for years, so I feel like I’ve gotten a pretty good handle on it and I can make it work for what I need it to do. But I know not everyone agrees with me — even among Adobe employees =) — and I’m 100% certain that there are cases where it won’t work — I just haven’t run into them myself.

The asynchronous API is certainly the recommended approach in general, in order to have better perceived performance (with the database engine running in the background rather than blocking the main thread — the one that causes the screen to redraw). That’s especially true for potentially-large SELECT statements or other groups of multiple statements.

All warnings and disclaimers aside, however, the synchronous API is in our internal builds, and assuming we get all the bugs worked out, I expect that it will be included in the next public release. (Sorry no dates at this time =)

I’ve heard rumor that at one of the recent stops of the On AIR tour bus, they demoed an app that used a synchronous sqlite API in AIR. Is this true!? If so, when we expect to get our hands on this API?

References:
http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=72&catid=641&threadid=1276219&enterthread=y
http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=641&threadid=1289146
http://tech.groups.yahoo.com/group/apollocoders/message/1611

Russ

I think AIR has to be the most exciting technology to come from Adobe in a long time, and the SQLite support only makes me more excited about it!

The addition of embedded database is possibly my favorite new feature in this mountain of features Adobe dropped on us this week. Paul Robertson, an Adobe developer, lets us know why he agrees with me.
……