Verified
Status Update
Comments
yb...@google.com <yb...@google.com>
cc...@google.com <cc...@google.com> #2
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
cc...@google.com <cc...@google.com> #4
Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.
Description
Version used: 1.0.0-alpha5
Devices/Android versions reproduced on: n/a
Steps to Reproduce: Attempt to call loadInitial() on a PositionalDataSource
Expected Result: For it to be possible to call loadInitial() on a PositionalDataSource
Actual Result:
- We cannot create instances of PositionalDataSource.LoadInitialCallback, because the LoadInitialCallback constructor takes a PageResult.Receiver<T> parameter, and PageResult is not public
- The LoadInitialCallback constructor is not public or protected, so we cannot chain to the superclass in our own LoadInitialCallback subclasses
- The same two problems hold for LoadRangeCallback (depends on PageResult, constructor not public or protected) for calls to loadRange() on a PositionalDataSource
As it stands, we cannot write code to consume a PositionalDataSource, such as those from Room, because we cannot call loadInitial() or loadRange(), because we cannot provide the necessary callbacks.
Workaround: put classes using PositionalDataSource into android.arch.paging, which is really icky