[WIP] Application Launching (SDL 4.0)

[joeljfischer]

💥 Not Ready to Merge 💥

Summary

This PR will involve several pieces to allow an iOS application to track available applications on the users phone that can be launched with SmartDeviceLink. This will involve 4 major pieces.

1. Head Unit tracking of the foregrounded application on a user's phone.
2. Head Unit requested querying of a server URL to retrieve a list of applications that are SDL compatible.
3. Parsing the response from the server, and determining which apps installed on the user's phone can be launched, and sending the filtered response to the HU.
4. Responding to a request from the HU to launch a specific app, and launching it.

In Depth

Tracking Foregrounded Application

The SDL Proxy object, upon opening a connection, will poll the application for its state, and send that across. It will also immediately set up observers on application state changes. Upon firing of those observers, it will recheck the application for its state, and push a new notification to the HU.

This PR also introduces the ability to send notifications from the Mobile API (issue #34). This is required because application state changes are sent via a pre-existing RPC Notification that was previously only sent from the HU, onHMIStatus. FULL is equivalent to foreground, LIMITED is equivalent to background.

Query Apps Server HTTP Request

The HU will request, via a OnSystemRequest, that the mobile device retrieve an application list from the server. The application may (this has not yet been determined) cache the response for a specified period.

Query Apps Filter Installed Applications

The server will respond with a set response, described here which will be parsed by the library. The library will then run a system call to determine which apps are installed on the phone. The library will then filter the list passed by the server so that only installed apps are represented, and forward it on to the HU.

Launch App

The HU will send an OnSystemRequest with a URL field that contains the URL scheme of the app they wish to launch to the foregrounded application. The library running in that application will then attempt to launch the application specified by the url scheme passed in. This will, of course, foreground that application, and background the application making the call.

TODO

General

• Make sure the proxy can handle being at v4
• Refactor SDLRPCNotification, SDLRPCMessage, etc., so that it sets it's messageType correctly. See PR Feature/2.3.1 #67 See If an SDLRPCMessage object is initialized using initWithName, the messageType is always set to "request" #64

Tracking Foreground State

• Track Application State
• Add the ability to send RPCNotifications (by sending any type of RPCMessage)
• Send an OnHMIStatus notification to connected HU when application state changes
• Remove app state observers when session closes
• Properly log and handle errors

Query Apps Server HTTP Request

• Create new SystemRequest enum type for Query Apps
• Capture OnSystemRequests for Query Apps and Launch App commands
• Make a query apps web call to the server specified in the OnSystemRequest to retrieve a list of URLs
• Parse the response from the server, determine applications to be checked
• Properly log and handle errors
• Determine if NSURLSessionUploadTask should be NSURLSessionDataTask

Query App Filter Installed Applications

• Test each application to see if it's installed on the phone
• Filter the response from the server based on which apps are installed on the phone
• Send the filtered response to the Head Unit
• Properly log and handle errors

Launch App

• Create new SystemRequest enum type for Launch App
• Parse a Launch App OnSystemRequest
• Open the specified application from a Launch App OnSystemRequest
• Properly log and handle errors

Other

• Test changes to query apps did not adversely affect Policy Server requests
• Refactor into new develop project layout

[joeljfischer]

This was originally #33, which was mistakenly merged (and was reverted).

[justinjdickow]

Core is not successfully parsing the onHMIStatus notification because the audioStreamingState and systemContext are not set and they are required parameters.

When I add

    HMIStatusRPC.audioStreamingState = [SDLAudioStreamingState NOT_AUDIBLE];
    HMIStatusRPC.systemContext = [SDLSystemContext MAIN];

to sendMobileHMIState, core successfully parses the notification.

The other issue we've found is that core and iOS both have a checks for protocol v4

if (_version >= 4) {

and

if (ProtocolVersion::kV4 == app->protocol_version()) {

it seems like both are sending v2, so the QUERY_APPS never happens in the current implementation :(

[justinjdickow]

Add

[[NSNotificationCenter defaultCenter] removeObserver:self];

to -SDLProxy:destructObjects

[joeljfischer]

Closed in favor of #99