Working Synchronously or Asynchronously?

Many frameworks, including Data Abstract, support Synchronous communication right out of the box. It is the general and accepted way of handling communication between client & servers. However over the last few years, fueled in part by mobile applications, Asynchronous programming has become increasingly popular.

So why might you choose one other style over the other? What are the pluses and minuses of both approaches?

Synchronous

The traditional way to create a client/server application was to use a Synchronous programming style, where when the client sends a message to the server it waits until the server has responded before continuing with further processing.

The major benefit of this approach is that it simplifies programming and makes your life as a developer easier. You don't have to worry about your application being in another state when a response from the server is received, or if there is a problem with the data that the middle tier was processing it can be immediately presented to the user for correction.

Unfortunately this leads to problems for the users of the client because they are required to wait for the middle tier to finish processing before they can get on with another task. Another issue that is particularly visible when the application isn't used on the local network is lag. If the user is on a mobile device in a low signal area they could be waiting for a long period for a server response, which they might interpret as a laggy user interface which puts them off using your application.

Asynchronous

In the last few years Asynchronous programming has become more popular because it helps to solve issues encountered with Synchronous programming which makes the user experience smoother and feel more responsive.

Unfortunately using an Asynchronous approach has its own draw backs. The development of applications is more complicated and can require more time to implement the needed functionality.

You have to consider cases that wouldn't occur at all in a Synchronous application. For instance you need to consider how you handle a situation where the server rejects a data change but the user has moved onto some other task in your application. Do you:

Wait till the current task is finished and then flag the problem to the user?
Flag it immediately and offer to save the current context and let the user swap back to edit the rejected data?
Save the rejected data so that should the user quit before fixing the issue, they can next time they run the application.
Indeed, what happens if they quit the application before the server has responded? On a mobile device you have background processing, but if you're application is a desktop application?

Level of support?

Clearly there is no one size fits all solution to the problem of communication in a Client/Server situation. You need to decide which is the most appropriate to your application, though we recommend developing your applications using the Asynchronous approach because of the benefits it brings to the user experience which outweigh the additional development time.

Regardless of which style you choose to use, Data Abstract has you covered. The main class of each platform of Data Abstract that serves as your conduit to the Data Abstract service has support to prepare and execute Synchronous and Asynchronous requests "right out of the box".

Asynchronous requests can be used with by either passing Delegates/Callbacks (depending on the language you are developing with) or Blocks. You choose which style best suits your programming style.

More detailed information and examples of platform specific approaches to using Asynchronous requests are available in the "Getting Start" section on each platforms documentation. Links can be found below.

Working Synchronously or Asynchronously?

Synchronous

Asynchronous

Level of support?

See Also