Callback to return value during App Shell navigation page closing

[TrueMoniker]

Example repo

I would like a consistent way to return a value to a previous page when a page is closed. For this discussion I'll call the original page the parent page and the page that was opened and is closing the child page. For me, it's a very common use case of: being in a parent page, opening a new child page to get a specific value, then needing that value returned to the parent page when the child page is closed. I would like to see an explicit interface for returning values added to the framework.

My proposed solution:

public partial class ViewModelWithReturn<TReturn> : ObservableObject, IQueryAttributable
{
    //TODO: I really want ViewModelWithReturn to be an interface, however I cannot find a way to ensure the recipient is correct without the recipientId.
    // and I cannot find a way to get the recipient id without passing it as an argument.        
    private static string RecipientIdName = "MySolution.RecipientIdName";

    private Guid recipientId;

    /// <summary>
    /// Part of <see cref="IQueryAttributable"/> . This is called when the navigation opens this view with parameters.
    /// </summary>
    public virtual void ApplyQueryAttributes(IDictionary<string, object> query)
    {
        this.recipientId = (Guid)query[RecipientIdName];
    }

    /// A command version of GoBackAsync, so that we can bind directly to it from the view xaml
    /// <param name="toReturn">The object to return. Must be passed as a command parameter</param>
    [RelayCommand]
    private async Task GoBack(TReturn toReturn)
    {
        await GoBackAsync(toReturn);
    }

    /// Closes this page and returns an object to whatever opened this page.
    /// In order to receive an object, the reciepient must have navigated to this page using <see cref="GoToAndReturn"/>
    /// <param name="toReturn">The object to return</param>
    public async Task GoBackAsync(TReturn toReturn)
    {
        WeakReferenceMessenger.Default.Send(new ViewModelWithReturnMessage<TReturn>(toReturn, recipientId));
        await Shell.Current.GoToAsync("..");
    }

    //A static helper that can be called from any object that wants to open this view and get a response when it closes. 
    /// Opens a page at the path and sets up to receive an object when the page closes.
    /// On the page closing, <paramref name="action"/> is executed.
    /// The page should use this viewmodel.
    /// <param name="recipient">The recipient to get the return. Should be <code>this</code></param>
    /// <param name="action">The action to execute when  the page closes and returns too where this was called</param>
    /// <param name="path">Path to navigate to. Obviously, don't close this page you are navigating from or it won't be around to get the callback.</param>
    /// <param name="query">Parameters to pass to the viewmodel, <see cref="IQueryAttributable"/> </param>
    public static async Task GoToAndReturn(object recipient, Action<TReturn> action, string path, Dictionary<string, object> query = null)
    {
        Guid thisRecipientId = Guid.NewGuid();

        //Unregister any previous registration. If we don't get a message back, we might try to reopen the page, which would mess with the subscription.
        WeakReferenceMessenger.Default.Unregister<ViewModelWithReturnMessage<TReturn>>(recipient);
        WeakReferenceMessenger.Default.Register<ViewModelWithReturnMessage<TReturn>>(recipient, (r, m) =>
        {
            //The recipientId makes sure we only have one class that handles the response, instead of any waiting for returns. 
            if (m.RecipientId == thisRecipientId)
            {
                //If this executes, we got the response back, so the view that we were listening for should have closed. We can unsubscribe from this.
                WeakReferenceMessenger.Default.Unregister<ViewModelWithReturnMessage<TReturn>>(recipient);

                //Execute the action to assign the result
                action(m.Value);
            }
        });

       //Add the recipient id to the query parameters so the child can tell who its parent is when sending the response in a message.
        query ??= new Dictionary<string, object>();
        query.Add(RecipientIdName, thisRecipientId);

        await Shell.Current.GoToAsync(path, query);
    }

    /// A message to pass data back from a viewmodel when it closes.
    /// <typeparam name="T">The type of the object that is being returned.</typeparam>
    private class ViewModelWithReturnMessage<T> : ValueChangedMessage<T>
    {
        public ViewModelWithReturnMessage(T value, Guid recipientId) : base(value)
        {
            RecipientId = recipientId;
        }

