2010-12-09 4 views
7

Estoy trabajando con el marco de accesorios externos. Estoy teniendo problemas para restablecer EASession después de que la aplicación entre en el fondo y luego vuelva al primer plano. Si termino mi aplicación y reinicio, la conexión Bluetooth se restablece como era de esperar. Sospecho que hay una parte del desmontaje que me falta, o que no está expuesta (??).EASession, EAAccessoryDelegate y "ERROR - sesión de apertura fallida"

[EAAccessoryManager shared AccessoryManager] connectedAccessories]] devuelve mi accesorio conectado, y puedo consultarlo para obtener el nombre, modeloNúmero, etc. Sin embargo, la siguiente línea establece _session a nil.

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

¿Hay alguna forma de diagnosticar el motivo de la inicialización fallida de EASession?

¿Hay algún mantra para borrar la antigua EASession?

Esta pregunta está relacionada con this, pero no estoy pidiendo consejos sobre qué camino seguir. Me pregunto por qué este camino tiene esta gran trampa y cómo navegar a su alrededor.

+0

[EADemo] (http://developer.apple.com/library/ios/#samplecode/EADemo/Introduction/Intro.html) no se filtra ... ¿Por qué otros (yo incluido) ven EASession y EAAccessory? ¿fuga? – Sam

Respuesta

6

He encontrado (en el mundo de la publicación iOS4.1) que al salir de la aplicación (Antecedentes o salir) hará que se dispare DidDisconnectNotification. En el caso de simplemente presionar el botón de encendido o hacer que el dispositivo duerma; no vemos la conexión descender.

Ahora, si el dispositivo BT se sale de rango o se va a dormir. Entonces la conexión se cae.

Como resultado, ya no dependemos de otra cosa que ConnectionNotifications. Ni siquiera confiamos en la lista [[EAAccessoryManager sharedAccessoryManager] connectedAccessories] porque hemos encontrado que a veces puede contener 'accesorios fantasma' que dicen que están conectados y tienen transmisiones a las que se puede conectar y obtener eventos disponibles incluso después de que todo el sistema bluetooth se haya ido abajo (icono de BT desactivado)

ConexiónLas notificaciones se guardan en la memoria caché cuando está en segundo plano, por lo que debe obtener un nuevo estado cuando vuelva a ingresar la aplicación.

Por supuesto en la primera entrada; desea asegurarse de haber configurado correctamente todos sus oyentes (etc.).

+0

Hola, estoy teniendo el mismo problema. Cuando enciendo la potencia del módulo BT cuando está conectado a la aplicación, ve al fondo y vuelve a conectarlo. Luego vuelve a la aplicación, EASession no puede ser init. ¿Puede explicar un poco más sobre "ConnectionNotifications se almacena en caché cuando está en segundo plano, por lo que debe obtener un nuevo estado cuando vuelva a ingresar la aplicación". ¡Gracias! – user1491987

2

Por lo que puedo decir, no hay eliminación de instancias de EASession antiguas. Puedo hipotetizar, pero realmente no sé por qué es esto. Sospecho que la EASession establecida no libera su asociación con su accesorio, y que esto evita que las instancias de EASession subsiguientes se asocien satisfactoriamente con el mismo accesorio.

Opté por dejar intacto EASession cuando la aplicación se cierra. Esto parece estar funcionando. En las pruebas, me conecté al accesorio Bluetooth, inicié mi aplicación, accedí al accesorio, envié mi aplicación a un segundo plano, desconecté/conecté el accesorio BT, puse la aplicación en primer plano y pude volver a acceder a los accesorios. Esto es todo lo que podría desear.

Una advertencia: con iOS 4.0 es posible tener más de un accesorio. Por ejemplo, un cable de video y un dispositivo Bluetooth son ambos accesorios.

-1

Tenía el mismo problema. En mi caso, el objeto de sesión, justo después de la creación, tiene retainCount = 3, por lo que una llamada [release de la sesión] no fue suficiente al recibir DidDisconnectNotification. Asegúrese de liberar realmente el objeto de sesión después de recibir la notificación de DidDisconnectNotification.

+0

También estoy viendo fugas de EASession (tiene retainCount de 2 antes de lanzar lo que debería haber sido el único retener). Comportamiento raro. – Sam

+0

http://whentouseretaincount.com/ – DanBlakemore

2

Tuve el mismo problema y lo resolví con un pequeño truco. Registraba el número de serie del accesorio cuando abrí una sesión y registré cuando cerré una sesión.

Así es como vi que algunas sesiones no se cerraron. Entonces, cuando mi aplicación va al modo de fondo, cierro definitivamente todas las sesiones abiertas por dispositivo.

-(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]; 
} 

Espero que ayude a alguien más.

2

Tuve el mismo problema. Estaba desarrollando una aplicación que abriría un Accesorio Bluetooth externo en un intervalo temporizado, leería algunos datos y luego cerraría las transmisiones. Esto había funcionado bien durante unos días, y de repente un día dejó de funcionar con este problema exacto. También se registró un mensaje en la consola.

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 

La documentación de Apple es clara, se permite sólo una instancia de cada protocolo de estar abierto a la vez y ninguna instancia anterior se cancela la asignación automática. Pero por qué de repente iOS no pudo desasignar la EASession anterior cuando había estado funcionando bien durante días.

Estaba perplejo y pasé tres días golpeándome la cabeza contra la pared. Busqué en Google y terminé aquí, leí las guías de Apple sobre la comunicación con accesorios externos y la guía de programación de NSStream. El código era todo correcto.

Finalmente, en el tercer día escuché un pitido desde la esquina de mi escritorio, mi teléfono Android se estaba quedando sin batería. Se encendió una bombilla en mi cabeza. Apagué el teléfono y violé, el problema en el dispositivo iOS desapareció.

Esto es realmente un problema de RF, no un problema de programación, pero incluyo mi historia aquí en caso de que alguien más se encuentre con este problema, Google lo traerá aquí. Apague todas las demás radios Bluetooth que estén cerca porque son fuentes de ruido y pueden provocar este problema.

Cuestiones relacionadas