Decompose Navigation Example for a BottomNav based UI

[falcon4ever]

Hi,

I'm working on a BottomNav demo to learn how to use Decompose. The sample is currently made for Android (Using AS Arctic Fox 2020.3.1 Beta 5 + Jetpack Compose) but the concepts should translate well for a KMM project.

Based on the docs (the routing example) and getting some inspiration from android-dev-challenge-compose-3 I created a demo project located here: DecomposeNavigationSample

I have attempted to structure the app like this:

   Root      
    |      
   Main (BottomNav lives here)      
 /  |  \     
A1  B1  C1 
|   |   |
A2  B2  C2

The reason there is a Root and Main component is because I saw it in the dev challenge 3 sample and thought it would be nice to have a mock landing/login page some point in the future:

           Root  
       /    |     \
Landing   Login    Main
                  /  |  \     
                 A1  B1  C1 
                 |   |   |
                 A2  B2  C2

Questions:

(1) How would one navigate from A1 to A2 (same for B and C)?

I am not sure how I am suppose to set up navigation from A1 to A2. I have exposed a navigateToA2() function in ScreenA1Component but should the actual navigation take place in the MainComponent as that's where the BottomNav and router lives? Does that mean the MainComponent needs to be aware of A2/B2/C2?

(2a) Multiple backstacks
This sample was also inspired by this demo: NavigationAdvancedSample and part of the purpose is to recreated the same behavior with Decompose.

Ideally I would like it to behave the same way as NavigationAdvancedExample does which is like this:

Case 1

• App opens up and displays A1 (default screen)
• A user taps the 3nd tab (Screen C1 is displayed)
• The user pressed the back button (A1 should now be displayed)

Case 2

• App opens up and displays A1 (default screen)
• A user taps the 3nd tab (Screen C1 is displayed)
• A user taps the button (Screen C2 is now displayed)
• A user taps the 1nd tab (Screen A1 is displayed)
• A user taps the 3nd tab (Screen C2 is displayed)

For the multipe backstacks to work properly, do I need to use multiple routers?

(2b)
In MainComponent, should I be using router.push or router.replaceCurrent when switching tabs? router.replaceCurrent was used in the dev challenge 3 sample, but when switching tabs I don't think I want to drop the previously opened tab.

[arkivanov]

@falcon4ever Thanks for good questions!

Regarding the question 1.

Based on the hierarchy you provided, A2 looks like a permanent child of A1. If you need to switch between A1 and A2, and if you want this navigation to be nested (so there is also a backstack of those nodes in Main), then you need intermediate nodes.

          Root      
           |      
          Main (BottomNav lives here)      
       /   |   \
     /     |     \
   A       B       C 
  / \     / \     / \
A1   A2 B1   B2 C1   C2

Now you can navigate between A1 and A2 in A, between B1 and B2 in B, and so on. Components A, B, C should have their own Routers.

[arkivanov]

Regarding questions 2a and 2b.

For such a logic you need to do a trick. The idea is to check if the required child's configuration is already in the stack. If it is, then move the configuration to the top the stack (end of the list). If not, then create a new configuration and push it to the stack. You can try the following function, I did not test it but I guess it should work:

inline fun <C : Parcelable, reified T : C> Router<C, *>.navigateSingleTop(crossinline config: () -> T) {
    navigate { stack ->
        val oldConfig: C? = stack.find { it is T }
        if (oldConfig != null) {
            (stack - oldConfig) + oldConfig
        } else {
            stack + config()
        }
    }
}

Also because you want the Main component to pop the back stack on back button press, you need the following:

1. Pass router(..., handleBackButton = true, ...) in the Main component
2. Don't pass handleBackButton in any child components, such as A, B or C. If you do, then the child component will have priority in back button handling (might be a desired behaviour).

[arkivanov]

I have filed an issue to add this function to the library, seems like a common use case.

[falcon4ever]

Hi @arkivanov

Thank you for your very thorough answers!

Looks like I have some work to do here, I'll try to update the sample app and link back when I get things working.

I have one more question regarding using Decompose with Jetpack Compose:

