Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit a6226f98671d28c18286a2a92eb296a170f8a591
Author: Jelle Fresen <jellefresen@google.com>
Date: Tue Sep 01 12:34:14 2020
Restore empty lines in BaseInputDispatcher
They were lost inhttps://r.android.com/1382562
Bug: 164060572
Test: N/A
Change-Id: I8b3535b2f0aa8cc8557f3000aa43b5afdcf0f324
M ui/ui-test/src/jvmMain/kotlin/androidx/ui/test/BaseInputDispatcher.kt
https://android-review.googlesource.com/1416789
Branch: androidx-master-dev
commit a6226f98671d28c18286a2a92eb296a170f8a591
Author: Jelle Fresen <jellefresen@google.com>
Date: Tue Sep 01 12:34:14 2020
Restore empty lines in BaseInputDispatcher
They were lost in
Bug: 164060572
Test: N/A
Change-Id: I8b3535b2f0aa8cc8557f3000aa43b5afdcf0f324
M ui/ui-test/src/jvmMain/kotlin/androidx/ui/test/BaseInputDispatcher.kt
pr...@google.com <pr...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 6b1f6e12e8448a8d84552a48056c7ceeb2ecebb9
Author: Jelle Fresen <jellefresen@google.com>
Date: Tue Sep 01 19:39:19 2020
Revisit MPP split of InputDispatcher
Most of the BaseInputDispatcher logic can be shared in commonMain. This
required replacing SparseArrayCompat with a regular MutableMap.
WeakHashMap is not available in commonMain, so the state saving
capabilities of InputDispatcher have been extracted into a subclass that
lives in jvmMain.
Bug: 164060572
Test: ./gradlew ui:ui-test:cC
Change-Id: I4bc4551fcd8324dd83a49c257c034d1b7b325f09
M ui/ui-test/src/androidAndroidTest/kotlin/androidx/ui/test/inputdispatcher/InputDispatcherTest.kt
D ui/ui-test/src/androidMain/kotlin/androidx/ui/test/AndroidBaseInputDispatcher.kt
M ui/ui-test/src/androidMain/kotlin/androidx/ui/test/AndroidInputDispatcher.kt
M ui/ui-test/src/androidMain/kotlin/androidx/ui/test/android/AndroidInputDispatcher.kt
M ui/ui-test/src/commonMain/kotlin/androidx/ui/test/GestureScope.kt
M ui/ui-test/src/commonMain/kotlin/androidx/ui/test/InputDispatcher.kt
M ui/ui-test/src/desktopMain/kotlin/androidx/ui/test/DesktopInputDispatcher.kt
D ui/ui-test/src/jvmMain/kotlin/androidx/ui/test/BaseInputDispatcher.kt
A ui/ui-test/src/jvmMain/kotlin/androidx/ui/test/PersistingInputDispatcher.kt
https://android-review.googlesource.com/1417170
Branch: androidx-master-dev
commit 6b1f6e12e8448a8d84552a48056c7ceeb2ecebb9
Author: Jelle Fresen <jellefresen@google.com>
Date: Tue Sep 01 19:39:19 2020
Revisit MPP split of InputDispatcher
Most of the BaseInputDispatcher logic can be shared in commonMain. This
required replacing SparseArrayCompat with a regular MutableMap.
WeakHashMap is not available in commonMain, so the state saving
capabilities of InputDispatcher have been extracted into a subclass that
lives in jvmMain.
Bug: 164060572
Test: ./gradlew ui:ui-test:cC
Change-Id: I4bc4551fcd8324dd83a49c257c034d1b7b325f09
M ui/ui-test/src/androidAndroidTest/kotlin/androidx/ui/test/inputdispatcher/InputDispatcherTest.kt
D ui/ui-test/src/androidMain/kotlin/androidx/ui/test/AndroidBaseInputDispatcher.kt
M ui/ui-test/src/androidMain/kotlin/androidx/ui/test/AndroidInputDispatcher.kt
M ui/ui-test/src/androidMain/kotlin/androidx/ui/test/android/AndroidInputDispatcher.kt
M ui/ui-test/src/commonMain/kotlin/androidx/ui/test/GestureScope.kt
M ui/ui-test/src/commonMain/kotlin/androidx/ui/test/InputDispatcher.kt
M ui/ui-test/src/desktopMain/kotlin/androidx/ui/test/DesktopInputDispatcher.kt
D ui/ui-test/src/jvmMain/kotlin/androidx/ui/test/BaseInputDispatcher.kt
A ui/ui-test/src/jvmMain/kotlin/androidx/ui/test/PersistingInputDispatcher.kt
Description
If you drag pull refresh, and release / fling downwards with some velocity, overscroll will show on top of the pull refresh animation.
Previously scrollable used to check if overscroll should dispatch (if the list can scroll in either direction) before dispatching preFling and dispatching postFling - sincehttps://android-review.googlesource.com/c/platform/frameworks/support/+/2384227 we now only check before the overall pass, so if preFling / the scrolling fling causes this to change (such as causing the list to refresh and now have no items) then the behaviour change is we now will dispatch postFling to overscroll, and show overscroll because pullRefresh did not consume.
Separately we might want to consider adding that check again and consuming all the velocity before we return from the lambda if the list can no longer scroll (but still calling it for correctness, so overscroll can clean up - before we might only call preFling and then never postFling), but the proper fix for pull refresh is to consume positive velocity if pull refresh is showing.
Theoretically in the future we may want to consider also consuming delta / velocity while pull refresh is showing, but at least for now it makes more sense to remain consistent with SwipeRefreshLayout, which does not do this.