Issues/Confusion with Complex Relative Shell Navigation Routes

[shadowfoxish]

Referencing this, which has imo a more helpful explanation of routes than the official docs has.

The app I'm developing has a huge hierarchy of pages:

The visual hierarchy:

Root:
(ShellContent): home 
Warehouse (FlyoutItem):
    (ShellContent): barcodes
    (ShellContent): bininfo
    (ShellContent): iteminfo
    (ShellContent): binmove
Inventory (FlyoutItem):
    (ShellContent): receiving
    (ShellContent): receivingstatus
    (ShellContent): putaway
    (ShellContent): vcarts
Picking (FlyoutItem):
    (ShellContent): totes
    (ShellContent): assign
    (ShellContent): picking
    (ShellContent): pickQa
    (ShellContent): inspect
Root:
(ShellContent): myaccount

And then a series of non-visual sub and sub-sub pages:

Routes.Add("binmove/bin", typeof(BinMovePage));
Routes.Add("barcodes/edit", typeof(BarcodeEditPage));
Routes.Add("bininfo/bin", typeof(BinPage)); 
Routes.Add("iteminfo/whichItem", typeof(ItemDisambiguationModal));
Routes.Add("iteminfo/item", typeof(ItemPage));
Routes.Add("iteminfo/item/print", typeof(PrintModal));
Routes.Add("iteminfo/item/viewImage", typeof(ViewImagePage));
Routes.Add("receiving/workload", typeof(ReceivingPage));
Routes.Add("receiving/workload/print", typeof(PrintModal));
Routes.Add("receiving/workload/summary", typeof(ReceivingSummaryPage));
Routes.Add("receiving/workload/quantityBin", typeof(QuantityBinModal));
Routes.Add("receiving/workload/viewImage", typeof(ViewImagePage));
Routes.Add("receiving/workload/editor", typeof(ReceivingEditorPage));
Routes.Add("receiving/workload/whichItem", typeof(ItemDisambiguationModal));
Routes.Add("picking/pickBin", typeof(PickBinPage));
Routes.Add("assign/choice", typeof(PickTicketAssignChooseActionPage));
Routes.Add("inspect/pickTicket", typeof(InspectPickTicketPage));
Routes.Add("selectCart", typeof(SelectCartPage)); 
Routes.Add("selectCart/moveTotes", typeof(MoveTotesPage));
Routes.Add("putaway/cart", typeof(PutAwayByCartPage));
Routes.Add("putaway/cart/print", typeof(PrintModal));
Routes.Add("putaway/cart/prefs", typeof(PutAwayPreferencesModal));
Routes.Add("putaway/cart/whichItem", typeof(ItemDisambiguationModal));
Routes.Add("putaway/cart/quantityBin", typeof(PutAwayQuantityBinModal));

I try to do all routing relatively, unless there's a specific "go back to the beginning" need so I use three slashes.

I definitely have had issues with routing from one page to another and it seems like I'm consistently doing something wrong/misunderstanding/seems like something is missing from how I have this set up. The leading slashes also sometimes seem kind of arbitrary? I get a lot of 'cant figure out route' or 'ambiguous route' errors, for things where I'm simply trying to navigate to a descendant route.

The first example

