Why is a separate notification proxy better than letting apps run in background and take care of their notifications? A simple poll() shouldn't waste much CPU, right? I think that is what my IMAP client and the mentioned conversations XMPP client do.
Is the overhead of having 1 TCP connection in idle state really noticably better than having ~20, each for every app? How does UnifiedPush work with apps with traditional protocols, e. g. IMAP/XMPP - I assume the remote server itself must be logged in to your IMAP/XMPP.
I never fully understood Google's mobile notifications.
If every app held open a truly idle TCP connection, only exchanging data when necessary, you're right. Open idle connections are pretty lightweight.
There are a number of problems. One is that apps weren't doing that. It's too tempting for app developers to do things like HTTP polling instead. Then you have apps all polling at different intervals, and then on average the phone's radio is constantly in an active state even if the user isn't doing anything.
Even if apps correctly used persistent connections, it's actually tricky to maintain a persistent connection. There is a balance between reducing traffic and detecting that the connection has failed (using keep-alives, etc.). After a network transition, connections must be re-established. Doing that once is cheaper than doing it N times, once per app.
XMPP servers do support push notifications (e.g. via Apple/Google), though they aren't usually necessary on Android unless you have an overly aggressive one ( https://dontkillmyapp.com ). On iOS they're practically essential.
It makes less sense for XMPP clients to use UnifiedPush, because if you're in an environment where you are able to have something constantly running as a UnifiedPush distributor and maintaining a persistent connection, you might as well make that something be your XMPP app, which can reuse the same connection for more than one thing.
It isn't about using the CPU. It's about waking from sleep to keep the connection alive, and being able to kill background apps to save memory.
It's a battery saving feature.
UnifiedPush is just here so that an app can tell other apps it already maintains a persitent connection, and can forward notifications.
You'd have to sync TCP keepalives across different apps otherwise. Moreover, UnifiedPush is transport-agnostic. Here, it's XMPP. It could be SMS or LoRA too, handled by a low power microcontroller or the modem itself.
Is the overhead of having 1 TCP connection in idle state really noticably better than having ~20, each for every app? How does UnifiedPush work with apps with traditional protocols, e. g. IMAP/XMPP - I assume the remote server itself must be logged in to your IMAP/XMPP.
I never fully understood Google's mobile notifications.