Recently I blogged that "
Polling is a smelly anti-pattern!".
I think it will be useful if I expand on this a bit.
I should probably also have been clearer that this is about polling on a timer. i.e. Every X seconds (or minutes) query the server to look for updated data, new messages, current status, etc.
Avoiding polling in a mobile app is a rule.
While I don't subscribe to the idea that "rules are made to be broken", I do believe that rules can be broken when appropriate (It's laws that can't be broken and I'm don't know any laws of software development!) but only on the following basis:
- Firstly learn the rule.
- Secondly, learn the reason(s) the rule exists.
- Thirdly, learn the consequences of breaking the rule.
- Fourthly, do the same for the alternatives to the rule.
Only once you've been throught the above four steps should you consider breaking the rule.
Ok, back to basics, why is timer based polling a bad idea in mobile apps?
2 reasons:
1. It may (depending on the platform) prevent the device from going to sleep/standby. If the device is prevented from going in to standby means that the battery will drain faster. When the battery runs out the device is useless so it's in the interests of both the users and the person wanting the application to be used for the battery to last as long as possible. SOme platforms may even wake the device when the timer fires - almost completely avoiding the benefit to battery preservation which a standby mode can provide.
2. By making a request just to see if there is some new data on a server the application is using the devices data connection. While a request that only responds with a message that there are no new messages is likely (hopefully) to be a small message it still uses network bandwidth. For some users, the cost of network access can be very expensive. A few bytes every minute (or however frequently you check) can add up.
So, breaking the rule may mean you run the users battery down and push up their data charges. See, I told you polling could be bad!
What about the alternatives?
There are a number of alternatives but their usefulness and availability depends on the platform you are using and the particular scenario.
If the application needs to be notified when something changes remotely this could be pushed from the remote location. This could be done with true push messages or with in a cruder method such as HTTP long polling.
Some platforms offfer the ability to subscribe and respond to system level events. This may be a change in the time, network connectivity or something else. This can be a very effective alternative to polling when it's available.
Subscribing to the hour changing can put much lower demands on the resources of a device when compared to running a timer which will only fire once an hour.
Subscribing to notification of email or SMS being recieved can be a good time to also check for new messages, etc. as there is a much greater chance of a network conenction being avaialble (You hadn't forgotten that you need to account of occassional connectedness - I'm sure.) It's also more likley that user will be in a position to see any new message and react to it - as they've just responded to an email or SMS notification.
Or check when the device is woken from sleep (if the platform offers the ability to detect this). This avoids the need to update status or list of unread messages when the screen is off and the user won't see them.
There is of course another scenario which is important to remember: when you must used timer based polling because the platform does not provide any other way of implementing the functionality. Obviously in this scenario you have to use it. Just make sure that you are aware of the consequences.
If you must poll, reconsider how often you do it. You can probably do it less often than your users think you need to ;)
To summarise:
Use polling when you must. But, avoid it if you can. And see if you can do it less often.
