Closed TonnyL closed 4 years ago
Thanks for reporting this, right now remote REFRESH is resolved synchronously and per your use-case I'm not sure this is desired behavior.
As a workaround, you can launch within RemoteMediator.load()
for the REFRESH case and immediately return MediatorResult.Success(false)
. If the remote REFRESH job has new items, the correct behavior is to still write to DB and invalidate PagingSource (unless nothing has changed). If you are using Room for local caching such as in the sample, any row updates will automatically invalidate PagingSource implementations generated by Room.
In the future, the best place to file issues with the library is through our issuetracker: https://issuetracker.google.com/issues/new?component=413106&template=1096385
In the meantime I've filed here to track: http://issuetracker.google.com/issues/160062540
Thx, I'll keep an eye on it.
Many thanks to you, it works for me with the paging snapshot build.
I'm doing the migration work to paging3 and I get this problem: every time I open my app, it displays a refreshing state(like the
PagingWithNetwork(db+network)
app does) with an empty list screen, but I want to display the offline data (maybe outdated) firstly while it is refreshing like many other apps does(google podcasts, for example).For paging2, my solution is
MediatorLiveData
, db data first, then network data, it seems doesn't work anymore for paging3. It there a way to achieve this for paging3?