Navigation model for an adaptive layout

[saket]

Does appyx offer any advice for building navigation systems for resizable apps that can switch between phone and tablet layouts while retaining its back stack?

I'm imagining a two-pane layout in tablet mode. When navigating to any screen, I'd like to open it in one of the two panes depending on some condition. When the app is resized to phone mode, I'd like to move all screens to a single pane.

[LachlanMcKee]

Hey @saket!

This is something I'm quite interested in exploring. I tried to implement this using jetpack navigation (in a different project), but hit some problems due to restrictions in Google's API.

I had planned to introduce these changes into Appyx. I will take a look this weekend, and figure out how much effort it would be.

It would also be nice to have for foldables as well!

[LachlanMcKee]

I made pretty decent progress over the weekend on this! Hopefully once I tidy a few things up I will submit a proposal PR later this week, or early next week.

The WIP API I am currently looking at is (forgive the slightly terrible pseudo code):

DualBackStack {
   constructor {
       initialLeft: Route
       initialRight: Route?
       showTwoBackStacksFlowable:  Flowable<Boolean>
   }

   operations {
      pushLeft(route)
      pushRight(route)
      pushBoth(leftRoute, rightRoute)
      popLeft()
      popRight()
      pop() // pops right until there is no right, then pops left until the last left route
      updateBackStackConfiguration() // This would be handled internally and would restructure the BackStack(s) depending on the state of 'showTwoBackStacksFlowable'
   }
}

An implementation of the showTwoBackStacksFlowable could then configured that inspected the configuration of the device and emit when something changes (i.e. rotation, unfold)

When there is only one backstack visible, it would show all the right backstack elements on top, then the left backstack elements below it. When you rotate/unfold they would be moved back to their left/right panels

[saket]

When there is only one backstack visible, it would show all the right backstack elements on top, then the left backstack elements below it. When you rotate/unfold they would be moved back to their left/right panels

I think this would break the visual hierarchy of screens by showing possibly stale screens on top. Here's how I'm imagining this:

Tablet: A (left) -> B (right) -> C (left) -> D (right)

When the device is switched to phone mode, the app will have C in foreground, which wouldn't be correct. When back is pressed, the app will go back to A, which wouldn't be correct either.

[LachlanMcKee]

The implementation that I wrote over the weekend would work as follows:

Tablet: L1 (left) -> L2 (left) -> R1 (right) -> R2 (right)

The list would always have the left elements to the list of the backstack, and the right elements on the right of the backstack.

In this case when you switch to phone mode, it would show R2 in foreground (as it's the right most element in the backstack). If you press back it would go back to R1.

I think that makes sense from a visual hierarchy perspective. Let me know if you think otherwise and we can brainstorm!

So just to put this in a less wordy format:

Initial setup

Tablet: L1 -> L2 -> R1 -> R2
Phone mode (1 panel): L1 (inactive) -> L2 (inactive) -> R1 (inactive) -> R2 (active)
Tablet mode (2 panels): L1 (inactive) -> L2 (active) -> R1 (inactive) -> R2 (active)

Back press example

Back press 1
Phone mode (1 panel): L1 (inactive) -> L2 (inactive) -> R1 (active)
Tablet mode (2 panels): L1 (inactive) -> L2 (active) -> R1 (active)

Back press 2
Phone mode (1 panel): L1 (inactive) -> L2 (active)
Tablet mode (1 panel): L1 (inactive) -> L2 (active)

Back press 3
Phone mode (1 panel): L1 (active)
Tablet mode (1 panel): L1 (active)

Push example

Push Left (L3)
Phone mode (1 panel): L1 (inactive) -> L2 (inactive) -> L3 (inactive) -> R1 (inactive) -> R2 (active)
Tablet mode (2 panels): L1 (inactive) -> L2 (inactive) -> L3 (active) -> R1 (inactive) -> R2 (active)

Push Right (R3)
Phone mode (1 panel): L1 (inactive) -> L2 (inactive) -> R1 (inactive) -> R2 (inactive) -> R3 (active)
Tablet mode (2 panels): L1 (inactive) -> L2 (active) -> R1 (inactive) -> R2 (inactive) -> R3 (active)

Push Both (L3, R3)
Phone mode (1 panel): L1 (inactive) -> L2 (inactive) -> L3 (inactive) -> R1 (inactive) -> R2 (inactive) -> R3 (active)
Tablet mode (2 panels): L1 (inactive) -> L2 (inactive) -> L3 (active) -> R1 (inactive) -> R2 (inactive) -> R3 (active)

[KovalevAndrey]

I don't think we should change underlying NavModel for that case. I haven't tried to build anything myself but this is what we can do at the moment:

1. Have more than one NavModel for the Node:

class ContainerNode internal constructor(
    buildContext: BuildContext,
    private val backStack: BackStack<Routing> = BackStack(
        initialElement = Picker,
        savedStateMap = buildContext.savedStateMap,
    ),
    private val backStack1: BackStack<Routing> = BackStack(
        key = "backStack1_key",
        initialElement = Picker,
        savedStateMap = buildContext.savedStateMap,
    )
) : ParentNode<Routing>(
    navModel = backStack + backStack1,
    buildContext = buildContext,
) { ... }

2. Depending on the screen size we can configure layout where to draw children

       Row(modifier = modifier.fillMaxSize()) {
            Children(
                modifier = modifier
                    .fillMaxHeight()
                    .fillMaxWidth(0.5f),
                navModel = backStack,
            )
            Children(
                modifier = modifier
                    .fillMaxSize(),
                navModel = backStack1,
            )
        }

3. Filter and rendrer children of specific type:

            Children(
               modifier = modifier
                   .fillMaxSize(),
               navModel = backStack1,
           ) {
               children<Routing.SpecificType> { child ->
                   child()
               }
           }

[LachlanMcKee]

Oh, that's really cool! I'll try implementing that and see how it goes.

I wasn't proposing modifying an existing NavModel, but creating a new one.

This approach could be more flexible however as you could have a different NavModel type for each column.