^^following up, would this generally mean that a s...

# android-architecture

[scottiedog45]

^^following up, would this generally mean that a shared view model could cover this need for each fragment to be backed by a viewmodel (instead of each fragment having a standalone VM)? I don’t see why not, but a little more research has shown that a shared view model can be an efficient way to handle passing data between fragments.

[escodro]

I think that the SharedViewModel does not replaces the specific ViewModel. The specific one has use cases/access/data to that screen and the shared one has the data that needs to be shared. They can work together if needed.

[escodro]

https://developer.android.com/topic/libraries/architecture/viewmodel#sharing

[scottiedog45]

so it would be more sound architecturally to have a shared VM that takes care of shared data, and a unique VM for each fragment, versus just a shared VM that handles both the shared and unique data for each screen. On the one hand, less view models, on the other hand, more specific view models…

[escodro]

The problem having only one is the possibility to call a function on Fragment A that is only related to Fragment B. This can be a problem of scoping and messy when the project grows.

[escodro]

The example that they share on the docs are Master/Detail screen. I know that that example is very simple, but there are no fetchData() on this ViewModel. The fetch logic should only be accessed by the Master screen.

[scottiedog45]

Gotcha. Thanks Igor 😃

[dewildte]

Another alternative to data communication is an EventBus of some kind.