Fixed
Status Update
Comments
lc...@gmail.com <lc...@gmail.com> #2
Nested scrolling works partially (as per http://b/122818889 ). Let's discuss if we need full support and if so make sure it works.
jo...@gmail.com <jo...@gmail.com> #3
Hi!
What is 'partially' exactly?
How do I see it?
Thanks!
What is 'partially' exactly?
How do I see it?
Thanks!
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #4
As of now:
- Nesting scroll views with a scroll direction perpendicular to the ViewPager2's orientation inside ViewPager2 works
- Nesting scroll views with a scroll direction parallel to the ViewPager2's orientation inside ViewPager2 does not work
- Nesting scroll views with a scroll direction perpendicular to the ViewPager2's orientation inside ViewPager2 works
- Nesting scroll views with a scroll direction parallel to the ViewPager2's orientation inside ViewPager2 does not work
jb...@google.com <jb...@google.com> #5
Horizontal ViewPager2 not correctly working into a vertical RecyclerView
Set a setNestedScrollingEnabled to the RecyclerView into the ViewPager2 (across reflection) resolves the problem
Set a setNestedScrollingEnabled to the RecyclerView into the ViewPager2 (across reflection) resolves the problem
ec...@gmail.com <ec...@gmail.com> #6
ageevvalentin@gmail.com, could you provide a sample app? I'd like to learn more about the circumstances that cause the problem; putting a clean ViewPager2 inside a clean RecyclerView seems to work fine, so there must be other factors involved.
jb...@google.com <jb...@google.com> #7
Added a patch for androidx-master-dev that demos a horizontal ViewPager2 inside a vertical RecyclerView.
Verified that it works correctly on a:
- Nexus 4 emulator with API 17
- Nexus 5X emulator with API 28
- Pixel 2 device with API 29
To reproduce:
- Check out the Android Jetpack source (at commit 256899f482ff85cddfb050f37550be7b5ec927ef) (see steps in [1])
- Apply the patch (`git apply 0001-Add-sample-where-a-horizontal-ViewPager2-is-nested-i.patch`)
- Build and install viewpager2's integration-tests app: `./gradlew viewpager2:integration-tests:testapp:installDebug`
- Run it
Closing the issue for now, but please reopen if you have a minimal reproduction app
[1]https://android.googlesource.com/platform/frameworks/support/+/256899f482ff85cddfb050f37550be7b5ec927ef
Verified that it works correctly on a:
- Nexus 4 emulator with API 17
- Nexus 5X emulator with API 28
- Pixel 2 device with API 29
To reproduce:
- Check out the Android Jetpack source (at commit 256899f482ff85cddfb050f37550be7b5ec927ef) (see steps in [1])
- Apply the patch (`git apply 0001-Add-sample-where-a-horizontal-ViewPager2-is-nested-i.patch`)
- Build and install viewpager2's integration-tests app: `./gradlew viewpager2:integration-tests:testapp:installDebug`
- Run it
Closing the issue for now, but please reopen if you have a minimal reproduction app
[1]
Description
Component used: Navigation
Version used: 2.4.0-alpha09
Devices/Android versions reproduced on: Not device dependent, code generation issue
Safeargs plugin on 2.4.0-alpha09 since it implemented this behaviour change below
When generating arguments, Safe Args now puts parameters without default values before those with default values. (I89709, b/198493585)
This bahvious change seesms to cause the side effect of compilation time errors in the genrated argument files. As far as I know this affects both kotlin and java generated files.
e.g.
XML navgraph destination (
NavCompFingerPrintAuthDialogFragment
)As you can see the arguments with no default values are not defined first.
this will generate the argument data object shown below with the behavios change which puts the arguments with no default values first in the constructor.
Now the problem is that in the
NavCompFingerPrintAuthDialogFragmentArgs.fromBundle(bundle: Bundle): NavCompFingerPrintAuthDialogFragmentArgs
companion function does not use named arguments when creating aNavCompFingerPrintAuthDialogFragmentArgs
from a bundle. And it uses the arguments in the order that it was defined in the navgraph and not in the order that theNavCompFingerPrintAuthDialogFragmentArgs
data object expects in its constructor. The same issue also apples for the companion functionfromSavedStateHandle(savedStateHandle: SavedStateHandle):NavCompFingerPrintAuthDialogFragmentArgs
but compilation will fail at the earliest point so it was not reported in the error. But from what i can see in the genrated code, its will have the same problem too.One solution is to just use named arguments for kotlin generated files, but it does not solve the issue for java generated files. So perhaps putting the arguments in the order of the
behavior change
mention above shld solve the issue.