Feature/2.3.1

[Mike-FoMoCo]

I've included the 2.3.1 release notes below:

Updates from AppLink 2.3 to 2.3.1 (iOS)

Changes / Enhancements – iOS

• Unregister method for transport (allows the transport to be called sooner increasing speed)
• Prevent unrelated accessories from causing a disconnect
• Better background connection on Gen1 head units.
• Better Multi-App experience on Gen1.1 head units

Fixed Issues – iOS

• Fixed “notifications weren’t setting their message type” bug.
• Fix for infinite loop when disconnected while waiting for connection. Call up one
  level higher so we re-perform the search to see what external accessories are
  connected.
• Changed the SDLProtocol to recursively call the processMessages method in
  the event that more than 1 message is in the buffer at once.

Note:

• Developers should NOT retain a reference to the protocol/transport objects within your app. (SDLIAPTransport, SDLAppLinkProtocol) Doing so may cause connectivity issues.

Edit (Joel): Changed Ford names to SDL ones

[justinjdickow]

@Mike-FoMoCo What are the changes for 2.3.1?

[Mike-FoMoCo]

(Joel) I moved this comment into the header

[joeljfischer]

All NSNotificationCenter observations can be removed from an observer by calling [[NSNotificationCenter defaultCenter] removeObserver:self], which will clean up a few lines of code and make sure you don't miss removing any observations at dealloc time.

[joeljfischer]

I would like for these to be addressed. In addition to these, the fact that this PR makes api removals means that this is a major version change, so the earliest this could be merged is 4.0. Before it is merged, it would also need to be rebased on develop and squashed.

[Heath-FoMoCo]

@joeljfischer Which APIs changed for this pull request? I am a bit confused; can you get more specific?

[joeljfischer]

Sure. This is the list I got.

SemVer major version changes:

• SDLAbstractProtocol public protocol conformance changed
• SDLAbstractProtocol method [sendEndSessionWithType:sessionID:] became [sendEndSessionWithType:]
• SDLProtocol method [sendEndSessionWithType:sessionID:] became [sendEndSessionWithType:]
• SDLProtocol method [handleBytesFromTransport] removed
• SDLProxy iVar rpcSessionID removed
• SDLProxy iVar bulkSessionID removed
• SDLProxy property protocol type changed
• SDLProxy method [initWithTransport:protocol:delegate:] input variable type changed
• SDLProxy method [getProtocol] removed
• SDLProxy method [putFileStream::] removed (was deprecated)

SemVer Minor version changes

• SDLRPCNotification [init] methods added
• SDLTransport [unregister] method added

[Heath-FoMoCo]

Thanks. We are reviewing these changes.

[jacobkeeler]

Some things to note about this fix:

1. The incorrectly set messageType issue does not just affect Notifications, but Responses as well
2. Unfortunately, what you currently have will not quite fix the issue. The reason for this is that while the messageType variable will be set correctly, this value is used in creating the internal dictionary, and thus the dictionary will be improperly structured.

-(id) initWithName:(NSString*) name {
    if (self = [super init]) {
        function = [[NSMutableDictionary alloc] initWithCapacity:3];
        parameters = [[NSMutableDictionary alloc] init];
        messageType = NAMES_request;
        [store setObject:function forKey:messageType];
        [function setObject:parameters forKey:NAMES_parameters];
        [function setObject:name forKey:NAMES_operation_name];
    }
    return self;
}

As you can see, the messageType is used as a key in the dictionary, and this key-value pair is set while the messageType is still "request".

messageType = NAMES_request;
[store setObject:function forKey:messageType];

The simplest way to fix this issue would be to remove these two lines from [SDLRPCMessage initWithDictionary] and add them to the override of initWithDictionary in SDLRPCNotification, SDLRPCResponse, SDLRPCRequest, replacing names_request with names_notification, names_response, and names_request respectively.

[joeljfischer]

Note that #71 could alleviate the issue of API changes that we are facing. Looking for feedback regarding that proposal.

[joeljfischer]

Closed in favor of #91