Verified
Status Update
Comments
cc...@google.com <cc...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit e36c65f67e49ddbfa0080542295f4a4850ae17da
Author: Sumir Kataria <sumir@google.com>
Date: Tue Aug 07 13:04:03 2018
Enforce ConstraintTracker#setState is on the main thread.
- setState now asserts that we are on the main thread
- Moved assert*Thread methods into their own utils
- Annotated several tests manually calling onBroadcastReceive
as @UiThreadTest as our broadcast receivers only operate on
the main thread (they use the default registerReceiver
method)
- NetworkCallbacks are invoked on non-main threads by default;
in this case, we re-post them to the main thread
This is part of the solution to a concurrency exception in
ConstraintTracker.
Bug: 112272753
Test: Updated and ran tests
Change-Id: I7011e5993b814f4fcafe861e283a827cd1edee12
M work/workmanager/build.gradle
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/BatteryChargingTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/BatteryNotLowTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/ConstraintTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/StorageNotLowTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/workers/ConstraintTrackingWorkerTest.java
M work/workmanager/src/main/java/androidx/work/impl/WorkManagerImpl.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcher.java
M work/workmanager/src/main/java/androidx/work/impl/constraints/trackers/ConstraintTracker.java
M work/workmanager/src/main/java/androidx/work/impl/constraints/trackers/NetworkStateTracker.java
A work/workmanager/src/main/java/androidx/work/impl/utils/ThreadUtils.java
https://android-review.googlesource.com/727429
https://goto.google.com/android-sha1/e36c65f67e49ddbfa0080542295f4a4850ae17da
Branch: androidx-master-dev
commit e36c65f67e49ddbfa0080542295f4a4850ae17da
Author: Sumir Kataria <sumir@google.com>
Date: Tue Aug 07 13:04:03 2018
Enforce ConstraintTracker#setState is on the main thread.
- setState now asserts that we are on the main thread
- Moved assert*Thread methods into their own utils
- Annotated several tests manually calling onBroadcastReceive
as @UiThreadTest as our broadcast receivers only operate on
the main thread (they use the default registerReceiver
method)
- NetworkCallbacks are invoked on non-main threads by default;
in this case, we re-post them to the main thread
This is part of the solution to a concurrency exception in
ConstraintTracker.
Bug: 112272753
Test: Updated and ran tests
Change-Id: I7011e5993b814f4fcafe861e283a827cd1edee12
M work/workmanager/build.gradle
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/BatteryChargingTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/BatteryNotLowTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/ConstraintTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/constraints/trackers/StorageNotLowTrackerTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/workers/ConstraintTrackingWorkerTest.java
M work/workmanager/src/main/java/androidx/work/impl/WorkManagerImpl.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcher.java
M work/workmanager/src/main/java/androidx/work/impl/constraints/trackers/ConstraintTracker.java
M work/workmanager/src/main/java/androidx/work/impl/constraints/trackers/NetworkStateTracker.java
A work/workmanager/src/main/java/androidx/work/impl/utils/ThreadUtils.java
cc...@google.com <cc...@google.com> #3
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.