How to manually destroy a shared ViewModelfrom the CommonsWare Community archives
At May 25, 2020, 5:36am, Shahood asked:
ViewModel in my Android app that is shared by two fragments and is therefore given the scope of
The thing is that this shared
ViewModel would stay alive will all the data that it contains, even after the fragments are detached, until the
Activity it is scoped to is destroyed.
So, is there a way to destroy such
At May 25, 2020, 11:14am, mmurphy replied:
There is no means to do that, sorry.
Either the activity needs the data, or it does not. If it does, then the activity-scoped
ViewModel is a good thing, and keeping it alive is a good thing.
If it does not, then the next question is: how big is the unique data (i.e., data that is not already referenced elsewhere, such as in a cache)? If it is large — say, hundreds of KB — then perhaps it is something that you need to worry about. Conversely, if the data is small, I would not worry about it unless you were encountering some specific problems.
But, if in the end you conclude that you do need to do something, I know of only three options:
Do something other than a shared viewmodel. For example, there is the
FragmentResultsystem. It’s only in alpha, and I have not used it, but it is an option for passing data between fragments.
See if you can find a tighter-scoped
ViewModelStoreOwner. For example, the Navigation component allows you to scope a
ViewModelto a navigation graph, so perhaps you could arrange for a nested navigation graph for these two fragments.
Something that knows about when these fragments come and go (probably the activity) tells the viewmodel to flush its caches when both of those fragments are gone.
At May 26, 2020, 12:25pm, Shahood replied:
Flush the cache? Is there a way to do this?
At May 26, 2020, 12:45pm, mmurphy replied:
Well, it depends a lot of what is in this
ViewModel. Your problem, as I understand it, is that you do not want to hold onto data. So, you need to set up your
ViewModel so you can have it stop holding onto data when you ask it to:
- If you have nullable
varproperties, set them to
- If you have
varproperties that hold an object from some
sealed class, set them to a value that does not hold anything large
- If you have
nullor something lightweight to it
- And so on
At May 26, 2020, 1:09pm, Shahood replied:
Hmm, makes sense. I’ll do that. Thanks!