NSHTTPURLResponse, since in some cases it might not be. Such as if we're using a local (within-app) authentication url based on NSURLProtocol.
modifications to the nested arrays while they are being iterated over.
non-dictionary and non-valid JSON responses. Also need to make sure we set isAuthorized back to NO if there is an error.
specific error, just create an unknown error if we aren't authorised and don't have an error.
…nded while the channel is unsubscribed.
before continuing to the next spec. Also unsubscribe when we are done.
The previous target/action bindings were causing a retain cycle between the binding (target/action proxy) and the channel. By using blocks with weak references to the channel, the blocks act as weak proxies to the channel, and the retain cycle is broken.
This reverts commit 1b92f78.
This avoids the need to make another authorisation request when reconnecting to an existing channel.
auto reconnect hasn't been disabled in the meantime before actually proceeding with the connection.
All auth requests are specific to a connection as they use the socket ID returned from Pusher - once that socket ID has gone away, the auth operations can never be successful.
If we want to cancel an auth operation, even if that request has completed, we do not want to notify the delegate - we should just ignore the response. We should also check for cancellation right at the start of the operation before running the URL request.
We already check that we are connected before beginning the subscription process, but where that process is asynchronous and non-immediate, in the case of private/presence channels (because we have to run the authorisation operation first), we should check that we are still connected again before finalising the subscription process.
…gate that the connection is open. Track this internally using an enum to track state rather than a simple boolean flag. This reverts old the old behaviour where the socketID would be available within the didConnect delegate call. See #47.
Normally, we would always attempt to send an unsubscribe message but if we are disconnected, this will cause an assertion error. Because we always mark channels as unsubscribed when the connection closes, it isn't necessary to send an unsubscribe message in this state. Instead of attempting to send the unsubscribe (which causes the assertion error), simply return without doing anything. Closes #46.
type of disconnection. When SocketRocket's connection fails, we won't always receive the 'didDisconnect' connection delegate method - sometimes we will receive the 'didFail' method. If we get the 'didFail' method, we'll pass that on to the Pusher delegate whether we were already connected or not. If we were already connected, then now it will also call the 'didDisconnect' delegate method. I've updated the connection monitor sample to account for this new behaviour. This should also fix #48.
using a real socket means that the mock connection behaves more like a real connection, including calling its own delegate.
PTPusher much easier for end users.