[Flowdalic]

Idle TCP connections do not consume any battery.

And on a data connectivity change, e.g. GSM <-> WiFi switch, there is a good chance that a dozen other components start trying to re-establish their connections, which means the radio is awake anyway (for, usually, at most a few seconds).

[rakoo]

> Idle TCP connections do not consume any battery.

An idle connection doesn't consume anything, but a useful idle connection will have some keepalive every X minutes. Multiply that by the number of connections your application will have and by the number of background application you run on your phone, and the radio will never truly sleep or enter the "low" mode. The solution wanted by Google and Apple is to maintain a single connection to their server on which every push is aggregated and sent, and that the OS itself manages.

[Flowdalic]

I use my mobile XMPP connections without a TCP keepalive but send a server ping if there has been stanzas received in the last 30 minutes and get a useful and reliable XMPP connection without a noticeable impact on battery. If you use Android's AlarmManager to trigger the check, then Android will even take care of scheduling the "alarm" with other alarms for efficiency.

> Multiply that by the number of connections your application will have and by the number of background application you run on your phone, and the radio will never truly sleep or enter the "low" mode.

Why would X x Y idle connections (X: TCP connections per app, Y: applictions) prevent your radio from sleeping?

[rakoo]

> Why would X x Y idle connections (X: TCP connections per app, Y: applictions) prevent your radio from sleeping?

In the worst case, if the pings aren't sent at the same moment and all applications have a timeout set to, let's say, 30 minutes, your phone will send a ping every 30/(X*Y) minutes. I don't know what the usual X and Y would be, but if they're high enough your radio will always be up (check out these slides, 23 in particular: https://www.igvita.com/slides/2013/io-radio-performance.pdf)

And that's only counting idle applications. If you have one that periodically polls a server, it gets even worse.

[Flowdalic]

Course, you shouldn't poll and if those mechanisms aren't coordinated, then you you will suffer. But that's why Android provides the AlarmManager API and I would expect other mobile platforms to provide something similar.