As announced last week, I am now finally publishing the article about my research in KMP and Declarating UIs, using the MVI pattern. I am presenting the D-KMP architecture, which allows 85% of shared code. I hope this can bring useful elements to promote Kotlin MultiPlatform! https://twitter.com/dbaroncellimob/status/1329044480515772420?s=09

Looking forward to reading this

I skimmed it but didnt see any code. Have you published something that one could dive into ?

@spand you find relevant code snippets in the part 3 of the article

Yeah. I knew it was a stretch but hoped for a complete sample 🙂

Great read @Daniele B! Currently working on a project that's C++, React Native, Swift, Obj-C, Kotlin & Java. This is going to be super helpful to try and start informing/selling my peers on KMM/KMP.

@spand I didn't get the chance to create a sample repository, as I have been working on a full app. However, in the article you get all the relevant code you need.

I wonder if similar solutions are created for other languages (swift multiplatform?) ​​that may turn out better than KMP in the future?

@Daniele B In your diagram you expose

StateFlow

that goes from the native view model back to the different platforms. The thing is that I haven’t managed to get StateFlow and iOS working together. I assume that you have succeeded?

@Robert Jaros Two considerations: 1) Kotlin is now de facto a multi-platform language, making any new feature available to 3 compilation targets: JVM, Native, JS. It's a huge effort, which is not trivial. 2) Swift is a language by Apple, which never had an interest in anything outside its ecosystem

I’ll give it a go 👍 which coroutines version are you using, 1.4.1?

I am using 1.3.9-native-mt

ah! this is why

StateFlow was introduced in 1.3.6

StateFlow is available since 1.3.6, as I mentioned in the article. SharedFlow was just released this month, and it's actually a generalized version of StateFlow. But in terms of state management for the UI layer, StateFlow is exactly what we need.

great read. I tried to make a project structure like this, but I have no luck here, I try to solve errors until I give up. I would love to see some minimum compiling implementation of android+js+ios+backend targets thrown together

ah yes, stable in 1.4.0 I think, I got confused by that https://blog.jetbrains.com/kotlin/2020/10/kotlinx-coroutines-1-4-0-introducing-stateflow-and-sharedflow/

I think stateflow is conflated by design, so if you got refresh state, then rotated screen, view would subscribe again and get obsolete refresh state. So one-time events are not designed to be dispatched in stateflows, exactly like those livedata hacks like singleliveevent etc

yup I agree ^

in this architecture, how much could views differ on each platform?

@Ferran I am following the MVI pattern, which is based on the concept of uni-directional data flow. This removes a lot of complexity, and makes the code very simple. StateFlow is ideal for the MVI pattern. I am not sure why you are interested in a bi-directional flow. This brings much more complexity, and I am not sure it has a lot of benefits. Do you have a special use case?

@Daniele B How do you send an event to the view model, do you call a suspend function, or you call a function that then calls a suspend function? Instead of that, with SharedFlow you can have unidirectional events from the UI and then collect the events inside the view model. This will decouple the action from the processing of the action and this gives you more control on the actions emitted, for example with the overflow you can control that only one action of the same type is emitted

yeah but my question was more if I would like to have different UI on each platform for whatever reason

@Ferran the UI layer is simply calling the events, which are extension functions of the ViewModel. Inside the events you can then define any asynchronous logic you want, with the advantage of being fully shared across any platform. You wouldn't be able to share any logic on the UI layer side.

@Daniele B to be honest I”m experimenting with a clean architecture kotlin native modules app, I’m not giving much attention to the UI components just yet as I’m planning to keep them as lean as possible

@Ferran yes, I was suspecting that. If you enter the world of declarative UIs, then most of your doubts fall. Uni-directional data flow is the way.

@Daniele B yup, its still unidirectional, my sharedFlow is not exposed, is just how I want to handle the async call internally in the class

I am not sure I am following. Before you were talking about having a reactive approach in both directions. I don’t see the use case for a sharedFlow here.

ok so in your design, if a user clicks refresh 3 times, how many times do you refresh the data? (imagine that somehow the user manages to do that on a button)

Inside the Event functions, you have the full flexibility to write any logic you want. You might add a logic of exiting the function in case there has been another call in the last 1 second.

yup indeed, but that’s dealing with states and in a complex app that will add lots of complexity. With an internal sharedFlow that’s handled for you out of the box, with any event

You can add a flow directly inside the Event function.

ah yes, maybe! I’ll have a look

Maybe you are not referring to a specific functionality of SharedFlow, but rather to the standard functionality of Flow. SharedFlow is about multiple subscribers with a replay cache. I still haven’t found a very interesting use case for SharedFlow yet.

yup, I was trying to build a very simple example. What I had in mind is to disconnect all data sources by using a reactive approach. So that one entity subscribes to it and another one submits actions. In this way everybody has the same state of it regardless of who calls it