Today it was a great milestone! I was able to run ...

# multiplatform

[Daniele B]

Today it was a great milestone!
I was able to run exactly the same shared ViewModel on both Android and iOS, using StateFlow!!!
I can easily say 85% of the code is on Kotlin Multiplatform, and 15% only on the platform-specific declarative UI (Compose and SwiftUI)!

on Android, it uses Compose's `collectAsState`:

@Composable
fun MainLayout(coreModel: CoreViewModel) {
    val appState by coreModel.stateFlow.collectAsState()
    ...
}

on iOS, it uses a very simple class extending ObservableObject , where a StateFlow “listener” is initialized:

class AppViewModel: ObservableObject {
  let coreModel : CoreViewModel = CoreViewModel()
  @Published var appState : AppState = AppState()
     
  init() {
      coreModel.onChange { newState in
          self.appState = newState
      }
   }
}

this is the shared `ViewModel`:

class CoreViewModel {

  internal val mutableStateFlow: MutableStateFlow(AppState())
  val stateFlow: StateFlow<AppState>
      get() = mutableStateFlow

  fun onChange(provideNewState: ((AppState) -> Unit)) {
      stateFlow.onEach {
          provideNewState.invoke(it)
      }.launchIn(CoroutineScope(Dispatchers.Main))
  }
}

[Kurt Renzo Acosta]

Congrats! Are you using Flow on your ViewModels? If so, were you able to consume it on iOS? I'm still doing the CFlow hack and I wanted to get rid of it soon

[Daniele B]

Yes, I am using StateFlow

[Kurt Renzo Acosta]

How are you observing it on iOS side? Edit: Just saw your edit with the code

[Kurt Renzo Acosta]

Yeah still the same pattern where we have to do a few tweaks to make it consumable to iOS. Suspend functions already get translated into a lambda. I hope we get the same for Flow operators too

[Daniele B]

@Kurt Renzo Acosta the StateFlow code on iOS is very straightforward. it’s just a “callback” providing the new state.

[flosch]

You are never canceling the job that is launched in onChange though.

[Kurt Renzo Acosta]

Yup. I was looking for a solution where we don’t have to create a callback and just use the StateFlow like we use it on Android.

I have the same pattern here with the help of KotlinConf’s CFlow so that I don’t have to create a callback for every StateFlow. I just hoped it would be possible to avoid it since suspend functions can be used in iOS but I guess not for Flow yet.

[Daniele B]

@Kurt Renzo Acosta I am not aware of a different way to collect StateFlow on iOS. But I guess it will arrive sometime soon, and it’s just a matter to update a few lines of code.

[Daniele B]

@flosch if you have any suggestion, it’s very welcome

[flosch]

I don’t know the inter-capabilities of iOS/kmpp, but since swift has a deinit you could create a DeallocWatcher that cancels the CoreViewModel scope

[Daniele B]

Just treat CoreViewModel as an Objective-C object, as it’s defined in an Objective-C framework. Feel free to share snippets.

[louiscad]

StateFlow is still a Flow and should work wrapped in CFlow linked above.

[flosch]

Yea well since CFlow uses a Closable, its the same principle, it needs to be cleaned up at some point. 👍

[Daniele B]

maybe we should ask the opinion of the Zar @elizarov

[elizarov]

Sorry, I'm not an iOS/Swift expert, so I cannot really contribute any new ideas here.

[Daniele B]

I just opened an issue:
https://youtrack.jetbrains.com/issue/KT-41953

[flosch]

Why create an issue for that though 🤔
In the kotlinconf app you can find the cleanup being done. And even if you wanted to somehow automatically close the CFlow (cancel the Job), this would be an implementation detail.

[audriusk]

In summary, as you know, on JetpackCompose there is a very neat way to collect a StateFlow:

That's because Android team (from Google) has incorporated Coroutines support into JetpackCompose.
I do not expect same support from Apple 😄 I think community will have to step up and create some sort of components for SwiftUI to bind StateFlow.
Maybe it's possible to wrap it with Swift's Combine framework 🤔 (There might be some problems since SwiftCombine is Swift-only and Kotlin Native has only supports Objective-C)

[Daniele B]

@flosch I think it would be great to have a one-line collectAsState() , so that developers don’t have to manage the cleanup themselves. But I am not sure if it’s feasible. Let’s see what’s the reply.
I also think, StateFlow didn’t exist at the time the kotlinconf app was made.

[Daniele B]

@audriusk maybe using Combine under the hood? Not sure. From a Kotlin developer point of view, there shouldn’t be the need to deal with Combine directly. It would make sense to only having to care about the Kotlin Flow.

[Kurt Renzo Acosta]

FYI StateFlow already existed before in the form of a ConflatedBroadcastChannel.

[Daniele B]

@Kurt Renzo Acosta by the way, I was looking for CFlow in the Kotlin documentation, but I cannot find it. Was it also renamed to something else?

[Kurt Renzo Acosta]

It’s just a util or a workaround to get it working on iOS. It’s not part of the library

[Daniele B]

ok, got it now

[Daniele B]

