When and how to use PrismNavigationPage

[munkii]

In the PrismAppBuilder action on startup I initialise our navigation stack like this

prism.CreateWindow( 
            "NavigationPage/HomeViewModel",
            HandleNavigationError);

My understanding is that the use of "NavigationPage" at the start of the uri is telling Prism to wrap Home in a Microsoft.Maui.Controls.NavigationPage.

When running the app in iOS I see a warning after pressing the "Back" button in the NavBar that says

NavigationPage has encountered an unhandled GoBack. Be sure to inherit from PrismNavigationPage.

All the Views in our app are ContentPages. What or where should I be inheriting from PrismNavigationPage?

[MarioSansone]

We also notice the same message "NavigationPage has encountered an unhandled GoBack. Be sure to inherit from PrismNavigationPage." when we navigate back via the left-arrow icon in the navigation bar which the iOS shows automatically if you navigate to a page. We are using "Prism 9.0.401.20976" on iOS and Android.

We even HAVE a class named "BaseNavigationPage" which inherits from PrismNavigationPage (like proposed in the warning) and it does the correct Back-button behaviour for Android, for iOS it has no logic but passes through the calls.

I can see from the Prism Library source code where this warning message is printed out, but I don't understand it. Who sets the NavigationSource and why is this NavigationSource always set to "Device" when we use the Prism NavigationService in all places in our app? So is "Device" the correct NavigationSource? And if "yes", why we always see this warning message?

Here is a sample navigation from a ListView to a detail page. We see that the PrismNavigationService is used and the NavigationSource is set to "Device", so when you navigate back from this detail page to the list page, you will again see this warning message:

https://github.com/PrismLibrary/Prism/blob/release/stable/9.0/src/Maui/Prism.Maui/Behaviors/NavigationPageSystemGoBackBehavior.cs

    private void NavigationPage_Popped(object sender, NavigationEventArgs e)
    {
        if (PageNavigationService.NavigationSource == PageNavigationSource.Device)
        {
            System.Diagnostics.Trace.WriteLine("NavigationPage has encountered an unhandled GoBack. Be sure to inherit from PrismNavigationPage.");
            MvvmHelpers.HandleSystemGoBack(e.Page, AssociatedObject.CurrentPage);
        }
    }

@dansiegel Can you please perhaps help here?

[thomasgalliker]

We inherit from PrismNavigationPage in order to get more control over the properties of NavigationPage. In one particular situation, we want to show/hide NavigationPage.ToolbarItems (which is part of a NavigationPage). To do so, we created a MainNavigationPage which inherits from PrismNavigationPage and registered it in the DI container:

containerRegistry.RegisterForNavigation<MainNavigationPage>("MainNavigationPage");

When we navigate paths like /MainPage/MainNavigationPage/HomePage a new instance of MainNavigationPage is used and we can programmatically control the visibility of the ToolbarItems from anywhere.

Some very important things I had to learn:

• Prism automatically registers PrismNavigationPage if no registration is done by myself. Even in my case, when I navigate a path like NavigationPage/SomeOtherPage, it uses PrismNavigationPage - and not MainNavigationPage (for obvious reasons).
• BE VERY CAREFUL when you inherit from PrismNavigationPage: DO NOT USE the constructor with the Page parameter. Instead USE the empty/default constructor. Otherwise you'll eventually end up with a navigation mess. (@dansiegel we should probably even think of removing the ctor(Page) from PrismNavigationPage. At least for now, I don't see a reason to have it there).

[dansiegel]

You really shouldn't need to ever provide your own NavigationPage. It's a bit of a weird scenario IMO. You should be able to apply a global style to customize the look and feel. Prism.Maui automatically registers the PrismNavigationPage using the NavigationPage key. You can of course override this by providing your own NavigationPage using the same key and Prism will not add the default registration.

[MarioSansone]

Oh, that's an helpful info. So you suggest to remove this BaseNavigationPage and simply use "NavigationPage" in all places where we do a "NavigateAsync()" call? I migrated this BaseNavigationPage from Xamarin Forms and an older version of Prism. So it could be that the stuff which was handled by this class (and only for Android btw) is perhaps already handled by Prism correctly and the styling of navigation bar could be moved to handlers?

Here is the code of this BaseNavigationPage. I think some lines of this code were from old days. ;-)

public class BaseNavigationPage : PrismNavigationPage
{
#if ANDROID
	INavigationPageController NavigationPageController => this;

	public new event EventHandler BackButtonPressed;

	public BaseNavigationPage()
	{
		BackButtonPressed += HandleBackButtonPressed;
		BarTextColor = Colors.White; // Android needs a white text color in the colored navigation bar
	}

	public BaseNavigationPage(Page page) : base(page)
	{
		BackButtonPressed += HandleBackButtonPressed;
		BarTextColor = Colors.White; // Android needs a white text color in the colored navigation bar
	}

	private async void HandleBackButtonPressed(object sender, EventArgs args)
	{
		await Prism.Common.MvvmHelpers.HandleNavigationPageGoBack(this);
	}
#else
	public BaseNavigationPage() { }

	public BaseNavigationPage(Page page) : base(page) { }

#endif

	protected override bool OnBackButtonPressed()
	{
#if ANDROID
		if (CurrentPage.SendBackButtonPressed())
			return true;

		if (NavigationPageController.StackDepth > 1)
		{
			BackButtonPressed.Invoke(this, EventArgs.Empty);
			return true;
		}

		return false;
#else
		return base.OnBackButtonPressed();
#endif
	}
}