Multiple beamers example: unpredictable Android back button behaviour

[andr2k]

Describe the bug There is a bug in this example: (https://github.com/slovnicki/beamer/tree/master/examples/bottom_navigation_multiple_beamers)

When another tab is selected, the system back button affects the hidden tab's state

Beamer version: master,

To Reproduce Steps to reproduce the behavior:

1. Start the app
2. Click on any book (check that you see the item details)
3. Click on 'Articles'
4. Click on any item there (check that you see the item details)
5. Click on the system back button
6. Click on the system back button (yes, again)
7. Click on 'Articles'
8. Click on the system back button
9. Click on 'Books'

device-2023-05-17-125245.webm

Result The back button click affected the hidden tab: 'Books' shows the list of items instead of the previously selected item The tab was changed to 'Books' on step 6

Expected behavior Pressing the back button should affect only the current tab, it should not change the tab

Smartphone (please complete the following information):

• Device: Pixel 2 (emulator)
• OS: Android 9, API 28

[andr2k]

Seems like using BeamerBackButtonDispatcher with fallBackToBeamBack set to false solves the issue to some extent:

IndexedStack(
        index: currentIndex,
        children: [
          Beamer(
            routerDelegate: routerDelegates[0],
            backButtonDispatcher: BeamerBackButtonDispatcher(
              delegate: routerDelegates[0],
              fallbackToBeamBack: false,
            ),
          ),
          Container(
            color: Colors.blueAccent,
            padding: const EdgeInsets.all(32.0),
            child: Beamer(
              routerDelegate: routerDelegates[1],
              backButtonDispatcher: BeamerBackButtonDispatcher(
                delegate: routerDelegates[1],
                fallbackToBeamBack: false,
              ),
            ),
          ),
        ],
      )

[slovnicki]

Hey @andr2k :wave: Thanks for creating an issue and sorry for my absence lately.

I can reproduce the bug and will try to find the root cause, which should give us an internal fix that doesn't require any workarounds in the example.

These back button dispatchers are always tricky... :thinking:

The error seems to be caused by routerDelegates[1] not taking the priority properly during its update call.