CODEWITHSUNDEEP
androidarchitectureandroid-architecture-components
jbxbergdev
jbxbergdev

Reputation: 880

Best practice to handle expensive, view-specific objects in MVVM

So MVVM states clearly that view models shouldn't contain view implementation/view specific objects. However, some views need objects that are either expensive to instantiate (e.g. a map rendering object), or take up a lot of memory. On Android, the temptation is to put these objects into a ViewModel so they survive lifecycle changes. But this breaks MVVM principles.

Is there any good practice how to handle heavy, view-specific objects in MVVM?

Upvotes: 1

Views: 115

Answers (1)

Roberto Canini
Roberto Canini

Reputation: 349

As you just said, view model should not contains any view reference due to detached-view reference dangerous event. Any heavy views should be instantiated into lifecycle owner class too. If this slow down view rendering, you can always apply some post-create or async logic.

View model can help you in this way. Infact, you can observe to a mutable flag object on viewmodel from the view. When the lock flag change you start the heavy object rendering.

This is just an example, maybe if you can be more specific on what you meant with heavy view objects we can find out a more precise and efficent solution.

Upvotes: 1

Related Questions