Anyone aware of a conversations fork with support for unified push notifications? Or a similar xmpp android app with omemo (just the same as conversations’ support) and unified push notifications support, available through the official f-droid repor or a f-droid repo if not available from the official ones?
BTW, I noticed !xmpp@lemmy.ml community was locked. Any particular reason for that?
Also, Converstions requests to set unrestricted use of battery, to use battery under background without restrictions. So it seems unified push notifications would help, though this github issue sort of indicates unified push notifications wouldn’t help, so it just tells me there’s no intention to include support for it on Conversations, but not that it wouldn’t help save battery.
Conversions on android keeps a websocket connection open to receive messages. It’s supposed to generate very little overhead in battery consumption. The unified push app on android uses the same technique to provide other apps with pushes. So you could set conversations to be the push provider on your phone and would not need the unified push app any more. This way you would be using the same amount of battery as before.
The conversations xmpp support channel is very helpful if you have further questions: someone there will also very likely know if any apps with unified push support exist.
Ohh, thanks, I’ll try asking there…
BTW, before molly supported unified push notifications, it was also using websocket and that still required to enable unrestricted use of battery, as currently conversations does. Once I the unified push molly version showed up, such unrestricted use of battery was no longer needed. Websocket definitely is much better than GCM/FCM, but it implies, I believe more battery consumption, though perhaps not unbearable.
Jami was also using websockets and required to allow consuming battery on the background as well, and then moving to unified push no longer required that, but in the case of Jami, by being peer to peer, the effect is more noticeable.
All that to say, that other apps have moved to unified push notifications for better battery savings, even though they used websockets before, and curiously enough conversations does take advantage of GCM/FCM push notifications, so is not clear to me why disregarding unified push ones, but it’s always up to the developers/maintainers, and what they need/want to invest on… So that’s why I mentioned I don’t quite get what was mentioned on the github issue, though it was clear to me there’s no intention to provide the support.
There is a tutorial here: https://joinjabber.org/tutorials/service/unifiedpush/
Basically there is no more efficient way to do it than via XMPP, FCM is also an XMPP service. So the best is really to use Conversations as an UP end-point to get notifications from other apps. AFAIK it doesn’t use a websocket, but a native xmpp connection for it, which is even more efficient.
The reason Conversations also supports FCM is that some Android phone vendors are extremely aggressive in putting apps into sleep mode and only FCM notifications work reliably on those.
ohh, I see, is there a setting, besides unrestricted battery use, one can should set as well then? I remember another about background use, but can’t seem to find it…
This is the first post that clarifies why there’s no need for unified push notifications, but still conversations supports GCM/FCM push notifications. I seem though for those phones unified push notifications would help, the same way GCM/FCM does? At any rate, for battery purposes I got it’s not required.
Many thanks !
Sadly these phones kill any app like nfty that tries to receive the UP notifications as well. Only the official system notifications that go through GCM/FCM are privileged and not affected by that.
As the sidebar of the lemmy.ml community explains, it was bugged for a long time due to an Lemmy issue and the community was moved to !xmpp@slrpnk.net
ohh, sorry, I didn’t noticed it, as you can tell…
If I may, what’s the issue with URLs?
Since this community is partially inaccessible due to some change in how URLs are handled
It was an issue during 0.17.x days if I recall correctly. The bug has been fixed, but since the community wasn’t fully accessible for months, it was better to move it.