You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e495908
Browse filesBrowse the repository at this point in the historyBrowse files
feat(sample): Add Nav3 lifecycle scenarios to sample app (JAVA-785) (#6309)
Part 5 of our Nav3 support for multi-Activity and multi-Fragment applications
Add multi-Activity and multi-Fragment Nav3 scenarios with shared transaction history so lifecycle handoffs can be exercised in the Android sample app.
Copy file name to clipboardExpand all lines: sentry-android-navigation3/src/test/kotlin/io/sentry/compose/navigation3/lifecycle/NavLeaseCoordinatorTest.kt
+3-198Lines changed: 3 additions & 198 deletions
Original file line number
Diff line number
Diff line change
@@ -269,25 +269,9 @@ class NavLeaseCoordinatorTest {
269
269
}
270
270
271
271
/**
272
-
* An owner that leaves must not leave its nav data behind on the shared scope.
273
-
*
274
-
* The coordinator records which owner last published nav data. Each handoff uses that record to
275
-
* clear the previous owner's screen and back stack, then publishes the incoming owner's. If the
276
-
* clear attempt throws, the coordinator must still record the incoming owner as the one that last
277
-
* published.
278
-
*
279
-
* This test runs two handoffs over three owners. The first owner publishes; the second takes the
280
-
* lease; and then the first owner's clear attempt throws. The third then takes the lease. The
281
-
* test verifies that third handoff clears the second owner's data, and not the first's. That lets
282
-
* us ensure the second problem listed below doesn't happen.
283
-
*
284
-
* In the setup above, if the coordinator didn't record the second owner's data after the first
285
-
* owner's clear attempt threw, two things would happen when handing off to the third owner:
286
-
*
287
-
* 1. Harmless: The handoff logic would try to clear the first owner's data again. That'd remove
288
-
* nothing because the scope no longer holds the values the first owner published.
289
-
* 2. Problematic: The handoff would never clear the second owner's data. Instead, the second
290
-
* owner's data would stay on the scope, so later events would report stale nav data.
272
+
* The coordinator records the incoming owner as the publisher before calling into the scope, so a
273
+
* clear callback that throws mid-handoff doesn't strand the incoming owner's nav data: the next
274
+
* handoff still clears it.
291
275
*/
292
276
@Test
293
277
fun`if a clear attempt throws during a handoff, the next handoff clears the new leaseholder's nav data`() {
@@ -323,71 +307,6 @@ class NavLeaseCoordinatorTest {
0 commit comments