aboutsummaryrefslogtreecommitdiffstats
path: root/src/main/java/de/pixart/messenger/entities (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-03-16do not merge oob messagesChristian Schneppe1-0/+2
2020-02-17do not warn user if bookmark already existsChristian Schneppe1-7/+1
2020-02-02show audio artist and title for audio filesChristian Schneppe1-0/+1
2020-01-31optimize importsChristian Schneppe1-1/+2
2020-01-24omemo changes: use 12 byte IV, no longer accept auth tag appended to payloadChristian Schneppe2-4/+4
2020-01-24make registration uris work with fixed usernamesChristian Schneppe1-0/+2
2020-01-24support registration via pars tokensChristian Schneppe1-0/+4
2020-01-02persist file size across abortsChristian Schneppe1-1/+5
2020-01-02make parts in Message.java finalChristian Schneppe1-1/+1
2019-12-09properly restore LMC edits. switch to LMC v1.1Christian Schneppe3-89/+109
2019-12-08show jabber accounts from local address in Quicksy flavorChristian Schneppe1-4/+10
2019-12-03Disable NewLines in Base64 values (#416)FH1-1/+1
Smack gets confused and throws NullPointerException when Base64 contains newlines. Therefor disable newlines in Base64. I assume newlines in Base64 are also not expected by other implementations.
2019-11-15prevent crash when counterpart in message was nullChristian Schneppe1-2/+6
2019-11-04rework message deletionChristian Schneppe2-1/+9
2019-11-03optionally search local muc rooms instead of jabber.networkChristian Schneppe1-0/+88
2019-11-02introduce setting to completely disable (OMEMO) encryptionChristian Schneppe1-0/+3
2019-10-26attempt to fix some rare crashesChristian Schneppe1-1/+1
2019-10-26update ui after bookmark changeChristian Schneppe1-2/+3
2019-10-26bookmarks2. introduce #compat namespaceChristian Schneppe1-2/+2
2019-10-26Bookmarks2: support retractionChristian Schneppe2-30/+46
2019-10-26WIP Bookmarks 2 supportChristian Schneppe1-7/+70
2019-10-26LMC: find replacedMessages based on bare JIDChristian Schneppe1-3/+6
2019-10-26mark cancelled jingle ft as such on both sidesChristian Schneppe1-1/+2
2019-09-20migrate to AndroidXChristian Schneppe6-9/+9
2019-09-13parse LMC 1.1Christian Schneppe2-2/+20
2019-09-13keep track of previously edited idsChristian Schneppe2-13/+103
2019-09-12show language in message bubble if multiple language variants were receivedChristian Schneppe2-6/+23
XML and by inheritence XMPP has the feature of transmitting multiple language variants for the same content. This can be really useful if, for example, you are talking to an automated system. A chat bot could greet you in your own language. On the wire this will usually look like this: ```xml <message to="you"> <body>Good morning</body> <body xml:lang="de">Guten Morgen</body> </message> ``` However receiving such a message in a group chat can be very confusing and potentially dangerous if the sender puts conflicting information in there and different people get shown different strings. Disabling support for localization entirely isn’t an ideal solution as on principle it is still a good feature; and other clients might still show a localization even if Conversations would always show the default language. So instead we now show the displayed language in a corner of the message bubble if more than one translation has been received. If multiple languages are received we will attempt to find one in the language the operating system is set to. If no such translation can be found it will attempt to display the English string. If English can not be found either (for example a message that only has ru and fr on a phone that is set to de) it will display what ever language came first. Furthermore we will discard (not show at all) messages with with multiple bodies of the same language. (This is considered an invalid message) The language tag will not be shown if we receive a single body in a language not understood by the user. (For example operating system set to 'de' and message received with one body in 'ru' will just display that body as usual.) As a guide line to the user: If you are reading a message where it is important that this message is not interpreted differently by different people (like a vote (+1 / -1) in a chat room) make sure it has *no* language tag.
2019-09-09introduce new file transfer statusChristian Schneppe1-0/+1
2019-09-03fix some crashesChristian Schneppe2-4/+12
2019-08-31do not put default nick into bookmark if none has been set beforeChristian Schneppe1-6/+10
2019-08-31create empty disco result on error to fire advance stream features eventChristian Schneppe1-0/+12
2019-08-31resetToWaiting should include http uploaded filesChristian Schneppe1-1/+1
2019-07-17handle blocking and unblocking of full jidsChristian Schneppe1-0/+92
2019-07-01migrate copy ond write list to synchronized hashset for pending mucsChristian Schneppe1-2/+2
2019-07-01rate limit muc pings / joins. never run two pings at same timeChristian Schneppe1-0/+1
2019-07-01implement FCM push for group chatsChristian Schneppe1-0/+1
2019-07-01code cleanup & small fixesChristian Schneppe1-1/+1
2019-06-25implement client support for muc pushChristian Schneppe1-0/+5
Staying connected to a MUC room hosted on a remote server can be challenging. If a server reboots it will usually send a shut down notification to all participants. However even if a client knows that a server was shut down it doesn’t know when it comes up again. In some corner cases that shut down notification might not even be delivered successfully leaving the client in a state where it thinks it is connected but it really isn’t. The possible work around implemented in this commit is to register the clients full JID (user@domain.tld/Conversations.r4nd) as an App Server according to XEP-0357 with the room. (Conversations checks for the push:0 namespace on the room.) After cycling through a reboot the first message send to a room will trigger pubsub notifications to each registered full JID. This event will be used to trigger a XEP-0410 ping and if necessary a subsequent rejoin of the MUC. If the resource has become unavailable during down time of the MUC server the user’s server will respond with an IQ error which in turn leads to the MUC server disabling that push target. Leaving a MUC will send a `disable` command. If sending that disable command failed for some reason (network outage) and the client receives a pubsub notification for a room it is no longer joined in it will respond with an item-not-found IQ error which also disables subsequent pushes from the server. Note: We 0410-ping before a join to avoid unnecessary full joins which can be quite costly. Further client side optimizations will also suppress pings when a ping is already in flight to further save traffic.
2019-06-20show own account in chatlist/contacts/conferences if you are in multi ↵Christian Schneppe3-6/+13
account mode
2019-06-20attempt to keep messages waiting until muc is connectedChristian Schneppe1-0/+1
2019-06-08synchronize around attributes in toContentValues()Christian Schneppe1-1/+3
2019-06-08performance improvementsChristian Schneppe1-2/+1
2019-05-18performance improvementsChristian Schneppe2-6/+8
2019-05-04go forward through cursor in message restoreChristian Schneppe1-26/+13
We have seen some weird CursorIndexNotFoundException that we were unable to reproduce. We assume that going forward (moveToNext()) through the cursor instead of (moveToPrevious() fixes that issue
2019-05-04small message optimizationsChristian Schneppe1-2/+2
2019-05-03introduced type private_file_message to handle attachments in PMsChristian Schneppe2-14/+46
2019-05-03store correcting message in dbChristian Schneppe1-5/+4
2019-05-03put PM hint above edittextChristian Schneppe1-0/+2
2019-04-12show users nick in chat if it's setChristian Schneppe1-1/+1
2019-03-31fix url detection for webpreviewsChristian Schneppe1-1/+2