Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
I assume you were expecting it to bias towards the longer matching deep link?
Right now, it is greedy, avoiding the need to iterate through your entire graph. That means a valid workaround for the moment would be to swap the order of your destinations, which should put the first deep link first.
Right now, it is greedy, avoiding the need to iterate through your entire graph. That means a valid workaround for the moment would be to swap the order of your destinations, which should put the first deep link first.
jb...@google.com <jb...@google.com> #3
Yes, exactly. I think most of the people would expect it to match longer deep link :)
Hmm... Do you think your solution is safe? It is totally based on implementation details, which could change in the next release. Plus I actually tested it and it doesn't work - I put exhibitorDetails on the top, but the behavior didn't change. I did a full clean of the project.
At the moment I look for deep link manually and I see if it contains "/exhibitors/{exhibitorId}". If it does, I redirect to the next view manually. Obviously, I hope it's gonna be fixed, as it looks ugly in my code, and I hate ugly code 😁 Do you think it's possible to include that bug in upcoming releases? I saw you're working on supporting query params in deep, that should be more or less same place in the project.
Hmm... Do you think your solution is safe? It is totally based on implementation details, which could change in the next release. Plus I actually tested it and it doesn't work - I put exhibitorDetails on the top, but the behavior didn't change. I did a full clean of the project.
At the moment I look for deep link manually and I see if it contains "/exhibitors/{exhibitorId}". If it does, I redirect to the next view manually. Obviously, I hope it's gonna be fixed, as it looks ugly in my code, and I hate ugly code 😁 Do you think it's possible to include that bug in upcoming releases? I saw you're working on supporting query params in deep, that should be more or less same place in the project.
ma...@gmail.com <ma...@gmail.com> #4
Yep, we'll fix it.
de...@atommobility.com <de...@atommobility.com> #5
This has been fixed internally in https://android-review.googlesource.com/870978 and will be available in Navigation 1.0.0-alpha10.
Navigation now biases selecting deep links based on the number of matching arguments (more matching arguments are considered better matches).
Navigation now biases selecting deep links based on the number of matching arguments (more matching arguments are considered better matches).
jb...@google.com <jb...@google.com> #6
Please file a bug with a minimum sample project that reproduces this issue.
th...@gmail.com <th...@gmail.com> #7
Hi Team,
Issue is still reproducible with Gradle 7.0
Please help to fix on priority
Issue is still reproducible with Gradle 7.0
Please help to fix on priority
jb...@google.com <jb...@google.com> #8
Please file a bug with a minimum sample project that reproduces this issue.
Description
When using Navigation SafeArgs
2.4.0-alpha01
+ with Kotlin versions before1.5.0
, you get the following:This is because the
titleCase
API was not added until Kotlin1.5.0
.In
2.4.0-alpha01
+, SafeArgs must be compatible with AGP4.2.0
and as a result Gradle6.7.0
, which is compatible with Kotlin versions prior to1.5.0
.We should avoid using
titlecase
in SafeArgs until we no longer need to support older Kotlin versions. As a workaround, you can update your gradle version to7.0
+.