Fixed
Status Update
Comments
il...@google.com <il...@google.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.
an...@gmail.com <an...@gmail.com> #3
Hi!
What is 'partially' exactly?
How do I see it?
Thanks!
What is 'partially' exactly?
How do I see it?
Thanks!
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
an...@gmail.com <an...@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.
ra...@gmail.com <ra...@gmail.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]
jb...@google.com <jb...@google.com> #8
Re-opening as requested by a few users. Narrowed down the focus to nested scrolling elements with the same scroll direction.
Description
Version used: 2.1.0-rc01
Devices/Android versions reproduced on:
Proposal: Safe Arg generated Builder Classes should have default values inside.
This is actually not a bug for navigation component but a kind of side effect which can make this feature more versatile.
In my scenario, we were trying to use generated safe arg Builder classes to pass arguments to the fragments in our project, as the normal bundle arguments are not type safe and kinda messy to work with.
The project I'm working on is relative large, in our team we decided to migrate gradually to navigation component.
As a first step we wanted to put the fragment in a nav graph just to generate safe args so that we can use those classes to safely pass arguments to our existing fragment with fragment transaction and eventually use the graph in future point. So we are trying to use Safe arg as mentioned below:
ChoosePackageFragmentArgs args =
new ChoosePackageFragmentArgs.Builder("testName", "testPackage")
.setIsExtend(true)
.build();
ChoosePackageFragment fragment = new ChoosePackageFragment();
fragment.setArguments(args.toBundle());
getSupportFragmentManager().beginTransaction()
.replace(R.id.container, fragment)
.addToBackStack(null)
.commit();
As you can see from the above example the "isExtend" property is optional and has a default value false which is set in the graph like this,
<argument
android:name="isExtend"
app:argType="boolean"
android:defaultValue="false" />
However if we use the generated safe arg builder class (ChoosePackageFragmentArgs) to pass the arguments to ChoosePackageFragment, without setting "isExtend" the ChoosePackageFragmentArgs.fromBundle(requireArguments()).getIsExtend() throws a NullPointerException because the builder doesn't set the default value when we call the args.toBundle() on the builder instance.
Moreover, when we try to call the getter method it can't find a value from the map, so it tries to cast a null value to (boolean), thus throwing the NullPointerException. Remember we're not using a NavController, just trying to take advantage of SafeArg feature.
This is the code from ChoosePackageFragmentArgs.Builder:
public class ChoosePackageFragmentArgs implements NavArgs {
....
@SuppressWarnings("unchecked")
public boolean getIsExtend() {
return (boolean) arguments.get("isExtend");
}
...
}
We were wondering why the default value is not present in the object. After digging for a while we've found that NavController.navigate() pulls the default values from NavAction.getDefaultArguments(); as we're not using NavComponent we're actually not getting the default value from Builder. Here's the code that pulls default args in NavComponent Library.
Code from NavController.java:
final NavAction navAction = currentNode.getAction(resId);
Bundle combinedArgs = null;
if (navAction != null) {
if (navOptions == null) {
navOptions = navAction.getNavOptions();
}
destId = navAction.getDestinationId();
Bundle navActionArgs = navAction.getDefaultArguments();
if (navActionArgs != null) {
combinedArgs = new Bundle();
combinedArgs.putAll(navActionArgs);
}
}
Suggestion:
If the safe arg plugin added the default values to the Builder while generating those SafeArgs Builder classes, the conventional fragment approach could get huge benefit out of it, and as these classes are accessible apis, I believe it makes more sense to have predictable behaviour for Builder classes as that seems like a standard predictable behaviour.