NavigationBar Control

[kazo0]

We need a control that, on iOS and Android, will hook into the Android Toolbar and iOS UINavigationBar and provide a way to customize the native navigation bar. On other platforms, this control will simply be a façade for the CommandBar. The logic to forward DependencyProperties to the native Toolbar/UINavigationBar already exists as part of the CommandBarRenderer for iOS and Android. This logic will be imported to the Toolkit and will be renamed to NavigationBarRenderer. Below is the proposed contract for this new NavigationBar control. The properties outlined here will replace the current Extensions that are being used as part of the CommandBar as well as having similar DependencyProperties to those of CommandBar, which will be forwarded to the inner CommandBar that the NavigationBar is composed of.

Property	Type	Comments
NavigationButton	AppBarButton
NavigationButtonMode	NavigationButtonMode	Defaults to NavigationButtonMode.Native
Subtitle	string	Android Only
PrimaryCommands	IObservableVector<AppBarButton>
SecondaryCommands	IObservableVector<AppBarButton>	Not available for iOS
Content	object

We will apply the refactoring of the CommandBar Extensions from this discussion to the NavigationBar.

On Android and iOS, the NavigationBar will not be rendered where it is placed in the XAML. It will serve as a placeholder from which to read the information we need to pass to the NavigationBarRenderer that will, in turn, setup the native Android Toolbar or iOS UINavigationBar. On other platforms, the default NavigationBar control template will simply contain a CommandBar whose properties are template bound to the same properties on the CommandBar. So, on platforms like WASM/Skia, the PrimaryCommands, SecondaryCommands, Content, etc. will be forwarded to the inner CommandBar

[kazo0]

Based on https://platform.uno/docs/articles/controls/CommandBar.html#appbarbutton, we are only allowing AppBarButton as an acceptable Primary/Secondary Command

[davidjohnoliver]

What's the motivation for creating this new control, versus continuing to have this functionality in CommandBar?

[davidjohnoliver]

Also just to make sure, it's not actually called NavBar, right? NavigationBar, yes?

[kazo0]

Yeah that makes more sense :)

[davidjohnoliver]

Agreed that the present CommandBar situation is confusing for app developers in multiple ways.

At some point it was under consideration to associate native navigation bar functionality with the Page.TopAppBar property, presumably this is a different direction? Are there shortcomings with the TopAppBar approach?

At present, the native modes of CommandBar, Frame, and Page are all intercoupled. Is that going to pose problems for lifting the CommandBar native behavior out of Uno.UI into an external library?

[francoistanguay]

Dont think property names should contain Navigation or NavigationBar as it's redundant.

Also, can we toggle between "Modes" by switching presenters and removing the Mode property somehow?

Should the LHS button also be called some type of Command like "MainCommand" or something?

Can Content be anything of just some string Text?

Could SubTitle be anything as well?

I thought there was a Titlle extension property at some point?

[kazo0]

@davidjohnoliver The TopAppBar approach was something I noticed as a possibility as well. I think it is still an option to do it this way. The AppBar seems to be able to be aware of whether it is part of the BottomAppBar/TopAppBar as opposed to just being an "inline" AppBar. I figured we could start with one option and if it gets too hairy we can explore the other option

[kazo0]

Property	Type	Comments
MainCommand	AppBarButton
Subtitle	string	Android Only
PrimaryCommands	IObservableVector<AppBarButton>
SecondaryCommands	IObservableVector<AppBarButton>	Not available for iOS
Content	string or FrameworkElement

In this revision:

• NavigationButton is renamed to MainCommand
• NavigationButtonMode is removed. I believe that, within the NavigationBarRenderer, we can check whether the MainCommand's Command Property is set and, if so, we can then assume that we need to place the AppBarButton in the native UINavigationBar. The main use case for the old NavigationCommand was to override the action of the native left-side button to provide logic for things like popping up a dialog before navigating. (Need @jeanplevesque and/or @MatFillion to review). Instead of checking whether the AppBarButton exists or is visible here, we can simply check if the AppBarButton's Command property is set, and, if so, we know we are overriding the native behavior and therefore we can set native.LeftBarButtonItem

[jeanplevesque]

For custom actions on back navigation, you can check my proposition here:
unoplatform/uno#4580