Fixed
Status Update
Comments
ti...@google.com <ti...@google.com> #2
Verified library version is `1.0.0-beta02`
ti...@google.com <ti...@google.com>
na...@google.com <na...@google.com> #5
I investigated the sample: https://github.com/marbat87/ScrollingViewPager2.git
See attached video:
1) no scrolling issues as long as angle is kept very close to x or y axis (0 -- 13s)
2) when scroll angle changes during a scroll, that is respected; if you remove NestedScrollView from the layout hierarchy (in fragment_main.xml) and have RecyclerView there directly, scroll orientation locking happens and makes for a better user experience
3) threshold / angle exploration (29s -- end) -- clearly the threshold angle is too narrow (touch slop not respected); it's worse with AppBarLayout collapsed than when it's expanded -- it confirms the issue; we'll investigate further
See attached video:
1) no scrolling issues as long as angle is kept very close to x or y axis (0 -- 13s)
2) when scroll angle changes during a scroll, that is respected; if you remove NestedScrollView from the layout hierarchy (in fragment_main.xml) and have RecyclerView there directly, scroll orientation locking happens and makes for a better user experience
3) threshold / angle exploration (29s -- end) -- clearly the threshold angle is too narrow (touch slop not respected); it's worse with AppBarLayout collapsed than when it's expanded -- it confirms the issue; we'll investigate further
[Deleted User] <[Deleted User]> #6
Project: platform/frameworks/support
Branch: androidx-master-dev
commit fb1c82582399043b149eb2630f524c75de9c88dc
Author: Jelle Fresen <jellefresen@google.com>
Date: Thu Aug 15 11:34:36 2019
Disallow intercept, touch slop and canScroll in nestedPreScroll
* Disallow intercept (requestDisallowInterceptTouchEvent(true))
When scroll delta is consumed by dispatchNestedPreScroll, the parent
should be requested not to intercept subsequent touch events, just as
when scroll is consumed by the widget itself or dispatchNestedScroll.
* Touch slop
NestedScrollingChild implementations should only call
dispatchNestedPreScroll after the delta x/y has exceeded the touch slop.
* canScroll (canScrollHorizontally/canScrollVertically)
The dx/dy values passed to dispatchNestedPreScroll should be zero if the
child can't scroll in that direction.
Fixed in:
- RecyclerView
- NestedScrollView
Bug: 138668210
Bug: 139530818
Test: ./gradlew connectedCheck
Change-Id: I85b327ad096fbbd204adb92f630770ec7fad5990
M core/core/src/androidTest/java/androidx/core/widget/NestedScrollViewNestedScrollingChildTest.java
M core/core/src/main/java/androidx/core/widget/NestedScrollView.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrolling3RequestDisallowInterceptTouchTest.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrollingChildTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/RecyclerView.java
https://android-review.googlesource.com/1105373
https://goto.google.com/android-sha1/fb1c82582399043b149eb2630f524c75de9c88dc
Branch: androidx-master-dev
commit fb1c82582399043b149eb2630f524c75de9c88dc
Author: Jelle Fresen <jellefresen@google.com>
Date: Thu Aug 15 11:34:36 2019
Disallow intercept, touch slop and canScroll in nestedPreScroll
* Disallow intercept (requestDisallowInterceptTouchEvent(true))
When scroll delta is consumed by dispatchNestedPreScroll, the parent
should be requested not to intercept subsequent touch events, just as
when scroll is consumed by the widget itself or dispatchNestedScroll.
* Touch slop
NestedScrollingChild implementations should only call
dispatchNestedPreScroll after the delta x/y has exceeded the touch slop.
* canScroll (canScrollHorizontally/canScrollVertically)
The dx/dy values passed to dispatchNestedPreScroll should be zero if the
child can't scroll in that direction.
Fixed in:
- RecyclerView
- NestedScrollView
Bug: 138668210
Bug: 139530818
Test: ./gradlew connectedCheck
Change-Id: I85b327ad096fbbd204adb92f630770ec7fad5990
M core/core/src/androidTest/java/androidx/core/widget/NestedScrollViewNestedScrollingChildTest.java
M core/core/src/main/java/androidx/core/widget/NestedScrollView.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrolling3RequestDisallowInterceptTouchTest.java
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/RecyclerViewNestedScrollingChildTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/RecyclerView.java
pe...@gmail.com <pe...@gmail.com> #7
1) N/A
2) Remove NestedScrollView
3) Was due to a bug in RecyclerView with pre-scroll, fix is on it's way
2) Remove NestedScrollView
3) Was due to a bug in RecyclerView with pre-scroll, fix is on it's way
Description
Jetpack Compose version:
1.2.0-rc03
Jetpack Compose component used:
AnimatedContent
Android Studio Build: 2022.1.1. Canary 7
Kotlin version:
1.7.1
When using
AnimatedContent
to animate between two contents, if you interrupt during the animation and attempt to return to the previous state, the target gets the wrong animation.Given:
When starting from the green screen, starting animation to the red screen and interrupting that animation to return to green the green animation incorrectly does a
slideIn()
transition after the interrupt.Expected:
The Green screen should always be fading. When we go from green to red it should be fading out. When returning back to green, because it is the targetState it should get the entering animation, which is a
fadeIn()
and the Red screen should be fading out.Observed:
On interruption, the Green screen gets the exit transition, which in this case is the
slideOut()
and reverses it so it ends up doing aslideIn()
and the Red screen fades out.Since the targetState is always the final state of the AnimatedContent, it should always receive whatever enter transition in passed into the
transitionSpec
.