IssueTracker

Hello, can you please attach a sample that reproduces your error?

I’ve attached two screen recordings demonstrating the mediator's behavior during the first and second launches after installation. Additionally, https://gist.github.com/yatiksihag01/20106aa4855bd438e3eb982034d4bb7d is link to a GitHub Gist containing the code for my remote mediator file for your reference.

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

1. RemoteMediator REFRESH actually returned empty data - what is the returned allNewsItems value on initial REFRESH?
2. 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 codelab which addresses possible races between Refresh and subsequent loads.

Hey! I ran into this same issue. It is in fact the second case you mentioned and is documented here.

I've published a repo reproducing the issue and filed a ticket proposing how this could be changed.

I am gonna try and report back, but I don't see the relevance at all. For reasons unrelated to this issue, I am not using Lazy components but instead I am loading a RecyclerView through an AndroidView inside a composable. So I believe this is a paging library bug and not a Compose one

I am gonna try and report back, but I don't see the relevance at all. For reasons unrelated to this issue, I am not using Lazy components but instead I am loading a RecyclerView through an AndroidView inside a composable. So I believe this is a paging library bug and not a Compose one

It will not fix it for you if you are using RecyclerView. You'll need to provide a repro for your jumping issue and file it separately, so we can address your concerns there.

The jump appears to be present even with 1.3.0-alpha03. Upon brief inspection it seems the get[index] sent to Paging is out of sync with the data shown on the UI after subsequent REFRESH (i.e. when remote mediator appends items into Room db).

Going to have take a deeper look into this.

Hi Andrey, it seems the problem is compose's index mismatching with paging's index, where paging's index is more reflective of where the user is actually scrolled to.

For example

1. screen scrolled to index[45]
2. refresh with key[28]
3. present on UI item[28-57]
4. compose sent get[18] ... get [26]        <----- this seems a little suspicious

RE: #6 Can you file please a separate bug under Paging with your repro on RecyclerView? Thanks.

Hi Andrey thanks for looking into this.

So the app loads data from both a local Room database and RemoteMediator (online database). RoomDb starts off empty which triggers RemoteMediator to load data and insert into Room. Essentially everytime Room runs out of data, RemoteMediator will load more to insert into Room, and every insertion will cause Paging to REFRESH the page. Whats happening is likely:

1. initial load 30 items
2. `2022-09-15 06:39:29.377 13418-13418/com.example.android.codelabs.paging I/System.out: PagingTest paging item count=55`  -- scrolling down causes paging to load more, hence itemCount = 55
3. The insertion into room invalidates Paging, which triggers a REFRESH to reload around where user was last scrolled to
4. While paging was loading, user keeps scrolling
6. `2022-09-15 06:39:31.588 13418-13418/com.example.android.codelabs.paging I/System.out: PagingTest paging item count=31` -- paging has refreshed again with initial 30 items
7. `2022-09-15 06:39:31.605 13418-13418/com.example.android.codelabs.paging I/System.out: PagingTest paging item count=40` -- loaded more data due to scrolling
8. The insertion into Room invalidates Paging, which triggers a REFRESH to reload around where user was last scrolled to
9. `2022-09-15 06:39:32.238 13418-13418/com.example.android.codelabs.paging I/System.out: PagingTest paging item count=32` paging has refreshed again with initial 30 items

And the reason the itemCount drops to 30 everytime Paging REFRESH is because the logic in GithubRemoteMediator#load clears the room db if its a REFRESh load before inserting newly loaded items.

Hope this helps. Alternatively if you can tell me how / where exactly you logged firstVisibleItemIndex and item count, I can see if this is indeed whats happening.

Seems like my initial guess is correct. Essentially within paging itself:

1. Paging load items [0 - 29]
2. present items [0-29]
3. user scrolls down
4. PagingTest new firstVisibleItemIndex=18
5. but actually its LazyPagingItems.get(24)
6. PagingTest composed item at index=24
7. Paging preemptively load items [30-39]
8. itemSnapshotList.size:34                       <----- first read, still based on items[0-29] + separators = 34 items
9. itemSnapshotList.size:45                       <----- read immediately again, now based on items [0 - 39] + separators = 45 items
10. PagingTest new firstVisibleItemIndex=20
11. .... after a bit PagingTest composed item at index=26
12. RemoteMediator preemptively load items [40-49] and insert into Room db
13. Room insertion invalidates paging causing screen refresh
14. Paging loads and displays items [7-36] upon refresh
15. itemSnapshotList.size:45                      <------ first read after refresh, still based on items in step 9.
16. itemSnapshotList.size:32                      <------ read immediately again, now correctly based on items [7-36] + separators

So items are added as users scroll more. It decreases when more data is inserted into room, Paging invalidates and starts refresh with a new snapshot containing the refreshed 30 items (30 is refresh load size).

I'm not sure but it seems like the read on stale snapshot in step 8 and 15 could be the cause of issue?

The issue happens when placeholders are off due to compose/paging not aware of the real index of an item within the database .

For example, if compose only loaded part of the data from database

LazyPagingItems = [10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
item 10 = index 0

But within the database

Database [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]
item 10 = index 10

So the jumping is due to scroll index being out of sync with datasource index. With remote mediator triggering constant refreshes, this problem becomes exacerbated.

Turning placeholders on resolves the issue because paging/compose is now aware that there are items [0...9] prior to item 10 and now knows that item 10 = index 10.

A proper fix for when placeholders are off would require some time.

I would recommend turning on placeholders in the meantime. That said, please file a ticket / upload sample project if you come across this issue with placeholders on.

Re: comment#21 can you please file a separate bug for the separator issue and include a minimal project that reproduces the issues you see?

any update on this issue?

I'm encountering the same problem.

List is jumping when using insertSeparator. I think there is a jump between the items inserted via separator and the items from the DB.

Re comment#24 do you have placeholders enabled?

comment#25 Yes, placeholders are enabled

comment#26 can you please file a separate bug and attach a sample repro?