Create constraints between lifecycle artifacts [242871265]

Fixed

Bug

Status Update

No update yet.

Description

il...@google.com

created issue #1

Aug 17, 2022 05:23PM

Component used: Lifecycle

Version used: 2.6.0-alpha01

Until feature requests such as b/146802533 are released, Gradle does not do any enforcement that Lifecycle artifacts are of the same version (i.e., you could mix and match lifecycle-common:2.6.0-alpha01 with lifecycle-runtime:2.5.1).

Gradle supports constraints, which ensure that upgrading a transitive dependency will also upgrade other dependencies.

We should manually add two way constraints, similarly to what was done for Paging in b/235256201, to the various lifecycle artifacts, which will help Gradle enforce the same version policy we intend.

The pairs of artifacts we should add constraints to should match the dependencies we have right now, which should mean the list looks something like:

lifecycle-common and lifecycle-common-java8
lifecycle-common and lifecycle-runtime
lifecycle-runtime and lifecycle-runtime-ktx
lifecycle-runtime and lifecycle-runtime-compose
lifecycle-runtime and lifecycle-runtime-testing
lifecycle-livedata-core and lifecycle-livedata-core-ktx
lifecycle-livedata-core and lifecycle-livedata
lifecycle-livedata and lifecycle-livedata-ktx
lifecycle-reactivestreams and lifecycle-reactivestreams-ktx
lifecycle-viewmodel and lifecycle-viewmodel-ktx
lifecycle-viewmodel and lifecycle-viewmodel-savedstate
lifecycle-viewmodel-savedstate and lifecycle-viewmodel-compose

Comments

ap...@google.com <ap...@google.com> #2Aug 20, 2022 05:23AM

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 to SecondFragment just to go somewhere else, each of the fragments take the entire content of SecondFragment 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.

ap...@google.com <ap...@google.com> #3Aug 20, 2022 07:25AM

Please example,what do you mean by that?

ap...@google.com <ap...@google.com> #4Aug 20, 2022 07:25AM

Have SecondFragment as part of your graph and then inside of SecondFragment call the childFragmentManager and replace with the fragment you actually want to show, whether that is SecondTypeOne or SecondTypeTwo.
Create different graphs and follow along with the docs on using different graphs dynamically and inflate and set the one needed based on logic in your Activity.

ap...@google.com <ap...@google.com> #5Aug 20, 2022 07:25AM

Thank you very much. Now the issue does not occur. When I added this code below in SecondFragment

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>

ap...@google.com <ap...@google.com> #6Aug 20, 2022 07:25AM

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> #7Aug 22, 2022 06:12PM

This was fixed by https://issuetracker.google.com/301887045 and will be available in the Navigation 2.7.4 release. We are also adding a regression test for this particular case.

ap...@google.com <ap...@google.com> #8Aug 22, 2022 06:12PM

Project: platform/frameworks/support
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

https://android-review.googlesource.com/2765553

ap...@google.com <ap...@google.com> #9Aug 23, 2022 04:43PM

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

ap...@google.com <ap...@google.com> #10Aug 23, 2022 07:35PM

Project: platform/frameworks/support
Branch: androidx-main

commit fe17ed80e60d5ec3bb42fe0552415424b7b3dde5
Author: Sanura N'Jaka <sanura@google.com>
Date: Thu Aug 18 17:36:11 2022

Add project dependency constraint between lifecycle-livedata and lifecycle-livedata-ktx

Added bi-directional project version constraint between
lifecycle-lifedata and lifecycle-livedata-ktx. If both
artifacts are in the dependency tree, their versions
should match. This will now be enforced by gradle
automatically bumping up either version to meet constraint.

Test: N/A
Bug: 242871265
Change-Id: Iba6d1ffb952fd20be91b813dcac193ecc1776173

M lifecycle/lifecycle-livedata-ktx/build.gradle
M lifecycle/lifecycle-livedata/build.gradle

https://android-review.googlesource.com/2189940

ap...@google.com <ap...@google.com> #11Aug 23, 2022 07:57PM

Project: platform/frameworks/support
Branch: androidx-main

commit 1e948aed8d0c01823ae60258ade0694da728b36d
Author: Sanura N'Jaka <sanura@google.com>
Date: Thu Aug 18 17:40:29 2022

Add project dependency constraint between lifecycle-livedata-core and lifecycle-livedata-core-ktx

Added bi-directional project version constraint between
lifecycle-lifedata-core and lifecycle-livedata-core-ktx.
If both artifacts are in the dependency tree, their
versions should match. This will now be enforced by gradle
automatically bumping up either version to meet constraint.

Test: N/A
Bug: 242871265
Change-Id: I6c6dd9de2e252217095c60de8ef577be6d940f1a

M lifecycle/lifecycle-livedata-core/build.gradle
M lifecycle/lifecycle-livedata-core-ktx/build.gradle

https://android-review.googlesource.com/2189941

ap...@google.com <ap...@google.com> #12Aug 24, 2022 08:02PM

Project: platform/frameworks/support
Branch: androidx-main

commit 325aa99d830327ccf016231f9836cf04db65c3ff
Author: Sanura N'Jaka <sanura@google.com>
Date: Mon Aug 22 22:23:18 2022

Add project dependency constraint between lifecycle-common and lifecycle-livedata-core

Added bi-directional project version constraint between
lifecycle-common and lifecycle-livedata-core. If both
artifacts are in the dependency tree, their versions
should match. This will now be enforced by gradle
automatically bumping up either version to meet constraint.

