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?
> 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.
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.
> 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?