This is not a good idea. HTTP polling is enough traffic to put the mobile radio into its DCH state, which uses a lot of power. (Second only to the screen on most phones.) Once you're in DCH, there's a timer (typically ~8 seconds) before it turns off again. When polling, you just wasted orders of magnitude more power to wake the radio than was used to actively communicate for that 500ms or so.
One of the great things about the internet is that you can neglect considerations of the physical layer when you design your app.
One of the sad things about the mobile web is that you can't neglect considerations of the physical layer when you design your app.
Some things that seem like a great idea at first (eg lazy loading of lists as the user scrolls) can actually be detrimental and counter-productive when it comes to battery life.
This is a bit simplified since often your app's activity won't be the only thing on the radio, but:
Full load: large transmission to start off, but radio is idle after, if the list is long or user scrolls slowly radio might go to sleep after its programmed idle timer (8 seconds in GP's post)
Lazy load: keep on making transmissions periodically, either waking up the radio (and keeping it on for another 8 seconds) or outright never letting it sleep (if you lazy load every 7 seconds or less)
Good find. They clearly know how to do push and in timing tests push notification is well under a second if done correctly. Apple Push is stupid fast. (probably a good separate post)
I suspect they are using a 3rd party push service and perhaps are trying to save a buck when the app is open. Not sure why they don't just keep a socket open?
For a company that's pretty push heavy, I'm surprised they didn't implement their own push service, since they manage the chat room logs anyway. It isn't complicated.
If only there was an established way, maybe a pattern, perhaps a device service, for getting notifications without constantly doing an HTTP poll request.
I thought this wasn't a valid use of multitasking by the App Store rules? Are Apple just not policing multitasking use at all right now?
edit: does this fall under "Local notifications"?
> Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.
This could also be seen as violating this
> Apps that provide Push Notifications without using the Apple Push Notification (APN) API will be rejected
They're not using multitasking. They're using the basic limited background task functionality, whereby you can request additional time to complete actions when closing the app. The system puts a hard limit on you at 10 minutes, at which point it will kill your app. This is designed for doing things like saving data, posting that tweet the user just wrote, syncing modified data to your server, etc. This app is abusing this functionality in a very stupid way.
The only other explanation I can think of is that push notifications can take about 3-5 seconds to be delivered as they are routed through Apple's servers. If these are long-poll HTTP requests directly to GroupMe's servers, then the message would be delivered instantaneously.
If it's long-polling, why are the requests happening over and over again? It should only need to make a single connection, fire off HTTP headers, and just sit there waiting for chunked-encoded replies. No need to kill the connection and re-establish.
They do this because it allows them to then use local notifications for those 10 minutes to ensure delivery of the notification of a new message, this reliability doesn't exist with push notifications.
Verbs, another instant messaging app for the iPhone, does the same thing.
One of the great things about the internet is that you can neglect considerations of the physical layer when you design your app.
One of the sad things about the mobile web is that you can't neglect considerations of the physical layer when you design your app.
Some things that seem like a great idea at first (eg lazy loading of lists as the user scrolls) can actually be detrimental and counter-productive when it comes to battery life.