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:
A "default" poll of the webservice would fire every minute regardless of any actions a user may perform.
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.
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.
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.
来源：https://stackoverflow.com/questions/14046509/ios-push-notifications-as-a-trigger-for-webservice-polling