Status Update
Comments
so...@gmail.com <so...@gmail.com> #2
From the other issue:
note that it is never the right approach to attach a
<deeplink>
to an<activity>
destination as that will never give you the right behavior when using anon another app's task (where the system back should immediately take the user back to the app that triggered your deep link). Instead, you should attach your deep link directly to your second activity (either by manually writing the appropriate implicit deep link <intent-filter>
or by adding the<deeplink>
to the start destination of a nav host in that second activity).
A lint error saying as such when a <deepLink>
element is added in Navigation XML would go a really long way to avoiding this case. Our navigation-runtime-lint
artifact that would contain this check.
so...@gmail.com <so...@gmail.com> #3
We have some
il...@google.com <il...@google.com>
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #5
Branch: androidx-main
commit cd77b4bbe312dd8892dfbb3c662344d13a96c82d
Author: Julia McClellan <juliamcclellan@google.com>
Date: Thu Apr 14 15:31:46 2022
Deep link in activity destination in navigation lint
Test: Included tests of API version and the lint rule
Bug: 178403185
Change-Id: Ic15a5ec165620b7ef5b3f03538cc83b5576add8d
A navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetector.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/ApiLintVersionsTest.kt
M settings.gradle
A navigation/navigation-runtime-lint/build.gradle
M navigation/navigation-runtime/build.gradle
A navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/NavigationRuntimeIssueRegistry.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetectorTest.kt
A navigation/navigation-runtime-lint/src/main/resources/META-INF/services/com.android.tools.lint.client.api.IssueRegistry
il...@google.com <il...@google.com> #6
ch...@gmail.com <ch...@gmail.com> #7
- Be on the initial Fragment (FragmentA)
- Press device back button (the back press will be consumed but nothing appears to happen)
- Click on a view that will cause an attempt to navigate to FragmentB
- Crash
il...@google.com <il...@google.com> #8
pi...@gmail.com <pi...@gmail.com> #9
Publiquei aqui:
Description
Version used: 1.0.0-alpha11
I'm seeing some strange behaviour when pressing back button and transistion back to a fragment from a fragment of the same id.
My app uses some generic fragment structures that are driven by args passed in, as such there are places like:
FragmentA -> FragmentB -> FragmentB -> FragmentC
However if the back button is pressed on the second instance of FragmentB, FragmentA is replaced in the navhost while the navgraph correctly displays in the toolbar. Forward navigation from this point however is missing from the navgraph and results in an IllegalStateException with the action 'not found' in the graph, unless the back button is pressed again (pushing the navgraph destination back to FragmentA)
Is this intended behaviour? If so is there a way to declare FragmentB as 'stackable'?