Realmente no entiendo cuándo se activa messageLostHandler en método subscriptionWithMessageFoundHandler.

Este es mi código:

func suscribeToNearbyDevices(myUserId: String){

    subscription = messageMgr?.subscription(messageFoundHandler: { (message: GNSMessage?) in
        if let incomingMessage = message, let content = incomingMessage.content {
            if let userIdEncoded = String(data: content, encoding: String.Encoding.utf8) {

                    NotificationCenter.default.post(name: Notification.Name(rawValue: CommunicationVariables.newUserNotificationKey), object: nil,
                                                    userInfo:userIdEncoded)

        }}, messageLostHandler: { (message: GNSMessage?) in
            if let incomingMessage = message, let content = incomingMessage.content {
                if let userIdEncoded = String(data: content, encoding: String.Encoding.utf8) {
                    NotificationCenter.default.post(name: Notification.Name(rawValue: CommunicationVariables.exitUserNotificationKey), object: nil,
                                                    userInfo: [CommunicationVariables.userIdNotificationField:userIdEncoded])
                }
            }
    }, paramsBlock:{(params:GNSSubscriptionParams?) in
        guard let params = params else { return }
        params.strategy = GNSStrategy(paramsBlock: { (params: GNSStrategyParams?) in
            guard let params = params else { return }
            params.allowInBackground = true
        })
    })
}

Tengo dos iphones, si tengo las dos aplicaciones en primer plano, pueden verse entre sí. Cuando presiono inicio en uno, el messageLostHandler se activa, pero si salgo del rango (como fuera de la casa-fuera del rango) el messageLostHandler nunca se activa.

¿Por qué? ¿Qué causa que se active messageLostHandler?

¡Gracias!

0
Julio_oa 12 ene. 2017 a las 05:38

1 respuesta

La mejor respuesta

Veo que su suscripción está configurada para funcionar en segundo plano, pero ¿la publicación también está configurada para segundo plano? De lo contrario, cuando presiona el botón Inicio en el dispositivo de publicación, la aplicación queda en segundo plano, lo que hace que la publicación se deshabilite y el suscriptor recibe una llamada al bloque messageLostHandler.

Respecto al problema de fuera de rango: BLE (Bluetooth Low Energy) funciona a un rango muy alto (hasta 100 m en exteriores, y menos cuando hay obstáculos). Así que tienes que caminar muy lejos para que los dispositivos estén completamente fuera de alcance. Una alternativa es colocar uno de los dispositivos dentro de una caja de metal completamente cerrada (una jaula de Faraday), que bloquea todas las transmisiones de radio. En 2-3 minutos, el suscriptor debería recibir una llamada al bloque messageLostHandler. (Por cierto, el tiempo de espera de 2-3 minutos es bastante largo y estamos discutiendo si deberíamos acortarlo).

Avísame si necesitas más ayuda para averiguar qué está pasando.

  • Dan
0
Dan Webb 14 ene. 2017 a las 03:52
Gracias por la respuesta Dan, tienes razón, si configuro tanto al suscriptor como al editor para que trabajen en segundo plano, el messageLostHandler no se activa. No sabía sobre el caché de 2-3 minutos, estaba leyendo otras preguntas que respondiste y esto, y sé que muchas cosas tienen sentido. Nunca espero tanto cuando pruebo, así que quizás muchas veces el código y la funcionalidad eran correctos, pero tengo que esperar más. Sería genial si pudieras convertir ese tiempo en un parámetro. ¡Gracias!
 – 
Julio_oa
16 ene. 2017 a las 03:23
Si configuro solo el medio de audio en suscribir / publicar en ambos dispositivos y salgo del rango, como el otro piso, la habitación y la puerta se cierra. Aún así, toma entre 2 y 3 minutos darse cuenta de que el otro dispositivo no está dentro del alcance (los dos dispositivos tienen conexión a Internet móvil). Incluso cuando detengo / comienzo a publicar / suscribo cada 10 segundos, todavía veo los otros dispositivos. ¿Es este el comportamiento normal? ¿Hay alguna forma de forzar un reinicio de caché? ¡Gracias!
 – 
Julio_oa
18 ene. 2017 a las 05:55
Near mantiene un caché de tokens que se escuchan desde dispositivos cercanos en dos lugares: (1) en el dispositivo y (2) en el servidor. Estos cachés sirven para diferentes propósitos relacionados con qué dispositivo está transmitiendo / escaneando vs publicando / suscribiendo. Es bastante complicado, y aunque puede vaciar la caché en el dispositivo (liberando el objeto GNSMessageManager y creando uno nuevo), desafortunadamente no es posible vaciar la caché en el servidor. Me disculpo porque actualmente no hay una solución, y estoy aumentando la prioridad de este error para que se solucione antes.
 – 
Dan Webb
19 ene. 2017 a las 01:36
Gracias por la respuesta Dan, ahora entiendo muchas cosas y estoy seguro de que esas decisiones tuvieron sentido en su tiempo. Intentaré solucionarlo por ahora. Aun así, es una gran herramienta lo que ha hecho el equipo cercano, gracias por el gran trabajo.
 – 
Julio_oa
19 ene. 2017 a las 05:38