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

Implement SDL-0243 Manager Update for Display Capability #1390

Conversation

kshala-ford
Copy link
Contributor

@kshala-ford kshala-ford commented Aug 29, 2019

Fixes #1386

This PR is ready for review.

Risk

This PR makes minor API changes.

Testing Plan

Extend unit tests to confirm display capability/capabilities conversion is as expected.

Summary

This PR changes SystemCapabilityManager according to SDL-0243 to make new capabilities available and also convert DisplayCapability and DisplayCapabilities objects.

Changelog

Existing SystemCapabilityTypes are marked as deprecated hence will appear as deprecated if apps are using them.

Enhancements
  • Adds new capability to the manager
  • Adds conversion of display capability objects for developer's convenience

Tasks Remaining:

CLA

…getter. Fixed bool vs. NSNumber condition. Fixed first time display backwards conversion. Fixed etst error in file manager toBeCloseTo was within 0.001 now is 0.01. Fixed a bug in menu manager test using wrong response notification name.
@kshala-ford kshala-ford changed the title [WIP] Implement SDL-0243 Manager Update for Display Capability Implement SDL-0243 Manager Update for Display Capability Aug 29, 2019
@kshala-ford
Copy link
Contributor Author

@joeljfischer the proposal is implemented and pretty much ready for review. Awaiting merge of #1350 so that I can pull latest develop and mark review ready

@joeljfischer joeljfischer added this to In progress in v6.4 via automation Aug 30, 2019
@joeljfischer joeljfischer added enhancement proposal Accepted SDL Evolution Proposal labels Aug 30, 2019
@joeljfischer joeljfischer added this to the 6.4.0 milestone Aug 30, 2019
@kshala-ford
Copy link
Contributor Author

@joeljfischer I just merged the latest develop into my branch and fixed some merge conflicts. The PR is now ready for review.

@joeljfischer joeljfischer self-requested a review September 4, 2019 14:28
Copy link
Contributor

@joeljfischer joeljfischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that portions of this PR are missing, and tests do not build and have numerous warnings.

SmartDeviceLink/SDLSystemCapability.m Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapability.m Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapabilityManager.h Show resolved Hide resolved
v6.4 automation moved this from In progress to Review in progress Sep 4, 2019
…issue_1386_manager_update_display_capability

# Conflicts:
#	SmartDeviceLink/SDLSystemCapability.h
#	SmartDeviceLink/SDLSystemCapability.m
@kshala-ford
Copy link
Contributor Author

@joeljfischer Sorry... Something went wrong with merging develop. The conflicts were not resolved correctly and I accidentally deleted some code like the windowCapabilityForWindowID... The PR should now be correct and up-to-date (merged latest develop again).

Copy link
Contributor

@joeljfischer joeljfischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly minor stuff

SmartDeviceLink/SDLSystemCapability.h Outdated Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapability.m Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapabilityManager.h Outdated Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapabilityManager.h Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapabilityManager.h Outdated Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapabilityManager.m Outdated Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapabilityManager.m Show resolved Hide resolved
SmartDeviceLinkTests/DevAPISpecs/SDLFileManagerSpec.m Outdated Show resolved Hide resolved
kshala-ford and others added 2 commits September 9, 2019 16:44
Co-Authored-By: Joel Fischer <joeljfischer@gmail.com>
…ions. Renamed convert flag. Created window and display capability group. Changed media clock to empty array. Changed repeat test to unique data. Other minor suggestions applied.
Copy link
Contributor

@joeljfischer joeljfischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally, sdl_systemCapabilityTypes needs to be updated with DISPLAYS in order for subscriptions to work properly.

if (!response.success.boolValue) { return; }

self.displays = [self sdl_createDisplayCapabilityListFromSetDisplayLayoutResponse:response];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's kind of odd that we'd be overwriting the displays information and then immediately overwriting it again with the OnSystemCapabilityUpdated information. IMO, this backward compatibility shouldn't occur if we're connected to a head unit that supports OnSystemCapabilityUpdated for display information.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be conflicting to what was accepted with the proposal:

If the application is connected to a < 6.0 or if the head unit did not provide DisplayCapability or WindowCapability for the DEFAULT_WINDOW yet, the system capability manager should convert DisplayCapabilities, ButtonCapabilities, SoftButtonCapabilities and PresetBankCapabilities objects and the string of displayName from RegisterAppInterfaceResponse and SetDisplayLayoutResponse into a new DisplayCapability object. This object should be stored in the DISPLAYS enum value.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I need to clarify. I mean that if you're connected to a 6.0+ head unit, then the displays data should not be overwritten by the deprecated data. On a < 6.0 head unit, as you quote, then it should pull the deprecated data. Currently, the code overwrites the OnSystemCapabilityUpdated.displayCapability data with the deprecated SetDisplayLayoutResponse data.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the application is connected to a < 6.0 or if the head unit did not provide DisplayCapability or WindowCapability for the DEFAULT_WINDOW yet

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should work

