Implementing an app with automatic connection between devices to exchange small bunch of data, using Multi-peer Connectivity framework and Nearby Services (both browser and advertiser).
I built a Session Manager handling all connections details. Its delegate is a View Controller in order to handle updates of UI when data are received.
The Session Manager builds:
- A Service Advertiser, the delegate being the Session Manager
- A Service Browser, the delegate being also the Session Manager
Launching the app on two devices (one under Xcode to get the logs, the other one stand alone), I receive a Found Peer message through Service Browser delegate corresponding method.
As stated in another message, I compare the displayName property of MCPeerID (both local and from received Peer) to decide whichever of both will send invitation, thus avoiding cross-invitations.
As stated on another message here, I have also added the "optional" MCSession delegate method - (void)session:didReceiveCertificate:fromPeer:certificateHandler:
However, delegate method (void)advertiser:didReceiveInvitationFromPeer:withContext:invitationHandler: of MCNearbyServiceAdvertiser is never called. There is only a NotConnected message received by the MCSession delegate method (void)session:peer:didChangeState:after the timeout setup in the invitePeer:toSession:withContext:timeout:method.
In the various options proposed:
- Session is initialized with security nil and MCEncryptionNone;
- discoveryInfo are nil;
- context sent in the invitation is just a short string archived as NSData.
To troubleshoot:
- I have checked that all items were existing (session and its delegate, advertiser and its delegate).
- Service Browser and Advertiser are never stopped, as long as app is active.
I don't know where to look over now!
Make sure that the MCpeerID you use for your local peer is the same for both the discovery and invitation phases.
I had a structure with a separate session manager to the connect/transfer worker. I made the mistake of initialising a new MCpeerID in the worker to create a session prior to the invitation, resulting in the same behaviour.
Passing the MCpeerID and MCNearbyServiceBrowser to the worker to create the session and invite fixed the issue.