Update the Shell Page of the NavPanel to use the new NavigationView control

[mrlacey]

Use the new native control when targeting Fall Creators Update

https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/navigationview

[crutkas]

goal here is to use the UWP Community Toolkit control, they will do the heavy lifting to support it, we migrate off once we have mainstream Fall Creators Update support. We won't migrate to this for a bit.

[crutkas]

cross ref: #212

[mrlacey]

Yes, there was a PR somewhere for moving to the community toolkit version. Added this when I discovered that the FCU will have a native control. At that point, we should switch to the native control, from the toolkit.

[crutkas]

agreed but that won't be for a bit due to the n-1 release rule.

[mrlacey]

@crutkas Xref #334 would be good to understand the implications of the N-1 rule. It also stops the ability to use WTS to explore new SDKs when they are out in preview. It's also the cause of #327. If we can get stats on the distribution of what versions people are running it would really inform this decision.

[crutkas]

This will happen after next release after Fall Creators Update

[ralarcon]

@mrlacey @crutkas We need to evaluate the implications of this change as well as if we can aford it for 1.5

[crutkas]

we are not updating to NavView until the next full update of Windows. The UWP Toolkit will handle a smart flip for this control depending on the build you are on.

[crutkas]

This will happen in the spring 2018 time frame :)

[mvegaca]

There is a documentation to explain how to move to NavigationView from HamburguerControl.

[mvegaca]

I will have a look on that.

[mrlacey]

The toolkit documentation is something we should point anyone with an existing app too.

Need to consider the impact on Settings in particular and try our best to not break backward compatibility when using 2.x templates to add pages or features to projects created with 1.x.

[mvegaca]

I've been working on adding NavigationView control to SplitView projects. In this branch can be generated apps that uses NavigationView control with all project types, Mvvm Basic framework, and Blank-Settings pages.

The first approach done is based on NavigationView documentation. We were trying to not use the Switch sentence on ShellViewModel and after finding this article on Jerry Nixon we update the templates to generate the apps using an Extension Class.

CountriesApp_Switch.zip
CountriesApp_Extension.zip

Templates update summary:

• Uwp Community Toolkit stops being necessary on Navigation pane projects.
• Now we don't need the ShellNavigationItem class.
• Titles in pages are now contained in the NavigationView HeaderTemplate instead of pages code. That provides a best user experience. In other project types (Blank and Pivot) The title of pages is composed using a composition template.
• SettingsPages is added to the NavigationView control using the property IsSettingsVisible and handle settings NavigationViewItem item in code. The problem here is that NavigationView has the responsibility to set the icon and the content of this menu item and always set the Gear icon and Settings label (this label is translated to other languages on runtime). If we use that we could think on cancel settings page name edition in the wizard.
• Now if you add a page to an old project that uses HamburgerMenu the postaction that adds the NavigationViewItem fails. It can be explained on a documentation with two options: How to add the new generated page to an old HamburguerControl or how to Update HamburguerControl on your project to start using NavigationView control.

@mrlacey @crutkas could you please review the two different approaches?

IMO Extensions created by Jerry Nixon is a better solution but could be not easier to understand to a new developer in the platform, but this removes a postaction on ShellViewModel and you can not break the navigation by changing a Tag property.

[mvegaca]

I'm agree with your naming proposal Matt.
By now, NavigationView is added on C#: CodeBehind, MVVM Basic, MVVM Light and CaliburnMicro (Prism missing). Apps can be generated in this branch.
I also have the proposal to remove the title in page for TabbedPivot project as it looks redundant.

[mvegaca]

Title TextBlock is defined in a composition template with the filter ProjectType != NavigationView. We only need to update this to ProjectType = Blank.

[mrlacey]

I think we can remove the "Title TextBlock" from every page regardless of project type. It's basically just placeholder content and expected to be removed anyway.

[sibille]

Thats true, but the blank project would be very blank without the title I guess. It also provides guidance about how to localize strings

[mrlacey]

Actively working on the VB versions

[mvegaca]

VB template merged. I was checking that all works fine. I'm going to remove the titles on Pivot Projects on a separated commit.

[mvegaca]

On this commit I've updated the ItemNameEditable property to enable pages to be single instance template. This is oriented to set a fixed name to settings page because NavigationView isn't thought to have more than one settings page.

[sibille]

NavigationView is setting the settings page name always to "Settings" (or its localized values) independently of the name you choose, that's why we think settings page name should not be configurable in the wizard to avoid confusion. But we loose the possibility to rename it on the Tabbed/Pivot (and Blank) project type too.

Telem for the last month has been 70% SplitView (15% each Blank and Tabbed Pivot)

[mvegaca]

Pull Request added! #2115

[sibille]

Created #2126 to see if we can re-enable name editing for settings page in project type blank and tabbedpivot.

[sibille]

NavigationView is in dev now. @lee or @milazzom could you have a look at the Prism implementation. @nigel-sampson could you have a look at the Caliburn.Micro implementation. Thanks!!

[nigel-sampson]

Will take a look tonight thanks @sibille

[sibille]

@mrlacey, for CodeBehind the helper method that looks for the correct NavigationViewItem comparing NavHelper and SourcePage type is called IsNavHelperForPageType, on the other frameworks IsNavigationViewItemFromPageType. Is there a reason for naming this different in CodeBehind? I think both are correct names for all frameworks, but both are difficult to understand. Would IsMenuItemForPageType be a better name?

[mrlacey]

@sibille yes IsMenuItemForPageType does sound better.

[mrlacey]

I've raised a PR to standardize the names

[nigel-sampson]

Looks ok to me, a little sad to see the move away from a more view model driven approach and having the view "leak" into the view model as raised earlier by @mrlacey but some of the binding limitations on navigation view make this unfeasible.

There could be some ways to work around this given we're already abstracting the view behind an interface though.

[mrlacey]

Verified in
wizardVersion="v0.17.18102.1"
templatesVersion="v0.17.18102.3"