MVVM vs. MVI - Understand the Difference Once and for All
Vložit
- čas přidán 16. 04. 2024
- After this video you'll understand the Difference Once and for All - MVVM vs. MVI!
👉 Save your spot for the FREE workshop 'The Essentials of Industry-Scale Android Development - REVEALED' on April 27: pl-coding.com/android-workshop
💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:
pl-coding.com/drop-table-ment...
⭐ Courses with real-life practices
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:
pl-coding.com/premium-courses/
Get my FREE PDF about 20 things you should never do in Jetpack Compose:
pl-coding.com/jetpack-compose...
Regular programming advice on my Instagram page:
/ _philipplackner_
Join my Discord server:
/ discord - Věda a technologie
All this time using MVI thinking it was MVVM hahaha, thanks for the video!!!
Same 😄
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.
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
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.
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)))
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.
As an android developer, I watch every video with eagerness. 🤩
Heyyy how are you ?
@@illuminati786uuh good , know ı you ? 😄
@@ibrahimaydn2030 Nahh you a stranger to me just asked it I mean their is allot going.
A really nice explanation! Thanks for your effort Philipp! 👍
The best comparison found out there! Cheers 👏
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.
Love it! keep up the good work! Very informative.
You're the man phillip thank you!
Whata job!! Thank you for sharing your knowledge!
Very informative video and great explanation, I love each of your videos. Thanks for sharing.
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.
@13:38 is actually better for performance in compose. The docs even encourages you to separate and pass the states parameters you need instead of grouping it in an object. Reason is that if you group all the states as an object, all composables dependent on the parameters of that state would be recomposed even if it’s just one parameter that changes but if you separate the states individually, if for instance post state changes, it’s only the composbales that make use of that post state that get recomposed
Great video, I really like mvi pattern a lot it makes the code less complex and more readable
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 aways used MVVM, however looking at MVI it seems very nice.
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
11:14 for navigation events I used to create another UI event class but with this approach I don't need to.
Thank you!
Thanks @philipp Since this both very similar we can you both in single project. thats my option here.
Thank for your video 👍
Hey, please create a video on different flavours of app that companies usually create and how we can write functions in gradle files
I've tried MVi and I liked it :) Will use it as default for the next projects )
your videos are the best.
If you have a large viewmodels and problems with navigation, you should try the Decompose library
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?
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 mostly use MVI but of late, I sort of use a mix of both as I find it more convenient.
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 👌.
Any plans to start a series on AOSP, as there are lots of things to cover and online no tutorial available.
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
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)
could you make another app tutorial? your plalist is very outdated and I find it hard to learn so this is the best channel
@philipp shall we have playlist on android AR and Android automotive.
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
16:07 oh wow didn't know about the snapshotFlow. But wouldn't it trigger extra recomposition?
of course mvvm, because d LEGEND
Philip uses it most of the time
For most React Devs learning Android + Jetpack Compose, go with MVI as it's very similar to Redux
lol i didn't even knew that i was using MVI
😂😂😂 you're not alone
Could you make video about clean architecture
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.
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())
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.
i am a little bit confused. Some you use the event class in your mvvm project is that not similar to mvi?
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
MVI reminds me of Elm and Redux/useReducer in React (I'm a web dev learning mobile, BTW)
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
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
I don't see the benefit of MVI. Would someone explain? To me it seems it's just more boilerplate code
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
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
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
How to get details of the workshop? As i am late to book me slot
I use MVI in complex screens but when the screen is simple, MVVM is better in my opinion
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..
i like to use MVVM but with states-classes🙂
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 🙌🙌
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 😮💨
Sir I am unable to access the internet on my android emulator
Same here, using MVI thinking it was MVVM lol
So it seems i have been using MVI without knowing its MVI since quite a while 😂
Can we say MVI is built on top of MVVM? No?
sometime I feel like we android developers are stuck in M** patterns world.
MVI is really better then MVVM, because I have only one source of truth for my UI - data class UiState()
so i been using mvi this whole time thinking it was mvvm 😅
flutter😁
first view
What is the point of acknowledging this? I keep seeing these types of comments but don't understand why people do it. Can you shed some light?
@@mikec4220what's the point of wasting your time by replying to these comments.
@@illuminati786uuh same as you spending your time replying to mine ;).
P.S. I'm naturally interested in behavioural patterns and had my reasons for that comment.
@@mikec4220 lol I knew you will say this 😂
MVI and MVVM are overrated, keep it simple and readble is better with observable patterns and MVC
MVI is a mess in large projects :)
Talk really fast and show some code but don't focus on the appropriate use of each pattern after 7 minutes of yapping at twice the rate that anyone could ever listen to. wtaf? I don't need to see your face or hear you talk about irrelevant details that have nothing to do with the topic.
Wait until you guys see a VIPER in an Android project.
Plz make some good project on android. Philip Lackner