[2.0] Single navigation history stack, back button to go back to the last screen

[hedgepigdaniel]

Is your feature request related to a problem? Please describe.
I find it confusing that there are multiple navigation history stacks. As I navigate through the app and use the Android back button, I expect to be taken to the last screen I was on. Instead, the back button goes to various screens that I don't expect. For example:

• Starting from the library tab, I press the search icon and enter a search query. When I press the back button, I expect to go back to the library tab, but instead the app exits.
• Starting from the search results screen, I click the play bar to open the now playing screen. Then, I open the context menu and select "View artist", which takes me to the artist screen. When I press the back button, I expect to go back to the now playing screen. If I press it a second time, I expect to go back to the search results screen. Instead, the first back button press takes me to the last screen I used inside the library tab.

Describe the solution you'd like
Instead of having multiple stacks of navigation history inside the 4 tabs (library, browse, search, settings), I would prefer for there to be only one. This matches my mental model of what the back button does - i.e. it goes back to where I was before.

The only exceptions I expect are:

• things that I don't see as "screens" should not be counted in the history. For example, if I open a context menu and "View artist", when I go back it would make sense if the context menu was closed rather than open (although I think open is fine too). This is because I understand the context menu as a thing I opened within the existing screen, not a separate screen I navigated to.
• things that could be considered redirects, or pre-configured flows. For example when I open the app for the first time I'm taken to the settings screen to add a source. After I've done this, I don't ever want to go "back" to the sources settings. Instead, I perceive that I was always on the default/home part of the app, but I was redirected through the login/setup flow before I could see it properly, as though the login flow was displayed physically on top of the library/default view, rather than chronologically before it.

Additional context
I think this could be implemented with auto_router by flattening the routes configuration, so there are no nested children.

This means that pages like ArtistPage would be independent of the tabs - i.e. not inside any tab in particular. The tab bar could behave in two ways with these routes:

• Always visible. When navigating to a route that is not in a tab, then there is no highlighted/selected button in the tab bar. Arguably now they are not so much "tabs" but "shortcuts".
• Replaced by routes outside tabs. When navigating to a route that is outside any tab, the tab bar is no longer visible. The user would need to go back to the tabs screens in order to see the tabs and select a different one.

If we can agree on an approach I'd be happy to make a PR.

[austinried]

This is pretty much what I'd like the navigation to be as well, and it would mostly match the 1.x behavior as well, I just haven't had time to work on the auto_route configuration for it. I am not sure configuring auto_route is as simple as just flattening the routes configuration however, but I would be open to a PR if you have a solution.

Couple things I would like to specify for the approach here though:

• The only screen that I believe should be above both the tab bar and the now playing bar is the now playing screen. Everything else (album/artist/playlist/source etc.) should still show the now playing bar and tab bar on the screen.
  • I'm actually not super concerned about the tab bar here, it's mostly the now playing bar I want to be visible while the user is browsing their library, but since that's above the tab bar it sort of needs to be shown as well. If you have other ideas here I'm open to them.
• The library tabs (albums/artists/playlists/songs) should probably not be in the history stack

Also, this bit sounds like a bug:

For example, if I open a context menu and "View artist", when I go back it would make sense if the context menu was closed rather than open

My intention here (and what happens on my devices) is that the context menu is closed once you choose an option that navigates somewhere else.

[hedgepigdaniel]

I am not sure configuring auto_route is as simple as just flattening the routes configuration however

Yeah, I've done a bit more experimentation and while doing that does fix the history stack, it introduces problems with animations (the tab bar "reappears" on each transition, even though I would say it didn't go anywhere and should not be included in the animation). I'm tempted to try vrouter aswell, because it's one of the few flutter routing packages that supports nested routes in terms of components (hopefully therefore animations), but still maintains a single linear history. Will fiddle a bit more and let you know what I come up with.

Everything else (album/artist/playlist/source etc.) should still show the now playing bar and tab bar on the screen.

Makes sense - I'll try and make that work and if there's an issue with it we can discuss alternatives.

The library tabs (albums/artists/playlists/songs) should probably not be in the history stack

Makes sense. I'm reading this as "when swiping between albums/artists/etc, that does not push a new entry onto the history stack - instead it replaces the current entry".

My intention here (and what happens on my devices) is that the context menu is closed once you choose an option that navigates somewhere else

Agree - AFAICT that is how it works - I don't see a problem. I was just describing how I expect it to work as a user, to illustrate the things that "don't count" as transitions in my mind. I think it's similar to what you said about the library artists/albums/etc - except that probably those tabs maintain their state when you go back, in contrast to the modal, which probably should be gone by the time the user comes back to the screen where it was shown.

[austinried]

Normally I think I would say swapping out routing packages at this point is too big of a change, but to be honest auto_route has been getting on my nerves for awhile now. After I upgraded to v6 I had other animation related bugs and had to downgrade back to v5, and it seems overly complex to do stuff like observe the current route/path.

So, I would also be open to swapping that out, but I'm mostly looking for a simpler solution here. I'm hesitant about vrouter though due to the not being updated in 12 months.