Status Update
No update yet.
Comments
yb...@google.com
when data source invalidates, paging calculates a diff between two lists, discovers changes and persists the current location on screen (when possible).
Can you provide a sample so that we can see why it is failing? Are your items immutable?
Can you provide a sample so that we can see why it is failing? Are your items immutable?
yu...@gmail.com
I create a sample which reproduces the issue:
https://github.com/YuriiLushchyk/PagingBugExample
It's a copy of the official Google sample for Paging library (https://github.com/googlesamples/android-architecture-components/tree/master/PagingWithNetworkSample )
Differences:
1. library version is release 2.1.0 instead of rc1
2. page size set to 5 for simplicity
3. added button "Refresh" which does the same thing as swipe-to-refresh layout -> invalidates data source.
Select any data source type and scroll to second or further page and press "Refresh". The list always jumps back to the end of the first page.
Reason: after invalidation new PagedList has only the first page and adapter "thinks" that we deleted rest of the pages.
How we can avoid this?
Thank you
It's a copy of the official Google sample for Paging library (
Differences:
1. library version is release 2.1.0 instead of rc1
2. page size set to 5 for simplicity
3. added button "Refresh" which does the same thing as swipe-to-refresh layout -> invalidates data source.
Select any data source type and scroll to second or further page and press "Refresh". The list always jumps back to the end of the first page.
Reason: after invalidation new PagedList has only the first page and adapter "thinks" that we deleted rest of the pages.
How we can avoid this?
Thank you
sa...@gmail.com
Any update around this?
de...@omni.chat
I'm having the same problem.
In the Paging Library documentation they say we can have more granular updates by encapsulating a in memory snapshot of a mutable list in a custom datasource and providing new paged list everytime the mutable list changes , but they don't provide any example on how to do that.
I have to add and update items to the list and I don't use ROOM to make those update automatically for me.
For me, it is a lack of feature or they should, at least, provide some example on how to do it without using ROOM.
In the Paging Library documentation they say we can have more granular updates by encapsulating a in memory snapshot of a mutable list in a custom datasource and providing new paged list everytime the mutable list changes , but they don't provide any example on how to do that.
I have to add and update items to the list and I don't use ROOM to make those update automatically for me.
For me, it is a lack of feature or they should, at least, provide some example on how to do it without using ROOM.
ev...@gmail.com
Hi there,
same with ItemKeyedDataSource.
load 3,4,5,6,7 items. out of 0,1,2,3,4,5,6,7,8
defined to load 5 items when initial load, 3 items when page load.
when scroll back into item 2 try to load items 0,1,2
items aren't found in db. -> using BoundaryCallback.
data is loaded from web and DataSource is invalidated.
initialLoad is called again when the key of item #7 (last one loaded).
this not desired behavior happens in contrast to Yigit explanation in:https://www.youtube.com/watch?v=BE5bsyGGLf4 20:50 min.
same with ItemKeyedDataSource.
load 3,4,5,6,7 items. out of 0,1,2,3,4,5,6,7,8
defined to load 5 items when initial load, 3 items when page load.
when scroll back into item 2 try to load items 0,1,2
items aren't found in db. -> using BoundaryCallback.
data is loaded from web and DataSource is invalidated.
initialLoad is called again when the key of item #7 (last one loaded).
this not desired behavior happens in contrast to Yigit explanation in:
it...@gmail.com
The upper comment is mine, please contact me at this mail if needed.
(no way to edit comment? )
(no way to edit comment? )
cc...@google.com
The scrolls offset issue here sounds like it could be a dupe of
For #6 - That sounds like a different issue. The problem there sounds like it could be page size. Generally we recommend a page size that's the size of multiple viewports, especially for initial load. The initial key is generally within the viewport, but not necessarily at the beginning or middle. In your case it's at the end, so loading around the last item loaded (or specifically, bound in the adapter's onBind, since that's what informs last load position) should get enough data to fill the viewport.
For #6 - That sounds like a different issue. The problem there sounds like it could be page size. Generally we recommend a page size that's the size of multiple viewports, especially for initial load. The initial key is generally within the viewport, but not necessarily at the beginning or middle. In your case it's at the end, so loading around the last item loaded (or specifically, bound in the adapter's onBind, since that's what informs last load position) should get enough data to fill the viewport.
Description
Version used: 1.0.0
Devices/Android versions reproduced on: Android 9, API 28
I am using the android paging library to show a list of posts in the recycler view, my data source loads data from inMemory list which I add and remove from it then invalidate the data source to refresh the PagedListAdapter, everything is working well, but the problem is that when I scroll through pages, for example, page #5, and delete some item and call invalidate(), the data source will be re-initialized and will invoke the callbacks again, which re-loads the items in the recycler view, and jump to the first page. The question is: How to refresh the items without jumping to the first page, and stick in the selected position?
Thanks.