Hacker News Reader

Comment by kaptainscarlet | Hacker News Reader

XMPP as a protocol is pretty much dead on Android with all the battery optimisations in the newer versions. You can't get a decent user experience unless you integrate it with Firebase.

View on HN

Conversations has supported Google push notifications since 2016, long before Android started getting more aggressive about battery optimizations.

It's been a standard feature of XMPP mobile apps for as long as it's been necessary.

These are surely not purely client-side XMPP... clients, though? In order for you to receive push notifications, some server somewhere is connecting as you in order to relay the messages through GCM.

There is an XMPP standard for asking your own server to send "new message" pings via a GCM proxy. Nothing has to "connect as you".

Server pings are almost useless in dozemode.

No need for a relay. The actual XMPP servers nowadays support GCM natively. The client generates a GCM token and just hands that to the XMPP server. The server doesn't have to send actual message content either, it can just be a "wake up, there's a new message" ping the app can handle specially.

Even if you send the wake up. You can't open an xmpp connection in the background

I know. But they had to resort to a not-so-pretty foreground service to get around battery optimisations. Do you call that a good user experience?

Many apps do that, it allows the app to stay connected which (perhaps counter-intuitively) is more efficient for realtime apps. It's entirely optional though, and even if the app has such a notification it can be hidden. On some ROMs however, even the notification does not suffice and the app gets killed anyway. Thanks to push notifications, it still works.

In any case, this is the choice of a specific implementation, and not something inherent to XMPP. Your original comment said that integration with Firebase was needed, and I wanted to point out that it is already integrated.

More on the app-killing ROMs can be found at https://dontkillmyapp.com

This was quite the opposite for me. Main reason my wife and I used XMPP for several years was because Conversations was the only app to get timely notifications on both googled and de-googled Android. And this worked until at least Android 11. At the time, Riot.im (now Element) either drained my battery checking for notifications without Google Play Services, or seemed to work fine, but did not get notifications in time even with Google Play Services.

What you're describing also has been true for iOS for a while. Apps cannot do long-polling and require a push notification server (usually provided by the app maker, e.g: siskin, snikket, chatsecure), and that adds another point of failure.

Yes. Once an Android device goes into doze mode, there is nothing an app can do to sync in the background.you have to somehow extend your xmpp to route some messages via firebase which I believe whatsapp is doing

Besides what MattJ100 wrote above, by itself this is also not true. You can tell Android to not optimize Conversations and allow it to run in the background. It will work just fine with a (usually idle) TCP connection. But for the typical user, having to instruct them to do this is cumbersome, and integrating with Firebase is easier. It does come with its own concerns w.r.t. privacy, both for the payload as well as metadata exchanged.

Pardon for a tangent!

I've been so full of missing and delayed notifications I just bought an iPhone, which has zero issues with it, with zero configuration.

Still, as I made a few really small android apps in the past, this has been a sticking point for me for years.

Is it possible to write an app that can notify at ANY time? Let's say I want to monitor my self-hosted infrastructure. On an iPhone I get e-mail alerts right away. On Android, some ring exactly at the time I pick up the cursed phone.

I checked for every possible consumer facing configuration option (deep sleep exclusion, background service allowed, etc.) and I found zero reliable options.

Ntfy.sh seems to work perfectly on stock Android without firebase/GSF. I do have "unrestricted" enabled in app settings but it doesn't seem to impact battery life in a noticeable way. I never missed any notifications.

Once you leave AOSP-land it can be more tricky, https://dontkillmyapp.com/ has more info if you're interested.

Thank you!

This actually looks very relevant [1]:

> Even disabling the system battery restrictions does not save the app from being killed. Let's find out, if it is a bug or a feature... Here you can read more details

I have Samsung s21; after years of fighting it (3 samsungs) I'm welcome to a bug explanation

- [1] https://dontkillmyapp.com/samsung#:~:text=Even%20disabling%2...

iphone doesn't solve it... XMPP apps on iphone just use a server to be your agent and send push notifications instead.

It solved "delayed notifications" for me, for certain: I still have original Samsung next to iPhone and it's clear as day:

- iPhone rings, Samsung nothing

- I wait few minutes just to be sure and pick up Samsung - immediately after picking it up the notification shows up, with the exact timestamp of the moment I picked it up

That's why I called it a tangent to XMPP

I think this is because iphone has never allowed background apps to hold open persistent connections, yet android does but with device and power-state specific limitations.

So the iphone version of any xmpp app has to use apples notification service, but the android version of the same app might try to use a direct connection (saving the app developer a lot of server costs), even though on many models of phone it only works when the device is charging for example.

Most android devices do that - sleep-state an application and it won't tell you anything until you actively pick up the device and use it. Been like that since I had my Kyocera DuraForce Pro on Android 6 or 7.

Yes, and there is an option to opt-out of that list. I did enable that.

I'll phrase my issue differently: Is there any way to have reliable notification delivery that are time critical? Is actually calling the only 100% reliable option, as the PagerDuty does?

Push notifications via play services are the only reliable way. They work even with battery saver on (but not extreme battery saver, unless the app is excluded).

Note that you can only have one push notification reliably per user interaction. So once you have sent a notification, further ones won't be reliably delivered until the user interacts with your app in some way.

That's perfect, thank you!

UnifiedPush distributors such as ntfy.sh seem to work pretty well, in my experience. They don't seem to affect battery life much (at least according to system graphs) and they work well.

Reply on news.ycombinator.com