Support async methods on the IActivate interface

A lot of the initial discussion took place in #245, however my thinking has evolved a bit from then.

The initial plan is as follows.

1. Move the IActivate interface to async only with sync looking like

Task ActivateAsync(CancellationToken cancellationToken);

I’m not 100% on the “Async” suffix, if this was a new codebase that was async first I’d leave it off, however due to migration it make it easier to show where there are breaking changes.

1. Update the protected methods on Screen that are overridden to the following

Task OnInitializeAsync(CancellationToken cancellationToken);
Task OnActivateAsync(CancellationToken cancellationToken);

1. Update the ScreenExtensions such as TryActivate in similar ways.
2. Add some helper extension methods that allow activation without a cancellation token.
3. Update the Conductor classes in a similar method. This is probably the larger piece of work as it means a lot of methods become async such as ChangeActiveItem and ActivateItem.

Anybody have thoughts on this?

[nigel-sampson]

1. Not a big fan of adding and then removing it.
2. Did consider that (although would be = default(CancellationToken) since it’s a value type. But default parameter values can cause some silliness in libraries that overloads don’t have.
3. Because your view models call into the model layer they need to be async for similar reasons. One of the largest issues is the way the OnInitialize, OnActivate lifecycle happens when the former is async void.

My thought process is to expose the “async” the whole way up the stack, making decisions about “this should be async void to hide stuff” will usually be the wrong decision for someone. Hence ChangeActiveItemAsync etc.

The main point is that the view models won’t do many things async, just better enable you to do them.

There could be some interesting things we can add where if a conductor is switching between items it can cancel the activation of the previous child view model.

[markgould]

I’ll start looking at it soon - are you going to push a new alpha to nuget or should we just work off of develop?