Verified
Status Update
Comments
cc...@google.com <cc...@google.com> #2
Able to reproduce the issue from your description, video attached (though I'm not able to see yours, I assume they're similar).
cc...@google.com <cc...@google.com> #3
The problem is that when the list shortens to be smaller than the viewport, the AsyncPagedListDiffer doesn't receive any signals that tell it that more needs to be loaded - it currently only loads in response to getItem(). Will fix this, but in the meantime you can workaround this by calling getItem() in onCurrentListChanged:
class MyAdapter extends PagedListAdapter<...> {
int lastPos = 0;
@Override
public void onBindViewHolder(@NonNull RecyclerView.ViewHolder holder, int position) {
lastPos = position;
// ... regular bind code ...
}
@Override
public void onCurrentListChanged(@Nullable PagedList<Item> currentList) {
// trigger load around most recently bound item
getItem(Math.min(lastPos, getItemCount() - 1));
}
}
class MyAdapter extends PagedListAdapter<...> {
int lastPos = 0;
@Override
public void onBindViewHolder(@NonNull RecyclerView.ViewHolder holder, int position) {
lastPos = position;
// ... regular bind code ...
}
@Override
public void onCurrentListChanged(@Nullable PagedList<Item> currentList) {
// trigger load around most recently bound item
getItem(Math.min(lastPos, getItemCount() - 1));
}
}
cc...@google.com <cc...@google.com> #4
In general, using a larger initial load size/prefetch distance avoids this problem as well.
We recommend page size to be several viewports worth of items (https://developer.android.com/reference/androidx/paging/PagedList.Config.Builder#setPageSize(int) ). If you follow that, you'll typically avoid this problem, as initial load size + prefetch are >= page size by default.
We recommend page size to be several viewports worth of items (
cc...@google.com <cc...@google.com> #5
Fix merged, will likely go out after 2.0: https://android-review.googlesource.com/c/platform/frameworks/support/+/760841
Again though, I'd like to reiterate that the ideal fix is, on the app side, using a large enough initial load size that this doesn't happen.
Again though, I'd like to reiterate that the ideal fix is, on the app side, using a large enough initial load size that this doesn't happen.
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-master-dev
commit f78707abc65b00041201a995f202ee3e95c9529b
Author: Chris Craik <ccraik@google.com>
Date: Tue Sep 18 15:06:03 2018
Trigger load after pagedlist swap
Fixes: 113122599
Test: ./gradlew paging:paging-runtime:cC
If a PagedList swap results in no content changes, but a
shorter-than-viewport initial list, the PagedList would be stuck,
since no calls from the adapter would trigger loads in this case.
To work around this in many cases, trigger a load on the new PagedList
based on the last access position. This can fail if the prefetch
distance < viewport size, but that's a fairly general problem with
small prefetch windows + no placeholders.
E.g. if the end of the initial load happens to perfectly line up with
the bottom of the viewport, and no in-viewport content changes are
made, no loads below will occur. Recommendation for now in such cases
(if they happen in practice) is to make prefetch larger. We already
default to prefetch = page size, which we recommend to be several
viewports in size.
Change-Id: I0d1e2db479d1ad05fbdb34a3854279fccad9b680
M paging/runtime/src/androidTest/java/androidx/paging/AsyncPagedListDifferTest.kt
M paging/runtime/src/main/java/androidx/paging/AsyncPagedListDiffer.java
https://android-review.googlesource.com/760841
https://goto.google.com/android-sha1/f78707abc65b00041201a995f202ee3e95c9529b
Branch: androidx-master-dev
commit f78707abc65b00041201a995f202ee3e95c9529b
Author: Chris Craik <ccraik@google.com>
Date: Tue Sep 18 15:06:03 2018
Trigger load after pagedlist swap
Fixes: 113122599
Test: ./gradlew paging:paging-runtime:cC
If a PagedList swap results in no content changes, but a
shorter-than-viewport initial list, the PagedList would be stuck,
since no calls from the adapter would trigger loads in this case.
To work around this in many cases, trigger a load on the new PagedList
based on the last access position. This can fail if the prefetch
distance < viewport size, but that's a fairly general problem with
small prefetch windows + no placeholders.
E.g. if the end of the initial load happens to perfectly line up with
the bottom of the viewport, and no in-viewport content changes are
made, no loads below will occur. Recommendation for now in such cases
(if they happen in practice) is to make prefetch larger. We already
default to prefetch = page size, which we recommend to be several
viewports in size.
Change-Id: I0d1e2db479d1ad05fbdb34a3854279fccad9b680
M paging/runtime/src/androidTest/java/androidx/paging/AsyncPagedListDifferTest.kt
M paging/runtime/src/main/java/androidx/paging/AsyncPagedListDiffer.java
cc...@google.com <cc...@google.com> #7
Released with Paging 2.1.0-alpha01
[Deleted User] <[Deleted User]> #8
delete
Description
Version used: 1.0.1
Devices/Android versions reproduced on: Any
If adapter already has items and you submit a new equals list (`submitList` in `PagedListAdapter`) and they do not feet all screen, `loadAfter` will not be invoked.
In my case, I use a refresh and create new PagedList from new DataSource but a content of items will not be changed.