0

I don't really understand when messageLostHandler is triggered on the subscriptionWithMessageFoundHandler method.

This is my code:

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
        })
    })
}

I have two iphones, If I have the two apps on the foreground, they can see each other. When I press home in one, the messageLostHandler is triggered, but if I walk out of range (like outside-of-the-house-out-of-range) the messageLostHandler is never triggered.

Why? What cause the messageLostHandler to be triggered?

Thanks!

Julio_oa
  • 570
  • 6
  • 15

1 Answers1

0

I see that your subscription is configured to work in the background, but is the publication also configured for background? If not, then when you press the Home button on the publishing device, the app is backgrounded, causing the publication to be disabled, and the subscriber receives a call to the messageLostHandler block.

Regarding the out-of-range problem: BLE (Bluetooth Low Energy) works at a very high range (up to 100m outdoors, and less when there are obstacles). So you have to walk very far for the devices to be completely out of range. An alternative is to place one of the devices inside a fully closed metal box (a faraday cage), which blocks all radio transmissions. Within 2-3 minutes, the subscriber should receive a call to the messageLostHandler block. (Incidentally, the 2-3 minute timeout is rather long, and we're have a discussion of whether we should shorten it.)

Let me know if you need more help figuring out what's going on.

  • Dan
Dan Webb
  • 348
  • 1
  • 7
  • Thanks for the answer Dan, you are right, if I set both subscriber and publisher to work on background the messageLostHandler is not triggered. I didn't know about the 2-3 minutes cache, I was reading other questions you answered and this, and know a lot makes sense. I never wait so long when testing, so maybe many times the code and functionality was correct, but I have to wait longer. It would be great if you can make that time a parameter. Thanks! – Julio_oa Jan 16 '17 at 00:23
  • if I set only audio medium on suscribe/publish on both devices and go out-of-range, like other floor, and room, and door closes. Still takes like 2-3 minutes to realize that the other device is not in range (the two devices have mobile internet connection). Even when I'm stopping/starting publish/suscribing every 10 seconds, still sees the other devices. Is this the normal behaviour? is there anyway to force a cache reset? Thanks! – Julio_oa Jan 18 '17 at 02:55
  • Nearby keeps a cache of tokens heard from nearby devices in two places: (1) on the device, and (2) on the server. These caches serve different purposes relating to which device is broadcasting/scanning vs. publishing/subscribing. It's rather complicated, and although you can flush the cache on the device (by releasing the GNSMessageManager object and creating a new one), it's unfortunately not possible to flush the cache on the server. I apologize that there's currently no solution, and I'm increasing the priority of this bug so it gets addressed sooner. – Dan Webb Jan 18 '17 at 22:36
  • Thanks for the answer Dan, I understand a lot of things now, and I'm sure those decisions made sense in their time. I will try to make some workaround for now. Even so, is a great tool what the nearby team has made, thanks for the great work. – Julio_oa Jan 19 '17 at 02:38