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.
kr...@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
Yep, we'll fix it.
il...@google.com
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).
Description
Version used: 1.0.0-alpha06
Devices/Android versions reproduced on: Android 8.1.0, Samsung Galaxy J5 (I don't think it's device related)
Navigation library doesn't handle deep links properly when there are 2 deep links registered and the second one is an "extension" of the previous one. Let me give a simplified example to make it more clear:
<fragment android:name="com.example.EventFragment">
<argument
android:name="eventId"
app:argType="string" />
<action
android:id="@+id/exhibitorDetails"
app:destination="@id/exhibitorDetails" />
<deepLink app:uri="example://events/{eventId}" />
</fragment>
<activity android:id="@+id/exhibitorDetails"
android:name="com.example.ExhibitorsActivity">
<!-- I know, not a single Activity app. But that's the case. -->
<argument
android:name="exhibitorId"
app:argType="string" />
<deepLink app:uri="example://events/{eventId}/exhibitors/{exhibitorId}" />
</activity>
When I use a link: example://events/event123/exhibitors/exhibitor123 I expect navigation library to navigate to an ExhibitorsActivity. Instead, it navigates to EventFragment. Furthermore, an eventId passed to a fragment is invalid, in this case, it's: "event123/exhibitors/exhibitor123".
I believe it's a bug of regex: in my example, passed link matches both regexes: example://events/{eventId} and example://events/{eventId}/exhibitors/{exhibitorId}.