@BrettyWhite
Copy link
Contributor

@kshala-ford Please also ensure the sub-managers are updated to use the new capabilities in this PR, similar to what i mentioned in the JavaSuite equivalent. Thank you

@kshala-ford
Copy link
Contributor Author

@joeljfischer I made a bunch of changes so that the new capability type is used instead of deprecated.

Copy link
Contributor

@joeljfischer joeljfischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly small stuff. The one that still concerns me the most is ensuring that updates are not sent on 6.0+ system when we've already received an update.

if (highestFound == 4) { break; }
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in 8fac298

SmartDeviceLink/SDLScreenManager.m Show resolved Hide resolved
SmartDeviceLink/SDLSystemCapabilityManager.m Show resolved Hide resolved

// call the observers in case the new display capability list is created from deprecated types
SDLSystemCapability *systemCapability = [[SDLSystemCapability alloc] initWithDisplayCapabilities:self.displays];
[self sdl_callSaveHandlerForCapability:systemCapability andReturnWithValue:YES handler:nil];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't appear to be the same as the agreed upon implementation. This shouldn't call the observers when a SetDisplayLayoutResponse is recorded unless we're on a < 6.0 system or no displayCapability has been provided through the notification. This is just always calling the observers.

return convertedCapabilities;
}

- (void)sdl_updateDeprecatedDisplayCapabilities {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be very helpful if you could add documentation comments to new private methods here. I keep forgetting what methods do exactly and have to re-read the code to figure it out.

SDLDisplayCapability *newDefaultDisplayCapabilities = newCapabilities.firstObject;
NSArray<SDLWindowCapability *> *newWindowCapabilities = newDefaultDisplayCapabilities.windowCapabilities;

for (SDLWindowCapability *newWindow in newWindowCapabilities) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a comment or two to this for loop to describe what's going on here for future reference

Copy link
Contributor

@joeljfischer joeljfischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few more important issues after testing against Core 6.0 in-progress.

@@ -65,8 +66,7 @@ - (instancetype)initWithConnectionManager:(id<SDLConnectionManagerType>)connecti
_transactionQueue = [self sdl_newTransactionQueue];
_batchQueue = [NSMutableArray array];

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(sdl_registerResponse:) name:SDLDidReceiveRegisterAppInterfaceResponse object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(sdl_displayLayoutResponse:) name:SDLDidReceiveSetDisplayLayoutResponse object:nil];
[_systemCapabilityManager subscribeToCapabilityType:SDLSystemCapabilityTypeDisplays withObserver:self selector:@selector(sdl_displayCapabilityUpdate:)];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This always fails because the SystemCapabilityManager.isStreamingSupported check in SystemCapabilityManager.subscribeToCapabilityType fails. Two solutions I can think of:

  1. This check always succeeds if checking DISPLAYS
  2. This check is removed entirely

I think I lean toward (1) right now. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is implemented as:

    [_systemCapabilityManager subscribeToCapabilityType:SDLSystemCapabilityTypeDisplays withObserver:self selector:@selector(sdl_displayCapabilityUpdate:)];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(sdl_hmiStatusNotification:) name:SDLDidChangeHMIStatusNotification object:nil];


- (void)sdl_displayCapabilityUpdate:(SDLSystemCapability *)systemCapability {
// we won't use the object in the parameter but the convenience method of the system capability manager
self.defaultMainWindowCapability = _systemCapabilityManager.defaultMainWindowCapability;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's a reason to use the getter from the systemCapabilityManager, the systemCapability that's passed should be equivalent because the handler here is only called after the merge finishes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in 89d623d
though funny it looks

…issue_1386_manager_update_display_capability

# Conflicts resolved:
#	SmartDeviceLink/SDLSystemCapabilityManager.m
#	SmartDeviceLinkTests/DevAPISpecs/SDLFileManagerSpec.m
#	SmartDeviceLinkTests/DevAPISpecs/SDLMenuManagerSpec.m
@theresalech
Copy link
Contributor

@kshala-ford @yLeonid can you please confirm if this PR should be closed in favor of #1419?

@yLeonid
Copy link
Contributor

yLeonid commented Sep 30, 2019

@theresalech #1419 contains all changes from this branch and also it has newer commits. So yes I confirm this PR can be closed

v6.4 automation moved this from Review in progress to Done Sep 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Accepted SDL Evolution Proposal
Projects
No open projects
v6.4
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

5 participants