Since 2022 I'm using MVI and I'm really enjoying this. Excellent video and explanation, everytime I see your videos the subject became clear for me. Thanks
I've used MVP, MVVM, and MVI professionally over the past 3 years. I personally tend towards using a mixture of MVVM and MVI. And there are a couple of reasons. - The MVVM pattern is just too good on a practical level. You don't have to worry about configuration changes, coroutine scopes, etc. It just works. - The MVI pattern is very good to reason about and Kotlin superpowers it. All in all the MVVM pattern solves many technical challenges of previous architectures, such as configuration changes, data access and DI. ViewModels in many cases are an extension of the actual View. Now, combine that with the simplicity of MVI and we have an amazing architecture pattern that is very easy to reason about.
I have just found out that I have used MVI in my latest project (relatively a small project) with out me knowing anything about MVI 💀 this actually make me think that MAYBE the right architecture will naturally enforce it self into your project, without you thinking about it that match...
I don't think that the difference lies in using using a ui state object instead of multiple states for each field, since we can have the same MVVM implementation but with an ui object instead of multiple mutable states for each fields. I think the difference is more on the "intent" part, which makes state management more manageable and predictable. For instance, when I was using Redux, a state management library for React, the intents would enable us to have an "history" of all the past uiStates and the actions that produces them, for debugging purposes or others, and that is really not possible in MVVM unless we track the changes in other ways. In MVI the foundation for that to be possible is already baked in by using the actions. By the way, in Redux we also had the concept of reducers, but I'm not sure if that is exclusive to MVI.
Yeah for example if some of the MVVM states are dependent on one another, you can just group them in a MVI fashion. Maybe it has disadvantages, but it works and still keeps things relatively clean.
I've always thought there are two aspects to MVI that don't necessarily need to belong together - a single state object, and a message queue with sealed classes. You can always use one without the other, depending on your requirements. Lots of methods in your VM? Use a message queue MVI style. Only one method? Probably not worth it. Likewise if a screen has lots of components that update frequently and independently of each other, maybe a single state object isn't best, but if it's fairly static, it may make more sense to use a single data class. I just mix and match MVVM and MVI according to what I need.
excellent and simple comparison (as usual). one nuance i might add for MVI is that it makes testing more intuitive. the ability to drive the view model in tests with a single place for inputs and single place for outputs can make it easier for testing.
I didn't know the difference in between mvvm and mvi . mvi is much more readable. knowing the difference will help me learning mvi faster. thanks for the video
I make a mixture of both, all my state are wrapped in data class and my methods remains in viewmodel, my ui receives a data class as state and callbacks from viewmodel, that's make more sense for me, to use the better of both worlds.
This appears to be the approach that the Google Android Basics with Compose course teaches while calling it MVVM. It's what I generally use too but only because I was taught it that way
Personally, I use MVI. I see issues with MVVM when complexity increases. For now I combine MVI with having Events (intent), Actions, Reducers, UiState and SideEffects. Because of this, my viewmodels are very simple, even the most complex ones don't reach more than 200 lines. Also, the whole codebase is very testable. It respects single responsibility and after getting used to it, making changes becomes very simple. It is maybe important to say that now, the most difficult part is to define Events, Actions and the UiState properly. They are all sealed classes and I think this is the best way to represent business logic
Thanks for your content, finally I get to fully understand the difference between MVVM and MVI. It seems mixing them is the best way to go, as long as it makes the code clean and readable.
It was really good explanation of the differences of both approaches. So I've got to know that I was using MVVM and I was using it wrong :) For now in my new projects I'm using MVI. And I must say from that video I also understand my mistakes. For me MVI looks better improving code readability.
do you guys remember when the common architecture was MVC? how about relax about what is the best architecture, and do what you're most comfortable with?
Probably, another advantage of MVI is a more loose dependency between the view and the ViewModel. The view just sends events to the ViewModel and the ViewModel itself decides what to do with it. Whereas in MVVM the view holds direct references to callbacks, and any change in the methods can potentially break the build. In modern IDEs it's not a problem, but for Kotlin Multiplatform linting doesn't work
Having a single onAction() which handles all user events seems a bit unnatural for me. It also tends towards large viewmodels. On the other hand, having a single state class is nice.
I am using both, I expose a single state, but I don't use the intent layer. 😁 I think MVI is really good, especially if combined with Rx. The elegance 👌.
I am using a mixture of both where the UI state is a single data class and the callbacks trigger viewmodel functions directly. That way im getting rid of the extra sealed interface that holds the events, also keeping my composable's constructor simpler (compared to the MVVM version showed in the video) because i have a single UI state data class.
The problem with that MviAction enum is not the size but that as your code grows it opens the door to that same 'when' statement being duplicated everywhere. This over time becomes a maintanence nightmare. You already started duplicating once in this example. As for the callback hell that can happen with the MVVM you can slap those callbacks on an interface and maybe even put the MvvmScreen as an extension function on that interface - a 'scope' if you may. The callback functions are then easily available in the scope of the screen and easy to find.
I am, apparently, using MVI / MVVM - neither, both, hybrid... and by the sound of what you're saying it bridges both MVVM and MVI eliminating the all/most bad parts. - I have an object "FeatureModels" that houses my supporting actors; `data class State()` | `sealed interface Event{}` | `interface Actions {}` - My ViewModel extends StateEventViewModel (or a subset for smaller screens State / Event) which exposes a single state (StateFlow) , a single "event buss" through a Channel and it also implements the Actions interface. - My Composable ScreenWrapper ("Route") holds a composable ("Screen") which takes always only two arguments: State and Actions. Route have access to the navController, NavBackStackEntry as parameters. It gets the ViewModel from hilt, collects State from ViewModel and holds the screen: FeatureScreen(state = state, actions = viewModel). Then the Route does `viewModel.collectEvents { event -> when (event) { ... } }` which mostly just handles navigation or platform interactions. - Also 1: The ViewModel have some nice `update { state -> state.copy(x ) ...) }` and `sendEvent(Event.GoToDetails("itemID"))` utility functions - Also 2: I have some extension functions that handles observing state and events using lifecycle etc. for the Route - Also 3: In the Feature Models object I have another object that holds nice to have preview states and actions: Preview {val emptyState: State get() = ..., val actions get() = ... } To me this is flawless, and I love it, but what is it? MVVM or MVI?
I'm a bit confused about navcontroller and navigation, since in your example you pass it to the composable and in the official documentaiton, it's recommanded to not pass it and just expose navigation action. That would be nice to have more info on this topic (I know you have many videos about navigation in compose, but I encountered many case uncovered by these)
very wonderful tutorial!! i have question about holding state in MVI. I want to have value of EditText in state in viewModel. so every time text changed, state must be updated and then ui updated. Problem occur when updating state was heavy (such loading image and …). what should we do in this scenario?
Is there a reason why you used mutableStateOf and not MutableStateFlow? I remember you had a video in which you preffered the StateFlow approach. Is that changed over the time? I'm just curious
In last 5 years, iOS, Flutter and now Android - all MVI. Just found it more predictable in development, maintenance and testing. Also should to note that SwiftUI, Flutter and Compose - all perfectly fit to MVI
To declare onAction intents, why to use sealed class, and not enum class instead? However we don't need the intents to have a class body. They are just data types. Is there some benefits to use sealed classes for intents?
It seems that I will move to MVI since it might fix the problem of my composables having alot of callbacks to viewmodel. A problem raised by state hoisting. Having alot of parameters to a function defies clean code.
As usual you managed to explained this better than anyone out there. Great video!!! I always use MVVM so it is the one that makes sense to me, but I can see the value in knowing both specially when you need to work with an existing app that someone else developed using MVI.
I had an interview, and they disagreed with your approach. They told me that MVI always needs to have a Redux implementation to change the state and handle the actions. What responses would be good in that case? I told them that we still use the Action as the intent to change the UI state, but they told me in the feedback that I didn't understand MVI architecture.
In my experience, MVVM is more flexible for having multiple concurrently running asynchronous operations that update the UiState. MVI only allows for a single asynchronous operation at a time which can be easier write tests for.
I think I understand what you mean (I'm a Junior), can you help me? What you are saying is that (as for an example) if my UI has 2 buttons that ultimately make a HTTP call that can potentially take 1 or 2 seconds, and both are pressed simultaniously something may go wrong? Like if I press button A and ActionA is dispatched and before it finishes I press ActionB it will somehow cancel ActionA?
@@Rajmanov Then @robchr point is invalidad? Or this queueing and middleware thing just makes it less efficient than just using MVVM? To my understanding, it's safe to combine both MVVM and MVI dependending on the requirements of each specific UI/Screen
In MVI , do we need to create some state or sharedFlow for oneTime events like toasts or snackBar . And how to handle error- in the main UiState or maybe create another state for error ?
Would using state.copy() to update values of the UI state data class from the ViewModel indicate I'm mixing practices of MVVM and MVI? I'm invoking my VM from my View directly, but I am holding reference to a single UI state data class as MutableStateFlow(MyUiState())
so what is the pattern which has a state class with "Callbacks", is that MVIVM? I'm starting to miss the vanilla days of android where android team told everyone to figure out their own architecture. seem like we've gone away from the original definition of MVVM which was data changes are a stream of data emitted by VM and were starting to label everything like a religion 😮💨
I mean...they are Extremly Similar 🤔 i thought there was other things i didnt know about it have been using MVI in some projects and never Realized about it😂
Since 2022 I'm using MVI and I'm really enjoying this.
Excellent video and explanation, everytime I see your videos the subject became clear for me.
Thanks
All this time using MVI thinking it was MVVM hahaha, thanks for the video!!!
Same 😄
me too xD
Same 🙈
LMAO same over here
man I was so scared when I noticed the same thing happened to me
I've used MVP, MVVM, and MVI professionally over the past 3 years. I personally tend towards using a mixture of MVVM and MVI. And there are a couple of reasons.
- The MVVM pattern is just too good on a practical level. You don't have to worry about configuration changes, coroutine scopes, etc. It just works.
- The MVI pattern is very good to reason about and Kotlin superpowers it.
All in all the MVVM pattern solves many technical challenges of previous architectures, such as configuration changes, data access and DI. ViewModels in many cases are an extension of the actual View. Now, combine that with the simplicity of MVI and we have an amazing architecture pattern that is very easy to reason about.
I have just found out that I have used MVI in my latest project (relatively a small project) with out me knowing anything about MVI 💀
this actually make me think that MAYBE the right architecture will naturally enforce it self into your project, without you thinking about it that match...
you are not alone! i've also just realised i've implemented MVI to the bone! (thinking i'm doing plain MVVM)
exactly, I didn't know this too. I just thought it is a different way of writing viewModel class. but know knowing the term it get clearer to me.
the same)))
As an android developer, I watch every video with eagerness. 🤩
Heyyy how are you ?
@@henrik908 good , know ı you ? 😄
@@ibrahimaydn2030 Nahh you a stranger to me just asked it I mean their is allot going.
I don't think that the difference lies in using using a ui state object instead of multiple states for each field, since we can have the same MVVM implementation but with an ui object instead of multiple mutable states for each fields. I think the difference is more on the "intent" part, which makes state management more manageable and predictable. For instance, when I was using Redux, a state management library for React, the intents would enable us to have an "history" of all the past uiStates and the actions that produces them, for debugging purposes or others, and that is really not possible in MVVM unless we track the changes in other ways. In MVI the foundation for that to be possible is already baked in by using the actions. By the way, in Redux we also had the concept of reducers, but I'm not sure if that is exclusive to MVI.
Personally, I think its totally fine to use a mixture of both.
Yeah for example if some of the MVVM states are dependent on one another, you can just group them in a MVI fashion. Maybe it has disadvantages, but it works and still keeps things relatively clean.
Exactly what I'm doing. Works very good.
Orbit mvi is the hybrid approach. Very simple and nice pattern
Mvi is just more boilerplate
I've always thought there are two aspects to MVI that don't necessarily need to belong together - a single state object, and a message queue with sealed classes.
You can always use one without the other, depending on your requirements. Lots of methods in your VM? Use a message queue MVI style. Only one method? Probably not worth it.
Likewise if a screen has lots of components that update frequently and independently of each other, maybe a single state object isn't best, but if it's fairly static, it may make more sense to use a single data class.
I just mix and match MVVM and MVI according to what I need.
excellent and simple comparison (as usual). one nuance i might add for MVI is that it makes testing more intuitive. the ability to drive the view model in tests with a single place for inputs and single place for outputs can make it easier for testing.
This shortcut with KFunction instead of multiple lambdas is smths crazy beatuful! This is what I was missing in my MVI implementation
You can check out my reply regarding another solution. I'm not selling something, I just want some genuine input :P
I didn't know the difference in between mvvm and mvi . mvi is much more readable. knowing the difference will help me learning mvi faster. thanks for the video
Clear and easy to undersand both MVVM and MVI. Thanks, Philipp!
For most React Devs learning Android + Jetpack Compose, go with MVI as it's very similar to Redux
I aways used MVVM, however looking at MVI it seems very nice.
I make a mixture of both, all my state are wrapped in data class and my methods remains in viewmodel, my ui receives a data class as state and callbacks from viewmodel, that's make more sense for me, to use the better of both worlds.
This appears to be the approach that the Google Android Basics with Compose course teaches while calling it MVVM. It's what I generally use too but only because I was taught it that way
This is still MVVM, as described by Google in their docs.
so one thing that makes MVI different than MVVM is in the sealed interface part for the action (not using ViewModel callbacks on the UI)?
Personally, I use MVI. I see issues with MVVM when complexity increases. For now I combine MVI with having Events (intent), Actions, Reducers, UiState and SideEffects.
Because of this, my viewmodels are very simple, even the most complex ones don't reach more than 200 lines. Also, the whole codebase is very testable.
It respects single responsibility and after getting used to it, making changes becomes very simple.
It is maybe important to say that now, the most difficult part is to define Events, Actions and the UiState properly. They are all sealed classes and I think this is the best way to represent business logic
MVI is like the ideal version MVVM, but in reality it's more easy to apply and maintain MVVM
Hey, please create a video on different flavours of app that companies usually create and how we can write functions in gradle files
Thanks for your content, finally I get to fully understand the difference between MVVM and MVI. It seems mixing them is the best way to go, as long as it makes the code clean and readable.
It was really good explanation of the differences of both approaches. So I've got to know that I was using MVVM and I was using it wrong :) For now in my new projects I'm using MVI. And I must say from that video I also understand my mistakes. For me MVI looks better improving code readability.
do you guys remember when the common architecture was MVC?
how about relax about what is the best architecture, and do what you're most comfortable with?
If you have a large viewmodels and problems with navigation, you should try the Decompose library
Probably, another advantage of MVI is a more loose dependency between the view and the ViewModel. The view just sends events to the ViewModel and the ViewModel itself decides what to do with it. Whereas in MVVM the view holds direct references to callbacks, and any change in the methods can potentially break the build. In modern IDEs it's not a problem, but for Kotlin Multiplatform linting doesn't work
Having a single onAction() which handles all user events seems a bit unnatural for me. It also tends towards large viewmodels. On the other hand, having a single state class is nice.
I am using both, I expose a single state, but I don't use the intent layer. 😁 I think MVI is really good, especially if combined with Rx. The elegance 👌.
11:14 for navigation events I used to create another UI event class but with this approach I don't need to.
I am using a mixture of both where the UI state is a single data class and the callbacks trigger viewmodel functions directly. That way im getting rid of the extra sealed interface that holds the events, also keeping my composable's constructor simpler (compared to the MVVM version showed in the video) because i have a single UI state data class.
I mostly use MVI but of late, I sort of use a mix of both as I find it more convenient.
could you make another app tutorial? your plalist is very outdated and I find it hard to learn so this is the best channel
Any plans to start a series on AOSP, as there are lots of things to cover and online no tutorial available.
of course mvvm, because d LEGEND
Philip uses it most of the time
The problem with that MviAction enum is not the size but that as your code grows it opens the door to that same 'when' statement being duplicated everywhere. This over time becomes a maintanence nightmare. You already started duplicating once in this example.
As for the callback hell that can happen with the MVVM you can slap those callbacks on an interface and maybe even put the MvvmScreen as an extension function on that interface - a 'scope' if you may. The callback functions are then easily available in the scope of the screen and easy to find.
Great video, I really like mvi pattern a lot it makes the code less complex and more readable
I am, apparently, using MVI / MVVM - neither, both, hybrid... and by the sound of what you're saying it bridges both MVVM and MVI eliminating the all/most bad parts.
- I have an object "FeatureModels" that houses my supporting actors; `data class State()` | `sealed interface Event{}` | `interface Actions {}`
- My ViewModel extends StateEventViewModel (or a subset for smaller screens State / Event) which exposes a single state (StateFlow) , a single "event buss" through a Channel and it also implements the Actions interface.
- My Composable ScreenWrapper ("Route") holds a composable ("Screen") which takes always only two arguments: State and Actions. Route have access to the navController, NavBackStackEntry as parameters. It gets the ViewModel from hilt, collects State from ViewModel and holds the screen: FeatureScreen(state = state, actions = viewModel). Then the Route does `viewModel.collectEvents { event -> when (event) { ... } }` which mostly just handles navigation or platform interactions.
- Also 1: The ViewModel have some nice `update { state -> state.copy(x ) ...) }` and `sendEvent(Event.GoToDetails("itemID"))` utility functions
- Also 2: I have some extension functions that handles observing state and events using lifecycle etc. for the Route
- Also 3: In the Feature Models object I have another object that holds nice to have preview states and actions: Preview {val emptyState: State get() = ..., val actions get() = ... }
To me this is flawless, and I love it, but what is it? MVVM or MVI?
Based on the video, should be MVI
I've tried MVi and I liked it :) Will use it as default for the next projects )
The best comparison found out there! Cheers 👏
I think as most says in here use mvvm with mvi I would prefer. End of the day make the code read able that is the most important goal.
would be interesting to see how would a mixture between both look like. also instead of intercepting ui events you can use effect pattern
@philipp shall we have playlist on android AR and Android automotive.
A really nice explanation! Thanks for your effort Philipp! 👍
16:07 oh wow didn't know about the snapshotFlow. But wouldn't it trigger extra recomposition?
I'm a bit confused about navcontroller and navigation, since in your example you pass it to the composable and in the official documentaiton, it's recommanded to not pass it and just expose navigation action. That would be nice to have more info on this topic (I know you have many videos about navigation in compose, but I encountered many case uncovered by these)
very wonderful tutorial!!
i have question about holding state in MVI.
I want to have value of EditText in state in viewModel. so every time text changed, state must be updated and then ui updated. Problem occur when updating state was heavy (such loading image and …). what should we do in this scenario?
When we use KMP, we have a solution with expect (Common) and actual MVVM deployments on different platforms. So MVI becomes redundant.
Why does it become redundant? Usually, you'd want to share the ViewModel and maybe even the UI
Is there a reason why you used mutableStateOf and not MutableStateFlow? I remember you had a video in which you preffered the StateFlow approach. Is that changed over the time? I'm just curious
It depends, if you wanna map, filter etc then use MutableStateFlow but if not you can use mutableStateOf
MVI! :) For a long time now. More simple and readable code.
Most mvi tutorials I've seen except yours, have a store and a reducer. Can you elaborate on that?
Store = the combination of state class and VM
Reducer = onAction function
@@PhilippLackner possible to share your source code of this MVVM and MVI? I'm trying to implement MVI on my KMP project..
Thanks @philipp Since this both very similar we can you both in single project. thats my option here.
In last 5 years, iOS, Flutter and now Android - all MVI. Just found it more predictable in development, maintenance and testing. Also should to note that SwiftUI, Flutter and Compose - all perfectly fit to MVI
Love it! keep up the good work! Very informative.
You're the man phillip thank you!
MVI reminds me of Elm and Redux/useReducer in React (I'm a web dev learning mobile, BTW)
To declare onAction intents, why to use sealed class, and not enum class instead? However we don't need the intents to have a class body. They are just data types. Is there some benefits to use sealed classes for intents?
Could you make video about clean architecture
Very informative video and great explanation, I love each of your videos. Thanks for sharing.
What is the difference between private set and backing field in the example at 16.30? It seems to me they are the same
i am a little bit confused. Some you use the event class in your mvvm project is that not similar to mvi?
lol i didn't even knew that i was using MVI
😂😂😂 you're not alone
I use MVI in complex screens but when the screen is simple, MVVM is better in my opinion
Good explanation, thanks a lot! Bump words
It seems that I will move to MVI since it might fix the problem of my composables having alot of callbacks to viewmodel. A problem raised by state hoisting. Having alot of parameters to a function defies clean code.
As usual you managed to explained this better than anyone out there. Great video!!! I always use MVVM so it is the one that makes sense to me, but I can see the value in knowing both specially when you need to work with an existing app that someone else developed using MVI.
Thank you 🙌🙌
And what if I use the single screen state like in MVI but all the actions of the screen are done with a separate method like in MVVM? Is it wrong?
MVI reminds me on Flutter BLOC pattern
I had an interview, and they disagreed with your approach. They told me that MVI always needs to have a Redux implementation to change the state and handle the actions. What responses would be good in that case? I told them that we still use the Action as the intent to change the UI state, but they told me in the feedback that I didn't understand MVI architecture.
sounds like a toxic company to work for and you sir dodged a bullet
In my experience, MVVM is more flexible for having multiple concurrently running asynchronous operations that update the UiState. MVI only allows for a single asynchronous operation at a time which can be easier write tests for.
I think I understand what you mean (I'm a Junior), can you help me?
What you are saying is that (as for an example) if my UI has 2 buttons that ultimately make a HTTP call that can potentially take 1 or 2 seconds, and both are pressed simultaniously something may go wrong? Like if I press button A and ActionA is dispatched and before it finishes I press ActionB it will somehow cancel ActionA?
@@walrider7374 no, you can queue it or handle it separately through middleware or a similar mechanism to ensure both actions are addressed.
@@Rajmanov Then @robchr point is invalidad? Or this queueing and middleware thing just makes it less efficient than just using MVVM? To my understanding, it's safe to combine both MVVM and MVI dependending on the requirements of each specific UI/Screen
Whata job!! Thank you for sharing your knowledge!
In MVI , do we need to create some state or sharedFlow for oneTime events like toasts or snackBar . And how to handle error- in the main UiState or maybe create another state for error ?
So MVI is more like redux then 🤔
Weldon Burgs
I don't see the benefit of MVI. Would someone explain? To me it seems it's just more boilerplate code
Would using state.copy() to update values of the UI state data class from the ViewModel indicate I'm mixing practices of MVVM and MVI? I'm invoking my VM from my View directly, but I am holding reference to a single UI state data class as MutableStateFlow(MyUiState())
How to get details of the workshop? As i am late to book me slot
your videos are the best.
Thank you!
Thank for your video 👍
so what is the pattern which has a state class with "Callbacks", is that MVIVM?
I'm starting to miss the vanilla days of android where android team told everyone to figure out their own architecture. seem like we've gone away from the original definition of MVVM which was data changes are a stream of data emitted by VM and were starting to label everything like a religion 😮💨
If you don't use MVI, maintenance is almost impossible in a big project.
i like to use MVVM but with states-classes🙂
MVI is really better then MVVM, because I have only one source of truth for my UI - data class UiState()
Sir I am unable to access the internet on my android emulator
Can we say MVI is built on top of MVVM? No?
Katrina Fork
Same here, using MVI thinking it was MVVM lol
Rashawn Avenue
Nader Knolls
Lopez Michelle Clark Brenda Martinez Ruth
Kuhic Cliff
Wilson David Jones Jose Lopez Timothy
So it seems i have been using MVI without knowing its MVI since quite a while 😂
625 Foster Throughway
Shet MVI looks tasty
Hernandez Susan Miller Donald Hernandez Eric
Huel Causeway
Keeling River
Kuhic Mission
I mean...they are Extremly Similar 🤔 i thought there was other things i didnt know about it
have been using MVI in some projects and never Realized about it😂
Thompson Christopher Miller Michelle Johnson Anna
Robinson Brian Williams Matthew Jones Sharon
sometime I feel like we android developers are stuck in M** patterns world.
so i been using mvi this whole time thinking it was mvvm 😅