iOS: PUSH Notifications As A "Trigger" for Webservice Polling?

Question

I'm just starting out learning OBJ-C but I do have an end-goal app that I'm working toward building; this app will be a master/detail app on the iPad that will be required to keep itself updated with a webservice in "real time". It will also need to send data to the remote MySQL DB when one of the multiple users (on separate iPad's) performs certain actions within the app.

EDIT: As lxt has so helpfully clarified: ""Is it appropriate to use push notifications as a cue to poll a webservice" - the answer is sort of."

The example I've imagined for the purposes of this question is a Widget Inventory Manager that has "incoming" inventory that flows into the table view and "inventory storage bins" that the users will drag-and-drop inventory to in the detail view.

Like so:

NOTE: My application DOES NOT require itself to stay updated when not in the foreground. It can happily sleep away until its launched again; at which point it would need to update itself with the most recent data. Kyle has provided an answer for this specific aspect of the problem using applicationWillEnterForeground:

In order to accomplish this without overtaxing my webservice server I've imagined a solution that combines webservice polling and PUSH notifications to trigger the polls when one user (iPad) makes any changes to the data. So, the flow would be like so:

1. A "default" poll of the webservice would fire every minute regardless of any actions a user may perform.

2. When a user drags an inventory item from the tableview and drops it in a storage bin that would initiate a PUSH notification to any other iPad logged in to the same overarching account and trigger a webservice poll to refresh its data.

In short: Any time a user on iPad "A" changes anything a PUSH notification is sent to iPad "B", iPad "C", etc. When the PUSH is received by B,C,D, etc. they then poll the server to refresh their data.

The alternative to this is to have every iPad on the account firing webservice polls every 15secs; which seems bandwidth-expensive to me (and would often result in no changes to the data).

My question is less of a "How do I ...?" and more of a "How should I ...?". I realise StackOverflow may find this somewhat "subjective", but I think this is a very worthy question considering I've spent two days researching this specific practice (using PUSH notifications to trigger webservice polling) and found exactly zero relevent articles.

Thanks for taking the time to read this. Any help would be appreciated. Example code and/or specific framework/kit information would be greatly appreciated. But really right now I just need to know if this is a good idea or not.

Hildie

So did you get the answer? means how you run the webservice on update notification comming from other device? – Morehouse

Answer 1

Updated for iOS 7

So the gist of your question seems to be "is it appropriate to use push notifications as a cue to poll a webservice" - the answer is yes, with a few things to be aware of. Before iOS 7 your app would have to have been in the foreground for this to work. Now, you can use Background App Refresh to trigger your web service polling in the background after receiving a push message.

Apple themselves use push notifications to trigger web service calls - it's how passes in Passbook get remotely updated. When an updated passes are available a push notification is sent, which then causes iOS to call the appropriate web service linked to in the pass to download the new payload.

A few things to remember: the first is that push notification is not guaranteed (not necessarily a problem), but also you have no guarantees about when it will be delivered. In most cases you would hope it to be instantaneous, but that's not always the case. Additionally, any users who have opted out of push notifications will get no benefit from this feature.

What you're looking to do isn't a hugely novel problem, and there are a few existing solutions you could use instead of using push notifications to trigger updates. You could use a socket based system (quite complicated), or HTTP long polling (less complicated). There are also third party services that exist to achieve this really easily - one such service is Pusher.

One of the big advantages of all three of these alternatives (sockets, long polling, third party services) is that they are usually platform neutral, and you can use them on other clients with ease (unlike APNS). If it was me I'd use one of these approaches over push notifications, but with background app refresh on iOS 7 you might find push can support everything you want to do.

Just my two cents anyway - hope it's useful to you.

Bastard

EXCELLENT! Thank you so much for taking the time lxt. This is exactly the info I'm looking for. I figured it wasn't altogether uncommon to need this sort of solution, but I couldn't for the life of me figure out why I couldn't find any solid information on it. I'll certainly look into the 'alternative' solutions you mentioned. Glad to hear that there are (obviously) a few ways to handle this. First thing I'm going to look into is the lag of PUSH notifications. Any idea of a ballpark of how long these can lag before receipt by the target device? – Hildie

It can vary on a lot of things, from the service you're using to send push (running your own, using a third party, etc) to the data connection on the user's device. Basically, how long's a piece of string. Sorry I can't give you a more definite answer - there's a longer summary here: #9205267 – Bastard

LXT: I figured as much. Thanks for taking the time. I'll look into this and post back any info I find so that others can hopefully benefit from this. – Hildie

Very well explained. I just have one question, what about when the app is killed? The push notification in this scenario cannot wake the app up, correct? Or is my understanding wrong? – Jiminez

Answer 2

We recently had a discussion about this for a project. The answer we concluded with: NO.

Reasons:

• Push notifications are not guaranteed. They could arrive in 5 seconds, they could arrive in 15 minutes, or they could never arrive.
• Users are not guaranteed to have an active data connection, thus requiring some sort of fool-proof logic and update process anyway.
• Lack of security in sending sensitive data (ids that could be potentially associated with persons) via push.

We also looked into some sort of sockets connection however this also has limitations, including the fact that the app must remain open during the interaction and the increased wear on the battery.

Ultimately we decided that this functionality was something that would suffice by being triggered by a button click. The trade-off just wasn't worth it. However this doesn't mean it can't be done, and in your particular situation it may be the best way. I'd recommend looking deeper at your product design and determining how important this feature is to you. If it's trivial, I recommend NOT using push notifications.

UPDATE:

Another possible option is to fire off your web service call whenever the user reopens the app. Try looking into applicationWillEnterForeground and maybe a solution similar to the one found here: applicationWillEnterForeground: reload Data from ViewController.

Sheasheaf

Thanks so much Kyle. It's very, very helpful to know that you've gone through this process and reached a conclusion. Combining what lxt offered in his answer and your advice it seems as though PUSH notifications just aren't intended to do this. Unfortunately for me my app requires that the devices keep their data fresh somehow so I'm looking into HTTP Long Polling and Pusher. Thanks for taking the time. – Hildie

@Hildie You are welcome. Another option is to fire your web service in applicationWillEnterForeground. See the update in my answer. – Sheasheaf

Ha. You read my mind. I was just now chewing over the idea that when my app enters the foreground the first thing it will do is update itself. It's important to note for others reading this discussion that my Widget Inventory Management app DOES NOT require itself to have updated data from the webservice unless its in the foreground. – Hildie