Routing between screens elegantly?

[ScottPierce]

I'm writing an application that shares logic between an Android and iOS application. I'm in the process of trying to port it to decompose.

I'm finding a few instances where things require more boiler plate / are unexpectedly inelegant.

Heres a simplified form of the class that I use for my backstack:

sealed class Screen : Parcelable {
    @Parcelize
    object AppLoading : Screen()
    // ...
}

Here is the router defined in my RootComponent:

    private val router: Router<Screen, Any> = router(
        initialConfiguration = Screen.AppLoading,
        handleBackButton = true,
        componentFactory = { screen, context ->
            when (screen) {
                is Screen.AppLoading -> AppLoadingComponent(context, repository).model
                else -> TODO()
            }
        }
    )

and here is my RootComposable:

@Composable
fun RootComponent.Model.RootComposable() {
    Children(child) { model, screen ->
        when (screen) {
            is Screen.AppLoading -> (model as AppLoadingComponent.Model).AppLoadingComposable()
            else -> TODO()
        }
    }
}

Having to cast the model object for routing to get the Component's model to the view is pretty ugly. What is a better way that I can do this?

[plusmobileapps]

I will work off your initial example assuming this is what lives in your RootComponentImpl with the addition of a main screen.

sealed class Screen : Parcelable {
    @Parcelize
    object AppLoading : Screen()
    object Main : Screen() 
    // ...
}

So normally in the RootComponent I create a child class which will take the needed component as a parameter.

    sealed class Child  {
        object AppLoading : Child() 

        data class Main(
            val mainComponent: MainComponent
        ) : Child()
    }

Your router would then need to add the child as the second parameter to the router type

    private val router: Router<Screen, RootComponent.Child> = router(
        initialConfiguration = Screen.AppLoading,
        handleBackButton = true,
        componentFactory = { screen, context ->
            when (screen) {
                is Screen.AppLoading -> RootComponent.Child.AppLoading
                is Screen.Main -> RootComponent.Child.Main(/*create your main component using context*/)
            }
        }
    )

Finally your root composable would look as follows:

@Composable
fun RootComposable(component: RootComponent) {
    Children(routerState = component.routerState, animation = crossfade()) { child, _ ->
        when(child) {
            is RootComponent.Child.AppLoading  -> AppLoadingComposable()
            is RootComponent.Child.Main -> MainComposable(child.mainComponent)
        }
    }
}

Slightly different approach to what you were trying to do, but I think it should solve the problem you were having needing to cast the model object.

[ScottPierce]

Thanks for taking the time to respond!

So for each Screen, I'd need a 1-1 mapping with a Child object, right? That seems like a valid solution, and also rings true to what happens in the provided example. I'm a little disappointed by how much boiler plate this requires though.

Also, I'd need to mark the Main screen as @Parcelize, right?

@Parcelize
object Main : Screen() 

[plusmobileapps]

Having a 1:1 mapping of a Screen to Child was my understanding after going through the Todo sample on the Jetbrains repo.

It can be a bit of boiler plate code to setup but maybe this architecture improves over time. So far I really appreciate the separation of concerns which can sometimes be at a cost of some boilerplate.

Yes, I should have annotated that Main screen with @Parcelize as you mentioned 👍

[arkivanov]

As @plusmobileapps pointed, there is not much we can do here, separation of concerns requires some boilerplate.

There are two when switches mentioned:

1. In the component factory supplied to the Router
2. In the Composable function that switches children

The first case is required due to the nature of instantiation of child components. This is very similar to what we have with AndroidX FragmentFactory, we have to switch child Fragment classes. In Decompose we have to switch Configurations, this in turn allows us to pass everything via constructor. You can read more about it in my article: The defective AndroidX FragmentFactory.

The second case is due to the fact that you need iOS support and so pluggable UI (Compose, SwiftUI, etc.). It is possible to have the following API here (like Jetpack Compose Navigation style):

    Children(component.routerState) {
        child<Child.Main> { TodoMainContent(it.component) }
        child<Child.Edit> { TodoEditContent(it.component) }
    }

But it does not save much code (still the complexity is N). And on the other hand there is no compile time safety. If you add another child, the code will compile without covering the new case.

If you would need only Compose UI, then it would be possible to use polymorphism here and avoid the second switch completely. This approach is used in my another article: Fully cross-platform Kotlin applications (almost).

Overall, I think there is not so much boilerplate in total. The framework is quite concise and extendable. At the same time it is compile time safe, which is the priority at the moment.

[ScottPierce]

I stayed up pretty late last night porting my app over to decompose. The boiler plate isn't ideal, but it wasn't as bad as I thought it would be once I got it set up. I ended up liking it a good bit once I got things working with @plusmobileapps approach.

[ScottPierce]

I wasn't able to get your child<Child.Main> { TodoMainContent(it.component) } syntax to work.

[plusmobileapps]

I haven't used that new syntax either, @arkivanov is that in a recent update using reified types I'm assuming?

[arkivanov]

No, it is something that one can build on top of the existing Children function. It's just an idea of another API.