Fixed
Status Update
No update yet.
Comments
mg...@google.com
ap...@google.com
This is because a PendingIntent doesn't use the extras/arguments to compare 2 intents, so each notification actually use the same pending intent, and the extras arguments are updated (PendingIntent.FLAG_UPDATE_CURRENT).
If you have a <deepLink> element in your destination, you should use the Uri to navigate to it.
```
<deepLink app:uri="http://www.example.com/users/{id} ">
Intent i = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.example.com/users/42 ");
```
If you have a <deepLink> element in your destination, you should use the Uri to navigate to it.
```
<deepLink app:uri="
Intent i = new Intent(Intent.ACTION_VIEW, Uri.parse("
```
na...@google.com
This has been fixed internally in https://android-review.googlesource.com/861068 and will be available in Navigation 1.0.0-alpha10. Navigation now uses both the destination ID and the arguments to build a unique requestCode for the PendingIntent, ensuring that you can create multiple PendingIntents to the same destination.
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-viewmodel-compose:2.9.0-alpha01androidx.lifecycle:lifecycle-viewmodel-compose-android:2.9.0-alpha01androidx.lifecycle:lifecycle-viewmodel-compose-desktop:2.9.0-alpha01
Description
Currently
lifecycle-viewmodel-composeare depending oncompose-uiincommonMain. The dependency is only used inandroidMain.This dependency brings alot of code for projects aiming to use Compose Runtime only, for example Redwood. At Voyager the Core and Navigator modules only depend on Compose Runtime, by adding the support for ViewModel to KMP projects with Voyager would bring the hole
compose-ui.The solution here is just move the
compose-uidependency toandroidMain.