Developers often ask for guidance on how to write responsive user interfaces. Reading most books about the .NET Framework over the past ten years, you’ll see coverage of the asynchronous programming model which requires a lot of careful attention while coding. That’s why the async features in the latest versions of C# and Visual Basic are tremendous step forward. And language innovation like async needs a great library to bring forward the potential. In this post, Alok Shriram – a Program Manager from the .NET Base Class Library team – shows the work done in the .NET Framework to be async ready.
"Performance" is a term that is used a lot when talking about apps, but it's actually a pretty vague term. There are at least two aspects of performance that most people think about: app launch time and throughput. Both of these can be measured and described with actual numbers. The true test of an app, however, is end-user perception. A stop-watch may tell us one thing, but a user may see something else. End-user perception is the basis of asynchrony and related features that we have built into the .NET Framework 4.5 Beta. Essentially, we can provide a more responsive UI experience if some of the more expensive app operations can be delayed. This will make the end-user happier, and it will help us make better use of computing resources than would be possible otherwise. While you’ve always been able to implement this pattern in the .NET Framework, the implementation has been difficult in practice. We’ve fixed that in the .NET Framework 4.5 Beta.
This post introduces the asynchronous features in the .NET Framework 4.5 Beta. Many of you have been introduced to “async” via the language changes in C#, but we also want to tell you about accompanying changes that we’ve made in the .NET Framework.
Asynchrony in the .NET Framework
If you have ever written any UI code, chances are that you have used the asynchronous capabilities of the .NET Framework. Asynchrony keeps the UI responsive while expensive operations are being performed. For instance, if you implement a mouse click event that has to go and fetch a large page from the Internet, and you implement it using the WebClient.DownloadString method, depending on the amount of time this call takes to return, the thread on which the UI is running will be blocked. This means that any subsequent actions performed on the UI will be delayed, and you will wind up getting a frozen UI. However, if you use an asynchronous version of the method instead (specifically, WebClient.DownloadStringAsync), the request will return control immediately, and subsequent UI interactions can be handled as they arrive, while the content is being asynchronously fetched from the resource.
Read more: .NET Blog
QR: 