Hi everyone, MVI is better than MVVM ?

# android

[haris mehmood]

Hi everyone, MVI is better than MVVM ?

[Christiano]

Depends on a couple of aspects, the scope of the project your working on, personal preference, needed features, ...

[Artem Zasypalov]

I think MVVM is easier and quicker to implement for small project, to test smth, make some experiment..

[Sudhir Singh Khanger]

Better for whom is the question. It depends on your project. Plus MVVM works well with architecture components.

[Amit Krishna A]

MVVM + State management > MVI

[haris mehmood]

For example project scope is high its contains video calling, chats and appointment booking like things... so should I go with MVVM or MVI? Is there anything that I can't achieve with MVVM but MVI?

[haris mehmood]

right now am using MVVM with coroutines, databinding, Livedata and Observers\

[Amit Krishna A]

MVVM is your go-to arch for projects. MVI is a very good arch but can create a lot of boilerplate code. Also MVI isn't very compatible with databinding especially if you use two way binding. I usually use MVVM and incorporate some of the perks of MVI into it. Like say: Having separate models for data, domain and viewstate ; ViewEffects. But I'm not a huge fan of single state object that is reassigned for every tiny state change.

Nevertheless you could achieve the same things with both MVVM and MVI cause these really just architectural patterns. So pick your favorite and start coding

[haris mehmood]

@Amit Krishna A Thanks a lot for your explaination

[appmattus]

as has been said above with MVI it really depends on the framework you use.
• #mvikotlin while the most feature complete is also by far the most complicated so has the highest onboarding costs and boilerplate
.
• Mavericks doesn’t play well with Koin nor Dagger Hilt so you still end up with boilerplate code to inject your viewmodels. Otherwise it’s a mature and popular framework
• Roxie is currently Rx only (coroutine version in a PR), uses streams so requires actions to be converted into objects to be later split back out into functions.
• I’m not sure of the state of mosby mvi.
• uniflow can be worth investigating, described as a less plumbery version of MVIkotlin.
• The last library that comes to mind is #orbit-mvi which can be used directly in jetpack viewmodels so works well with any DI and it’s syntax makes the code pretty much read like MVVM but with protection around the state, protects it from threading issues for example. Side effects/one-off events are also part of the library so it’s clearer how you’re expected to implement things like navigation with the library.
I coauthored the coroutine version of #orbit-mvi but am giving my opinion in an unbiased way as possible. It’s important to evaluate the frameworks for yourself and draw your own conclusions, I base mine on porting a simple list/detail app to each of the frameworks above along with experience of writing Android apps since API 4.