Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HMI Specification Inconsistencies #541

Closed
justinjdickow opened this issue May 16, 2016 · 4 comments
Closed

HMI Specification Inconsistencies #541

justinjdickow opened this issue May 16, 2016 · 4 comments

Comments

@justinjdickow
Copy link
Contributor

The following inconsistencies have been noted by third parties

  1. Press Mode is wrong.
    In 8.3.1.2 ButtonPressMode in SDL Integration Guidelines 4.0, "SHORT" is 0 and "LONG" is 1. But it turns out that SDL Core expects "SHORT" to be 1 and "LONG" to be 0.
  2. Alert timeout with soft buttons.
    It seems that SDL Core set timeout as 0 for Alert with soft buttons, but SDL Integration Guidelines 4.0 says "pressing KEEP_CONTEXT type soft button is to renew the timeout for the alert dialog".
  3. Alert text fields.
    Now SDL Core expects that at least one of alertText1 and alertText2 is not empty string, but SDL Integration Guidelines 4.0 does not mention this.
  4. Alert - HMI defined "close" button behavior .
    HMI -> SDL == {"id":34,"jsonrpc":"2.0","error":{"data":{"method":"UI.Alert"},"message":"Aborted","code":5}}
    (Actual) SDL -> MOBILE == { "resultCode":"INVALID_ID", "success":false, "info","Aborted” }
    (Our Expectation) SDL -> MOBILE == {"resultCode":"ABORTED","success":false}
  5. For 6.18.1.1, among the parameters of "BasicCommunication.OnSystemRequest", spec says that "appID" is an integer, but SDL Core expects it to be a string when testing.
  6. In 10.6.2.2, the description of parameter "ttsName" for "TTS.ChangeRegistration" is wrong. That is the description of parameter "vrSynonyms" for "VR.ChangeRegistration".
  7. In 7.29.3, it shows that when the response is SUCCESS for "UI.SetDisplayLayout", it can include four parameters "displayCapabilities", "buttonCapabilities", "softButtonCapabilities", and "presetBankCapabilities". But SDL Core logs will show "Incorrect parameter from HMI" when the response contains any of this four parameters.
  8. In 10.2.3.1, it shows that the first parameter of "TTS.GetCapabilitites" is "capabilities". But I checked SDL Core code, and it expects "speechCapabilities".

Parameter boundary do not align:

  1. Add command into specific sub menu.
    AddSubMenu.MenuID Min value = 1 However AddCommand.menuParams.ParentID Min value = 0
  2. PutFile.syncFileName string length Max value = 255 however Image.value string length Max value = 65535
  3. PutFile.syncFileName string length Min value = 1 however Image.value string length Min value = 0
  4. PutFile.syncFileName string length Max value = 255 however SetAppIcon.filename string length Max value = 500
  5. SoftButton.Text is not mandatory and SoftButton.Image is not mandatory.
    But when we set SoftButton.type = BOTH and ignore text and image. It responses INVALID_DATA
@AnastasiyaBritanova
Copy link

AnastasiyaBritanova commented Jun 13, 2016

About the inconsistencies:

  1. Press Mode is wrong.
    -> needs to be fixed in Guidelines
  2. Alert timeout with soft buttons.
    -> SDL has a requirement to cancel the internal timeout for Alert with SBs.
    -> Per current requirements, if app -> SDL: Alert + SBs:
    and with "duration" -> SDL must transfer "duration" to HMI via UI.ALert
    and without "duration" -> SDL must omit "duration" in UI.Alert to HMI
    in both cases, HMI must apply the "default HMI timeout for alerts with SBs"
    -> So, in case of Alert with SBs it's completely HMI's responsibility to provide UI.Alert_response: SDL will keep waiting even without OnResetTimeout notification.
    ==> to sum up:
    a. it's SDL's defect to zero the "duration" in UI.Alert (while it's expected when SDL's internal timeout is zeroed)
    b. Guidelines needs to be updated for KEEP_CONTEXT behavior
  3. Alert text fields.
    -> Per SDL requirements, in case mobile_API omits "minlength" descriptor of string param, SDL must use value of "minlength = 1" by default.
    -> returning INVALID_DATA to app's Alert that contains zeroed AlertTextStrings is an expected behavior.
    -> This above description is out of "SDL-HMI Guidelines" scope, since it impacts app-SDL relations only.
  4. Alert - HMI defined "close" button behavior .
    -> the expected behavior is correct.
    -> please bring up as a separate issue, with logs if possible.
  5. For 6.18.1.1, among the parameters of "BasicCommunication.OnSystemRequest", spec says that "appID" is an integer, but SDL Core expects it to be a string when testing.
    -> SDL behavior is fixed to expect integer "appID" in release_4.1.0
  6. In 10.6.2.2, the description of parameter "ttsName" for "TTS.ChangeRegistration" is wrong. That is the description of parameter "vrSynonyms" for "VR.ChangeRegistration".
    -> Guidelines need to be fixed
  7. In 7.29.3, it shows that when the response is SUCCESS for "UI.SetDisplayLayout", it can include four parameters "displayCapabilities", "buttonCapabilities", "softButtonCapabilities", and "presetBankCapabilities". But SDL Core logs will show "Incorrect parameter from HMI" when the response contains any of this four parameters.
    -> needs to be investigated (the above behavior is against the requirements). Please bring up as a separate issue.
  8. In 10.2.3.1, it shows that the first parameter of "TTS.GetCapabilitites" is "capabilities". But I checked SDL Core code, and it expects "speechCapabilities".
    -> Guidelines need to be fixed

Parameter boundary do not align:

  1. Such is inherited from mobile_API.
    The expected behavior is that when app sends AddCommand with ParentID=0 -> HMI needs to add it to the top-level menu (like "options" in html5_hmi)
  2. Such is inherited from mobile_API.
  3. Such is inherited from mobile_API.
  4. Such is inherited from mobile_API.
  5. That is expected SDL behavior (see also mobile_API description).
    The background is: what should HMI display if neither text nor image are provided for a softButton?
    If softButtons struct is included - it must contain reasonable values. If softButtons are not expected - the struct might be just omitted.

@justinjdickow
Copy link
Contributor Author

These will have to be fixed now that we have a documentation system in place that can support hmi requirements for releases as well as develop branches

@AnastasiyaBritanova
Copy link

AnastasiyaBritanova commented Jun 17, 2016

Guidelines will be planned for updates by p. 1, 2, 6, 8 from "inconsistencies" portion above.

@justinjdickow
Copy link
Contributor Author

Closing in favor of the above reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants