TODO

I need to add Unit tests but otherwise ready to review

Description of Change

• Creates the APIs required inside Maui.Core to implementation navigation
• Implements Navigation for Android. The Maui.Core implementation leans heavily on JetPack Navigation in order to avoid having to interact with fragment management ourselves.
• Toolbar Management still only exists at the controls level. In a later PR we'll better organized the ToolBar management into Core

INavigationView

The idea with only using requests is that it forces immutable communication about navigation stack changes. Once the xplat layer requests a change that's the change that gets applied and the native layer only applies changes related to those args. Requests are also useful because you need to convey information about the navigation operation (i.e. animated) which can't be indicated through a property change.

The nice thing about doing everything through stack mutations is that it allows you to modify the stack atomically opposed to having to chain navigation operations together.

For example in XF if you want to swap out the Main Page users would typically do

NavigationPage.InsertPageBefore(mainpage, newpage);
NavigationPage.Pop();

Or if you want to pop down multiple pages but not to root

NavigationPage.Pop();
NavigationPage.Pop();
NavigationPage.Pop();

Where as now we can add APIs that just let users perform multiple operations in one go.

// This would get exposed as a simpler API to the user but it demonstrates the behavior
void SwapRoot(object sender, EventArgs e)
{
	if (_currentNavStack == null)
	{
               // save stack so you can swap back to it
		_currentNavStack = Navigation.NavigationStack.ToList();
		(Parent as INavigationView).RequestNavigation(
		new NavigationRequest(
			new List<NavigationGallery>
			{
				new NavigationGallery()
			}, false));
	}
	else
	{
		(Parent as INavigationView).RequestNavigation(
			new NavigationRequest(_currentNavStack, true));

		_currentNavStack = null;
	}
}

public interface INavigationView : IView
{
	void RequestNavigation(MauiNavigationRequestedEventArgs eventArgs);
	void NavigationFinished(IReadOnlyList<IView> newStack);
}

Alternative API (possibly for future PR)

public interface INavigationView : IView
{
	IReadOnlyList<NavigationItem> NavigationStack { get; }
	void NavigationFinished(IReadOnlyList<IView> newStack);
}

public class NavigationItem
{
	IView View;
	Animation PopEnter;
	Animation PopExit;
	Animation Enter;
	Animation Exit;
}

NavigationManager

If users want to customize any of the behavior of navigation they can provide a custom Navigation Manager

public class NavigationManager
{
        public virtual FragmentNavigator.Destination AddFragmentDestination();
        public virtual void Connect(IView navigationView, NavigationLayout nativeView);
        public virtual void RequestNavigation(MauiNavigationRequestedEventArgs e);
        protected virtual void OnBackButtonPressed();
        protected virtual void OnNavigationViewFragmentDestroyed(AndroidX.Fragment.App.FragmentManager fm, NavigationViewFragment navHostPageFragment);
        protected virtual void OnNavigationViewFragmentResumed(AndroidX.Fragment.App.FragmentManager fm, NavigationViewFragment navHostPageFragment);
        protected virtual void OnDestinationChanged(NavController navController, NavDestination navDestination, Bundle bundle);
}

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might affect accessibility?

• Does this PR introduce a new control? (If yes, add an example using SemanticProperties to the SemanticsPage)
• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arrangement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me

If any of the above checkboxes apply to your PR, then the PR will need to provide testing to demonstrate that accessibility still works.