Fixed
Status Update
No update yet.
Comments
il...@google.com
ma...@gmail.com
Thanks for the report - do you have any reproduction steps?
ch...@moqi.co.uk
Nevermind, this has been fixed and will be available in an upcoming release.
il...@google.com
An unfortunate side effect of this seems to be that the adapter is set to null before any pending fragment animations are completed.
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
ap...@google.com
Since the
Please file a bug against Fragments the with a sample project that reproduces this issue and we will be happy to take a look at what's going on.
Description
android.arch.navigation:navigation-fragment-ktx
android.arch.navigation:navigation-ui-ktx
Version used:
1.0.0-alpha05
Devices/Android versions reproduced on:
-SM-A510F, Android 7.0
-Emulator x86_64 API 28
Sample project:
Description:
Having this structure:
nav_graph.xml
<navigation
android:id="@+id/nav_graph"
app:startDestination="@id/startFragment">
<fragment
android:id="@+id/startFragment"
android:name="com.example.navbug.StartFragment"
android:label="StartFragment"
tools:layout="@layout/fragment_start">
<action
android:id="@+id/action_startFragment_to_nested_nav_graph"
app:destination="@id/nested_nav_graph" />
</fragment>
<include app:graph="@navigation/nested_nav_graph" />
</navigation>
nested_nav_graph.xml
<navigation
android:id="@+id/nested_nav_graph"
app:startDestination="@id/nestedStartFragment">
<fragment
android:id="@+id/nestedStartFragment"
android:name="com.example.navbug.NestedStartFragment"
android:label="NestedStartFragment">
<action
android:id="@+id/action_nestedStartFragment_to_nestedSecondFragment"
app:destination="@id/nestedSecondFragment"
app:popUpTo="@+id/nestedStartFragment"
app:popUpToInclusive="true" />
</fragment>
<fragment
android:id="@+id/nestedSecondFragment"
android:name="com.example.navbug.NestedSecondFragment"
android:label="NestedSecondFragment" />
</navigation>
I want to achieve this navigation pattern:
StartFragment => NestedStartFragment => NestedSecondFragment =(back)=> StartFragment
I'm trying to implement this by setting the action NestedStartFragment=>NestedSecondFragment with the options [popUpTo=NestedStartFragment, popUpToInclusive=true], so that the resulting stack would be:
0. NestedSecondFragment
1. NestedNavGraph
2. StartFragment
3. NavGraph
When navigating from NestedStartFragment to NestedSecondFragment, the following execption occurs:
java.lang.IllegalArgumentException: Navigator androidx.navigation.fragment.FragmentNavigator@ccc9092 reported navigation to unknown destination id com.example.navbug:id/nestedSecondFragment
at androidx.navigation.NavController$2.onNavigatorNavigated(NavController.java:142)
at androidx.navigation.Navigator.dispatchOnNavigatorNavigated(Navigator.java:217)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.java:207)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.java:45)
at androidx.navigation.NavDestination.navigate(NavDestination.java:407)
at androidx.navigation.NavController.navigate(NavController.java:683)
at androidx.navigation.NavController.navigate(NavController.java:630)
at androidx.navigation.NavController.navigate(NavController.java:618)
at com.example.navbug.NestedStartFragment$onViewCreated$1.onClick(Fragments.kt:31)
at android.view.View.performClick(View.java:6597)
at android.view.View.performClickInternal(View.java:6574)
at android.view.View.access$3100(View.java:778)
at android.view.View$PerformClick.run(View.java:25885)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Right before the navigation, the stack is:
0. NestedStartFragment
1. NestedNavGraph
2. StartFragment
3. NavGraph
When NestedStartFragment is popped on my request, NestedNavGraph is also popped because
"// We never want to leave NavGraphs on the top of the stack" (from NavController.onNavigatorNavigated)
with the effect that eventually the requested destination NestedSecondFragment is pruned from the graph and cannot be reached anymore.
Unless I'm doing something wrong, it seems that NavGraph automatic popping should be avoided if the final destination actually belongs to it.