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>
ru...@gmail.com <ru...@gmail.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
il...@google.com <il...@google.com>
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.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
il...@google.com <il...@google.com> #8
Correction, the fix is in. Will be released in the coming release of recyclerview (1.1.0-beta04)
[Deleted User] <[Deleted User]> #9
Thank you Ian :)
ap...@google.com <ap...@google.com> #10
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 3dd6d1fcdb3ffa7d4bd265a023f0ac7c94e14d19
Author: Ian Lake <ilake@google.com>
Date: Mon Mar 18 09:36:37 2019
Deprecate FragmentNavigator.instantiateFragment
Instead of providing a custom subclass of
FragmentNavigator, instantiation of Fragments
should be controlled by setting a custom
FragmentFactory, which is the default behavior
of instantiateFragment() now.
By deprecating the class, we ensure that
developers who were overriding this method
are informed of the changes and can change
their code to use FragmentFactory.
Test: ./gradlew checkApi
BUG: 119054429
Change-Id: Iff46919face98baa6dc62835ca3fc105d987d141
M navigation/fragment/api/2.1.0-alpha01.txt
M navigation/fragment/api/current.txt
M navigation/fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.java
https://android-review.googlesource.com/930120
https://goto.google.com/android-sha1/3dd6d1fcdb3ffa7d4bd265a023f0ac7c94e14d19
Branch: androidx-master-dev
commit 3dd6d1fcdb3ffa7d4bd265a023f0ac7c94e14d19
Author: Ian Lake <ilake@google.com>
Date: Mon Mar 18 09:36:37 2019
Deprecate FragmentNavigator.instantiateFragment
Instead of providing a custom subclass of
FragmentNavigator, instantiation of Fragments
should be controlled by setting a custom
FragmentFactory, which is the default behavior
of instantiateFragment() now.
By deprecating the class, we ensure that
developers who were overriding this method
are informed of the changes and can change
their code to use FragmentFactory.
Test: ./gradlew checkApi
BUG: 119054429
Change-Id: Iff46919face98baa6dc62835ca3fc105d987d141
M navigation/fragment/api/2.1.0-alpha01.txt
M navigation/fragment/api/current.txt
M navigation/fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.java
Description
Version used: Fragment 1.1.0-alpha01, Nav 1.0.0-alpha07
Devices/Android versions reproduced on: All
When using FragmentFactory attached to a fragment manager, FragmentNavigator$Destination.createFragment() throws an "InstantiationException: <Fragment> has no zero argument constructor". It appears that upon creating the nav graph, NavHotsFragment instantiates fragments itself instead of delegating to the fragment manager.