Starting activities from Jetpack Compose Composables with Decompose

[moffpage]

Hello! Thanks for your amazing work! I've got a question for you: How would you start activity with an Intent (e.g. to open a map or dialer) in KMM project using Decompose with Jetpack Compose for Android (at least for now 👀). Would you just start activity from @composable function by passing LocalContext.current or delegate it to a Store from the Component? How would you retrieve the result back?
I've been using a library for routing called Modo by terrakok: https://github.com/terrakok/Modo, his library is also cross-platform, but has a different implementation than yours and the sample has a feature where he navigates to a browser web view. When setting up, you have to link ModoRender to an activity so that when you could tell router to launch ExternalScreen-s outside of the view layer. How should we handle these use cases (intent launch + getting result back) with Decompose?
Maybe an update for extensions-compose-jetpack ? 👀

[Shabinder]

As for now, I just pass the intent as a callback (which can be called later) when inflating your component in Android's Activity.
Similar to how we pass dependencies.

I wonder if there is a better approach for this.

[moffpage]

Well, I believe you don't inflate your components in activity, that's just for the root one. You think I should pass the callback down for like even 2 subcomponents? Like e.g. if I want to start dialer from component X, which is a child of component Y, which in itself is a child of component Z, which is a child of the root component. Or should I start an activity while consuming events in view by sending intent to component?

[Shabinder]

Well, I believe you don't inflate your components in activity, that's just for the root one.

when inflating your component

Here I meant Root Component Only,

As you described the relations: Root->Z->Y->X, for instance, if there is a specific event which I Need to be available in every component, then maybe I can consider it making available statically, and will initialize It as soon as I initializes root(use late init and pass it to root and initialize it in init{} block).
However when you want to access it in 1-2 components only then maybe you can pass the callback around.

@arkivanov do you think there is a better approach to this?

[arkivanov]

Personally I like explicity and compile-time safety. So I would go with the following solution:

// In module X

class ComponentX(
    componentContext: ComponentContext,
    private val startCamera: (CameraParams) -> Unit
) : ComponentContext by componentContext {

    fun onCameraResult(fileName: String) {
    }
}

class CameraParams

// In module Y

class ComponentY(
    componentContext: ComponentContext,
    private val startCamera: (CameraParams) -> Unit,
    private val startBrowser: (url: String) -> Unit
) : ComponentContext by componentContext {

    fun onCameraResult(fileName: String) {
        // Deliver the result to ComponentX
    }
}

class CameraParams

// In module Z

class ComponentZ(
    componentContext: ComponentContext,
    private val startCamera: (CameraParams) -> Unit,
    private val startBrowser: (url: String) -> Unit,
    private val startFileChooser: () -> Unit
) : ComponentContext by componentContext {

    fun onCameraResult(fileName: String) {
        // Deliver the result to ComponentY
    }

    fun onFileChooserResult(fileName: String) {
    }
}

class CameraParams

// In module Root

class RootComponent(
    componentContext: ComponentContext,
    private val startCamera: (CameraParams) -> Unit,
    private val startBrowser: (url: String) -> Unit,
    private val startFileChooser: () -> Unit
) : ComponentContext by componentContext {

    fun onCameraResult(fileName: String) {
        // Deliver the result to ComponentZ
    }

    fun onFileChooserResult(fileName: String) {
        // Deliver the result to ComponentZ
    }
}

class CameraParams

Such approach clearly indicates what screens can be launched by the whole tree or a sub-tree. You must satisfy all dependencies, otherwise it won't compile. This is specially important when you want to reuse a component, with all its children. E.g. when you include ComponentY in another component, it is clear that it can launch camera and browser and what are the parameters. You may choose to split screen arguments (e.g. (a, b, c) -> Unit, etc.), or combine them into one single class (e.g. (CameraParams) -> Unit). The later will require to add similar classes in each parent level and provide mappings between them. Yes, it is verbose, but at the same time it is explicit.

Later, if for example you will have CameraComponent, you may change your RootComponent:

// In module Root

class RootComponent(
    componentContext: ComponentContext,
    private val startBrowser: (url: String) -> Unit,
    private val startFileChooser: () -> Unit
) : ComponentContext by componentContext {

    fun onFileChooserResult(fileName: String) {
        // Deliver the result to ComponentZ
    }

    // Handle camera requests from the ComponentZ using CameraComponent
}

And so it will become single activity in this case.

[moffpage]

Oh, yeah definitely a good argument right there. I just don't want to start the activity from @composables (or views, anyway), and I want to share the logic of making a phone call, navigating to a map, etc. Every single system activity start should be handled by root platform-specific objects like Activity and whatever else it is in iOS world?

[arkivanov]

But the logic can not be shared between platforms, because it is platform specific. If you really want to start screens directly from components, then you need to provide/inject some API. So create something called e.g. ExternalScreenLauncher and provide it to components (via constructor or via extended AppComponentContext).

But as I mentioned above, this will make components aware of the "kind" of the screen. Like making a phone call is "external", but showing an item details is "internal". From my point of view components should not care about this sort of stuff.

[moffpage]

Good point about components caring about whether their router gonna navigate to an "internal"/"scoped" screen or external (in the way that it's gonna leave the app). However I don't understand your take that logic cannot be shared, couldn't you just say "router.navigateTo(Dialer(phoneNumber = "..."))" in your business logic? Oh damn, why can't I decide which one is the right one.

[arkivanov]

The Router is scoped in its hosting component, it can navigate between components in scope of the host. When you want to navigate to a component in a scope of one of the parents, you have to bubble the event up. Of course you technically can inject parent's Router to child components, but this will couple the child component to that exact parent. This will prevent the child and the parent to be placed in separate Gradle modules, and also prevent the child from being reused.

[moffpage]

Finally I rethought through this topic and I'm now able to understand your approach. Big thanks to you, Arkadii! What an amazing feedback.