Asynchronous programming (Windows Store apps)
Using asynchronous programming helps your apps stay responsive when they do work that might take an extended amount of time. For example, an app that downloads information from the Internet might spend several seconds waiting for the information to arrive. If you use a synchronous method on the UI thread to retrieve the information, the app is blocked until the method returns. The app won't respond to user interaction, and because it seems non-responsive, the user might become frustrated. A much better way is to use asynchronous programming, where the app continues to run and respond to the UI while it waits for an operation to complete.
Many Windows Runtime features like MediaCapture and StorageFile are exposed as asynchronous functions. By convention, the names of asynchronous functions end with "Async" to indicate that part of their execution may take place after the call has returned.
When you use asynchronous APIs in your Windows Store app, your code makes non-blocking calls in a consistent way. When you implement these asynchronous patterns in your API, callers can understand and use your code in a predictable way.
Here are some common tasks that require calling asynchronous Windows Runtime APIs.
Displaying a message dialog.
Working with the file system.
Sending and receiving data to and from the Internet.
With Windows Runtime asynchronous APIs, you don't need to manage threads explicitly or interact directly with the underlying implementation.
Each programming language supports the asynchronous pattern in its own way:
|Programming language||Asynchronous representation|
|C#||future objects, await operator|
|Microsoft Visual Basic .NET||future objects, Await operator|
|Microsoft Visual C++||task class, .then method|
A promise object represents a value that will be fulfilled in the future. In the Windows Runtime you get a promise object from a factory function, which by convention has a name that ends with "Async".
In many cases, calling an asynchronous function is almost as simple as calling a conventional function. The difference is that you use the then or the done function to assign the handlers for results or errors and to start the operation.
A typical segment of code written in C# or Microsoft Visual Basic executes synchronously, meaning that when a line executes, it finishes before the next line executes. Various programming models, such as the Asynchronous Programming Model and the Event Asynchronous Pattern, have been used over the years to enable developers to write asynchronous code. While these models have succeeded in enabling asynchronous execution, the resulting code tends to emphasize the mechanics of executing asynchronous code instead of focusing on the task that the code is trying to accomplish. This has made asynchronous code hard to write, hard to understand, and hard to maintain. The Windows Runtime, .NET framework, and C# and Visual Basic compilers have added features that abstract the asynchronous mechanics away from your code so that you can write asynchronous code that focuses on what your code does instead of how to do it. You can now write asynchronous code that looks similar to synchronous code. For more info about calling asynchronous APIs in the Windows runtime from C# or Visual Basic, see Quickstart: Using the await operator for asynchronous programming.
- Silverlight Async Project Explorer
- Quickstart: using the await operator for asynchronous programming
- Asynchronous Programming with Async and Await (C# and Visual Basic)
- Reversi sample feature scenarios: asynchronous code
Build date: 11/29/2012