I were applying MVVM to my project and there is no problem so far, but I just confuse is there any p...

# android-architecture

[Jason]

I were applying MVVM to my project and there is no problem so far, but I just confuse is there any problem with MVVM or what problem that MVVM can not resolve…

[toan.tran]

I don’t see any problem with MVVM so far , having the app on Google Play for more than a year and continue develop it

[toan.tran]

Seems efficient enough and help the codebase be in well-organized state.

[ursus]

I recommend Mvvm with single State and single liveData, it makes emits more atomic if you change multiple things at once

[tschuchort]

MVVM is still fine. I say stick with it and adopt features from other architectures as you see fit

[dewildte]

There is no "best" architecture. The one that solves your problems at the time is what matters.
MVP, MVC, MVVM, M** does not matter.

What matters is things like encapsulation, SOLID and GRASP.

[dewildte]

MVVM is just one pattern that helps you to make your code more SOLID.

[dewildte]

Understanding why those patterns exist and the principles behind them is important.

[Anastasia Finogenova]

I think the preference now is mvvm with the use of jetpack libraries as you get Google sample apps in their repo as an example and supposedly a sort of cohesive set of tools to use in mvvm pattern for Android

[Jason]

Thank guys for the reply. Let me describe some use case that MVVM does not support ( or maybe my implemented was not good )

[Jason]

I have a super complex screen ( of course the problem also come from our UI/UX team design)

1. A screen has many part, call it BoardA, BoardB, BoardC. 
2. On each Board , there are many information can be changed so we use LiveData for each iem.
3. So we can image a structer of this screen like this: 
- BoardA ( FragmentA + ViewModelA + several LiveData in ViewModelA )
- Same for BoardB
- Same for BoardC
- MainScreen we have an Activity + ViewModel

There are many LiveData that the reason I have to separate ViewModel .
The problem come when I want to share /control LiveData between each ViewModel .
So viewmodel will be depend on each other… I think it is not good for architecture designing

[Anastasia Finogenova]

If you want to have access to livedatas on each board from a unified source you can have one view model shared between fragments (boards). If you are using navigation there is such a things as getting a shared instance of viewmodel for that navigation part. You can look into that. I personally think there should be different livedata instances for different UI pieces being on the single responsibility vibe to have more flexibility and avoid "losing" data as LiveData only propagates latest data so some of your updates may get lost if they are latest by for a different UI element

[Anastasia Finogenova]

So imo you shouldn't share live data instances for different views updates

[ursus]

maybe model it as LiveData<State> where State(boardAState, boardBState..)

[ursus]

that implies single viewmodel as a facade, and then divide it into subviewmodels inside it

[ursus]

or opposite way, emit state into common object, i.e. have StateManager which is shared between your board viewmodels