Note: Sorry for the delay on this article. I composed this article a couple of weeks ago, and then I got busy with work and holidays and I forgot and didn’t publish it until now =(

If you’ve been following my posts on AIR and the SQL database functionality, you may have noticed a trend: every time there’s a new beta, I tend to go silent for a few weeks beforehand as I try to get things finished up with the documentation. Well, here we went again – another period of silence, another AIR beta.

The marketing team kept things pretty low-key with announcing this new beta, especially compared to previous rounds. I’m not sure of all the reasons for that, but there are a few that are important and helpful for you to know if you’re developing AIR applications:

• AIR is now API-frozen – as of this beta, there shouldn’t be any changes to the AIR apis. In fact, the goal was to have as few API changes as possible between AIR beta 2 and AIR beta 3, as things get closer to being locked down. Naturally, if we find a big security issue that requires us to change an API, we’re going to consider it – but aside from that, things are now the way they will be for AIR 1.0 (phew – it’s been tiring for me to update apps every beta, and I’m sure it has been for you, too).
• Along with the new AIR beta, Adobe also released a beta of a new product code-named ”BlazeDS”. This very cool offering is a free, open-source, slimmed down LiveCycle Data Services – basically it includes the RPC Components (“Flash Remoting”) functionality as well as the Messaging functionality. In addition, we’re releasing an official specification for the AMF format. While the format was (for the most part) reverse-engineered long ago, I think it’s great to have something official for all the other open-source offerings like AMFPHP, Fluorine, etc. to work from.
• Along with beta 3, Adobe created the ”Adobe AIR Marketplace” where developers can post apps for people to download and try out – basically an extension of the
• Flex 3 beta 3 is officially the last Flex 3 beta before Flex 3/AIR 1.0 (second paragraph, also in the FAQ PDF). ‘nuff said =)

Of course, following the trend of my going silent before each beta, you can expect that to be magnified as we continue leading up to AIR 1.0. There have been a few things each beta that I wanted to do but had to put off until later – but of course, this time there isn’t any “until later” – so it’s now or never!

Talking specifically about the local SQL database functionality, there were only a few changes this beta, but they’re pretty significant and maybe even a bit sneaky so you’ll want to pay attention to them:

• Specifying synchronous and asynchronous execution: Synchronous database execution was added to SQLConnection in beta 2. At that point, to specify that a SQLConnection’s operations were synchronous rather than asynchronous, you had to specify a true parameter in the SQLConnection() constructor. Now, however, the SQLConnection() constructor doesn’t accept any parameters. Instead, you specify the execution mode when you open the connection to the main database. To specify that you want to use synchronous execution, you call the SQLConnection.open() method; to specify async execution, you call the new SQLConnection.openAsync() method.

  The most important thing to note surrounding this change is this: if you’re migrating an app from beta 2 to beta 3, you may be changing the behavior of your app without even realizing it! If you want a connection to be synchronous, you’ll know you have to change things because the code won’t compile (SQLConnection() no longer accepts a parameter). However, if you want you connection to be asynchronous, then if you don’t change anything the code will still work but it will actually use synchronous rather than asynchronous execution. If you have a long-running query and it’s freezing the UI now, that’s probably the reason – the exact code you used previously to specify asynchronous execution (no SQLConnection() parameter, and open() to connect the db) now is the way to specify synchronous execution. If your code doesn’t cause any errors, you might not even notice immediately because the SQLConnection and SQLStatement events are still triggered even in synchronous execution – so your “success” event listeners will still get called (but error listeners won’t – the operations will throw exceptions instead).

• There were a couple of changes to the SQLError class and related classes: The SQLError.code property was removed (because it already inherited errorID from Error) and the details property was added, providing a more detailed error message in certain cases. Along with this, the SQLErrorCode class was removed entirely (tragically – I spent a fair amount of time hammering out those error descriptions with Jason, the engineer for the feature).

I think that’s it, but please let me know if I’ve forgotten another change!

In the mean time, In addition to the SQL database stuff I’ve been doing more with another part of AIR that I’ve previously been working on as I’ve had time – the AIR-related Flex components. This release includes a new one, the FlexNativeMenu component, which is pretty slick. Watch for more on this in the (hopefully near) future!