Android Drop-In UI: Allow the user to continue his navigation even after he reaches his destination.

[Sridhar261990]

Hi, I am using DropInUI for my application. I saw the navigation stops navigating further once the user reaches the destination. For example, If the driver passed his destination by mistake then the navigation should reroute the driver to the destination again. I think the dropInUi is not working in that way right now. Sometimes if the drivers passed the destination then there is no way he can navigate to his destination again. The only way is he should close and restart the navigation.

Android 10 implementation 'com.mapbox.navigation:ui-app:2.8.0-beta.2' implementation 'com.mapbox.navigation:ui-dropin:2.8.0-beta.2'

Steps to trigger behavior

1. Start the navigation to any destination
2. Reach the destination
3. The active navigation stops automatically and the maneuver instruction,speed,sound, overview and recenter button will go away.

Expected behavior

The navigation should continue until the driver tap x(cancel) button in the infopanel.

Actual behavior

It stops the navigation.

[abhishek1508]

@Sridhar261990 Thanks for cutting the ticket!

@mapbox/navigation-android I am curious if we have a recommended solution for the problem described outside Drop-In UI with standalone components. I remember this being raised by other logistics based user base/prospects. Can someone who knows more pitch in?

@zugaldia @mapbox/navnative @AhmerKhan1

[EricGeiler]

@abhishek1508 I will post a use case shortly. I had opened a ticket with support in 0.4x regarding this, and we did a custom solution until 1.x that worked very well. I'm seeing a definite need for a change/handling mod for the logistics / driver user base.

[EricGeiler]

Current Real example of driver behaviour

1. Driver starts nav
2. Driver approaches destination located on the right side of roadway for example, 1 single curbside/street parking available just prior to the destination.
3. Driver sees an empty spot, but misses the spot due to whatever reason, so he continues straight, however as he passes the destination, his navigation stops, as he thinks hes arrived. Meanwhile the driver turns right/right/right on the first way, (going around the block to get back to that spot he passed) during this whole time, the driver does not have navigation in 2.x Drop-In UI. Drivers therefore would have to essential re-start the nav progress to receive instructions again on how to reach the location. This creates frustration among drivers, as they legally cannot be touching a mobile device while driving in Ontario, therefore we are essentially asking the driver to pull over to restart his nav, which wastes time, loses his spot in traffic, adds to accident potential as the driver attention is distracted from the road in a high traffic / high pedestrian risk urban area.

Ideal Expected Behaviour

1. Driver starts nav
2. Driver approaches destination located on the right side(assuming developer has used arrival on right) of roadway for example, 1 single curbside/street parking available just prior to the destination.
3. Driver sees and misses empty spot, he continues until first way, as he passes the destination on the right, the arrival process is not triggered via a development parameter ideally, therefore the nav engine uses the values such as Continue Straight or Uturn permission availability to re-route or route driver back to destination. Each time the user approaches the destination, we would want to hear the normal scripted speech when approaching a destination. In our experience drivers, will end the navigation or expect it to end when they have parked their car.
4. We expect the driver to ack/confirm that they arrived by pressing a button on the info panel to end the navigation and take user session back to in-house app screen to do the a&b related workflow.

Background info / side notes.

1. Some drivers are not the geographically aware hence why nav app exist, we find that the majority of drivers who drive past a destination in attempts to location parking in urban metro cores(financial districts, business towers, high density), require assistance to "re-find" the destination, even its as simple as making a u-turn and going back 200 meters, they will make the u-turn when advised too, but have no clue where 661 University Avenue is for example. Without a "continuous" nav session.

2. We took it one one step further, if a user it navigating to an high density urban area, where parking is possible an issue, we have some geographic areas, were we provide parking location assistance to the driver, essentially the first nav request is to a parking spot, once the user confirms they arrived at parking, the app auto starts a new nav session in walking mode from the current location (parking spot) to the actual destination (office building for example) where the driver needs to attend to pickup or deliver a package. Upon arriving at the actual suite driver does in-app workflow, then hes prompted to start nav to return to his car, we do this walking mode, using store lat/long from the parking spot. Once user arrives back at car, hes on to the next stop / order / pickup / delivery etc.

Essentially the ideal option would be a way for developer to turn on and off the arrival / end of navigation upon reaching a destination. if users passes destination, re-route the driver back to the destination.

Its my non-programmer understanding that this can be accomplished with a little work on our side, and change on the mapbox side, based on my chat with our developer @Sridhar261990

[etl]

Sounds like arrival-trigger confirmation callback. However this behaviour might have side effects:

• last instructions probably would need to be committed
• new route (reroute) should be calculated
• message about missing arrival
• etc.

[1ec5]

Essentially the ideal option would be a way for developer to turn on and off the arrival / end of navigation upon reaching a destination. if users passes destination, re-route the driver back to the destination.

The iOS navigation SDK has an option that sounds a lot like this: NavigationServiceDelegate.navigationService(_:shouldPreventReroutesWhenArrivingAt:) gets called when arriving at any waypoint; you can return true or false depending on whether you want the navigation service to continue to track the user’s location and continually reroute them. By default, it does not continue to track the user’s location, but this functionality is beneficial in the use cases you describe.

The iOS navigation SDK lost this functionality when adopting MapboxNavigationNative but reimplemented it due to customer demand and to preserve backwards compatibility: mapbox/mapbox-navigation-ios#3001 mapbox/mapbox-navigation-ios#3195. The implementation is purely iOS-specific, adapted from legacy code from before we adopted MapboxNavigationNative, but you’re welcome to use it as a guide to addressing the cases in https://github.com/mapbox/mapbox-navigation-android/issues/6281#issuecomment-1248008081.

/ref https://github.com/mapbox/mapbox-navigation-android/issues/3087#issuecomment-840653255

[EricGeiler]

@1ec5 holy moly! This is exactly what we need to see.

so I guess its true, you really do hold the secrets! 🥇

+1 for port to Android SDK.... Drop-In UI?

[abhishek1508]

@EricGeiler We're evaluating options of bringing this functionality to Android and we'll come back with updates when we have them.

[EricGeiler]

@EricGeiler We're evaluating options of bringing this functionality to Android and we'll come back with updates when we have them.

Thank you very much! We look forward to seeing this feature request come to the android platform!

[EricGeiler]

@abhishek1508 any updates on progress?

[abhishek1508]

@EricGeiler Unfortunately, we haven't been able to make much progress here. The changes required would need other internal teams to make changes as well. I am afraid this is gonna take some more time.

cc @AhmerKhan1 @etl @Chadiarazek

[rebeccachin]

Hello! Any chance that this android issue has been prioritized? Has the SDK evolved to have a potential workaround?

[EricGeiler]

I don't believe so, we ended up building a custom workaround that suited us for the time being, however we are still tracking this thread for a official mapbox solution.