Status Update
Comments
ru...@futured.app <ru...@futured.app> #2
Hello, can you please attach a sample that reproduces your error?
du...@google.com <du...@google.com> #3
I’ve attached two screen recordings demonstrating the mediator's behavior during the first and second launches after installation. Additionally,
ru...@futured.app <ru...@futured.app> #4
Based on first_launch_after_installation.mp4
, your paging state is indeed showing null
for nextKey, so it makes sense that Paging concluded there are no more items to load.
So I think the question is why the PagingState
contains only an empty page and null
values. My guess is either
- RemoteMediator REFRESH actually returned empty data - what is the returned
allNewsItems
value on initial REFRESH? - RemoteMediator REFRESH successfully loaded data and inserted it into database, but Paging hasn't processed that yet by the time Append is triggered, so PagingState is empty.
The second case doesn't seem likely though.
If you attach an executable app, I can look into this further.
Otherwise, you may gain more insight through Paging logs with adb shell setprop log.tag.Paging VERBOSE
. You can also try implementing RemoteKeys
in this
cl...@google.com <cl...@google.com>
vo...@gmail.com <vo...@gmail.com> #5
Hey! I ran into this same issue. It is in fact the second case you mentioned and is documented
I've published a repo
ja...@veeva.com <ja...@veeva.com> #6
I am having the same issue adding stickyHeaders
on LazyPagingItems
, we have to iterate overall the items, and this can only cause bad performance and potential out-of-memory crash...
ma...@molo17.com <ma...@molo17.com> #7
fe...@molo17.com <fe...@molo17.com> #8
dm...@gmail.com <dm...@gmail.com> #9
+1
in...@gmail.com <in...@gmail.com> #10
lv...@hubspot.com <lv...@hubspot.com> #11
ti...@gmail.com <ti...@gmail.com> #12
All workarounds result in loss of smooth animation when scrolling slowly. It looks like the list (elements of LazyColumn) is jumping in tiny steps. Not applicable
Description
Currently, the only way to use stickyHeaders with Paging is of the following form:
This has the drawback of being unaware of what items changed, so we need to iterate through the entire list to figure out where to add sticky headers.
It would be desirable for paging-compose to provide an API that allows incremental computation, caching results from items that have not changed.
In the case of using sticky headers as "separators" it may make more sense to provide the item before and after, similar to .insertSeparators on PagingData.
Currently stickyHeader is still an experimental API, but before it goes stable we should make sure we have a good story for compatibility with Paging.