Status Update
Comments
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #2
So there does seem to be a bug in Navigation that causes this to fail.
When it navigates with popUpTo
and removes SecondFragment
, that removal in fragment is set for a frame later and before it is actually removed the navigate call in the onViewCreated
of SecondFragment
enqueues another call to add it back. But we still need to destroy SecondDetailFragment
which ends up marking the NavBackStackEntry
associated with SecondFragment
as complete before navigation has received the call from the fragment that it has been added back. So by the time it hits this check, the SecondFragment
is in the correct state, but Navigation has no way of referencing it so it assumes that it is not associated with an entry.
But this is not the way this type of situation should be implemented. Instead of having the destinations as part of the NavGraph, they should:
- be managed by the childFragmentManager of
SecondFragment
. So instead of going back toSecondFragment
just to go somewhere else, each of the fragments take the entire content ofSecondFragment
and are swapped out. - for some sort of a/b testing, set different graphs in the Activity. The graphs would keep the same
SecondFragment
id, but swap out the names and then you choose the correct graph based on the condition.
va...@google.com <va...@google.com> #3
va...@google.com <va...@google.com> #4
- Have
SecondFragment
as part of your graph and then inside ofSecondFragment
call thechildFragmentManager
andreplace
with the fragment you actually want to show, whether that isSecondTypeOne
orSecondTypeTwo
. - Create different graphs and follow along with the
on using different graphs dynamically and inflate and set the one needed based on logic in your Activity.docs
jb...@google.com <jb...@google.com> #5
shardViewModel.onGetTypeSecond.observe(viewLifecycleOwner) { isType1 ->
if (isType1) {
val graph = findNavController().graph
val carInstallmentNavGraph =
graph.findNode(R.id.nav_second) as NavGraph
carInstallmentNavGraph.setStartDestination(R.id.secondTypeOneFragment)
findNavController().navigate(SecondFragmentDirections.actionSecondFragmentToSecondTypeOneFragment())
} else {
val graph = findNavController().graph
val carInstallmentNavGraph =
graph.findNode(R.id.nav_second) as NavGraph
carInstallmentNavGraph.setStartDestination(R.id.secondTypeTwoFragment)
findNavController().navigate(SecondFragmentDirections.actionSecondFragmentToSecondTypeTwoFragment())
}
}
and removed app:popUpTo="@id/secondFragment" and app:popUpToInclusive="true"
<fragment
android:id="@+id/secondFragment"
android:name="com.example.navigationdeeplink.SecondFragment"
android:label="fragment_second"
tools:layout="@layout/fragment_second" >
<action
android:id="@+id/action_secondFragment_to_secondTypeOneFragment"
app:destination="@id/secondTypeOneFragment" />
<action
android:id="@+id/action_secondFragment_to_secondTypeTwoFragment"
app:destination="@id/secondTypeTwoFragment"
app:popUpTo="@id/secondFragment" />
</fragment>
jb...@google.com <jb...@google.com> #6
Is there a planned fix for this issue? We've been stuck on Navigation 2.5.3 for some time due to issues in 2.6.x and now this issue, and the suggested workaround of restructuring our navigation graph is a pretty big lift. If that's the only recommended path it would be helpful to know so we can try to plan for that work, otherwise we'd want to just wait for the fix that doesn't require restructuring.
ap...@google.com <ap...@google.com> #7
This was fixed by
jb...@google.com <jb...@google.com> #8
Branch: androidx-main
commit b292676aa37122f0ca0215023dcdbe27168b2469
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 27 21:25:35 2023
Add a test for navigate with popUpTo nested graph
Adding a test to ensure that if the start destination of a nested graph
is popped off the back stack when a fragment is created, Navigation does
not crash and gets to the correct position.
Bug: 287133013
Test: adding a test
Change-Id: Ie1e03aeeb00b730b7688311741847b2312bdbaa0
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/NavControllerWithFragmentTest.kt
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #9
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-fragment:2.8.0-alpha01
mo...@google.com <mo...@google.com> #10
There appears to be a problem with the order of operations. I'm going to look into fixing that.
ap...@google.com <ap...@google.com> #11
Branch: androidx-main
commit e57dd5f9ac6cbb8cf83b221e2d5b3fbd3e88ce6b
Author: George Mount <mount@google.com>
Date: Thu Nov 09 14:33:53 2023
Fix animateToStart with Slide.
Fixes: 300157785
Slide was not repositioning the View to its proper
translation after animating it to the start position.
This fixes that so that it is moved.
Test: new test
Change-Id: I698f4dbcef46304f9aa545847d205f7b70c80d63
M transition/transition/src/androidTest/java/androidx/transition/SlideEdgeTest.java
M transition/transition/src/androidTest/java/androidx/transition/TranslationAnimationCreatorTest.java
M transition/transition/src/main/java/androidx/transition/TranslationAnimationCreator.java
pr...@google.com <pr...@google.com> #12
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.transition:transition:1.5.0-alpha05
Description
Component used: Transition Version used: 1.5.0-alpha02 Devices/Android versions reproduced on: API 34
If you do a gesture back in Fragments using transitions and cancel the gesture multiple times, after the first cancel, starting the gesture will result in the transition on the exiting view failing to run.
I believe the cause of this is that the this
beginDelayedTransition()
called by with a 0 duration called by Fragment never triggersonAnimatedEnd()
callback inVisibility
. That results in the visibility failing to be added removed from the overlay and so the subsequent transitions on the view do not run.Here are logs synced with the calls from Fragment and Visibility. I would expect there to be an
onAnimationEnd reversed=false
log before theonTransitionEnd
in Visibility.The can be reproduced by patching in aosp/2748867 and doing the following in the navigation-integration app :