What’s Next in C#? Get Ready for Async!
Today we announced the Visual Studio Async CTP, which shows one of the major features we plan to include in a future release of C# and Visual Basic. This feature makes development of asynchronous applications–which include everything from desktop applications with responsive UI to sophisticated web applications–much easier.
The future release will introduce two new keywords to the C# language: await and async. The await keyword is used to mark asynchronous calls, so that you don’t need to create callback functions anymore and can write code in the same way as if it were synchronous. The compiler will do all of the heavy lifting for you. The async keyword must be presented in the signature of the method that makes asynchronous calls. Briefly, you can use the await keyword only if the async keyword is in the method signature. The same is true for lambda expressions.
This post presents just a short description of the feature. I strongly recommend that you visit the Visual Studio Async CTP page to learn more of the details and get tons of useful resources, including the language spec and cool samples.
Although we have plenty of examples and resources available, it’s never enough. So I’m giving you one more demonstration of how much easier it might be to create asynchronous programs with a future version of the C# and Visual Basic languages.
First, some preparatory steps to make the example work:
- Download the Visual Studio Async CTP and install it.
- Open Visual Studio 2010 and create a new Silverlight 4 project (To make things easier later, name it FacebookAsync.)
- Add a reference to AsyncCtpLibrary_Silverlight.dll. It should be in My Documents/Microsoft Visual Studio Async CTP/Samples.
- Add a reference to the System.Json library, because it’s used in the example. This is a standard Silverlight library.
- Go to the properties of the web project and, on the Web page, check what port it uses for the Visual Studio Development Server. My sample application uses the port 50750, so it might be easier for you to use the same one.
- Register your application on Facebook. You will get an application ID (which is the same as a client ID) and a secret key.
The FacebookAsync application I want to show you downloads a list of friends from Facebook and displays their names and Facebook IDs. It has a button and a DataGrid control that autogenerates columns. Here is its XAML.
To get a list of friends, an application needs to perform several steps (according to Facebook Graph API), including making two asynchronous calls:
- You need to redirect from the application page to the Facebook authorization page and provide a client ID, a secret key, and a return URL as parameters of the URL. The user should authorize the application. (In debugging mode the user is probably you, so you should have your own Facebook account.)
- If the user authorizes the application, the Facebook API redirects to a return URL, which your application provides. Facebook also adds an authorization code into its redirect URL as a parameter. No asynchronous calls are made yet, because this is done by simply navigating between pages.
- The application should exchange the authorization code to an access token by using the GET request. Remember that Silverlight doesn’t have a synchronous API, so you have to make an asynchronous call.
- After the application gets a token, it makes a new GET request to the Facebook API to get a list of friends for the current user. Once again, this call should be asynchronous.
- The application parses the response from Facebook and displays it on the page.
The full code of the version that doesn’t use the new async feature might look like this.
This is what you typically see when you have to deal with asynchronous applications: lots of callbacks, and overall the code is rather hard to read, although I spent some time on beautifying it. Now, let’s see how much easier it might be with the new async feature.
XAML will not change. The same is true for the FacebookFriend class, the button’s event handler, and all the properties in the MainPage class.
The changes start, unsurprisingly, in the GetFriends method. I’m going to make asynchronous calls by using the await keyword. But to enable this, I have to add the async keyword to the method signature.
Now I can start changing the code within the method. Let’s take a look at the existing code:
Instead of making a callback, you can get the result string by using the await keyword.
Note that I used a different method here: DownloadStringTaskAsync. This method doesn’t exist in Silverlight today; it’s a part of the CTP release only. In addition to new keywords in the C# and Visual Basic languages, future versions of the .NET Framework and Silverlight need to implement the Task-based Asynchronous Pattern (TAP). The details about this pattern are also included into the CTP release; look for “The Task-based Asynchronous Pattern” document.
According to this pattern, asynchronous methods should follow a certain naming convention: They should have the “Async” postfix (or “TaskAsync” if a method with the “Async” postfix already exists in the given API, as with the WebClient class). Such methods return instances of the Task or Task<TResult> class from the Task Parallel Library. But once again, the compiler does some work for you when you use the await keyword. In my example, the type of the token variable is not Task<String>, but just String; no extra work such as conversion or type casting is necessary.
And now you can simply continue writing your application logic in the same method! Everything I had in the OnDownloadCompleted_Token method can be moved to the GetFriends method. I don’t even need to create a new WebClient, since I already have one.
So, the code
from the OnDownloadCompleted_Token() method can be replaced with the following code (once again, using the new await keyword) and moved to the GetFriends method.
After that I can simply delete the OnDownloadCompleted_Token method. In fact, I can make everything even shorter. I don’t need to create the token variable, because I can use the await keyword right in the method call, like this:
The last step is to simply move the code from the OnDownloadCompleted_Friends method to the GetFriends method and delete the OnDownloadCompleted_Friends method.
Here’s what the final version of the GetFriends method looks like:
Instead of three methods I have just one, and it’s much more straightforward and easier to read. It simply has less code to begin with. I hope that I gave you just enough information to encourage you to explore more on your own and read more about the Visual Studio Async CTP.