@Kurt Renzo Acosta @flosch I just noticed this important difference between StateFlow and `ConflatedBroadcastChannel`:

StateFlow cannot be currently closed like ConflatedBroadcastChannel and can never represent a failure

https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-state-flow/

[Daniele B]

StateFlow seems “smarter” than ConflatedBroadcastChannel

[flosch]

Yes, you cannot close StateFlow, but if you launch it there will still be a Job that probably should be cleaned up

[Daniele B]

@rocketraman glad to hear! were you able to write a better code for handling StateFlow on iOS?

[rocketraman]

Not sure if you could call it better... it was just pulling together some pieces. I copied the code of CFlow directly from the Kotlin Conference app along with the native dispatcher from the same place:
1. https://github.com/JetBrains/kotlinconf-app/blob/master/common/src/mobileMain/kotlin/org/jetbrains/kotlinconf/FlowUtils.kt
2. https://github.com/JetBrains/kotlinconf-app/blob/master/common/src/iosMain/kotlin/org/jetbrains/kotlinconf/DispatcherNative.kt
I injected the view model's CFlow adapter into the iOS ObserverObject (on Android the view model is injected directly). From there, using StateFlow on Android normally, and on iOS using `CFlow`'s watch to set the @Published vars just worked.

[rocketraman]

All the extra rigamarole should go away when https://github.com/Kotlin/kotlinx.coroutines/issues/470 is implemented.

[Daniele B]

I am still waiting for this to be answered by the JetBrains team:
https://youtrack.jetbrains.com/issue/KT-41953

[louiscad]

@Daniele B Instead of waiting, you could make your own solution (which can be to just copy/paste CFlow), because they might not be able to answer the way you hope for in the timeframe you're looking for.

[Daniele B]

@louiscad the CFlow code deals with a closable Flow, but as far as I understand StateFlow is not closable

[rocketraman]

CFlow seems to be the way to go as of now. On that, you just call close in the appropriate callbacks in Swift code. The conference app has some examples showing this.

[rocketraman]

@Daniele B You are closing the Job that reads the StateFlow, not the StateFlow itself.

[Daniele B]

@rocketraman @louiscad
I have modified this:

fun onChange(provideNewState: ((AppState) -> Unit)) {
        stateFlow.onEach {
            provideNewState(it)
        }.launchIn(
            CoroutineScope(Dispatchers.Main)
        )
    }

into this:

fun onChange(provideNewState: ((AppState) -> Unit)) : Closeable {
        val job = Job()
        stateFlow.onEach {
            provideNewState(it)
        }.launchIn(
            CoroutineScope(Dispatchers.Main + job)
        )
        return object : Closeable {
            override fun close() {
                job.cancel()
            }
        }
    }

[Daniele B]

do you think it’s ok now?

[rocketraman]

Dispatchers.Main should probably be an expect/actual which points to this native dispatcher in iOS: https://github.com/JetBrains/kotlinconf-app/blob/master/common/src/iosMain/kotlin/org/jetbrains/kotlinconf/DispatcherNative.kt

[Daniele B]

isn’t Dispatchers.Main the UI dispatcher also recognised on iOS?

[rocketraman]

Otherwise, yes, that's essentially the same code as CFlow, except CFlow is nice as it wraps any Flow, so you don't have to add that onChange method directly to your view state.

[rocketraman]

For the dispatcher, I think there are potential issues with the built-in Main dispatcher. See: https://github.com/Kotlin/kotlinx.coroutines/issues/470.

[Daniele B]

@rocketraman I was thinking the implementation is comparable: in both cases a method is defined as closeable. In the kotlinconf app it’s called “watch”, in my app it’s called “onChange”.

[rocketraman]

Yeah its the same, except yours is on the View right? If you have more than one view its not DRY. Abstracting it into a wrapper class puts it in one place regardless of how many views you have.

[rocketraman]

correction: view model

[Daniele B]

I am actually planning to have just one ViewModel and one StateFlow

[rocketraman]

In that case, its the same, yeah, though I still think separating the concerns is a good idea i.e. the throwaway code that should eventually go away is independent from the code that should stick around.

[rocketraman]

Plus: on android you shouldn't be using that method as you should be using different scopes there (e.g. lifecycleScope), and so abstracting that method away into a separate class like CFlow makes it easier to not mistakenly use that onChange method where it shouldn't be used.

[Daniele B]

yes, I am just using it on iOS

[Daniele B]

on Android, I am just using JetpackCompose’s collectAsState()

[rocketraman]

Exactly my point 😉

[louiscad]

@dagomni There's already great suggestions for folks above. TL;DR: You can copy and use CFlow from KotlinConf app (link above) or edit it to suit your needs. Is it not enough?

[louiscad]

You can see the Flow type from Swift, so you can pass it to CFlow from Swift before getting the values in iOS code.

[Kurt Renzo Acosta]

I’m using CFlow on Android and iOS and I’m fully sharing my VMs. No need for a wrapper on iOS.

[Daniele B]

I have eventually published an article on the topic:
https://danielebaroncelli.medium.com/the-future-of-apps-declarative-uis-with-kotlin-multiplatform-d-kmp-part-1-3-c0e1530a5343