https://kotlinlang.org logo
#android-architecture
Title
# android-architecture
s

scottiedog45

05/23/2019, 12:08 PM
^^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.
e

escodro

05/23/2019, 12:14 PM
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.
s

scottiedog45

05/23/2019, 12:18 PM
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…
e

escodro

05/23/2019, 12:21 PM
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.
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.
s

scottiedog45

05/23/2019, 12:27 PM
Gotcha. Thanks Igor 😃
😉 1
d

dewildte

05/23/2019, 4:15 PM
Another alternative to data communication is an EventBus of some kind.
4 Views