|Managing Asynchronous Code - Callbacks, Promises & Async/Await|
|Written by Mike James|
|Wednesday, 12 August 2015|
Page 3 of 3
The Ghost Of Promises Gone
After you have been using promises for a while it all gets to be second nature and you almost start to think that you are programming synchronous code but in a very strange way.
The reason is that it is easy to forget that the functions in the then methods are not obeyed immediately as part of the flow of control of your code. To avoid subtle mistakes you need to keep in mind that the Promise objects are created by the asynchronous methods you are using and they exist and are used long after your code has handed control back to the dispatcher.
Overall promises are a step in the right direction but a fairly small one.
The next approach takes the whole asynchronous problem and does its best to make it go away.
Async and Await
Async and await are the simplest solution to the single threaded UI asynchronous problem for the user but the most difficult for the language creator to implement.
Async and await make the compiler do all the work - no callbacks and no need for promises. Essentially asynchronous code vanishes and you really don't need to know about it in any great detail.
The basic idea is that any function that is marked as async can make use of await to give up the UI thread while an asynchronous operation completes. When it does complete the function resumes from where it left off with complete restoration of state.
Even though it is asynchronous it is coded exactly like a synchronous function.
What happens is that when the LoadA function is called the UI thread is released and it gets on with servicing the UI and making the app look active. When LoadA finally completes the UI thread automatically returns to the await restores the state of the function, stores the result of the function in text and then gets on with the rest of the function as if nothing had happened.
A typical async function can make use of multiple awaits and these can be within control structures.
The point is that using async and await the problem of writing asynchronous code vanished - well almost.
There are still many restrictions and "interesting" behaviours because you are using asynchronous code. Many of these problems are similar to the sort of things encountered when using "doEvents". For example the UI thread can respond to an event a second time and start the async function will it is still in the middle of an await.
You might at this point be thinking why did we bother with promises?
The point is that the sort of asynchronous code we are forced to write, at least on the client side, is due to the single threading of the UI. This is not something that is intrinsic to the programs we write and if the UI was multi-threaded we would simply wait for a long running operation to complete. In this sense the whole asynchronous problem is just a compiler problem. It is up to the compiler to make asynchronous operation look like synchronous operation and so hide the details from us.
Asynchronous programming as implemented to cope with a single threaded UI isn't a solved problem but async and await gets are close as it is likely to get.
The key idea is that single threaded UI asynchronous programming is a problem for the compiler not the programmer.
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Friday, 31 March 2017 )|