Calling Long Running Methods Asynchronously

When you are able to call an async method, do it using async and await or by making your method return a Task:


public async Task<string> RequestData(Uri uri)
{
    WebClient webClient = new WebClient();
    return await webClient.DownloadStringTaskAsync(uri);
} // Rely on underlying Tasks whenever possible.


public Task<string> RequestDataAsync(Uri uri)
{
    WebClient webClient = new WebClient();
    return webClient.DownloadStringTaskAsync(uri);
} // Rely on underlying Tasks whenever possible.

Dealing with synchronous calls

When the method you are calling is not asynchronous, wrap the method in a task delegate:

 
public Task<string> RequestDataAsync(Uri uri)
{
    return Task.Run<string>(
        () =>
        {
            WebClient webClient = new WebClient();
            return webClient.DownloadString(uri);
        });
} // Create Tasks when you have no other choice.


Capturing Exceptions

Getting a little more advanced, what if you might need to capture exceptions from a long running method? Use the following pattern:
 

public Task<string> RequestDataAsync(Uri uri)
{
    var tcs = new TaskCompletionSource<string>();
    WebClient webClient = new WebClient();
    webClient.DownloadStringCompleted +=
        (_, args) =>
        {
            tcs.SetResult(args.Result);
        };
    webClient.DownloadStringAsync(uri);
    return tcs.Task;
} // Example of wrapping Async/Completed.

More info

Async'ing Your Way to a Successful App with .NET
http://channel9.msdn.com/Events/Build/2013/3-301

Creating Async Libraries That Are Modular, Reusable and Fast, in Microsoft Visual C# and Visual Basic
http://channel9.msdn.com/Events/TechEd/Europe/2013/DEV-B318


Popular posts from this blog

Ways to Spot Single Responsibility Violations

Classes should only have one reason to change. We should attempt to increase cohesion between things that change for the same reason, and decrease the coupling between things that change for different reasons. Classes should do one thing and one thing well. Violations of the Single Responsibility Principle can cause code to be difficult to test and maintain, and can make it easier for bugs to manifest. There are a few symptoms of SRP violations which can give warning signs of these issues. Large classes/methods Obviously large classes and methods do not always point to SRP violations as there may be a requirement for a significant amount of logic. However, it is usually a good sign. Large methods are more likely to point to an SRP violation than large classes, or at least too much cyclomatic complexity. You'll become aware of this when you attempt to cover the method with test cases, and realise there are excessive test combinations required. Too many injected depe
Read more

Clean coding Tips: Access Modifiers

Image
It seems to be by default that classes, methods, etc are created with the public access modifier. This is not actually the case, the default is internal class/private members, but public seems to be the de-facto choice by a lot of developers. If you're creating a public class - you have a big responsibility. Your code can now be used by anything else in the application, or even outside it. This means if you change the internal working of it, you will affect everything that uses it - and you have no control over what that is. This means a couple of things. Naming is always super important Naming of public classes and methods and their expectations should be crystal clear. Don't rely on comments to convey intentions. It must be highly obvious what the class is for, what it does, and how method parameters are used. It should be specific and adhere to the Single Responsibility Principle - one reason to change. If someone comes along and adds a parameter to one of your methods t
Read more

In Coding, Nothing is Trivial

Image
Imagine you're reviewing some code, as part of a Pull Request, and the developer has misspelt a variable. Or added a magic string instead of a constant. Or put the expected/actual parameters in an assertion the wrong way around (although it kinda doesn't matter because they're the same)? You can politely comment on it, and perhaps they will fix it up. But sometimes you might be met with resistance.  "It's not that important." To a degree, they're right. These are pretty trivial observations. There are probably bigger things to address, such as the logic, the architecture, the test coverage etc.  However, in coding, these trivial issues tend to come back to bite you, either as bugs, or as maintenance headaches. You don't want to nag people. You don't want to become a "clean code nazi". But you can firmly assert that you think a mistake is being made and that a potential issue could arise.  There are some things in coding that are a persona
Read more