Reverse chronological navigation on platforms with a hardware back button (Android for example)

[Norbert515]

TLDR: The hardware back button (for example on Android) should navigate in reverse chronological order when up navigation is not available.

The setup is as follows:

Suppose you are on a login screen, and you can navigate to the registration screen by tapping a link.

A sensible implementation for this would be:

'/login' => LoginPage()
'/register' => RegisterPage(),

When tapping the link on the LoginPage:

context.go('/register')

But what happens when the user wants to go back to the login page?

Where this works

The following sections are about scenarios where this implementation works out of the box.

Web

On the web, the browser handles navigating backward by implementing a so-called 'Reverse chronological navigation.' This term essentially means, going back in the browser will always go back to the last URL you visited, regardless of what relation it has to the current route.

In this case, the initial route is '/login'; this is saved internally by the browser. Then the user navigates to '/register' but decides to want to go back to login. Pressing the back button results in the browser going back to '/login' as the last URL visited.

This is to be expected and works out of the box.

More information about this: https://material.io/design/navigation/understanding-navigation.html#reverse-navigation

Platforms without a hardware back button

Some platforms don't have the notion of a hardware back button. A prominent example of this is desktop (regardless of OS).
For example, when navigating to a page on Windows, there is no way to go back to the previous page except if the app implements that itself.

In this case, a sensible implementation to allow the user to go back to log in would be to include a 'Want to login instead?" link which goes to '/login' like:

GestureDetector(
  onTap: () {
    context.go('/login'):
  },
  child: Text('Want to login instead?')
)

As there is no hardware back button for the user, the app has to provide a way to navigate further in the app explicitly.

Where this breaks - the hardware back button

Some platforms (in addition to the web) provide a way to navigate the hierarchy themselves. A prominent example of this is Android.

Source: https://stackoverflow.com/questions/61931429/what-is-the-name-of-bar-that-contains-hardware-back-button-on-android-emulator-a

On Android, it is widespread to use the hardware back button to navigate backward in apps. The most common navigation is 'upwards.' This means if multiple routes are pushed (using sub-routes), allowing going 'up' the navigation stack.

Before back press

/items/blue_vase

After back press

/items

These routes are in relation to each other (items being the parent of blue_vase). This upwards navigation is automatically handled by go_router.

The unexpected

Coming back to the initial scenario, when the user navigates to '/register' and presses a hardware back button
-> the app closes?!

This is because when the user goes to '/register' it is not pushing the route on the stack but instead replacing the URL with another one. Because go_router only handles upward navigation but not Reverse chronological navigation (as a browser is), there is nothing to go back to.

As an Android user, I would not expect that.

Ways to achieve this

A couple of ways reverse chronological navigation could achieve this currently

Sub routes

One could create a route '/login/register' that would make this a parent-child relation which would fix navigation. The URL would look very weird on the web, though.

Linking back to '/login

This is the preferred way on desktop but doesn't handle the hardware back button on Android

Using push

This works and generates the desired result on all platforms but introduces additional complexity to the application. It is essentially going back to Navigator 1.0 way of doing things and is discouraged (From what I personally understood).

The proposal

Add configuration about the hardware back button behavior. This would allow choosing Reverse chronological navigation on platforms other than the web (as the web already handles it on a browser level). Listening for hardware back events is pretty easy in Flutter, and the go_router would only have to keep track of a list of previously visited routes.
This implementation also wouldn't break desktop as there is no hardware back button.

Considerations

• How does this behave with push, or is push even needed anymore after this?

Additional resources

An interesting read about up vs. back navigation on Android: https://stuff.mit.edu/afs/sipb/project/android/docs/design/patterns/navigation.html