Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
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.
ya...@google.com <ya...@google.com>
an...@google.com <an...@google.com> #3
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.
ap...@google.com <ap...@google.com> #4
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?
Description
Version used: 2.0.0-rc01
Devices/Android versions reproduced on:
room.expandProjection can rewrite "SELECT *", but it still shows warnings about cursor mismatch.
Cause:
PojoRowAdapter shows the warnings. It runs before QueryInterpreter transforms the SQL. The ResultInfo is updated, but PojoRowAdapter uses the old ResultInfo from "SELECT * ".