Update SDLTouch to handle NSNull occurence

[kshala-ford]

Fixes #1534

This PR is ready for review.

Risk

This PR makes no API changes.

Testing Plan

• I have verified that I have not introduced new warnings in this PR (or explain why below)
• I have run the unit tests with this PR
• I have tested this PR against Core and verified behavior (if applicable, if not applicable, explain why below).

Unit Tests

Running all existing unit tests validating no existing test fails. Adding new tests resulted into assertion crashes therefore checking that this PR doesn't harm any valid touch event json was the testing focus.

Core Tests

Tested against
Core version: 4.2 Ford
HMI name: SYNC 3.0 (MY18) which can cause the issue of sending "null" for timestamps.

Test steps on affected IVI:

1. Connect nav app to SYNC3
2. Activate nav app
3. Move nav app map somewhere
4. Confirm SYNC3 did send "null" in the touch event
5. check that app logs show "null" being replaced with phone clock
6. Confirm that nav app map moves

Test steps on functional IVI:

1. Connect nav app to SYNC3
2. Activate nav app
3. Move nav app map somewhere
4. Confirm SYNC3 did send timestamps in the touch event
5. check that app logs show the timestamps
6. Confirm that nav app map moves

Summary

The changes are very small. Basically the change is to read the "timeStamp" param from the TouchEvent struct. Now with the new type checking, the param may return nil instead of whatever the head unit sent (previously it might have been [NSNull]).

The issue of wrong JSON data is already known. This PR replaces an old and outdated workaround with a new workaround.

Bug Fixes

• Fixes the issue that touch input is not computed properly.

CLA

• I have signed the CLA

[joeljfischer]

Hi @kshala-ford, can you please fill out the "Testing Plan" section with the results of your running the unit tests and the Core tests / warnings, in addition to the sections that you deleted about what you tested against? Thanks!

[kshala-ford]

@joeljfischer Sorry, I missed this. Please check the edit of the description.

[joeljfischer]

Is it still possible for it to not be an NSArray?

[kshala-ford]

That was the reason I used id to be sure if we ever change the store extension of the NSDictionary... but it's not needed especially as you suggest timestamp to be type specific.

[kshala-ford]

@joeljfischer I added a condition if timestamps.count == 0. I left the check if timestamps is kind of an array to be absolutely sure otherwise calling count could lead to crash if it's not an array. As long as the NSDictionary+store extension doesn't change again this check is never false though so I am also OK to remove it if you want.

[joeljfischer]

I think I'd still like it removed, because it can never be false. I'd rather have the explicit fail than an implicit one if we ever changed that method, though I don't think we'll be changing it anytime soon.

[kshala-ford]

@joeljfischer I agree. thanks for the suggestion.

[joeljfischer]

Sorry, I missed one last thing. I've tested and will approve after this.