Asynchronous programming (Windows Runtime 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 APIs are exposed as asynchronous APIs. By convention, the names of asynchronous APIs 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 Runtime app, your code makes non-blocking calls in a consistent way. When you implement these asynchronous patterns in your code, 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, including displaying a file picker.
Sending and receiving data to and from the Internet
Sockets, streams, connectivity
Appointments, contacts, calendar
Working with file types, such as opening Portable Document Format (PDF) files or decoding image or media formats
Interacting with a device or a service
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 for the Windows Runtime in its own way:
|Programming language||Asynchronous representation|
|C#||async keyword, await operator|
|Visual Basic||Async keyword, 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 method 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. The Windows Runtime, Microsoft .NET framework, and C# and Visual Basic compilers have added features that abstract the asynchronous mechanics out of your code. For .NET and the Windows Runtime you can write asynchronous code that focuses on what your code does instead of how and when to do it. Your asynchronous code will look reasonably similar to synchronous code. For more info, see Quickstart: Calling asynchronous APIs in C# or Visual Basic.
- Quickstart: Calling asynchronous APIs in C# or Visual Basic
- Asynchronous Programming with Async and Await (C# and Visual Basic)
- Reversi sample feature scenarios: asynchronous code