MVVM vs. MVI - Understand the Difference Once and for All

[@rarmijob]

All this time using MVI thinking it was MVVM hahaha, thanks for the video!!!

[@johnaqualls389]

Same 😄

[@redditPepe]

me too xD

[@afaqrabbia]

Same 🙈

[@leonelp9593]

LMAO same over here

[@renvzla]

man I was so scared when I noticed the same thing happened to me

[@DanielLuche]

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

[@george_sigalas]

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.

[@jam4l]

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...

[@pelealexandru]

you are not alone! i've also just realised i've implemented MVI to the bone! (thinking i'm doing plain MVVM)

[@weaponx3373]

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.

[@10wyk-f2y]

the same)))

[@ibrahimaydn2030]

As an android developer, I watch every video with eagerness. 🤩

[@henrik908]

Heyyy how are you ?

[@ibrahimaydn2030]

@@henrik908 good , know ı you ? 😄

[@henrik908]

@@ibrahimaydn2030 Nahh you a stranger to me just asked it I mean their is allot going.

[@kgandkg]

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.

[@PedroBarbosaRoman]

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.

[@blaupunkt1221]

Personally, I think its totally fine to use a mixture of both.

[@tiltedbybox6118]

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.

[@Mike-er2ih]

Exactly what I'm doing. Works very good.

[@jakosss]

Orbit mvi is the hybrid approach. Very simple and nice pattern

[@cloakrabbit767]

Mvi is just more boilerplate

[@philblandford5560]

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.

[@JocelinoFernandes-l4j]

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.

[@MrStopMotionKid]

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

[@h8pathak]

This is still MVVM, as described by Google in their docs.

[@zidan6900]

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)?

[@ngapps]

This shortcut with KFunction instead of multiple lambdas is smths crazy beatuful! This is what I was missing in my MVI implementation

[@nikwintren]

You can check out my reply regarding another solution. I'm not selling something, I just want some genuine input :P

[@funkypopper]

Clear and easy to undersand both MVVM and MVI. Thanks, Philipp!

[@laujimmy9282]

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.

[@MrCalyho]

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.

[@mahmoudkhairymohamed3572]

Can I show an example for that scope extension functio

[@dusilva3796]

I aways used MVVM, however looking at MVI it seems very nice.

[@berkc5323]

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.

[@gekylafas]

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.

[@rajiac7552]

Mvi suits more for compose, especially the state is scattered over diff composables,than having a single fragment/activity tied to a single model. Just looking at state and events,may be an additional effect class reflects what the single screen user is gonna interact with

[@zappy__idk-vw8eg]

For most React Devs learning Android + Jetpack Compose, go with MVI as it's very similar to Redux

[@weaponx3373]

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

[@mateusznepath3344]

16:07 oh wow didn't know about the snapshotFlow. But wouldn't it trigger extra recomposition?

[@Alchemist10241]

11:14 for navigation events I used to create another UI event class but with this approach I don't need to.

[@gleb-dev]

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

[@emanuelemaso3061]

The best comparison found out there! Cheers 👏

[@yossimaskin1393]

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

[@clementjoymasinamela4244]

It depends, if you wanna map, filter etc then use MutableStateFlow but if not you can use mutableStateOf

[@coldwised]

If you have a large viewmodels and problems with navigation, you should try the Decompose library

[@sparshchadha5469]

Hey, please create a video on different flavours of app that companies usually create and how we can write functions in gradle files

[@NikNewNik]

Thank you! MVI for me 🙂

[@baijusharma6027]

Any plans to start a series on AOSP, as there are lots of things to cover and online no tutorial available.

[@7cs13]

And I thought I'm using MVVM architecture. Its more of an hybrid. TY for this

[@DjuroRadusinovic]

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

[@ayeshdon]

@philipp shall we have playlist on android AR and Android automotive.

[@marvinalone]

With MVI you can put everything in the state, but you still need to extract it somewhere...so that's not a difference from MVVM I think the key difference to me is MVI is a single direction flow, the 'state' is immulate, things in view only can be changed thru 'action' thus generates a new state and then notify the view to update accroding to the new state, this is similar to ReactJS

[@alsh2887]

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.

[@Guilo583]

i am a little bit confused. Some you use the event class in your mvvm project is that not similar to mvi?

[@grumpyshoe]

A really nice explanation! Thanks for your effort Philipp! 👍

[@Ayor88]

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)

[@finchicoph]

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 👌.

[@denissolomasov]

What is the difference between private set and backing field in the example at 16.30? It seems to me they are the same

[@Atlantican16]

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?

[@arielapp9469]

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?

[@amirrezalotfi8919]

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?

[@josephofem5448]

I mostly use MVI but of late, I sort of use a mix of both as I find it more convenient.

[@warTag68]

would be interesting to see how would a mixture between both look like. also instead of intercepting ui events you can use effect pattern

[@bogdan.801]

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?

[@lifebylazy]

You're the man phillip thank you!

[@TP-rn2gm]

