[Enhancement] ViewModel add OnApearing like methods for async/await invoke

[jingliancui]

Summary

In traditional way , something async operations can be invoke at OnApearing method in Page.cs , but
something async operations I want use on viewmodel after the constructor method. Maybe refer the PrismFramework but maybe MAUI can do this without Inherited some class from App.cs

API Changes

Provide some interface method to implement or abstract method to override in viewmodel.

Intended Use Case

Viewmodel can do something async/await operations after its constructor finished.

[ChaseFlorell]

Prism already has this with IPageLifecycleAware

Essentially, if Maui were to implement something similar, they could just extend the SendAppearing() and SendDisappearing() methods to check the BindingContext

if(element.BindingContext is IPageLifecycleAware lifecycleAware)
{
    lifecycleAware.OnAppearing(); 
}

Then your view model would just implement the interface

public class MyFunViewModel : IPageLifecycleAware
{
    public void OnAppearing() { }

    public void OnDisappearing() { }
}

_{note: interface name notwithstanding}

[dansiegel]

FWIW, I wouldn't complain about not having to support that in Prism for MAUI

[MathewLC]

I don't know if this belogns here but, it would be nice too if passing parameters direct to ViewModel, when navigating between pages, was implemented from the begining. Like queryProperties that shell(link here) already has in xamarin.
That is also something that prism support since a long time.

[TrueMoniker]

I had a similar problem for passing parameters. I didn't like that the parameters weren't type safe, and processing them into and out of the object dictionary or query string is a lot of boiler plate code. I suggested an idea here

[VladislavAntonyuk]

You can write small navigation service:

Public interface INavigationService 
{
 Task NavigateTo<ViewModel>() where ViewModel:BaseViewModel;

Task NavigateTo<ViewModel, TObject>(TObject parameter);

}

Public class NavigationService:INavigationService
{
...
var page= GetPageFromVM(ViewModel);
Navigation.NavigationStack.PushAsync(page);
ViewModel.Init(parameter);
...
}

[MathewLC]

@VladislavAntonyuk that it's what I actually do.

[VladislavAntonyuk]

I totally disagree with the idea of adding page methods to view model. We have code behind for that. VM shouldn’t know anything about the page and can be applied to any page

[timmi-on-rails]

I agree with @VladislavAntonyuk
Though these lifecycle events sound appealing, it will have an effect on the desired loose coupling of View and ViewModel in the MVVM pattern.

Nothing stops me from using the very same ViewModel instance in two different views at the same time. How would the proposed lifecycle interface help in this case?
Maybe passing in the view instance as a parameter?
But this might lead to a tighter coupling of the ViewModel to the concrete type of view.
IMHO this needs more thinking....

[matt-goldman]

Just reviving this old thread in case anyone is watching...

I think .NET MAUI should have an opinionated way of asynchronously initialising events for a page. We have some lifecycle methods in the Page base class already, but IMO these have three problems:

1. They don't fire at the appropriate time during the page's lifecycle i.e., "when the page is about to appear; I would like the page to render before I kick off my initialisation logic so that I can show a loading indicator.
2. These methods are void, meaning you either need async void or to rely on clever tricks or 3rd party plugins.
3. If your Page scope is singleton, your initialisation logic will fire every time the page appears (you can of course manage this yourself; you also have the same problem if its transient anyway).

