Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
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.
ma...@marcardar.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.
Description
Version used: 1.0.0-alpha07
Devices/Android versions reproduced on: Android 8.1
This is a feature request.
In my Nav drawer I have a Settings item. Currently, using the Nav Architecture component, clicking this causes the current back stack to be popped up to (not including) the start destination, and then the Settings fragment is added on top of that. I would like to be able to customise this so that the pop does not occur - i.e. that the Settings fragment is simply placed on top of the current destination. Anyway, isn't this what the user would expect for a Settings screen?
The key method call seems to be on the second line of NavigationUI.setupWithNavController() where popUp = false is passed. Maybe whether to popUp or not could be specified in the nav_graph destination?