Hi everyone. Is it normal to use labels to do some...

# mvikotlin

[lehakorshun]

Hi everyone. Is it normal to use labels to do something in the view (like navigation for example) ? from the scheme it is not right. but sometimes we can’t use the state for it.

[Arkadii Ivanov]

Hello! Labels were introduced exactly for such cases. They are one time events. Just be careful, you can't do navigation in background, and Labels can be missed in this case.

[lehakorshun]

Great, thx

[JimK]

I'm currently attempting to build out a coordinator pattern that maps the relevant labels to coordinator events -- a lot of iOS apps already use this pattern for navigation and I see quite a bit of reuse between the platforms being available. The coordinator relies on a navigator which is platform-specific!

[Arkadii Ivanov]

Yep. This should be totally fine in iOS. There are issues with Android, e.g. you can't switch Fragments while the app is minimized. So you have to listen for Labels only while the screen is active (START-STOP). So if business logic produce a Label while in background, navigation won't happen. In such cases navigation via state is preferable. The latter can be implemented as follows (did not actually test this particular snippet, just as an example):

interface MyStore : Store<Intent, State, Nothing> {
    sealed class Intent {
        object ClearSelectedUserId : Intent()
    }

    data class State(
        val selectedUserId: String? = null
    )
}

interface Navigator {
    fun showUser(id: String)
}

class MyController(
    lifecycle: Lifecycle,
    private val navigator: Navigator
) {
    private val store: MyStore = TODO()

    init {
        bind(lifecycle, BinderLifecycleMode.START_STOP) {
            store.states.mapNotNull(State::selectedUserId).distinctUntilChanged() bindTo {
                store.accept(Intent.ClearSelectedUserId)
                navigator.showUser(it)
            }
        }
    }
}

Or there is also single-live-event pattern:

class ConsumableValue<T : Any>(
    private var value: T?
) {
    fun consume(): T? = value?.also { value = null }
}

So you don't need to clear data in state, but it can break time travel a bit in some circumstances.

[Arkadii Ivanov]

Also I'm experimenting with shared navigation here: https://github.com/arkivanov/Decompose
It is absolutely not production ready, just FYI. Will probably publish an article soon.

[JimK]

Hey -- Is the ribs integration the end goal for multiplatform projects or a stepping stone to take a project written with ribs multiplatform?

[Arkadii Ivanov]

Sorry @JimK could you please elaborate the question?

[Arkadii Ivanov]

What is "ribs integration"?

[JimK]

Sorry -- the branch in decompose project ribs-integration that was pushed up 2 days ago appears to have some tools to bridge the gap between a Multiplatform decompose project and an Android project written with the badoo/Ribs framework

[JimK]

I saw a reddit AMA where the badoo/bumble team described that multiplatform experiments were going on and was wondering if that branch was to introduce tools that would allow for a migration from badoo/Ribs to decompose

[JimK]

Or if there is a different intent for that work. I'm playing catch-up on a few of these frameworks. Just trying to understand

[Arkadii Ivanov]

Ahh yes! I'm playing with ribs-decompose interop currently. There is no intention to replace Badoo/Ribs. The Ribs framework has lots of useful Android specific features, however decompose is just a simple tool for multiplatform routing and lifecycling. But the interop would be useful if Decompose used in a Ribs based project. This would allow us to gradually introduce multiplatform features and connect them to an already existing structure.

[Arkadii Ivanov]

Decompose can only replace Ribs if the project is fully multiplatform, or Ribs' additional features are not required.

[JimK]

Got it! Thanks! I saw quite a few parallels between the projects and thought maybe it was a future state for those apps (all multiplatform).

[Arkadii Ivanov]

I would love if Decompose become a state of MPP apps 🙃 At the moment it is an experiment. Will probably publish a blog post soon.

[JimK]

MVIKotlin and decompose together appear to me to be the best out there for mpp. Moko was interesting but MVVM in multiplatform projects have proven to me to be really cumbersome to scale out.

[JimK]

Just have to wrap my head around jetpack compose and implement a more complex tree structure (which I've struggled with possibly because compose is still a bit magic to me)

[Arkadii Ivanov]

As far as I know there is nothing about navigation in Moko, please correct me if I'm wrong. But I agree, MVI is a perfect fit for MPP.

[Arkadii Ivanov]

It is possible to use normal Android Views UI with Decompose

[Arkadii Ivanov]

So declarative frameworks are not mandatory for Decompose

[JimK]

Haha I know but compose is too cool to ignore

[Arkadii Ivanov]

Absolutely

[JimK]

It's a necessary learning curve for future apps in my opinion. After watching the droidcon(?) video about badoo/ribs and building views depth-wise instead of breadth-wise, I figured we can burn a week or two in research / testing

[Arkadii Ivanov]

Tree structure all the way!

[JimK]

Thanks for being active, hah!