Other UI frameworks provide methods for handling this. For example, if you look at Angular, you can subscribe to something in your Init method for a component, and then delegate the result (which can actually be multiple results, but that's a separate issue) to a function. A closer example to this though is Blazor, which has the OnAfterRenderAsync method, and even passes in a bool to let you know whether its the first time the page has been rendered or not.

In short, I want the OnAfterRenderAsync method in .NET MAUI. I think this would be super powerful. You can call your page initialisation logic in here and check to see if it's the first run, so you don't have to worry about reloading your data every time. Your page will already be visible at this point, so you can easily show your loading UI (whether it's an ActivityIndicator, a custom skeleton, or whatever), and you can call an async initialisation method in your ViewModel too.

How difficult would it be to implement something like this in .NET MAUI?

cc: @jfversluis

[drmaven]

@matt-goldman

I am NOT sure if this is the correct way to handle it, but I think it works OK. Using CommunityToolkit.MVVM v8.
I was inspired by this answer. I believe that MVVMCross (which I come from) use a similar implementation.
I would love to hear your thoughts on this.

public BaseViewModel()
		{
            InitTask = Initialize();
		}
 
        private TaskNotifier initTask;
        public Task InitTask
        {
            get => initTask;
            private set => SetPropertyAndNotifyOnCompletion(ref initTask, value);
        }

        public virtual async Task Initialize()
        { }

[matt-goldman]

This is neat and definitely a good way to go. In fact probably one of the better approaches.

I would still like to see something in the framework though. This is a ubiquitous requirement that is supported in other UI frameworks and needs to be in this one too. I think this approach still has three problems:

1. As mentioned, it's not in the framework. If you look at my point 2 above:

meaning you either need async void or to rely on clever tricks or 3rd party plugins

While this is technically a 1st party plugin, it's still external to the framework.
2. It requires you to follow the MVVM pattern. While arguably people should be following the MVVM pattern (or MVU, but MVU already handles this in a different way), they shouldn't have to. You need a ViewModel to perform this initialisation, there's no way to do it in a Page.
3. This approach is not lifecycle aware. There's not necessarily anything wrong with that, but if you look at how Blazor does it, you can call some logic once you know this page has rendered. I think this provides some benefits.

I think it works OK

I agree - I think this is a really good approach. But I would still like to see .NET MAUI provide for this requirement.

[drmaven]

I totally agree with you that these things should be baked into the framework and we shouldn't be needing workarounds constantly.
Regarding your third point, I have noticed that the page method "protected override void OnNavigatedTo(NavigatedToEventArgs args)" is called once everything is rendered. Maybe use this until a better solution is found?

Below I have attached the code I currently use, in case anyone stumbles upon this thread.

//ViewBase.cs
public abstract class ViewBase<T> : ContentPage where T : BaseViewModel
    {

        protected T ViewModel { get; set; }

public ViewBase()
        {
            BindingContext = ViewModel = ServiceHelpers.GetService<T>();
        }

        protected override async void OnAppearing()
        {
                ViewModel.Prepare();
                ViewModel.StartInitialization();
                base.OnAppearing();
              
                ViewModel.OnAppearing();
        }

    protected override void OnNavigatedTo(NavigatedToEventArgs args)
            {
                base.OnNavigatedTo(args);
                ViewModel.OnNavigatedTo(args);
            }
}

//Note: On the xaml page side, don't forget to insert your xmlns:viewmodel namespace, and then x:TypeArguments=vm:[vmName].

//BaseViewModel.cs
public BaseViewModel()
{}
        public void StartInitialization()
        {
            InitTask = Initialize();
        }
       
        public virtual void Prepare()
        { }

        private TaskNotifier initTask;
        public Task InitTask
        {
            get => initTask;
            private set => SetPropertyAndNotifyOnCompletion(ref initTask, value);
        }

        public virtual async Task Initialize()
        { }

        public async virtual void OnAppearing()
        {        }

        public virtual async void OnNavigatedTo(object parameters) { }

//ServiceHelpers.cs
public static class ServiceHelpers
    {
        public static TService GetService<TService>() => 
            Current.GetService<TService>();

        public static IServiceProvider Current =>
#if WINDOWS10_0_17763_0_OR_GREATER
			MauiWinUIApplication.Current.Services;
#elif ANDROID
    MauiApplication.Current.Services;
#elif IOS || MACCATALYST
			MauiUIApplicationDelegate.Current.Services;
#else
                null;
#endif
    }

[jingliancui]

I'm surprised and happy that this idea will be shown to me again at that moment.
I try to recall why I suggest this idea:
1)I was developing a product 3 years ago that one scenario is the page need load List will take about 2 seconds to show in UI. At that time I was just focus on MVVM pattern and ignore I can compress with page async operations. When I meet prismframework and found it has this async operation in baseviewmodel, I thought that awesome and we can do some async operation in viewmodel. But why the inbox xamarin can not do this.
2)Until now in 2023, one opinion above thread let me think the leverage about the clean mvvm pattern without page element or page operation, because the thinking about design pattern is important for our developer.
3）As a tech lead, I think the fast way to make new teammates to get familiar with the product/project codes.It is the framework that take few time to learn,why shouldn't we just use the original framework without others framework. Like UWP provide x:bind feature inbox at that time.

At last, if you go to look at others ideas I raised, like this idea, I just suggest that it is a virtual method, that's mean: hey the framework is good that provide enough features to us to do what I want to do. But that's will not bother me because it is virtual, it is just a options for me like prismframework do.

[TrueMoniker]

I've ran into a similar problem where I need to load data asynchronously after a view model is created.

On other posts, some suggest creating the task to load the data in the view model's constructor. I do not like that option because getting the final load onto the main thread is easy to mess up.

I agree with the discussions in this post to call the init code in the view's OnAppearing method. I chose to have the view model implement an interface so that it could still inherit from a class if needed

