Status Update
Comments
jb...@google.com <jb...@google.com> #2
[Deleted User] <[Deleted User]> #3
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));
}
}
il...@google.com <il...@google.com>
jb...@google.com <jb...@google.com> #4
We recommend page size to be several viewports worth of items (
ap...@google.com <ap...@google.com> #5
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.
il...@google.com <il...@google.com> #6
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
pr...@google.com <pr...@google.com> #7
an...@daresay.co <an...@daresay.co> #8
li...@gmail.com <li...@gmail.com> #9
I wouldn't say this is fixed. If you add a back-callback in the activity which is lifecycle aware, and then background->foreground the app, the activity back-callback will be put on top of the callback pile. This leads to that any BackHandler in your composable will NOT be triggered.
The best workaround I have for now is to use the non-lifecycle aware function in the activity.
class MainActivity : FragmentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// open fragment which hoists the composables
...
if (savedInstanceState == null) {
onBackPressedDispatcher.addCallback(onBackPressedCallback = someBackHandling())
// onBackPressedDispatcher.addCallback(owner = this, onBackPressedCallback = someBackHandling) // not this one
}
}
ho...@gmail.com <ho...@gmail.com> #10
ho...@gmail.com <ho...@gmail.com> #11
ho...@gmail.com <ho...@gmail.com> #12
Bug Fixes : NavHost in Navigation Compose now correctly intercepts system back calls even after the Activity has been STOPPED and RESUMED.
It works fine for me.
gi...@gmail.com <gi...@gmail.com> #13
va...@zedge.net <va...@zedge.net> #14
In my case it works fine when the app is first ran, but my custom callback calls navController.popBackStack internally if it can't handle back press on its own. So, when I run the app and click back, everything works, but after I pop up all the Composables from the stack and return to the app, the custom callback is not called anymore.
il...@google.com <il...@google.com> #15
Re
Note that you should never, ever be calling navController.popBackStack()
in your own BackHandler
as Navigation must be the only one handling its own back stack with the system back button so that Predictive Back works correctly in the future.
ja...@gopuff.com <ja...@gopuff.com> #16
ja...@sense.com <ja...@sense.com> #17
I believe this is still an issue even without using NavHost like mentioned in
Description
Versions
Component used: Navigation
Version used: 2.5.3
Devices/Android versions reproduced on: any
Description
According to the documentation of [BackHandler], nested BackHandlers(https://developer.android.com/reference/kotlin/androidx/activity/compose/package-summary#top-level-functions ) should take priority:
However, this doesn't work correctly if the activity is paused and then resumed.
Steps to reproduce
Code to demonstrate the issue
A sample project is attached.