New navigation service doesn't seem to be truly async as opposite to old ShowViewModel() navigation

[telzhov]

Steps to reproduce

1. Download Playground sample from https://github.com/MvvmCross/MvvmCross/tree/develop/TestProjects/Playground

2. In ./Playground.Core\ViewModels\Tab1ViewModel.cs, override initializer and add a couple of dummy other overridings (just to be able to set breakpoints and follow the call sequence):

    public override async Task Initialize()
    {
        await Task.Delay(2000);
    }
   
    public override void ViewAppearing()
    {
        base.ViewAppearing();
    }
   
    public override void ViewAppeared()
    {
        base.ViewAppeared();
    }
   

Expected behavior

I'm expecting the view to appear immediately (as it does for ShowViewModel()), then ViewAppearing() and ViewAppeared() should be called, and after that the Initialize() should complete when Task.Delay(2000) is done. Possibly this issue is pretty close to #2046

Actual behavior

The app is freezing and waiting for Task.Delay(2000)'s completion, and after that ViewAppearing() and ViewAppeared() are called.

Configuration

Version: 5.1.0, tested sample is from 491b012 with updated Playground.

Platform:

• iOS
• Android
• WPF
• UWP

[martijn00]

ShowViewModel was not async, but Fire and forget because it was called using reflection. We do experience the same problem you describe here so i think we should look into this.

[telzhov]

Ah okay, got it, thanks.

[martijn00]

We have 2 option right now i think. We can wrap the Initialize in a Task.Run so it will not stop the showing of the view, or we do the Initialize after the showing of the view, but then the parameter might not be available to the view events.

Another option would be to create 2 methods. One to pass the value, this can just be a normal void which is set before showing the view, and then run the Initialize Task after the showing. this would be a breaking change.

[telzhov]

Martijn, thanks for your reply.

Moving all long-awaiting code into ViewCreated() solved the problem, so this could be a solution: using Initialize() just for parameters passing, and place all awaits into ViewCreated() (since it doesn't block the UI event loop, and ViewAppearing & ViewAppeared can also fire before ViewCreated()'s completion). It would also make since mobile developers are mostly familiar with the initialization wrapper on UI side (ViewDidLoad() for iOS, not aware for Droid).

But in case we use Initialize() just for parameters, it doesn't make much sense to make it performing any async operation at all (and also returning Task), though...