Test: N/A
Bug: 242871265
Change-Id: I22e0fda00e22bc4fc56ac1bf5b7dcd2369ad533e

M lifecycle/lifecycle-livedata-core/build.gradle
M lifecycle/lifecycle-common/build.gradle

https://android-review.googlesource.com/2192537

ap...@google.com <ap...@google.com> #13Aug 26, 2022 04:47PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-main

commit 27355f7c30e816f6636928caeef29d473b896e28
Author: Sanura N'Jaka <sanura@google.com>
Date: Wed Aug 24 22:41:48 2022

Add project dependency constraint between lifecycle-viewmodel-savedstate and lifecycle-livedata-core

Added bi-directional project version constraint between
lifecycle-viewmodel-savedstate and lifecycle-livedata-core.
If both artifacts are in the dependency tree, their versions
should match. This will now be enforced by gradle automatically
bumping up either version to meet constraint.

Test: N/A
Fixes: 242871265
Change-Id: I94cc3ddd0f86033653c1477cf3f8ad8a1d93adae

M lifecycle/lifecycle-livedata-core/build.gradle
M lifecycle/lifecycle-viewmodel-savedstate/build.gradle

https://android-review.googlesource.com/2193733

ap...@google.com <ap...@google.com> #14Aug 26, 2022 04:47PM

Project: platform/frameworks/support
Branch: androidx-main

commit 0598f5400a797fc9e31858e0d8a1b575ad7158a7
Author: Sanura N'Jaka <sanura@google.com>
Date: Thu Aug 18 18:28:20 2022

Add project dependency constraint between lifecycle-viewmodel-savedstate and lifecycle-viewmodel-compose

Added bi-directional project version constraint between
lifecycle-viewmodel-savedstate and lifecycle-viewmodel-compose.
If both artifacts are in the dependency tree, their versions
should match. This will now be enforced by gradle automatically
bumping up either version to meet constraint.

Test: N/A
Bug: 242871265
Change-Id: I2810d3afbe0cb8e8e387d1bc64eb3c698285d471

M lifecycle/lifecycle-viewmodel-savedstate/build.gradle
M lifecycle/lifecycle-viewmodel-compose/build.gradle

https://android-review.googlesource.com/2190016

na...@google.com <na...@google.com> #15Sep 12, 2022 05:51PM

This bug was linked in a change in the following release(s):

androidx.lifecycle:lifecycle-common:2.6.0-alpha02
androidx.lifecycle:lifecycle-livedata:2.6.0-alpha02
androidx.lifecycle:lifecycle-livedata-core:2.6.0-alpha02
androidx.lifecycle:lifecycle-livedata-core-ktx:2.6.0-alpha02
androidx.lifecycle:lifecycle-livedata-ktx:2.6.0-alpha02
androidx.lifecycle:lifecycle-reactivestreams:2.6.0-alpha02
androidx.lifecycle:lifecycle-reactivestreams-ktx:2.6.0-alpha02
androidx.lifecycle:lifecycle-runtime:2.6.0-alpha02
androidx.lifecycle:lifecycle-runtime-compose:2.6.0-alpha02
androidx.lifecycle:lifecycle-runtime-ktx:2.6.0-alpha02
androidx.lifecycle:lifecycle-runtime-testing:2.6.0-alpha02
androidx.lifecycle:lifecycle-viewmodel:2.6.0-alpha02
androidx.lifecycle:lifecycle-viewmodel-compose:2.6.0-alpha02
androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.0-alpha02
androidx.lifecycle:lifecycle-viewmodel-savedstate:2.6.0-alpha02

da...@google.com <da...@google.com> #16Sep 28, 2022 02:38PM

This release seems to have conflicting artifacts in the classpath. When both:

androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.0-alpha02

androidx-lifecycle:lifecycle-livedata-ktx:2.6.0-alpha02

are added as dependencies, the following error pops up:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sync:sync-test:checkProdDebugAndroidTestDuplicateClasses'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable
   > Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.6.0-alpha02-runtime (androidx.lifecycle:lifecycle-viewmodel:2.6.0-alpha02) and lifecycle-viewmodel-ktx-2.3.1-runtime (androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1)
     Duplicate class androidx.lifecycle.ViewTreeViewModelKt found in modules lifecycle-viewmodel-2.6.0-alpha02-runtime (androidx.lifecycle:lifecycle-viewmodel:2.6.0-alpha02) and lifecycle-viewmodel-ktx-2.3.1-runtime (androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1)
     
     Go to the documentation to learn how to <a href="d.android.com/r/tools/classpath-sync-errors">Fix dependency resolution errors</a>.

Downgrading to 2.6.0-alpha01 fixes this.

sa...@google.com <sa...@google.com> #17Oct 17, 2022 05:23PM

As an update to the above comment from TJ, this issue has been fixed and will be available in Lifecycle 2.6.0-alpha03.

na...@google.com <na...@google.com> #18Oct 24, 2022 01:38PM

The following release(s) address this bug:

androidx.lifecycle:lifecycle-runtime:2.6.0-alpha03
androidx.lifecycle:lifecycle-runtime-compose:2.6.0-alpha03
androidx.lifecycle:lifecycle-viewmodel-compose:2.6.0-alpha03
androidx.lifecycle:lifecycle-viewmodel-savedstate:2.6.0-alpha03