3 ms·

Mobile OSes (such as Android and iOS) heavily restrict what apps can do in the background, or even terminate them entirely when they are not in the foreground.

Mobile OSes (such as Android and iOS) heavily restrict what apps can do in the background, or even terminate them entirely when they are not in the foreground. This is to increase battery life, etc. For many apps, notifications are important. Using Mastodon as an example - if someone mentions you on Mastodon, your app should tell you. But unless you actually have the app open, it won't be able to receive any notification from your Mastodon server due to the OS restrictions. As a solution, the OS vendors created special services embedded into the OS that are allowed to maintain a persistent network connection to the OS vendor's cloud servers. Then if an app developer wants their app to display a notification, they obtain an API key from the OS vendor and connect to the OS vendor's API and submit their notification to it. The OS vendor's servers will then deliver the notification to the notification service on the device, the notification service will display it to the user or wake up the app. Google's service (Firebase Cloud Messaging (FCM)) and Apple's Push Notification Service are proprietary things. On Android, there are free and open-source apps that don't link to Google's proprietary components, including their notification service. F-Droid is an FLOSS "app store" that will not distribute apps using Google's APIs in their repository. Some "de-Googled" Android flavours remove the component entirely from the OS. However some developers still would like a way for their app to receive notifications without constantly polling (repeatedly making requests to check for new data) in the background. It's annoying and not very efficient (for network usage or battery). UnifiedPush is an open API/specification that provides an alternative to the proprietary APIs. It allows you to set up a "distributor" app which will relay notifications to the other apps on your device. The distributor app generally keeps a single open connection to a server, and waits for notifications to come in. App developers can deliver notifications to the user's chosen notification server using a standard API, and know that it can reach their device. The OS vendors are no longer in the loop. Conversations is a messaging app, usually used for chats/calls like any other. It uses an open messaging protocol called XMPP, which has a bunch of open-source servers and clients, and can be self-hosted. Conversations already maintains a connection to the XMPP server, and XMPP already has various optimizations to minimize network activity and battery usage. The Conversations developer has developed a way to re-use the existing XMPP connection for notifications, as well as your messaging traffic. Conversations acts as a "distributor" and will relay notifications to other apps on your device that support UnifiedPush. Hope this helps! It can be a lot to take in :)

jesprenj 4y ago
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.
- MattJ100 4y ago
  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 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.
- fIREpOK 4y ago
  > Why is a separate notification proxy better than letting apps run in background and take care of their notifications? Another likely reason is that Google gets a lot more data by using this method, even if the power consumption was also initially a concern.
- 4y ago

jesprenj 4y ago

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.

MattJ100 4y ago
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 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.
fIREpOK 4y ago
> Why is a separate notification proxy better than letting apps run in background and take care of their notifications? Another likely reason is that Google gets a lot more data by using this method, even if the power consumption was also initially a concern.
4y ago