If you are planning on building an Adobe AIR application, you need to be familiar with the concepts of Synchronous and Asynchronous requests, henceforth referred to as sync and async, respectiviely.
The terms sync and async are used all over the place. There are sync and async transmissions, sync and async learning, sync and async communications, and in Ajax and AIR we have sync and async requests and connections.
I am not going to belabor this discussion with a bunch of tech talk on sync vs. async. While there may be a far more technical and specific explanations of sync vs. async, for our purposes, that would simply manage to confuse things. I am going to explain it my way and with the goal of explaining the concepts only so far as we need them.
Synchronous RequestsA synchronous request is used in a situation where we want our application to "pause" while we wait for an answer to the request. That is to say, we don't want the user of the application to be able to do anything while we wait for the response.
As an example, if we were writing an application that manages to-do lists (I love to-do lists) and we are writing the feature that allows a user to create a new list, we might use a synchronous request. We don't want the user to be able to start adding to-do items to a to-do list until it has actually been created. So we will have the program "pause" while that request is being made. Once a success message is returned, we can allow processing to continue.
Keep in mind, the application does not need to "pause" in an ugly way. We can throw up a "waiting..." screen with an animated graphic that shows the program is working, if we want. Or we can just let it hang and frustrate the user. Your choice.
There are, of course, disadvantages to using synchronous requests. They can frustrate the user because the program keeps "pausing", they can make numerous requests take longer than they would if they ran asynchronously, and you may have to question why you are creating an RIA if you are going to continually pause the program for every request to the back end. I would argue that is worse than page refreshing. At least with a page refresh you can assume that the program didn't lock up.
Asynchronous RequestsAsynchronous requests are used when we do not want the application to pause during processing. When we want the user to be able to continue using the application while we wait for a response, an async request is the answer.
With an async request, the application will make the request, which runs in the background, and allow the user to continue working while it listens for a response to the request. When the application receives the response, it can act on that.
As an example, we'll return to our to-do list applicaiton. Let's say a user is adding to-do items to a to-do list. Well, each time the user add a new to-do item, we don't want the user to have to wait after hitting enter before the next item can be entered. We want the request to add the new item to be sent off while the user is able to work on the next item.
Here is how a scenario might work:
- User enters a to-do item and clicks submit
- The item is immediately added to the front end list (Using DOM manipulation), but its edit and delete buttons are disabled
- A request to persist the item to the database is sent to the back end database
- A listener is set up to listen for a response from the database engine
- The application allows the user to continue working
- When the listener hears a response from the db engine, it acts on it. If there is an error it displays the error. If the operation is successful it enables the edit and delete buttons for the item and possibly throws a small, unobtrusive notification up that does not prevent the user from continuing work.
And just like sync requests, there are disadvantages to using async requests. With async requests it is harder to control program flow. For example, if you want specific actions to be performed in a specific order. Or if you want one thing to happen after three other things are completed. Sync requests are also easily subject to race conditions when we are unsure of how long different async requests will take.
Synchronous and Asynchronous Communication with SQLite in Adobe AIR
Adobe AIR gives you the ability to make both sync and async requests to the database engine (SQLite). This is great because it really gives us a lot of control over how the application works and over the user experience. Like a said, why build an RIA if the user experience is going to suck?
As I have learned the hard way, there are different situations where you might use sync vs. async connections to the db engine, and it is certainly reasonable that you might use both types in the same application. When I started my application, I decided to use async requests, not realizing that there were going to come a few times when I needed to control the program flow more rigidly and need a sync connection. I am now going to have to go back and refactor some of my application to accommodate both types of connection. Live and learn, right?
In my next couple of posts I will demonstrate using both synchronous and asynchronous database connections with Adobe AIR.