About MVI and *Multiplatform*: All articles talkin...

# multiplatform

[Daniele B]

About MVI and Multiplatform:
All articles talking about MVI with Kotlin I have been reading just deal with Kotlin/Android and not with Kotlin/MultiPlatform.
They all seem to use SealedClasses for defining the Intents. For any event, the Android UI layer references a Sealed Class Intent.
However in a multiplatform context, on iOS is not really possible to reference a SealedClass Intent, AFAIK.
For this reason, my MVI/KMP implementation doesn’t use Sealed Classes for Intents, but just standard functions defined on the shared ViewModel.
I wonder if anyone has some different suggestions.

[ankushg]

I've played around with still using sealed classes (so that it's easier on Android) but then creating factory functions for the sealed class subclasses to be used on iOS

If we eventually do get real sealed class support on iOS, you can just deprecate the factory functions

[Javier]

there are no plans for 1.5, no?

[Daniele B]

Why not using simple functions (which can easily be translated in any language on any platform) for defining the Intents, instead of Sealed Classes?

[Javier]

because I prefer modeling states with sealed classes

[Javier]

if I have a ViewModel which emit a sealed class, I can see a description about what the screen does easily

[ankushg]

I think @Daniele B is on board with sealed classes for state

My understanding is that the question is around sealed classes vs functions to represent the actions that are being passed up from the view to the viewmodel (so that the viewmodel can emit an updated state later)

[Daniele B]

I am actually considering not using Sealed Class at all, not even for state.

My ViewModel is made of two sets of elements:
- Events
- StateManager

Events are extension functions defined directly on the shared ViewModel class. These are basically the intents, but they are just normal functions, called directly by the UI layer.

StateManager is a component internal to the ViewModel itself, which has the role of managing the State. It’s also where StateFlow is defined.
State Reducers are simply extension functions of the StateManager.
The State Reducers are called directly by the Event functions.

If you use SealedClass Intents, you would have one single reducer function, processing all intents.

If each StateReducer is a function on its own, you can organize the state reducers in different files, kept together by topic/context.

[Nadjib]

@Daniele B thanks for sharing your architecture diagram. I'm wondering how did you implement StateFlow? Are you using Kotlin Flow?

[Daniele B]

@Nadjib in this article (on the 3rd page) you can find the relevant code:
https://danielebaroncelli.medium.com/the-future-of-apps-declarative-uis-with-kotlin-multiplatform-d-kmp-part-1-3-c0e1530a5343

[Nadjib]

Thanks @Daniele B it was a joy to read your article. You really summarized how I always wanted to architect my frontend clients. I was a bit skeptical of Kotlin KMM but your article gave me confidence. I agree the future will be D-KMP ..

[darkmoon_uk]

@Daniele B Thanks to your inspiration and articles; and following a 4 hour discovery session with a client, a portion of my screen now looks like this: 🎉 K

[Daniele B]

yes, I am pretty sure your client will be eventually very happy! 🙂