In the dev challenge samples, it looks like a Content object is used in the router:

// Content.kt in the utils folder
typealias Content = @Composable () -> Unit
fun <T : Any> T.asContent(content: @Composable (T) -> Unit): Content = { content(this) }

interface Root {
    val routerState: Value<RouterState<*, Content>>
}

and the the RootUi uses this code to render the child(ren) without explicitly saying which ones:

@Composable
fun RootUi(root: Root) {
    Children(routerState = root.routerState, animation = crossfade()) { child, _ ->
        child()
    }
}

I think that's because the childContent method in the RootComponent is taking care of the routing internally and tying it to a specific UI:

private fun childContent(child: Child, componentContext: ComponentContext): Content =
    when (child) {
        is Child.Landing ->
            LandingComponent(
                componentContext = componentContext,
                ...
            ).asContent { LandingUi(it) }

        is Child.Login ->
            LoginComponent(
                componentContext = componentContext,
                ...
            ).asContent { LoginUi(it) }

        is Child.Main ->
            MainComponent(
                componentContext = componentContext,
                ...
            ).asContent { MainUi(it) }
    }

This seem to work for Decompose 0.1.9.

When looking at a more recent sample such as the todoapp in the compose-jb repo I see that a different pattern is used (as well in the Decompose 0.2.6 project):

interface TodoRoot {
    val routerState: Value<RouterState<*, Child>>

    sealed class Child {
        data class Main(val component: TodoMain) : Child()
        data class Edit(val component: TodoEdit) : Child()
    }
}

with the UI part:

@Composable
fun TodoRootContent(component: TodoRoot) {
    Children(routerState = component.routerState, animation = crossfadeScale()) {
        when (val child = it.instance) {
            is Child.Main -> TodoMainContent(child.component)
            is Child.Edit -> TodoEditContent(child.component)
        }
    }
}

This does make the Component decoupled from the UI framework. My guess is that it is the new recommended pattern?

Going back to the sample I'm working on, I think that means that in order to display the correct screen for a given tab (A/B/C), I will have to make sure that the A/B/C components will be tied to a composable that looks like this right? (And that this composable will be responsible for routing to the correct child composable).

@Composable
fun ScreenAContent(component: ScreenAComponent) {
    Children(routerState = component.routerState, animation = crossfadeScale()) {
        when (val child = it.instance) {
            is Child.ScreenA1 -> ScreenA1Content(child.component)
            is Child.ScreenA2 -> ScreenA2Content(child.component)
            is Child.ScreenA3 -> ScreenA3Content(child.component)
            is Child.ScreenA4 -> ScreenA4Content(child.component)
            is Child.ScreenA5 -> ScreenA5Content(child.component)
            is Child.ScreenA6 -> ScreenA6Content(child.component)
            is Child.ScreenA7 -> ScreenA7Content(child.component)
            is Child.ScreenA8 -> ScreenA8Content(child.component)
            ...
        }
    }
}

[arkivanov]

@falcon4ever I think you understand the difference between using sealed class Child vs typealias Content right. The former is required if you have to support different UI frameworks, so not only Compose but also e.g. SwiftUI, React, etc. In this case it indeed provides the complete isolation between UI and business logic. The latter was just an experiment to reduce the when boilerplate in the UI layer. It works, however I did not properly checked it in all scenarios like unit/integration testing.

So neither is a recommended, it's outside of the scope of the library. But I usually prefer sealed class Child.

Re: ScreenAContent: the sample code looks good to me. Just one terminology correction: it is the UI is tied to components, not vise versa. And the components are responsible for routing, the UI just displays whatever is in the state.

[falcon4ever]

Hi @arkivanov,

I've updated the sample and added a readme and your navigateSingleTop function seems to work flawlessly.

I did leave the handleBackButton enabled in the A,B,C components as it would not allow me to navigate back from a child node (B2->B1) when pressing the back button.

It does seem to do the correct thing for Case 1 and Case 2 described in a previous comment.

[arkivanov]

Glad it worked for you. Having or not having handleBackButton in A, B, C nodes is up to you, depends whether you need B2->B1 or not.