        /// the id of the object that should handle this message.
        public Guid RecipientId { get; }
    }
}

How it works:

It's passing the return value from the child to the parent through the WeakReferenceMessenger. It handles the setup for the messenger for me, I only have to remember to open the child page using the GoToAndReturn method, and close the child page using the GoBackAsync method.
To use, inherit the class ViewModelWithReturn in your viewmodel. Set the TReturn generic parameter to the type of the object returned.

public partial class MyViewModel : ViewModelWithReturn<MyResponseObject>

Then, when you want the page to close, call GoBackAsync with the return object.

await GoBackAsync(toReturn);

Override Back Button

If you want to return something when the back button is pressed, you can override the back button behavior in the page xaml to call a command you define. That command should call the GoBackAsync method.

<Shell.BackButtonBehavior>
    <BackButtonBehavior Command="{Binding MyMethodCommand}"/>   
</Shell.BackButtonBehavior>

Alternatively, ViewModelWithReturn provides the GoBackCommand to close the page and return the command parameter.

<Shell.BackButtonBehavior>
    <BackButtonBehavior Command="{Binding GoBackCommand}"
                        CommandParameter="{Binding ToReturn}"/>   
</Shell.BackButtonBehavior>

Usage

When navigating to the page that should return a parameter, call the static methdo on the viewmodel GoToAndReturn.

For the parameters:

• the recipient should always be this
• the action is the callback to handle the returned object
• the path is the same as the Maui app shell navigation path
• the query is the same as the Maui app shell navigation query parameter

await ViewModels.MyViewModel.GoToAndReturn(this,
    (response) =>
        MyResponse = response,
   "MyPagePath");

IMPORTANT: The page you are navigating to with GoToAndReturn must be registered in the AppShell routes rather than created in the app shell xaml at startup. This is because I am using IQueryAttributable to identify the returned to page and pass the parameter.

Pros:

• It's type safe. When used properly, the callback tells you the return type. Changing the return type of a child page without changing the call from the parent would be obvious to the developer because it would cause a compiler error.
• It guarantees uniqueness. If you open several child pages in quick succession, the callback for a closing child will only trigger the one time that is set from where it opened. Similarly, if you open a large stack of similar pages (like parent => child => parent => child), when the deepest child page closes, the callback will only trigger for the parent that opened the child, not the higher level ancestors.
• It can be used anywhere, not just from a page on the Shell. If you need to get a return value into a popup or service, it can. Just make sure you do not dispose of the parent before the child returns.

Cons:

• This still allows me to navigate to the child page or close the child page using the standard shell navigation, without handling the return value. Doing this would make the child page useless. Ideally this solution would enforce it's proper usage.
• It's heavy. It has it's own boiler plate code and it has to use the resources for passing around messages. Ideally a solution wouldn't need this many resources because roundabout way through the messenger.

Why I do it this way:

Maui doesn't have an explicit way to return a value when a page is closed. When I search around, I find two options recommended.

Option 1: Use the messaging center

based on this discussion
Use the messaging center ,now changed to WeakReferenceMessenger and StrongReferenceMessenger, to pass the return value back to parent page in a message. The parent page has to subscribe to the message the child is sending. This is the method I went with, though with my own layer on top. The messenger has a lot of boiler plate code, it is not type safe, it is easy to accidentally call an orphaned subscriber that hasn't been garbage collected yet, and can be difficult to understand why the subscription is there for anyone reading the code for the first time. My implementation uses the messenger option, but attempts to resolve these issues.

Option 2: Pass the value as a parameter from the child page back to the parent page

based on this discussion
I did not use this option. I have qualms with the way Maui handles parameters, discussed here. But besides that, this method of returning a value requires the parent page to handle the returned value as a parameter. If the parent page already accepts parameters, this adds another step for checking and casting the parameter that will only be there sometimes. If the parent page uses several child pages in it's lifetime, the problem is worse as each one will have a parameter condition in the parent page.

[herczegzoltan]

Hi,

Thank you for the solution this is what exactly I have been searching. However I got some issue with the usage.

I have created two pages and viewmodels:

public partial class NewPage1ViewModel : ViewModelWithReturn<MyModel>
{
    [ObservableProperty]
    MyModel _myResponse;

