Thread
#android-architecture
    s

    scottiedog45

    3 years ago
    ^^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

    escodro

    3 years ago
    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

    3 years ago
    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

    escodro

    3 years ago
    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

    3 years ago
    Gotcha. Thanks Igor 😃
    d

    dewildte

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