Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
Verified library version is `1.0.0-beta02`
il...@google.com <il...@google.com>
il...@google.com <il...@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
sp...@google.com <sp...@google.com> #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
Description
Version used: android.arch.navigation:navigation-ui:1.0.0-alpha05
Devices/Android versions reproduced on: any
I suppose it's no a bug, but just a wrong behavior.
If i have i custom scheme, like "com.example://" - this could not be used and inside framework http(s) will be appended.
NavDeeplink states that there is a scheme pattern, that should detect if there is any scheme before ":", but it fails if there is any dot in scheme. So any scheme that contains dots will fail. Only schemes with "-" are supported by now.
private static final Pattern SCHEME_PATTERN = Pattern.compile("^(\\w+-)*\\w+:");