I've been spoiled by async/await! Now struggli

问题:

Edit (after acceptance)

It might not be immediately apparent but @Servy's answer is correct without needing a custom implementation of Unwrap under monodroid - in my comments I said it didn't exist, but it definitely does.

End edit

I'm writing a bunch of apps that use our RESTful web services and, despite thinking I know how to use tasks properly it turns out I don't. The scenario is that I have code implemented for Windows Store - using async/await and I need to implement something near-identical for MonoDroid - which doesn't have that (without some build hacks that I don't want to use).

I've boiled down the problem for this question to a simple set of tasks for getting an integer asynchronously, then, in the continuation, firing another asynchronous task that turns a string built from that integer. In C#5 this would be:

Note - of course I'm using Task.FromResult<T> here in place of actual async code

private async Task<string> GetStringAsync()
{
    return await GetStringFromIntAsync(await GetIntAsync());
}

private async Task<int> GetIntAsync()
{
    return await Task.FromResult(10);
}

private async Task<string> GetStringFromIntAsync(int value)
{
    return await Task.FromResult(value.ToString());
}

To convert this to a continuation-based pattern I tried this:

private Task<string> GetStringAsync()
{
    //error on this line
    return GetIntAsync().ContinueWith(t => GetStringFromIntAsync(t.Result));
}

private Task<int> GetIntAsync()
{
    return Task.FromResult(10);
}

private Task<string> GetStringFromIntAsync(int value)
{
    return Task.FromResult(value.ToString());
}

However, this isn't correct because the GetStringFromIntAsync method returns a Task<string> meaning that the continuation ends up returning a Task<Task<string>> instead of a Task<string>.

I've found that explicitly waiting on the GetStringFromIntAsync method does work, however:

private Task<string> GetStringAsync()
{
    return GetIntAsync().ContinueWith(t =>
    {
        var nested = GetStringFromIntAsync(t.Result);
        nested.Wait();
        return nested.Result;
    });
}

The question is, though - is that the right way to do it - can I not return a continuation of some sort that the caller then waits on?

I have used tasks quite a bit - but not to chain tasks of different types together like this (except with async/await of course) - and feel a bit like I'm going mad here - so any help is greatly appreciated.

回答1:

So, first off, your non-async/await imlementations of the second and third implementations is what you should do even when you have async/await. Using it adds nothing except a bit of unneeded overhead.

As for the first case, no, you don't want to use Wait. That will block the thread instead of allowing it to be returned to the pool. You simply need to unwrap the task and get it's inner task. You can use the Unwrap method to do that:

private Task<string> GetStringAsync()
{
    return GetIntAsync()
        .ContinueWith(t => GetStringFromIntAsync(t.Result))
        .Unwrap();
}

Here is an Unwrap function that you can use if one is not available to you.

public static Task<T> Unwrap<T>(this Task<Task<T>> task)
{
    var tcs = new TaskCompletionSource<T>();

    task.ContinueWith(t =>
    {
        t.Result.ContinueWith(innerT => tcs.SetResult(innerT.Result)
            , TaskContinuationOptions.OnlyOnRanToCompletion);
        t.Result.ContinueWith(innerT => tcs.SetCanceled()
            , TaskContinuationOptions.OnlyOnCanceled);
        t.Result.ContinueWith(innerT => tcs.SetException(innerT.Exception.InnerExceptions)
            , TaskContinuationOptions.OnlyOnRanToCompletion);
    }
        , TaskContinuationOptions.OnlyOnRanToCompletion);
    task.ContinueWith(t => tcs.SetCanceled()
        , TaskContinuationOptions.OnlyOnCanceled);
    task.ContinueWith(t => tcs.SetException(t.Exception.InnerExceptions)
        , TaskContinuationOptions.OnlyOnFaulted);

    return tcs.Task;
}

回答2:

For a full supported approach, it's probably best to wait for the official async/await support for MonoDroid - Xamarin have said this is 'coming soon' - the first half of the year.

However, if you are feeling more adventurous... then at least a couple of people have managed to get async/await working in MonoDroid:

• Using "Full Mono" - http://fizzylogic.nl/2012/05/04/adding-asyncawait-support-to-your-mono-for-android-projects/
• Using "Microsoft BCL" - see the twittersearch sample and code from Daniel Plaisted's talk at BUILD http://channel9.msdn.com/Events/Build/2012/3-004

回答3:

that is what I have done working with async tasks in .net 4.0 (VS 2010). Some have said you do not need to call task.Wait(); and other have said, yes you do need to call task.Wait(); I think the difference is whether task.Wait() is implied/encapsulated in the task.Result property.

I stuck with the more explicit approach of calling task.Wait();.

This will block until the call completes, but I'm not sure what other options are available if you are not working with 4.5.