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

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

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

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

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

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.

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.

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

The best comparison found out there! Cheers 👏

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

You're the man phillip thank you!

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.

Whata job!! Thank you for sharing your knowledge!

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

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

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

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

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

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

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?

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

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

Thank you!

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

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

your videos are the best.

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

Thank for your video 👍

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.

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

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.

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

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)

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

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

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

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

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

Could you make video about clean architecture

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

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

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

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

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

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

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?

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

MVI reminds me on Flutter BLOC pattern

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

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

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

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 like to use MVVM but with states-classes🙂

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

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

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

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

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 😅

flutter😁

first view

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