Ich hatte meinen Code in einem anderen Projekt in einer Klasse mit der folgenden Signatur:
%Vor%Dann habe ich die Verbindung in die eigene Klasse verschoben, damit ich sie in jeder Verbindung wiederverwenden kann:
%Vor% Als ich das getan habe, habe ich den viewDidLoad() Code in init() verschoben. Ich habe auch versucht, den Code init in eine separate Funktion zu setzen und diese Funktion nach der Instanziierung der Klasse aufzurufen. Das hat nichts geändert.
Ich kann zwischen den beiden Projekten, dem alten und dem neuen, wechseln, nur um sicherzustellen, dass es sich nicht um ein Serverproblem handelt, und das bestätigt, dass dies nicht der Fall ist.
Nach jedem Durchlauf der Anwendung ist das Ergebnis anders. Es ruft entweder nicht das HasSpaceAvailable auf und sitzt nur dort, oder es gibt einen (lldb) Fehler, der auf Thread 1 in meiner Klasse class AppDelegate: UIResponder, UIApplicationDelegate, FBLoginViewDelegate geworfen wird. Dieser Fehler kann zwar mit der Facebook-Integration zusammenhängen, aber mit lldb gibt es nicht viel zu sehen. Bei jedem Durchlauf wird jedoch HasSpaceAvailable im Gegensatz zu dem anderen Projekt nie aufgerufen.
Hier ist der vollständige Code des NStreamDelegate, also gibt es keine Verwirrung. Diese Klasse ist eine ziemlich standardmäßige Verbindungsmethode, die das XMPP-Protokoll verwendet.
%Vor% Ich kann also zwei Dinge sehen, die das verursacht haben könnten. Entweder man verschiebt es in seine eigene Klasse und macht eine Instanz davon oder die Änderung der Vererbung. Wenn ich an die erste Möglichkeit denke, sehe ich mir die Threading-Zeilen des Codes an: self.input!.scheduleInRunLoop(NSRunLoop.currentRunLoop(), forMode: NSDefaultRunLoopMode)
Nach dem Überprüfen der streamStatus.toRaw() heißt es 1 was NSStreamStatusOpening ist. Ich bin mir nicht sicher, ob sich das jemals ändert.
Ich könnte das Problem reproduzieren, wenn XMPPConnection in einer lokalen Variable gespeichert ist,
z.B.
Die Zuordnung der Instanz wird aufgehoben, wenn diese Methode zurückgegeben wird. Auf der anderen Seite der Strom
Delegaten zeigen immer noch auf die Instanz, dies verursacht die Abstürze. Der Code%
Eigenschaft von delegate wird als
ist das Swift-Äquivalent von "assign" aka "unsafe_unreadyed". Deshalb
Durch das Festlegen des Delegaten wird das Objekt nicht beibehalten und die Zuweisung des Objekts aufgehoben
setzt die Eigenschaft nicht auf NSStream (wie bei schwachen Referenzen).
Wenn die Instanz in einer -Eigenschaft gespeichert ist , z. B.
%Vor%dann hat Ihr Code in meinem Test richtig funktioniert.