EASession, EAAccessoryDelegate und "ERROR - Öffnungssitzung fehlgeschlagen"

Question

Ich arbeite mit External Accessory Framework. Ich habe Probleme mit der Wiederherstellung von EASession nach App geht in den Hintergrund und kehrt dann in den Vordergrund. Wenn ich meine App kündige und neu starte, wird die Bluetooth-Verbindung wie erwartet wieder hergestellt. Ich vermute, dass es einen Teil des Teardowns gibt, den ich vermisse - oder der nicht ausgesetzt ist (??).

[EAAccessoryManager sharedAccessoryManager] connectedAccessories]] gibt mein verbundenes Zubehör zurück, und ich kann es abfragen, um Name, Modellnummer usw. zu erhalten. Die folgende Zeile setzt _session jedoch auf null.

_session = [[EASession alloc] initWithAccessory:_accessory forProtocol:_protocolString]; 

Gibt es eine Möglichkeit, den Grund für fehlgeschlagene EASession-Initialisierung zu diagnostizieren?

Gibt es ein Mantra, alte EASession zu löschen?

Diese Frage bezieht sich auf this eine - aber ich frage nicht um Rat auf welchem ​​Weg zu folgen. Ich frage mich, warum dieser Pfad eine große Fallstricke hat und wie man ihn umgehen kann.

Answer 1

Ich habe festgestellt (in der Post iOS4.1 Welt), dass das Verlassen der App (Hintergrund oder Beenden) eine DidDisconnectNotification auslöst. Im Fall, dass Sie nur den Netzschalter drücken oder das Gerät schlafen lassen; Wir sehen nicht, dass die Verbindung nach unten geht.

Jetzt, wenn das BT-Gerät außer Reichweite geht oder sich selbst schlafen geht. Dann wird die Verbindung unterbrochen.

Als Ergebnis sind wir nicht mehr auf etwas anderes als die ConnectionNotifications angewiesen. Wir vertrauen nicht einmal der [[EAAccessoryManager sharedAccessoryManager] connectedAccessories] Liste, weil wir herausgefunden haben, dass es manchmal "Ghost-Zubehör" enthält, die sagen, dass sie verbunden sind und über Streams verfügen, mit denen Sie verfügbare Ereignisse schreiben können, selbst nachdem das gesamte Bluetooth-System verschwunden ist down (BT-Symbol aus)

ConnectionNotifications werden zwischengespeichert, wenn Sie sich im Hintergrund befinden. Daher sollten Sie einen neuen Status erhalten, wenn Sie die App erneut eingeben.

Natürlich beim ersten Einstieg; Sie möchten sicherstellen, dass Sie alle Ihre Listener (usw.) ordnungsgemäß eingerichtet haben.

Answer 2

Soweit ich das beurteilen kann, gibt es keine Löschung von alten EASession-Instanzen. Ich kann hypothetisieren, aber ich weiß nicht wirklich, warum das so ist. Ich vermute, dass die etablierte EASession ihre Assoziation mit ihrem Accessory nicht freigibt - und das verhindert, dass nachfolgende EASession-Instanzen erfolgreich mit dem gleichen Accessoire verbunden werden.

Ich entschied mich, EASession in Takt zu verlassen, wenn App aktiv zurücktritt. Das scheint zu funktionieren. Beim Testen habe ich mich mit dem Bluetooth-Zubehör verbunden, meine App gestartet, auf Zubehör zugegriffen, meine App in den Hintergrund geschickt, das BT-Zubehör getrennt/wiederverbunden, die App in den Vordergrund gebracht und wieder auf Zubehör zugreifen können. Das ist so viel, wie ich hoffen könnte.

Ein Vorbehalt: Mit iOS 4.0 ist es möglich, mehr als ein Zubehörteil zu haben. Zum Beispiel sind ein Videokabel und ein Bluetooth-Gerät beide Zubehör.

Answer 3

Ich war das gleiche Problem hebend. In meinem Fall hat das Sitzungsobjekt unmittelbar nach der Erstellung retainCount = 3, sodass ein Aufruf [Sitzungsfreigabe] beim Empfang von DidDisconnectNotification nicht ausreichend war. Stellen Sie sicher, dass Sie das Sitzungsobjekt nach Erhalt der DidDisconnectNotification-Benachrichtigung wirklich freigegeben haben.

Answer 4

Ich hatte das gleiche Problem und löste es mit einem kleinen Trick. Ich habe die Seriennummer des Zubehörs beim Öffnen einer Sitzung protokolliert und beim Schließen einer Sitzung protokolliert.

So sah ich einige Sitzungen waren nicht geschlossen. Wenn meine App in den Hintergrundmodus wechselt, schließe ich definitiv alle geöffneten Sitzungen nach Gerät.

-(void) closeSessionForDevice:(EAAccessory*) device{ 
EASession *lclSession = (EASession*) [sessionDictionary valueForKey:[device serialNumber]]; 
[[lclSession inputStream] close]; 
[[lclSession inputStream] removeFromRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; 
[[lclSession inputStream] setDelegate:nil]; 

[[lclSession outputStream] close]; 
[[lclSession outputStream] removeFromRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; 
[[lclSession outputStream] setDelegate:nil]; 

lclSession = nil; 

NSLog(@"Session Closed for : %@", [device serialNumber]); 

[device setDelegate:nil]; 
} 

Ich hoffe, es hilft jemand anderem.

Answer 5

Ich hatte das gleiche Problem. Ich entwickelte eine Anwendung, um ein externes Bluetooth-Zubehör in einem bestimmten Intervall zu öffnen, einige Daten zu lesen und dann die Streams zu schließen. Das hatte einige Tage gut funktioniert, dann eines Tages hörte es auf, mit genau diesem Problem zu arbeiten. Eine Nachricht wurde auch in der Konsole protokolliert.

2015-06-20 23:54:43.371 MyApp[2083:404019] ERROR - opening session failed 
1 2015-06-20 23:54:43.371 MyApp[2083:404019] ERROR - /SourceCache/ExternalAccessory/ExternalAccessory-288.20.7/  EASession.m:-[EASession dealloc] - 141 unable to close session for _accessory=0x174018750 and sessionID=65536 

Die Apple-Dokumentation ist klar, nur eine Instanz jedes Protokoll darf zur gleichen Zeit geöffnet sind und keine vorherige Instanz wird automatisch freigegeben. Aber warum hat iOS plötzlich die vorherige EASession nicht freigegeben, obwohl sie tagelang gut funktioniert hatte?

Ich war perplex und ich verbrachte drei Tage meinen Kopf gegen die Wand schlagen. Ich habe Google durchsucht und bin hier gelandet. Ich habe die Anleitungen von Apple zur Kommunikation mit externem Zubehör und dem NSStream-Programmierhandbuch gelesen. Der Code war alles korrekt.

Endlich am dritten Tag hörte ich einen Piepton aus der Ecke meines Schreibtisches, mein Android-Handy hatte keinen Saft mehr. Eine Glühbirne ging in meinem Kopf aus. Ich habe das Telefon ausgeschaltet und Viola, das Problem auf dem iOS-Gerät ging weg.

Das ist wirklich ein RF-Problem, kein Programmierproblem, aber ich schließe meine Geschichte hier ein, wenn jemand anderes auf dieses Problem eingeht, wird Google Sie hierher bringen. Schalten Sie alle anderen Bluetooth-Geräte in der Nähe aus, da sie Lärmquellen sind und zu diesem Problem führen können.