... is kind of just some weirdness I've encountered:
If let's say I'm on route assign. A function on the page wants to bring you to another page, so I GoToAsync("choice", [args]). That works, but I dont think it should. The documentation says navigating to a route that does not start with a slash means we navigate UP the hierarchy (I'm interpreting UP as meaning toward root. Also UP/DOWN not a clearly explained concept in the docs), how could it possibly be finding the correct page to navigate to by moving UP? If I use GoToAsync("/choice", [args]), it also works, more in the way I'd expect. //choice makes an error "unable to figure out route for: //choice (Parameter 'uri')", and ///choice

Just to summarize, my current route is a shell route, assign and the result of navigating to...

• choice works, but not sure why
• /choice works
• //choice fails, "unable to figure out route for: //choice (Parameter 'uri')". Reasonable, it's not a root route
• ///choice fails, "unable to figure out route for: ///choice (Parameter 'uri')". This should work, if the documentation is to be believed.

The second example

... is more a physical constraint with navigation that I can't seem to work around. Its also a bit more esoteric:
All of the pages in the Picking FlyoutItem [totes, assign, picking, inspect] (except pickQa) share a common functionality. There is a series of screens that runs to change the status of the underlying objects. This works by having two pages that sort of chain execution and walk the user through a specific flow, selectCart followed by selectCart/moveTotes.

1. Lets say I'm on //inspect which is a root/visual hierarchy route.
2. I can click on an item, and view a detail page GoToAsync("/inspect", [args]). I'm now at //inspect/pickticket.
3. The user finds some data issue, so I want to start the selectCart workflow. GoToAsync("/selectCart",[args]). So far so good. I'm now at //inspect/pickTicket/selectCart. Wait a sec, how did that happen? The route for the page I want is at selectCart, how is this working?
4. Anyway, I satisfy that screen, and move to the next one, GoToAsync("/moveTotes",[args]). I'm now at //inspect/pickTicket/selectCart/moveTotes and interact there for a bit.
5. The page is happy, so it then does GoToAsync("../../../") which sends me back to //inspect. My intention is that the navigation stack resets at this point, because the process is finished and there is no way to really "go back" once you finish. Usually you do this by navigating to ///route.

Apart from the weirdness with selectCart/moveTotes, this is good and working.

Here's where the problem comes in. I'm hard coding ../../../ but really I need some way to go back to the ShellContent root route, whatever it is, but I don't know what it is. I can wind up in the selectCart/moveTotes workflow from any of the other screens; and with an arbitrary nesting level, and ../../../ wouldn't work. (Example; picking/selectCart/moveTotes). Basically what I want is to return to ///inspect or ///picking (or others) from moveTote, without having to have moveTote know where it is. Is that possible?

Taking it one step further...

The routes I have listed above were the closest thing I could come up with that works almost right.
What I attempted at first, made logical sense to me. Just make a route for selectCart in each path where it was possible.

Routes.Add("picking/pickBin", typeof(PickBinPage));
Routes.Add("picking/pickBin/selectCart", typeof(SelectCartPage)); 
Routes.Add("picking/pickBin/selectCart/moveTotes", typeof(MoveTotesPage));
Routes.Add("picking/selectCart", typeof(SelectCartPage));  /*There were two ways to get to selectCart from the picking path*/
Routes.Add("picking/selectCart/moveTotes", typeof(MoveTotesPage));
Routes.Add("assign/choice", typeof(PickTicketAssignChooseActionPage));
Routes.Add("assign/choice/selectCart", typeof(SelectCartPage)); 
Routes.Add("assign/choice/selectCart/moveTotes", typeof(MoveTotesPage));
Routes.Add("inspect/pickTicket", typeof(InspectPickTicketPage));
Routes.Add("inspect/pickTicket/selectCart", typeof(SelectCartPage)); 
Routes.Add("inspect/pickTicket/selectCart/moveTotes", typeof(MoveTotesPage));

This seemed clean, but I couldn't get it to work at all, because no matter how I tried to relatively navigate to selectCart it told me it was always an ambiguous route.

It also has the same problem of not being able to escape back to the root in any simple way. I would love to see navigation to "///" be an option to go back to the ShellContent page and clear the history stack.

Summary

1. What am I doing wrong with these routes in AppShell.xaml.cs?
2. Is it possible somehow to get Maui to dump out a list of all of the combined (AppShell.xaml and AppShell.xaml.cs) routes possible for the app? I tried some stuff with watch window, but the relevant classes I found are all marked internal.
3. The MAUI documentation should use ancestor, sibling, and descendant terminology when talking about the hierarchy.
4. Why did GoToAsync for "choice" work?
5. If there are multiple routes with the same naming but in different hierarchy paths, why does MAUI think they are ambiguous?
6. How can I simultaneously clear the history stack and return the user to the root ShellContent page they started from, without tracking the navigation stack depth myself?

[shadowfoxish]

For number 6, I implemented this as a workaround

public Task NavigateToCurrentRoot()
{
	string path = Shell.Current?.CurrentState.Location.ToString();
	string root = path.Split("/", StringSplitOptions.RemoveEmptyEntries)[0];
	return NavigateTo("///" + root);
}

[ToolmakerSteve]

IMHO, Shell is like a TabbedPage, with a navigation stack tacked on. I thnk it holds TWO kinds of information: the tab that is showing, plus a navigation stack for "go back".

I can't comment on its design decisions, or how it might be improved, but I've used it enough to address some of your confusion about how it works.

---

choice works, but not sure why

"upward" seems to first search for a (sibling) entry in current page's parent.
If not found, it recurses to parent's parent, and searches there.

Better description might be "first path element must be sibling of current page or sibling of an ancestor". By "first path element", I mean "choice/more" would look for "choice" in those places. Then would look for "more" child of "choice".

---

go back to the ShellContent page and clear the history stack.

The root isn't a page. Its AppShell itself. You have to tell it what root page (tab) you want to display.
Presumably it could be changed to go to the default (initial) page of Shell.

Alternatively, Shell could remember which tab you were displaying last, and pop back to that tab

---

///choice fails, "unable to figure out route for: ///choice"

The issue here is the part of "///" that does "The matching page will REPLACE the navigation stack."

Refer back to the beginning of this comment. The problem is that there isn't ONLY a nav stack. There also has to be a current root tab to "go back" to. Routing hides this limitation.

Perhaps this could be changed so that it acted exactly like "/choice" in your case.
If did from "inspect" tab, the nav stack would implicitly become "inspect", then "inspect/choice".
So ".." would pop back to "inspect" tab.

[By "implicitly", I mean that "inspect" isn't stored on the stack. Its held elsewhere. If you examine the actual nav stack, it will only have one page on it, "inspect/choice". If you pop that, the internal stack is empty.]

But "/choice" already does that, so don't need "///choice" to do the same

[askariya]

hey have you gotten an answer to this? It seems to me that there is no functional difference between GoToAsync("**/**page") v.s. GoToAsync("page").
I assumed one of them would work sort of like a "GoBackTo(specificPage)" but both just seem to push a new copy onto the stack so what even is the difference between using them?

[shadowfoxish]

The pathing helps figure out ambiguous routes. In my example above, GoToAsync("selectCart") would be ambiguous.

[askariya]

The pathing helps figure out ambiguous routes. In my example above, GoToAsync("selectCart") would be ambiguous.

Sorry, I'm confused how does it help? GoToAsync seems to always push a new page onto the stack, it doesn't seem like the contents of the hierarchy makes a difference for that.