iOS Multipeer connectivity framework invitationHandler doesn't seem to accept?

Question

I\'m using the mutlipeer connectivity framework for the first time, and I want programmatic ( not with the assistant classes) control.

Everything is working exactly

Answer 1

I've been having similar problems. It seems though that if I have run my app on one iOS device, and connected to another, then quit and relaunch (say when I rerun from Xcode), then I am in a situation where I get a Connected message and then a Not Connected message a little later. This was throwing me off. But looking more carefully, I can see that the Not Connected message is actually meant for a different peerId than the one that has connected.

I think the problem here is that most samples I've seen just care about the displayName of the peerID, and neglect the fact that you can get multiple peerIDs for the same device/displayName.

I am now checking the displayName first and then verifying that the peerID is the same, by doing a compare of the pointers.

- (void)session:(MCSession *)session peer:(MCPeerID *)peerID didChangeState:(MCSessionState)state {

    MyPlayer *player = _players[peerID.displayName];

    if ((state == MCSessionStateNotConnected) &&
        (peerID != player.peerID)) {
        NSLog(@"remnant connection drop");
        return; // note that I don't care if player is nil, since I don't want to
                // add a dictionary object for a Not Connecting peer.
    }
    if (player == nil) {
        player = [MyPlayer init];
        player.peerID = peerID;
        _players[peerID.displayName] = player;
    }
    player.state = state;

...

Answer 2

The "didReceiveCertificate" delegate method is optional and if you don't implement it, the framework will assume that you accept the certificate (note that certificate can be nil).

However, if you implement the method and then leave it empty, then, sure, the peer will not connect, because the framework will expect you to call the certificateHandler with either a YES or NO.

Answer 3

There is a bug that Apple is aware of apparently.

This is what led to the discovery: Why does my MCSession peer disconnect randomly?

You must implement the following delegate callback even though it is listed as optional in the docs...

- (void) session:(MCSession *)session didReceiveCertificate:(NSArray *)certificate fromPeer:(MCPeerID *)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler
{
 certificateHandler(YES);
}

Answer 4

Another problem I found (also in other sample codes, i.e PeerKit) is that stopAdvertisingPeer right after invitationHandler(YES) is probably wrong. Because even you accept invitation there is no guarantee you will be connected. I think it is better to stopAdvertisingPeer only when is connected.