[Withdrawn] SDL 0281 - Add a mechanism to exclude route guidance between embedded navigation and SDL navigation

[theresalech]

Hello SDL community,

The review of "SDL 0281 - Add a mechanism to exclude route guidance between embedded navigation and SDL navigation" begins now and runs through February 25, 2020. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0281-Add-a-mechanism-to-exclude-route-guidance-between-embedded-navigation-and-SDL-navigation.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#942

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
theresa@livio.io

[joeljfischer]

The concern seems to be that when an SDL navigation app is activated, the embedded navigation app is deactivated, even if there's a route in progress, and visa versa. It's hard to discern if the primary issue that this proposal has is a lack of clear documentation on the OnEventChanged(EMBEDDED_NAVI, true/false). I think that making more clear whether the primary issue of this proposal is the lack of documentation, or to change the current behavior.

I don't agree with the proposed solution. Simply leaving up to app developers what should happen with embedded or SDL navigation is not a good idea. It leads to inconsistent user experience when app developers do different things, even on the same head unit.

Instead, the behavior should be controlled either by SDL itself, which is the current situation, or by the HMI in a consistent way. I believe we should either (A) keep the current situation but clarify the documentation, or (B) change the current situation - while keeping the same general solution - and clarify the documentation.

If we choose (B), we need some general guidelines. I don't believe that we should allow two different navigation apps to simultaneously have routes occurring. The current situation is that activating an SDL app will cause it to become the "active" navigation app for the head unit, while closing it causes the embedded navigation to become the "active" navigation app for the head unit. This will cancel the route of the embedded nav, and should cancel the route of the app, and so it is one way to solve that problem. A second way to solve that problem is by using app services. The current navigation service can have a route running, but other navigation services should cancel a route if they relinquish being the active navigation service.

So, while I personally think that we should stick to the current situation and simply improve documentation, another option is to leverage app services. In either case, I believe that the RPC / app dev based solution of this proposal should not be accepted.

[Kazuki-Sugimoto]

@joeljfischer -san
Thank you for your opinion.
I will reply on behalf of @Shohei-Kawano.

I don't believe that we should allow two different navigation apps to simultaneously have routes occurring.

It doesn't seem to tell us what we want to do.

For example, there is a use case in which another navigation application is started just to see a map.
In that case, if the navigation route that goes behind disappears, it will be a bad UX for the user.
I thought that if the last route set by the user was the only route, it would be a good UX according to the user's intention.

[joeljfischer]

I understand that request, but the current proposal of leaving it up to app developers, which will lead to bad and inconsistent UX.

My proposed solution is to add documentation that clarifies the situation and simply says that routes should not be cancelled in the embedded nav app if an SDL nav app comes forward. The problem with that is that the system should cancel the embedded nav route if the SDL nav app starts a route. As I mentioned above, the way we can do that is through navigation app services. Nav app services will provide data when they have a route in progress compared to when they don't. So when the SDL nav app starts a route, they will stop the embedded nav app's route.

The second problem is the other way around. How do you stop an SDL nav app if they start the route on the embedded system? A possible solution would be to document that if an SDL nav app running a route stops being the active service, they should stop their route.

[joeygrover]

I agree with @joeljfischer's point that asking the developer to use this RPC will result in dramatically different user experiences when going between different navigation apps. In fact, a developer can just send this RPC as soon as they receive their first HMI_FULL status, which would result in the same behavior we have know and therefore the issue would still exist.

I believe that using app services is the best path forward. The HMI can be a consumer of navigation services, when one becomes active and sends route data that can be used to determine that nav service/app should be used for their route guidance. The embedded nav should also be described as an app service for this reason and that the feature allows. This can inform other nav apps just the same as other apps that the user has started a route and that app should stop its guidance at that time.

[Kazuki-Sugimoto]

@joeljfischer -san

A possible solution would be to document that if an SDL nav app running a route stops being the active service, they should stop their route.

Does this mean when other nav services become active services (not when other nav launches)?
If it is correct, your suggestion will meet our request. Therefore we will drop this proposal.

[joeljfischer]

@Kazuki-Sugimoto Yes, that's effectively what I'm suggesting. We can clarify documentation to that point.

[theresalech]

This proposal has been withdrawn per the author's request.