AIR beta 3 and local SQL database changes
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
trueparameter in theSQLConnection()constructor. Now, however, theSQLConnection()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 theSQLConnection.open()method; to specify async execution, you call the newSQLConnection.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 (noSQLConnection()parameter, andopen()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.codeproperty was removed (because it already inheritederrorIDfrom Error) and thedetailsproperty 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!
You can leave a comment, or trackback from your own site.
3 Comments so far
Add your comment
Comment notes
Please keep comments on topic. Comments that are inappropriate or offensive will be edited or removed.
Paragraphs and line breaks are automatically converted to HTML, and quotation marks are converted to “smart” quotes.
The following XHTML tags can be used: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> . All others will be removed.
Articles by Type
Articles by Topic
- .NET (5)
- ASP.NET (3)
- ActionScript (63)
- AS3 (30)
- Vector (typed arrays) (1)
- AIR (20)
- local SQL database (12)
- Application Design (13)
- Book reviews (3)
- Coding (8)
- Design Process (1)
- Dreamweaver (4)
- Flash (54)
- Flex (33)
- Flex Builder (4)
- Frameworks (6)
- JavaScript (2)
- Life at Adobe (2)
- MS SQL Server (4)
- Pixel Bender (1)
- Presentations (8)
- Projects (4)
- SaaS (1)
- Semantic Web (1)
- SQL (8)
- Unit testing (2)
- User-centered design (12)
- Web Browsers (6)
- Web Design (16)
- CSS (6)
- Writing (11)
January 4th, 2008 at 4:44 am
Hiroaki Nakamura is reported to have said:
You should see
http://labs.adobe.com/wiki/index.php/AIR:Release_Notes#API_Changes_in_Adobe_AIR_Beta_3
for other API changes.
The removal of SQLStatement.prepare() without any explanation was a big shock to me.
January 4th, 2008 at 3:09 pm
Paul is reported to have said:
Oh yeah, how could I have forgotten — SQLStatement.prepare() was also removed.
Yes, I was pretty annoyed about that one when I saw it in the checkin notes when that change was submitted to source control. I tried to argue to get it back, but the “API Review Board” thought that it made the API too confusing to have prepare().
I absolutely agree that prepare() is useful. Unfortunately there isn’t really a workaround. The only thing you can do is just keep in mind that the first time the SQLStatement is executed it will be prepared and executed, and after that as long as you don’t change the statement text it will already be prepared. (So basically, there’s no way to avoid the performance hit the first time the query is run, although you can save yourself grief on successive executions. And if you were preparing a statement, chances are you were planning to execute it multiple times anyway…)
Not much consolation, I’m afraid. I’m with you — I lament the loss of prepare(), and hope that the powers that be can be convinced to add it back in.
January 7th, 2008 at 5:24 pm
Paul is reported to have said:
I just had a conversation with Jason, the engineer who did the local SQL database feature, about prepare() and its removal. He mentioned another point that he considered that helped him conclude that it was okay to remove prepare(). Specifically, he told me that in testing he found that the amount of time necessary to prepare the statement was usually much smaller — generally 2-4 times smaller — than the execution time for the query, and overall execution speed turned out to be positive. Consequently, even on the first execution of a statement when the statement is being prepared, the additional processing time will probably be small enough that it won’t make a noticeable difference on overall execution time.
Hopefully that helps provide some consolation — or at least clarifies for you (as it did for me) that the issue was given a fair amount of consideration before it was decided.