It seems commonsense nowadays that polling is a bad practice and pushing is the way to go when developing mobile applications that require to constantly receive data from a remote server.

All major mobile shops provide their version of a push notification service:

However I'm wondering to what extent this assumption is valid. I mean, if I have an application that polls a remote server only a couple of times a day, and to which "notifications" don't need to be delivered instantly (a large delay is acceptable), then would it be a good decision to poll for data instead of pushing it?

Thanks in advance!

  • 1
    I'm not familiar enough with the mobile push mechanisms to really weigh in on this, but I wonder if using the push mechanism might save some headaches, for example with regard to dealing with power off / sleep scenarios. If this were just a desktop / web application, then I would say that polling is fine; pushing typically also involves keeping a connection open on your web server, so that's another advantage of polling in a desktop / browser, but since this is a mobile application, and you can use these alternate push mechanisms, I think the answer might be different. Jan 23, 2014 at 19:30

3 Answers 3


Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself is why would you use one instead of the other?

The purpose of a push service is a couple things; it can be considerably less traffic for you to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this allows you to send one message and have thousands receive it. But as you note, the biggest boon of a push service is the realtime nature that allows for immediate updates to reach your consumers. However when doing pushes you really don't ever want to be pushing large data sets if you're broadcasting, and you're also at the mercy of the third party push service you utilize (if you utilize one).

The purpose of a poll is to check for data differences periodically, where the update period can have an acceptable SLA of inaccuracy up to a certain time period. A poll will require all your clients to request the data periodically which will mean a connection being requested for every running client, and the necessity of a live service able to monitor that data accurately to serve it up to the pollers. Having accurate data to serve up means some data persistence which will take up disk and maintenance time.

So from this we can see that if you have concerns about network traffic or the maintenance of a service (which means possibly authenticating/authorizing requests, logging them which takes up disk space, all the normal requirements of maintaining a service) then you don't want to force clients to poll. However if the use case requires transmitting a particularly large data set or you can't be tethered to a third party's API which may change in time as well as their SLA or charges, then a home grown polling system may be applicable, though the maintenance overhead may be significantly more. Alternatively you may already be running service and have the data persisted such that the polling is a light addition to already in-place infrastructure, which makes polling more desirable.

Though to the central point you make you are correct; if real-time is necessary, polling will not do. If it is not, then you just have to do the math on how periodic the data can be checked multiplied by your client base multiplied by your data set size to decide if the network cost is going to be worth it, or if a push service would be better where you can always just push a change event that let's them request the large data set in a secondary step (though atomicity of these steps may be something you need to be careful of depending on the criticality of the data).


Polling should be fine in your case. And you won't have to integrate with yet another system (or multiple systems for multiple platforms).

Device specifics may be an issue, though. Can you reliably poll when the app isn't front and center on the device? (may or may not be an issue for you). Your ability to do so may depend on the techonolgy you are using for developing the app.

  • I'm planning to use built-in timers to make sure the app polls the server even if it is not "active". I know how to do it on Android, and I hope iPhones and WindowsPhones provide the same functionality ;) Jan 23, 2014 at 19:49

Of course. It's also easier (just beware of pull spikes if everyone is pulling on the same schedule).

That said, I would challenge the assumption that 'a large delay is acceptable', considering mobile users expectations. ('Maps are not updated in real time! Unacceptable!' - or - 'I know it's the weather service, but I'm going to keep pushing that refresh button every five seconds until forecast for tomorrow turns sunny!')

  • Good point about preventing everyone from polling at the same time. I guess setting timers randomly will do the trick! Jan 23, 2014 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.