///Page
public partial class InitPage<T> : ContentPage where T : IInitViewModel
{
      private bool needsInit = true;

      public InitPage(IInitViewModel vm)
      {
          this.BindingContext = vm;
      }

      protected override async void OnAppearing()
      {
          base.OnAppearing();
          if (this.BindingContext is IInitViewModel vm)
          {
              if (needsInit)
              {
                  needsInit = false;
                  await vm.InitAsync();
              }
              await vm.OnAppearingAsync();
          }
      }
}

///View Model
public interface IInitViewModel
{
  Task InitAsync();
  
  Task OnAppearingAsync();
}

Cons:

• This violates the loose coupling of views and viewmodels. However, I am almost okay with it because Maui's single use object-based navigation data already violates it by passing view model parameters during page navigation.

Pros:

• Handles the asynchronous task on the proper thread so I don't have to think about it
• Ensure the init is only called once but the appearing is called each time
• ViewModel can still inherit a class if need be.

Notes:
The generic parameter in the InitPage provides type safety to ensure the view model actually implements the interface, though you could make it less strict by removing the generic parameter and leave the OnAppearing method.

[dsolteszopyn]

This can cause jerky page navigation because you have to wait for your init to finish before page finishes rendering. Makes app feel slow when navigating

[TrueMoniker]

Not in my experience. As long as your loading actions are asynchronous, the page will finish navigating while the loading is still occurring. I use it is to load lists asynchronously for several pages.

[dsolteszopyn]

If you await then it doesn't finish appearing until your loading is done. OnnavigatedTo should be used which fires after on appearing

[TrueMoniker]

That's interesting, because I'm using it in OnAppearing. Yes, in the most technical sense, the OnAppearing doesn't finish until my loading is done; all the visual elements of navigation do occur without issue while my loading is happening.

At one point I did try it in OnNavigatedTo and it worked just as well. I had to go back to OnAppearing though. I ran into edge cases with different behavior for OnNavigatedTo, like Tabs in a TabBar don't trigger OnNavigated when they are opened from another tab.

[matt-goldman]

I'm starting to think this might be a documentation issue. In many discussions the .NET MAUI team are encouraging people to perform page initialisation tasks in (or triggered from) the OnNavigatedTo page lifecycle method. I've been prodding this a little bit and have a write-up here: https://goforgoldman.com/posts/MAUI-EventOrder/

I would still like the framework to have an opinionated way of doing this, because it's such a ubiquitous requirement. But in the absence of that, if OnNavigatedTo is the recommended way, I would like to see that in the docs.

[LeoJHarris]

I'm quite interested in this as well and stumbled on this repo https://github.com/Keflon/Maui.MvvmZero and are now using it as a Prism replacement for MVVM navigation and taking advantage of page lifecycles in our view model pages.

Without going into all the details it has available OnOwnerPageAppearing and OnOwnerPageDisappearing for the view model.

MVVM navigation is supported

public async Task<TViewModel> PushVmAsync<TViewModel>(Action<TViewModel> initViewModelAction,

Which seems to be a similar to how Popups pushes the popup view model

this.popupService.ShowPopup<UpdatingPopupViewModel>(onPresenting: viewModel => viewModel.PerformUpdates(10));

To more easily support swapping out 3rd party plugins we created a NavigationService wrapper class:

public class NavigationService(IPageServiceZero pageServiceZero) : INavigationService
{
    TViewModel INavigationService.FindAncestorPageVm<TViewModel>() => pageServiceZero.FindAncestorPageVm<TViewModel>();

    Task<TViewModel> INavigationService.NavigateAsync<TViewModel>(Action<TViewModel>? initViewModelAction, bool isModal)
    {
        initViewModelAction ??= static vm => vm.Initialize(null);

        return pageServiceZero.PushVmAsync(initViewModelAction, isModal: isModal);
    }

    Task INavigationService.PopAsync(bool isModal, bool animated) => pageServiceZero.PopAsync(isModal, animated);

    Task INavigationService.PopToRootAsync() => pageServiceZero.PopToRootAsync();

    public void RemovePageBelowTop() => pageServiceZero.RemovePageBelowTop();
}

Initialize is just a virtual method in our base page view model, the null check on initViewModelAction ensures the base method still gets called if null.

Usage is as follows with our own custom NavigationParameters implementation:

 await navigationService.NavigateAsync<MyPageViewModel>(vm => vm.Initialize(new NavigationParameters
 {
     { NavigationParameterKeys.RandomParamKey, "The Value" }
 })).ConfigureAwait(false);