Ich benutze das Mutlipeer Connectivity Framework zum ersten Mal und möchte programmatische (nicht mit den assistant Klassen) Kontrolle.
Alles funktioniert genau so, wie ich es beschrieben habe, wenn ich meinen Code auf zwei verschiedenen Geräten abspiele, bis der Werbetreibende den Delegierten-Callback erhält:
Der Delegat-Callback des Browser-Clients wird aufgerufen, wenn er den Werbetreibenden entdeckt:
%Vor%}
Dann wird der Callback für den Delegierten des Werbekunden aufgerufen, wenn er die Einladung erhält:
%Vor%Nachdem 'invitationHandler (YES, _session)' aufgerufen wurde, scheint die Verbindung zwischen dem 'Browsing'-Client und dem' Advertising'-Client nie hergestellt worden zu sein.
Ich erhalte nie irgendwelche Delegatenrückrufe (ein- oder zweimal, die ich einen MCSessionStateNotConnected erhielt) auf den MCSession-Objekten auf jedem Clientgerät. Ich hätte gedacht, dass ich den MCSession-Delegierten-Rückruf erhalten hätte:
%Vor%Vermisse ich etwas? Ist jemand anderes auf dieses Problem gestoßen?
Es gibt einen Fehler, den Apple offensichtlich bemerkt.
Dies führte zur Entdeckung: Warum trennt mein MCSession-Peer zufällig ab? ?
Sie müssen den folgenden Delegat-Rückruf implementieren, obwohl er in den Dokumenten als optional aufgeführt ist ...
%Vor%Die Delegate-Methode "didReceiveCertificate" ist optional, und wenn Sie sie nicht implementieren, nimmt das Framework an, dass Sie das Zertifikat akzeptieren (beachten Sie, dass das Zertifikat null sein kann).
Wenn Sie jedoch die Methode implementieren und sie dann leer lassen, stellt der Peer keine Verbindung her, da das Framework erwartet, dass Sie den certificateHandler entweder mit YES oder NO aufrufen.
Ich habe ähnliche Probleme gehabt. Es scheint jedoch, dass, wenn ich meine App auf einem iOS-Gerät ausgeführt und verbunden, dann beenden und neu starten (sagen wir, wenn ich von Xcode erneut ausführen), dann bin ich in einer Situation, in der ich eine Connected-Nachricht und dann eine nicht verbundene Nachricht etwas später. Das hat mich abgeworfen. Aber wenn ich genauer hinschaue, kann ich sehen, dass die Nachricht "Nicht verbunden" eigentlich für eine andere Peer-ID gedacht ist als die, die verbunden ist.
Ich denke, das Problem hier ist, dass die meisten Beispiele, die ich gesehen habe, sich nur um den displayName der peerID kümmern, und vernachlässigen die Tatsache, dass Sie mehrere peerIDs für das gleiche Gerät / displayName erhalten können.
Ich prüfe jetzt zuerst den displayName und überprüfe dann, ob die peerID die gleiche ist, indem ich einen Vergleich der Zeiger tue.
%Vor%Ein weiteres Problem, das ich gefunden habe (auch in anderen Beispielcodes, d. h. PeerKit), ist, dass stopAdvertisingPeer direkt nach invitationHandler (YES) wahrscheinlich falsch ist. Da Sie selbst eine Einladung annehmen, gibt es keine Garantie, dass Sie verbunden sind. Ich denke, es ist besser, AdvertisingPeer nur zu stoppen, wenn verbunden ist.
Tags und Links objective-c ios delegates multipeer-connectivity