1

I am in the process of writing an iOS app which uses Google Nearby API. I have noticed that on occasions when one device starts a subscription and picks up publications from another nearby device (both iOS devices) the subscribing device might get released publications from the other device (from previous runs of the other device, which obviously have been released by my app). I am sending UUIDs when publishing and I definitely see old (i.e. previous runs') UUIDs received by the subscriber.
I came across https://stackoverflow.com/a/32540735 which explains “sessions” are divided into 10 minutes buckets which might explain this issue, however the answer seems to be related only to Android. I noticed the iOS Nearby is still in beta, could this be a bug?

Any ideas? Thanks.

Community
  • 1
  • 1
Urilicious
  • 11
  • 2

1 Answers1

0

Here are the scenarios that can cause the problem you're seeing: - If the publishing app is killed while the publication is alive. E.g., if you swipe to kill it, or if you kill it from the debugger. - If network connectivity is lost or bad enough to prevent a call to the Nearby server.

When the publication object is deallocated, it calls the Nearby server to revoke the published message, and subscribers should no longer receive the published messages. In the above scenarios, the call to the server isn't made, so the publication persists for a while. On iOS, this "for a while" amount is 5 minutes.

Does the problem go away after about 5 minutes?

Dan Webb
  • 348
  • 1
  • 7
  • The problem does go away after a few minutes. So setting the publication to nil isn't enough, you have to allow it enough time to notify the server, which is not possible if the user kills the app or puts it in the background, correct? – Urilicious Jun 01 '16 at 12:55
  • It should be able to successfully call the server when the app is pushed into the background (we use [UIApplication -beginBackgroundTaskWithExpirationHandler:](https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/#//apple_ref/occ/instm/UIApplication/beginBackgroundTaskWithExpirationHandler:) to virtually ensure it runs long enough). But if it's killed while the publication is active, there's nothing we can do. Can you make sure there's not another reference to the publication object? – Dan Webb Jun 01 '16 at 19:19
  • I believe so. In my AppDelegate.applicationDidEnterBackground I am setting all publishers, subscribers and even the GNEMessageManager to nil, so there wouldn't be any GNS activity in the background (this is done to follow the nearby tips given at the video [here](https://www.youtube.com/watch?v=hultDpBS22s) which say to unpublish and unsubscribe on an Android onPause). My debugging also shows my publisher is nil at that time. – Urilicious Jun 02 '16 at 12:10
  • 1
    Pubs & subs are foreground-only on iOS, so there's no need to disable them when the app goes to the background; this is handled automatically by Nearby Messages. (On iOS we handle more of these state transitions for you, so it's a little easier to use than Android.) Can you try removing your background/foreground handling, and see if the problem goes away. I tried to reproduce it just as you described, but my publication is still getting disabled when backgrounded, even when I simulated a bad network using Network Link Conditioner. – Dan Webb Jun 02 '16 at 21:19
  • I have removed my background app handling. When minimizing the app on one device which was broadcasting, I expected a message lost to happen on another device which picked that message earlier. I get that message lost only after 5 minutes, same as with my handling in the background. Shouldn't that message lost happen immediately? does it mean, as you suggested, that it didn't have time to notify the server and revoke the message? I didn't kill the app, just minimized it. Even if I do have another reference to the publication, all publications should be handled automatically as you said. – Urilicious Jun 06 '16 at 13:44
  • Hmm, that's awfully strange. Does your publishing device have a good internet connection? Can you turn on debug logging and send me the logs for when the app goes into the background? Turn it on my doing this before creating your message manager: [GNSMessageManager setDebugLoggingEnabled:YES]; – Dan Webb Jun 07 '16 at 16:58
  • Where would you like me to send them to? I couldn't find any address on your profile – Urilicious Jun 08 '16 at 17:38
  • Apparently there's no way to send private messages, so I think the best way is to save it to a public storage site (Google Drive, dropbox) and share the public link here. – Dan Webb Jun 09 '16 at 21:24
  • Sorry for the delay, here is the [LOG](https://www.dropbox.com/s/us5fen49o785lgp/Log.rtf?dl=0). The app loads, broadcasts some data and creates a subscription. The subscription then picks up some data from another device nearby. I then minimized the app. Both publisher and subscriber were set to nil. The other nearby device only got the lost message about 5 minutes afterwards. There are no Internet connectivity issues. – Urilicious Jun 17 '16 at 05:35
  • Thanks for the logs. I reproduced the problem after staring at the logs for a while. The logs show that you're using both audio and BLE, but there are no audio broadcast or recording log messages. I assume this means you've denied microphone access for your app. I did the same in my app, and now I see the problem. The server call isn't being issued (most of the time) because without audio, the app is suspended much sooner after backgrounding. It's hiding a bug in my logic that tries to keep the app alive for the server call to complete. I will fix the bug in a future release. Thanks! – Dan Webb Jun 21 '16 at 22:53
  • If you allow access to the microphone, the problem will (mostly) go away. However, the problem is also reproducible if you use BLE only. – Dan Webb Jun 21 '16 at 22:54