Sdl_evolution: [Accepted] SDL 0115 - CloseApplication RPC

[theresalech]

Hello SDL community,

The review of "CloseApplication RPC" begins now and runs through November 28, 2017. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0115-close-application.md

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

https://github.com/smartdevicelink/sdl_evolution/issues/351

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
[email protected]

[joeljfischer]

I have a few questions about the purpose of this proposed RPC. The motivation states:

In order to close an app the driver can enter the apps menu on the head unit and select "Exit {AppName}". This is working without any issues for template based apps. Users are able to get back control of an app which was started before. Projection apps like mobile-navigation apps are going to add their own menu which follows their own design guideline instead of using AddCommand. This leads into a problem of how those apps are closed. Once started on the head unit user won't be able to get back control of the app as Core is auto-resuming apps.

This seems perhaps to conflict in usefulness with a second in-progress proposal: In-Progress RPC. If the app can just open the menu, then they wouldn't need their own menu, and they wouldn't need the ability to close their app.

Second, is this something that will be enforced that apps must add to their menu? If not, I can't see very many apps actually adding a button that exits their app. I think it could be enforced, but I think the other way of solving this problem (enforcing that apps have a button to show the menu as seen in the other proposal) is a better way to solve the problem.

[JackLivio]

I think this proposal is is similar to SDL 0116 - Open Menu RPC and that both cases could be solved by the use of a single RPC instead of each case having their own.

We could maybe create an RPC called SetHMIStatus and use enums already defined in Core

    <function name="SetHMIStatus" functionID="OnHMIStatusID" messagetype="request">
        <param name="hmiLevel" type="HMILevel" mandatory="false">
            <description>Enumeration that describes current levels of HMI</description>
        </param>

        <param name="systemContext" type="SystemContext" mandatory="false">
            <description>Enumeration that describes possible contexts an app's HMI might be in. Communicated to whichever app is in HMI FULL, except Alert.</description>
        </param>
    </function>

To Close app
Proxy -> Core
SetHMIStatus : { appID : 1234, hmiLevel: NONE, systemContext : MAIN }

To Show app menu
Proxy -> Core
SetHMIStatus : { appID : 1234, hmiLevel: FULL, systemContext : MENU }

[joeljfischer]

I like @JackLivio's suggestion quite a bit.

[NickFromAmazon]

Many of the hmiLevel and systemContext values don't make sense as settable values by a connected app; providing this much flexibility when only a couple of permutations are actually valid seems like it could be confusing.

[kshala-ford]

Although I like the idea of using already defined API I agree to @NickFromAmazon. It might be confusing and cause more effort in checks for invalid values. At the end it looks much more complex to be implemented.

Changing the HMI level is a sensitive task. Apps might want to be abel to move to HMI_FULL with this API. We at Ford talked about it and agreed to only accept the move to HMI_NONE. Those apps who want to get into HMI_FULL should use Alert with STEAL_FOCUS soft button.

Second, is this something that will be enforced that apps must add to their menu? If not, I can't see very many apps actually adding a button that exits their app. I think it could be enforced, but I think the other way of solving this problem (enforcing that apps have a button to show the menu as seen in the other proposal) is a better way to solve the problem.

CloseApplication should be part of the certification process for nav apps who don't want to use the built-in menu.

Generally this proposal does not conflict with OpenMenu RPC. Both proposals could coexist and solve problems with apps who want to use the built-in menu and those who don't (we have both kinds of apps).

• CloseApplication is for nav apps who don't want to use the built-in menu
• OpenMenu is supposed to be used for nav apps using AddCommand

[theresalech]

The Steering Committee voted to accept this proposal.

[theresalech]

Issues Entered:
Android
Core
iOS
RPC
sdl_hmi
generic_hmi