mrlacey
commented
7 years ago This issue seems confused and overly broad.
Is it about adding to the sample and related documentation, or is it about changing the service?
While the bullet points above are good on their own they also need to be more clearly defined.
Navigate to a Single page
What does this mean, how is it different to the blank project type?
Navigate between navigation pane pages
Is this something people want, need, or are asking for? What scenarios is this good for and are there any examples of apps that use this?
Give a full-screen experience to a navigation pane page
Does this relate to the "FullScreen" functionality of the ApplicationView or something else? Why would it only be relevant for apps using a navigation pane?
Add a GoHome concept (cleaning the navigation stack)
Is this being asked for explicitly? There are good reasons to have and not have this behavior in an app using a NavPanel. Adding this could mean needing more configurable versions of existing templates or forcing all generated apps down a path that isn't appropriate for all. It's often more appropriate to apps with multi level navigation or a hub and spoke model. Clearing the back stack is only a single line of code, is there a lot of demand for this or specific benefit for adding it?
Leave the navigation pane to a single page and could choose if can go back or not
Why would you not want to go back after doing this?
Think about scenarios like First use tutorial page, extended splash screen, etc.
see more below
I think it's very important to be very careful about adding to the Navigation Service.
-
It would be very easy to build a lot of functionality into it on the basis that it might be useful but not balancing how it corresponds with the overall aims of the project. (Getting people started vs trying. to build an entire app.) As more functionality is added to this service it becomes more for anyone using the generated code to have to understand. As WTS is, in part, for trying to get people started with UWP development it's important to be careful about how much is being asked of them to understand the generated code versus general UWP knowledge. (I have concerns that the ActivationService already goes too far in this respect.) WTS should not, I believe, be trying to build mini-frameworks for pieces of functionality. There's lots of potential for overlap with the 3rd party frameworks that are incorporated (MVVM Light, Caliburn, & Prism) and it distracts from the actual goals of the project.
-
Any changes made to the NavigationService but which are specific to the NavPanel project type need to be made in consideration of the NavigationView control which we'll be switching to with FCU support.
-
Need to avoid modifying the service in small amounts with each release. There are lots of other, existing, issues that relate to this (#291 #292 #293 #294 #331 #462 #482 #697 #1012 and possibly more!) Making small changes that don't consider future requirements leads to more work overall as adding related items that weren't considered as part of earlier changes means the earlier work needs altering too. The frequent change of the code is also a potential issue for people working with the generated code as they have to adapt to the changes.
mvegaca
ralarcon
myokeeh
Related to the issue #775 and after creating the MixedNavigationSample and write the navigation documentation we need to think about different improvements to NavigationService.
Things that we need to think about adding to MixedNavigationSample:
Things that we could think about to improve the NavegationService to reach more complex app scenarios.
This could be an approach to solve this: Add an abstraction navigation layer in NavigationService in order to navigate across the app and handle a navigation stack without depending on the frame that realizes the navigation. This implementation could mean that NavigationService becomes harder to understand and use, but it will be more powerful.