Prism: Remove pages from NavigationStack without pushing another one

Created on 16 Mar 2018  路  8Comments  路  Source: PrismLibrary/Prism

Description

I want to remove pages from my current navigation stack (i.e. I want to go two levels back).

Say my current NavigationUriPath would be NavigationPage/CampaignOverviewPage/CampaignMainPage/RecordPage/SummaryPage

I have a two step approach of recording data, first go the record page and then see the data on the summary page before submitting. After the submit I want to go back to the main page of the data collection campaign.

I tried using NavigationService.NavigateAsync("../../"); but I doesn't do anything. GoBackAsync only works for one level. Removing pages from the NavigationStack only works when pushing another page, which I don't want.

Steps to Reproduce

  1. Create a navigation hierarchy similar to above
  2. Try to navigate two pages back without pushing another page

Expected Behavior

NavigationService.NavigateAsync("../../"); from the summary page should bring me back to the main page.

Actual Behavior

Nothing happens and I stay at the summary page.

Basic Information

  • Version with issue: 7.0.0.396
  • Xamarin.Forms version: 2.5.0.122203
  • IDE: Visual Studio 2017 Preview
XF enhancement

Most helpful comment

This has been implemented in the form of PR #1427. This will be merged later today and available via our CI builds on MyGet for testing.

All 8 comments

funny, I tried this today not realizing that it wasn't supported. This is more "GoBackAsync" related, but should totally be supported 馃榾

I'm really struggling with this one because I don't like having two ways of doing the same thing. There is already a GoBackAsync API meant for going back. However, this would only work within a NaviationPage, so it may not be that big of a deal.

It's important to understand that the "../" does a RemovePage operation, and not a Pop. So this means that if you were to try and use "../" without pushing another page, you would not get the pop (go back)animation. This may not be the desired end-user experience. I would almost just say that you should call GoBackAsync multiple times.

I think the only way to make it go would be to have another internal method for this specific case whereby you remove to underlying Page(s) and then call GoBackAsync :man_shrugging:

Yeah, I'm having a hard time convincing myself to implement this.

:cry:

This has been implemented in the form of PR #1427. This will be merged later today and available via our CI builds on MyGet for testing.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings