ConnectSDK / Connect-SDK-iOS

iOS source project for Connect SDK

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Compatibility-breaking improvements

eunikolsky opened this issue · comments

Here's a list of improvements in the SDK that would break backward source compatibility:

0 Remove all deprecated APIs.

1 Prefix all the SDK's identifiers. According to an Apple's recommendation, third-party frameworks should use 3+ letter prefixes. Examples: CNT, CCT, CNNT, CNCT.

2 Unmake DiscoveryManager as a singleton. – I cannot see a compelling reason why it should be a singleton.

3 DiscoveryProviderDelegate – method names are misleading:

- (void) discoveryProvider:(DiscoveryProvider *)provider didFindService:(ServiceDescription *)description;
- (void) discoveryProvider:(DiscoveryProvider *)provider didLoseService:(ServiceDescription *)description;

They should be:

- (void) discoveryProvider:(DiscoveryProvider *)provider didFindServiceWithDescription:(ServiceDescription *)description;
- (void) discoveryProvider:(DiscoveryProvider *)provider didLoseServiceWithDescription:(ServiceDescription *)description;

4 A number of protocol methods are not Objective-C-ish. E.g.:

  • ConnectableDeviceDelegate:
    1. -connectableDeviceDisconnected:withError: => -connectableDeviceDidDisconnect:withError:;
    2. -connectableDevice:capabilitiesAdded:removed: => -connectableDevice:didAddCapabilities:didRemoveCapabilities:?;
    3. -connectableDevice:connectionFailedWithError: => -connectableDevice:connectionDidFailWithError:.
    4. etc.
  • etc. to be appended

5 Get rid of

// @cond INTERNAL// @endcond

blocks in headers. I'm not sure what they are for. Most likely, they should be moved to private headers.

6 MediaControl protocol: remove the @optional keyword. I have no idea why it is there, making half of it optional, whereas no other capability has that. DONE

7 WebOSTVServiceSocketClientDelegate: socketWillRegister: is a misleading name as we figured out and should be renamed. See TODO

8 MediaControl: getMediaMetaDataWithSuccess: and subscribeMediaInfoWithSuccess: methods provide the same information, but one is MediaMetaData and another is MediaInfo. One of them should be renamed to provide consistency.

9 DeviceService: capabilities is an array currently. However, I don't see a reason why it should be an array, and not a set. Capabilities are not ordered, so it makes sense to use NSSet instead.

Anyone: please feel free to add stuff and discuss it.

Existing issues:

  • ConnectableDevice: replace multiple capability getters with one method #127
  • TBD Capability interfaces are not very correct now. That is, we want to split a service class (e.g., DLNAService) into multiple classes, each one implementing its own capability (e.g., MediaPlayer and VolumeControl). However, current architecture forces us to still have DLNAService implementing every supported capability, even though the only method used is a getter (-mediaPlayer and -volumeControl) returning the corresponding capability class and all the other method should just redirect messages to that class.
    Suggestion: move all these getters into one (?) protocol. BTW, ConnectableDevice currently implements all those getters w/o any protocol.
    TODO: check how this plays with ConnectableDevice: replace multiple capability getters with one method
  • TBD MediaControl and PlaylistControl protocols should only be available once a media has started, but currently it's possible to retrieve them via devices and services.
  • TBD ConnectableDevice has the isConnectable property, which is YES for all the current services, because every one does something in the connect method. I think there is no use of this property.
  • TBDHuge change: use higher-level promises/futures/signals/etc. instead of callbacks (aka, CPS) for our public interfaces. We would get rid of two parameters in almost every capability function and make them more composable.
  • TBD As a Connect SDK user, I want to subscribe to play state events without playing a media so that I can synchronize media playing between devices/apps.

Currently, -subscribePlayState is defined in MediaControl, which should only be available when a media is playing and can be controlled (it's not the case now, see #153 (comment)). => So we can move -getPlayState and -subscribePlayState to MediaPlayer. The question is how a subscribed user will get a MediaControl object to control?

10 Fix capitalization: ZeroConfDiscoveryProvider => ZeroconfDiscoveryProvider and PlayListControl => PlaylistControl.

11 Everything should be NS_ASSUME_NONNULL_* by default, and nullable values should be explicitly marked.

12 MediaInfo and ImageInfo require some parameters to be set. Current implementation silently returns nil in the default -init method (which is at least surprising). A better solution would be to throw an exception with a clear explanatory message. Or something like this: http://cocoa.tumblr.com/post/117719761353/nullability-and-inherited-initializers-in-objective-c

13 Use a real MIMEType class instead of a generic string, so we could validate it in one place.

14 Make the capability strings values identical to the Android version. And the values should be hidden in implementation files, like it's done for kMediaPlayerSubtitleSRT.

15 Hide all unnecessary public headers. See #152 (comment).