From a0be2dc54fdc8c1d42559cb256cd2e501d0b7624 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Mon, 21 Jan 2019 11:55:52 +0100 Subject: [PATCH] updated readme --- README.md | 4 ++++ src/main/java/eu/siacs/conversations/entities/Message.java | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 1d816e197..b9f7466c4 100644 --- a/README.md +++ b/README.md @@ -195,6 +195,10 @@ You can find a detailed description of how your server, the app server and FCM a ¹ Your server only needs to support the server side of [XEP-0357: Push Notifications](http://xmpp.org/extensions/xep-0357.html). If you use the Play Store version you do **not** need to run your own app server. The server modules are called *mod_cloud_notify* on Prosody and *mod_push* on ejabberd. + +#### But why do I need a permanent if I use Google Push? +FCM (Google Push) allows an app to wake up from *Doze* which is (as the name suggests) a hibernation feature of the Android operating system that cuts the network connection and also reduces the number of times the app is allowed to wake up (to ping the server for example). The app can ask to be excluded from doze. Non push variants of the app (from F-Droid or if the server doesn’t support it) will do this on first start up. So if you get exemption from *Doze* or if get you get regular push events sent to you Doze should not pose a threat to Conversatons working properly. However even with *Doze* the app is still open in the background (kept in memory); it is just limited in the actions it can do. Conversations needs to stay in memory to hold certain session state (online status of concats, join status of group chats, …). However with Android 8 Google changed all of this again and now an App that wants to stay in memory needs to have a foreground service which is visible to the user via the annoying notification. But why does Conversations need to hold that state? XMPP is a stateful protocol that has a lot of per-session information; packets need to be counted, presence information needs to be held, some features like Message Carbons get activated once per session, MAM catchup happens once, service discovery happens only once; the list goes on. When Conversations was created in early 2014 none of this was a problem because apps were just allowed to stay in memory. Basically every XMPP client out there holds that information in memory because it would be a lot more complicated trying to persist it to disk. An entire rewrite of Conversations in the year 2019 would attempt to do that and would probably succeed however it would require exactly that; a complete rewrite which is not feasible right now. That’s by the way also the reason why it is difficult to write an XMPP client on iOS. Or more broadly put this is also the reason why other protocols are designed as or migrated to stateless protocols (often based on HTTP); take for example the migration of IMAP to [JMAP](https://jmap.io/). + #### Conversations doesn’t work for me. Where can I get help? You can join our conference room on `conversations@conference.siacs.eu`. diff --git a/src/main/java/eu/siacs/conversations/entities/Message.java b/src/main/java/eu/siacs/conversations/entities/Message.java index 44ba36270..772cf5b85 100644 --- a/src/main/java/eu/siacs/conversations/entities/Message.java +++ b/src/main/java/eu/siacs/conversations/entities/Message.java @@ -491,7 +491,7 @@ public class Message extends AbstractEntity { return Collections.unmodifiableSet(this.readByMarkers); } - public boolean similar(Message message) { + boolean similar(Message message) { if (type != TYPE_PRIVATE && this.serverMsgId != null && message.getServerMsgId() != null) { return this.serverMsgId.equals(message.getServerMsgId()) || Edited.wasPreviouslyEditedServerMsgId(edits, message.getServerMsgId()); } else if (Edited.wasPreviouslyEditedServerMsgId(edits, message.getServerMsgId())) {