2

I'm looking into enabling background fetch in our iOS app to give time to PubNub to prevent a presence timeout.

EDIT - Some background: our app is communicating its geolocation to a service over a pubnub channel. We ask the user to authorize location when its in the background, and when that's granted, we're already getting occasional time from the os. We've been trying to use presence features so the service can know if our app has quit/dropped connectivity vs just stopped moving. However when the device stops moving when in the background, we don't get execution time from locations arriving, and so pubnub timeout occurs anyway.

After enabling that background state, it looks like I need to

  • call setMinimumBackgroundFetchInterval with an interval when we have a connection we don't want to timeout (and also with Never when we don't).
  • implement an application:performFetchWithCompletionHandler:

However, some things are not obvious:

  1. What fetch interval should I choose in relation to our pubnub timeout? It seems the fetch interval specified is not necessarily obeyed by the os. In general we've wanted to keep our timeouts short so when our app goes offline or is force quit, our other end detects that fairly soon. That seems at odds with the heartbeat and making sure we don't inadvertent timeouts. I'm considering just using the Minimum interval.

  2. I don't think I need do anything in my performFetchWithCompletionHandler method to make sure the presence heartbeat is sent, rather just by the fact that the app is woken up will let PubNub's timers fire and take care of everything. However can I do anything do invoke the completion block only after the heartbeat transaction, or know when to return newData vs. noData vs. failed. Also, I'm concerned that just calling the completion right away every time with noData will be taken by the os as a clue to back off the fetch interval.

Or, if anyone can recommend an alternative to this approach for preventing timeouts, I'd appreciate that.

Pierre Houston
  • 1,631
  • 20
  • 33
  • The problem with keeping your client from timing out when it is in background is that your client "is in the background" and is not connected for long term subscribe so it would not receive any messages anyway. So I think I just need to know what your true requirements are for this. If it is to receive messages while in background, then why not use APNS as fallback as we recommend? – Craig Conover May 02 '17 at 04:40
  • Check out my edit which adds some context, but briefly: our app already sends pubnub messages both when its in foreground or background when data comes available, and we're trying to use presence so our remote side can see if our app is still online, even when there's a pause in that data. In fact, we're already using APNS when appropriate for communicating other data back to the app, and that's working well. But I'm hoping not to reimplement heartbeat at the APNS level, when presence already has that feature and the app is already doing background execution. – Pierre Houston May 02 '17 at 18:15

1 Answers1

2

PubNub Presence Heartbeat

If you want to keep your background app presence on a channel (or channels), you can simply use a REST call to send a heartbeat every 4 minutes (faster than every 5 minutes which is the default timeout - 4 just seemed like a nice round number):

https://ps.pndsn.com/v2/presence/sub-key/{yourSubKey}/channel/{listOfchannels}/heartbeat?&uuid={clientuuid}

For example:

https://ps.pndsn.com/v2/presence/sub-key/sub-c-1234.../channel/channel1,channel2/heartbeat?&uuid=db9c5e39-7c95-40f5-8d71-125765b6f561

Just make sure the UUID you send is the same as the UUID you initialized the PubNub instance with in that user's app.

This heartbeat ping has the same effect as a long running subscribe connection. It will keep the given UUID present on the channels you pass in.

See PubNub REST Docs for more details.

Community
  • 1
  • 1
Craig Conover
  • 4,710
  • 34
  • 59
  • @smallduck - do get back and let me know if this works for you and post any mods you had to make. Could make for a great KB article. – Craig Conover May 03 '17 at 15:12
  • 1
    For sure. What we know now is that it looks like background fetch is not suitable for running code at accurate intervals measured in minutes and not hours. We're looking into receiving a silent push notification from our service if it's about to show our app is offline, and we'll see if connecting to the REST endpoint you mentioned will work to rejoin channel, or if we need to do something else. – Pierre Houston May 03 '17 at 17:00
  • 1
    Finished what I mention above, our app re-joins the channel and our service cancels its offline state. We gave the service 10 seconds to observe that join, and it seems to work reliably. I originally wanted to see if worked without making that REST call, but haven't tried that yet. And I realize now that maybe you mean the REST call could be done from elsewhere, not our app! We also never tried that. (Also, admission: I keep mentioning a "service" our app communicates with, however it's really another app, iOS & Android versions. I didn't want to confuse my description calling both "app") – Pierre Houston May 04 '17 at 22:21
  • Hmm, our use of this API has stopped working for us! I tried adding the callback & state parameters which the docs say are required but no dice. This is the GET request that's now giving us a 403 response: `https://ps.pndsn.com/v2/presence/sub-key/sub-c-.../channel/ourchannelname/heartbeat?callback=0&state=%7B%7D&uuid=thisclientsuuid`. – Pierre Houston Jun 27 '17 at 18:21
  • Is an auth parameter required, the docs don't make any mention of that w.r.t the heartbeat APIs. If needed, is there a value for this we can get out of the PubNub framework (we're on iOS), or better yet, a framework api call I haven't noticed yet for sending an explicit heartbeat. – Pierre Houston Jun 27 '17 at 18:37
  • Yes, adding an auth parameter was the answer. talked with server guy and the expected auth value is fortunately a value already known to our app. This is what's now working: `https://ps.pndsn.com/v2/presence/sub-key/sub-c-.../channel/o‌​urchannelname/heartb‌​eat?callback=0&state‌​=%7B%7D&uuid=thiscli‌​entsuuid&auth=ourauthkey` – Pierre Houston Jun 27 '17 at 19:03
  • It sounds like you enabled Access Manager which requires you to grant access to auth-keys that your clients use to execute operations. – Craig Conover Jun 27 '17 at 21:57