    public NewPage1ViewModel()
    {
        MyResponse = new();        
    }

    [RelayCommand]
    private async Task MyGo() 
    {
        await GoToAndReturn(this, (response) => MyResponse = response, nameof(NewPage2));
    }
}

 public partial class NewPage2ViewModel : ViewModelWithReturn<MyModel>
 {
     [RelayCommand]
     private async Task MyGoBack()
     {
         await GoBackAsync(new MyModel() { MyProperty = 10 });
     }
 }

NewPage1 is the parent page
NewPage2 is the child page

Inside
ViewModelWithReturn I changed to:
private static string RecipientIdName = "MauiApp.RecipientIdName";

When I debug I see the inside the GoBackAsync the recipientId guid is empty/full zeros.

Am I missing something?

[TrueMoniker]

Hi,
Thanks for trying it out.

Changing the value of RecipientIdName shouldn't cause any issue.
Please try this,

• In GoToAndReturn, what's the value of thisRecipientId when you call query.Add(RecipientIdName, thisRecipientId);
• In ApplyQueryAttributes, What's the value of the query[RecipientIdName]?

That is where we pass and retrieve the recipientId. The two values should match

[herczegzoltan]

In the GoToAndReturn at query.Add(RecipientIdName, thisRecipientId); for thisRecipientId seems I do have a valid guid value.

However when I call MyGoBack command in NewPage2ViewModel it calls the GoBackAsync(TReturn toReturn) here WeakReferenceMessenger.Default.Send(new ViewModelWithReturnMessage<TReturn>(toReturn, recipientId)); for recipientId is empty guid after the private class constructor is called with also empty guid.

ApplyQueryAttributes is not even called during this GoToAndReturn and GoBackAsync.

Do I need to do something with the ApplyQueryAttributes? Apply before calling
GoToAndReturn? I attached the two viewmodels

[TrueMoniker]

Hello,

In your AppShell, are you registering the second page as route or creating it in the AppShell directly?
In order to use the IQueryAttributable like I am, the page you are navigating to with GoToAndReturn must be registered in the AppShell routes rather than created in the app shell xaml at startup.

I created an example repo with my implementation and your pages. If changing the routing doesn't work, please try running the example repo and compare the difference between your solution and mine.

[herczegzoltan]

Hello,

Thank you for providing the example repository; it works as expected. As you mentioned, the root page must be registered in AppShell.

If I understand correctly, and based on my testing, navigation and return will not function properly if the initial page is not registered in AppShell.

In my application, I have tabs defined in AppShell, and one of these tabs includes a button that navigates to a subpage. From this subpage, I navigate further to another subpage. My goal is to return a value to the previous page rather than the root page.

Tab -> Page1 -> Page2

Data return
Page2 -> Page 1

I have done some investigation and this version is working for me (without registrating the root page in the appsehell):

As the test AppShell I did the following, there's a tab bar with multiple tabs. One of these tabs contains a button that navigates to a subpage Page1 using the regular Shell.Current.GoTo method. This subpage, which inherits from ViewModelWithReturn, has two buttons one navigates to Page2, and the other to Page3. When I press the back button with return on either of these subpages to return to Page1, I receive the expected values from both pages.

public partial class BaseViewModelWithReturn<TReturn> : ObservableObject
{
    public async Task GoBack(TReturn toReturn)
    {
        WeakReferenceMessenger.Default.Send(new ViewModelWithMessage<TReturn>(toReturn));

        await Shell.Current.GoToAsync("..");
    }

    public async Task GoToAndReturn(object recipient, Action<TReturn> action, string path) 
    {
        WeakReferenceMessenger.Default.Unregister<ViewModelWithMessage<TReturn>>(recipient);
        WeakReferenceMessenger.Default.Register<ViewModelWithMessage<TReturn>>(recipient, (r, m) =>
        {
            action(m.Value);
        });
        await Shell.Current.GoToAsync(path);
    }

    private class ViewModelWithMessage<T> : ValueChangedMessage<T>
    {
        public ViewModelWithMessage(T value) : base(value)
        {
        }
    }
}