I'm wondering if i have two list, when i set new state value to each list at a time, the other remains the same, will it rebuild only the list that changed or will it rebuild both list

[@szpitor]

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.

[@زيد_اليماني]

Great video, I really like mvi pattern a lot it makes the code less complex and more readable

[@PartyPooperXX]

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.

[@warTag68]

sounds like a toxic company to work for and you sir dodged a bullet

[@Coldalecs]

Love it! keep up the good work! Very informative.

[@jackeblan]

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.

[@cloakrabbit767]

I don't see the benefit of MVI. Would someone explain? To me it seems it's just more boilerplate code

[@josephmalachosky7141]

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())

[@nikwintren]

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?

[@georgikopchev1739]

Based on the video, should be MVI

[@vitalijuskolinko9011]

I've tried MVi and I liked it :) Will use it as default for the next projects )

[@-sb9nb]

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 ?

[@TheShadowvaultAwaits]

Most mvi tutorials I've seen except yours, have a store and a reducer. Can you elaborate on that?

[@PhilippLackner]

Store = the combination of state class and VM Reducer = onAction function

[@aditya3n]

@@PhilippLackner possible to share your source code of this MVVM and MVI? I'm trying to implement MVI on my KMP project..

[@DeveloperDikshitaPatel]

How to get details of the workshop? As i am late to book me slot

[@SamyakKumar-ck8se]

of course mvvm, because d LEGEND Philip uses it most of the time

[@LightDante]

MVI is like the ideal version MVVM, but in reality it's more easy to apply and maintain MVVM

[@veluchamykarthik107]

Could you make video about clean architecture

[@skarloti]

When we use KMP, we have a solution with expect (Common) and actual MVVM deployments on different platforms. So MVI becomes redundant.

[@PhilippLackner]

Why does it become redundant? Usually, you'd want to share the ViewModel and maybe even the UI

[@yewo.m]

MVI reminds me of Elm and Redux/useReducer in React (I'm a web dev learning mobile, BTW)

[@ayeshdon]

Thanks @philipp Since this both very similar we can you both in single project. thats my option here.

[@selebdroid6423]

Good explanation, thanks a lot! Bump words

[@alfetch1337]

MVI! :) For a long time now. More simple and readable code.

[@vegadhardik]

Very informative video and great explanation, I love each of your videos. Thanks for sharing.

[@leonardocvaleriano]

Whata job!! Thank you for sharing your knowledge!

[@sabbib007madness]

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 😮‍💨

[@processorman2858]

Sir I am unable to access the internet on my android emulator

[@forbiddenbox]

could you make another app tutorial? your plalist is very outdated and I find it hard to learn so this is the best channel

[@walrider7374]

MVI reminds me on Flutter BLOC pattern

[@pelealexandru]

your videos are the best.

[@tuanphanvan5169]

Thank for your video 👍

[@est4058]

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

[@devatrii]

lol i didn't even knew that i was using MVI

[@SoftSkilsDevs]

😂😂😂 you're not alone

[@DiabloZq]

Thank you!

[@ManuelSilverioCoder]

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.

[@PhilippLackner]

Thank you 🙌🙌

[@sebastianluna4190]

So MVI is more like redux then 🤔

[@ztzmtv7069]

I use MVI in complex screens but when the screen is simple, MVVM is better in my opinion

[@Sharon6Lee-u1j]

Weldon Burgs

[@alexmercerind]

Can we say MVI is built on top of MVVM? No?

[@robchr]

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.

[@walrider7374]

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]

​@@walrider7374 no, you can queue it or handle it separately through middleware or a similar mechanism to ensure both actions are addressed.

[@k4ba]

@@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

[@dhruvsharma5786]

❤❤❤❤❤

[@graart6076]

i like to use MVVM but with states-classes🙂

[@FreemanArno]

Wilson David Jones Jose Lopez Timothy

[@dev-sr1rq]

If you don't use MVI, maintenance is almost impossible in a big project.

[@mohamedayad70]

Bro I'm literally mvi expert even without knowing that

[@AbdulBarek-p3q]

Lopez Michelle Clark Brenda Martinez Ruth

[@abr464]

Same here, using MVI thinking it was MVVM lol

[@leonelp9593]

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😂

[@ishubhamsingh]

So it seems i have been using MVI without knowing its MVI since quite a while 😂

[@androidkotlin-6234]

MVI is really better then MVVM, because I have only one source of truth for my UI - data class UiState()

[@FreddieSlipper-o5s]

Katrina Fork

[@tashi7160]

sometime I feel like we android developers are stuck in M** patterns world.

[@Mojiborkhan-i1s]

Hernandez Susan Miller Donald Hernandez Eric

[@NatalieFuller-x6n]

Lopez William Lee Shirley Clark Robert

[@NatalieFuller-x6n]

Robinson Brian Williams Matthew Jones Sharon

[@ElsieBernice-v2q]

Huel Causeway

[@HoraceCharlotte-q9k]

Kuhic Cliff