Verified
Status Update
No update yet.
Comments
ja...@google.com
I haven't looks on repro yet, but there is no such thing as AlwaysOnLifecycle in latest versions, LiveData has strong references on all observers (including that were added as observeForever). If nothings keeps a livedata, then it is gced.
cc...@google.com
ah I see: in observe with Lifecycle we add LiveData as observer to Lifecycle and it keeps it alive. However keeping observerforever + livedata, when nothing has reference on them, is a memory leak by definition: user can't clean this memory anyhow, because neither observer / livedata could be referenced.
cc...@google.com
It is true, though from usage perspective, it is not obvious at all.
e.g. you are in a class, like a singleton repository where you want to observe the database for some query.
and you write:
MyRepository(dao : MyDao) {
dao.someLiveData().observeForever(....do something...);
}
And it suddenly stops working :/ which is very non-obvious from the developer's perspective.
If we kept the lifecycle in memory as long as it has observers, wouldn't it solve the problem since they can break the chain by calling stopObserving(observer) ?
When they use observeForever, they are already responsible to remove the observer so I think it is fine?
e.g. you are in a class, like a singleton repository where you want to observe the database for some query.
and you write:
MyRepository(dao : MyDao) {
dao.someLiveData().observeForever(....do something...);
}
And it suddenly stops working :/ which is very non-obvious from the developer's perspective.
If we kept the lifecycle in memory as long as it has observers, wouldn't it solve the problem since they can break the chain by calling stopObserving(observer) ?
When they use observeForever, they are already responsible to remove the observer so I think it is fine?
cc...@google.com
well, the issue is: no reference on observer, you can't break the chain because you don't have a reference. If you have a reference, LiveData (unfortunately) wouldn't be gc-ed, because even AlwaysActiveObserver inrenally has strong reference on livedata.
cc...@google.com
It turns out I had an app with the exact above use case: a singleton repository observing a database. The code was working properly with arch components 1.0.0 but unpredictably with 1.1.0. I think this is a good example of a leaky abstraction.
Since I want to observe the database forever with no intention to remove the observer at any point, I had no reason to keep a reference to the LiveData and it ended up being GCed along with the observers in it.
You could also argue that the problem is not with LiveData but with Room using weak references to observers but the developer is not supposed to know the Room implementation details.
Since I want to observe the database forever with no intention to remove the observer at any point, I had no reason to keep a reference to the LiveData and it ended up being GCed along with the observers in it.
You could also argue that the problem is not with LiveData but with Room using weak references to observers but the developer is not supposed to know the Room implementation details.
Description
Jake, is this something like what you had in mind:
ViewModel:
public LiveData<Pair<String, PagedList<Item>>> list;
Activity:
viewModel.list.observe(this, it -> submitList(it.second, () -> setTitle(it.first)));