SDL 0167 - App Services - Navigation Service

[jordynmackool]

Proposal: SDL 0167 - App Services - Navigation Service

SmartDeviceLink has always been limited to a 1 - 1 relationship between module and smartphone apps. However, to create truly compelling experiences this should be expanded. This proposal will aim to introduce a paradigm that allows apps to advertise a "service" they offer that the module and other apps can leverage. This allows users to augment their vehicle's IVI system with off-board solutions. This proposal also details how SDL apps can communicate with each other through the module.

smartdevicelink/sdl_evolution#591

Steering Committee Decision:

The Steering Committee voted to accept this proposal. There was additional discussion regarding lane guidance being included in this iteration of the proposal. It was concluded that with how complicated this App Service Type implementation is, it should be put on hold to be included. The author noted that a prompt string was added to the servicedata that could accomplish this in a non-structure manner, but still gets the point across; The author noted that a prompt string was added to the servicedata of the Navigation service that could accomplish this in a non-structured manner. Adding this string made it a little freer forming, as currently the implementation has a good base. Adding additional features in the future is always an option.

[NicoleYarroch]

Added in PR #1165

[jordynmackool]

Accepted and Noted Revisions as of 2019-03-06: smartdevicelink/sdl_evolution#675

• Fix various typos and unify naming conventions.
• Make AppServiceType a documentation item and change all uses of the AppServiceType to String. This will allow for support of future app services that core does not recognize.
• Add notes regarding system capability updates.
• Change serviceIcon type to Image.
• Change uriScheme to type String.
• Change handledRPCs type to Integer. Change is for similar reasons that appServiceType should be sent as a String. Also handledRPCs as an integer will allow for better integration with policies.
• Defined functionIDs for new RPCs.
• Remove servicesSupported from AppServicesCapabilities. The available serviceTypes can be found in the appServices parameter. appServices -> updatedAppServiceRecord -> serviceManifest -> serviceType.
• Remove configuration for supportedAppServices in the ini file. Proposal states that core should be able to handle future unknown service types with conflicts with defining service types in core’s static ini file.
• Define policy table structure.

[jordynmackool]

Implementation revision as of 2019.03.15:

• param name="weatherIconImageName" type="String" mandatory="false"/ toparam name="weatherIcon" type="Image" mandatory="false"/
• serviceData no longer mandatory in GetAppServiceDataResponse