Fixed
Status Update
No update yet.
Comments
il...@google.com
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.
ou...@gmail.com
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.
il...@google.com
ap...@google.com
Yep, we'll fix it.
il...@google.com
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).
sp...@google.com
Yes, Manifest Merger supports this. Pending CL adds test for this scenario.
Description
Version used: android.arch.navigation:navigation-ui:1.0.0-alpha05
Devices/Android versions reproduced on: any
I suppose it's no a bug, but just a wrong behavior.
If i have i custom scheme, like "com.example://" - this could not be used and inside framework http(s) will be appended.
NavDeeplink states that there is a scheme pattern, that should detect if there is any scheme before ":", but it fails if there is any dot in scheme. So any scheme that contains dots will fail. Only schemes with "-" are supported by now.
private static final Pattern SCHEME_PATTERN = Pattern.compile("^(\\w+-)*\\w+:");