"composed with"

Generics have been in C# for a long time now, and I have been using them, but I have had trouble explaining them to new developers, or at least how to read the code. That is, until just the other day. Using generic lists is easy to understand,

var customers = List<Customer>();

can be read as customers is a List of type Customer. But we often do something like

class ManageUsersPresenter  : basePresenter<IManageUsersView>
{}

What the hell is that? A ManageUsersPresenter of Type ManageUsersView? That just doesn’t make sense a presenter of type View, and then it came to me. What we are doing is composition. I can replace the “of Type” with “composed with”.

A ManageUsersPresenter composed with ManageUsersView. Now that makes sense. When you see an object that has a generic of another type then most likely we are composing these 2 objects to be used together.

Of course you probably want to make sure that your are composing the 2 objects together but it makes reading the code a little easier

Async Await or ContinueWith

So what’s the difference with these 2 code snippets?

var result = await subscriber.RunAsync((T)messagePacket.Body, cancellationToken);

 

await subscriber.RunAsync((T)messagePacket.Body, cancellationToken) .ContinueWith(anticedant => { //do something });

Well not much really, except for the error handling. What to do with those pesky exceptions. Especially since we are handing in a cancelation token. If the operation is canceled then an exception will be thrown. In the first instance the await keyword is kind of hiding the task that the Async operation returns. It will catch the exception and in this instance re-throw a new exception. You can choose how to handle it either wrapping the call or allowing it to percolate up the call stack.

In the second snippet we can do something without a new exception being thrown. We can look at the task that is returned and do something depending on the state of the task.

await subscriber.RunAsync((T)messagePacket.Body, cancellationToken)
    .ContinueWith(anticedant =>
    {
       switch (anticedant.Status)
       {
           case TaskStatus.RanToCompletion:
               //do something ... or nothing
               break;
           case TaskStatus.Faulted:
               subscriber.Abort();
               Trace.WriteLine("Request failed");
               break;
           case TaskStatus.Canceled:
               subscriber.Abort();
               Trace.WriteLine("This task timed out"); 
               break;
    }
    });

We lose a little of the readability of the Async await keyword paring and of course we could always wrap the first method in a try catch block and handle the second exception thrown, but I was taught that throwing exceptions is bad and expensive and for me I can understand what’s going on so I am going to stick with ContinueWith when I need to handle a cancelled or timed out request.

Wrapping OData Client Async Calls with Async – Await

I am a great believer in tooling that makes jobs, coding, and even the need for learning disappear. So the other day I was attempting to use “Add Service Reference” in VS 2012 to add a reference to an OData feed I had just created. I am using the release candidate and the .NET 4.5 framework, so I expect a few changes, and of course the resulting proxy has changed a little. In my investigation I discovered the Asynchronous call back mechanisms. The mechanisms did not match the new .NET Framework 4.5 Async Await pattern. I expect that the generated proxy will get updated at some point to support this, but how hard can it be to do it myself? Well like everything once you have learned how to do it, it’s easy right!!

To test new things I like to use a unit test framework to make it easy to run the code, and I created a little test helper class to act as a container for my method. The service I was using is for a application that handles an approval process for downloading from the internet, so the service proxy is called SDAReadService (Software Download Approval Read Service) and the context is called ReadModelContainer.  In the code below, the key is really the Factory.FromAsync method that has a number of overloads that allows you to pass in any pair of begin and end methods with up to 3 parameters.

public class Testhelper
{
    public static Task<IEnumerable> GetSoftwareDownloadRequestAsync()
    {
        var container = new SDAReadService.ReadModelContainer(new Uri("http://localhost:10494/readservice.svc"));
        DataServiceQuery query = (DataServiceQuery)from sdr in container.SoftwareDownloadRequests
                                                       select sdr;
        var task = Task<IEnumerable>.Factory.FromAsync(query.BeginExecute, query.EndExecute, query);
        return task;
    }
}

The above method can be called with the await key word.

Troubleshooting

Apart from finding an example of how to do this the only issues I had was with passing in the correct form of the Begin and end methods. I first passed them in as methods with parameters, I knew it was not right because the parameters did not make any sense, but it took me some time before I recognized that I need to pass in the method it’s self. As usual it looks right, and you think its right, until you see what is wrong.

Here is a link to a page that demonstrates how to call the query http://msdn.microsoft.com/en-us/library/dd756367(v=vs.100).aspx.

Not too difficult to understand the old way to call an Asynchronous method with a call back, and here is documentation on how to wrap it in a task. http://msdn.microsoft.com/en-us/library/dd997423.aspx.