The previous way we were getting the next/previous record didn't take into
consideration that some records aren't in the cursor -- some are in the
fastRecords map. We now use the proper position to get the next/previous
message.
For self-sends, we were never marking attachments as uploaded. I made is
so that happens now, but to prevent it for showing for already-sent
messages, we also don't show controls for self-send conversations.
Previously, contact shares would be displayed as "Media Message". Now
it'll show the same as it does in a notification, namely
"{contact-emoji} {contact-name}".
We have to make some changes, and it's gotten to the point where
maintaining it as a separate library is more hassle than it's worth,
especially with Google releasing WorkManager as the preferred job
scheduling library.
Previously, we made each full-text search query a single prefix query.
That means that the query "do c" would turn into "do c*". That means it
would match "do cat" but not "dog cat".
Now, we make each token a prefix query. So "do c" would turn into
"do* c*". That means it would match both "do cat" and "dog cat".
Previously, if a message disappeared while looking at it in the search
results, it'd still stick around. Now they'll disappear from the results
in real-time.
There was an issue where we were backing up group receipts and attachments
that were for expiring messages (which are already excluded from the backup).
This commit excludes these items from the backup, and for backups made
before this change, this commit also deletes these invalid entries at
the end of the restore process.
We also do a little database migration to cleanup any bad state that may
have been imported in the past.
Previously, SQLCipher's memory usage would grow indefinitely, up until
it hit the end of the cursor. We've now switched to a release where the
memory used by the cursor can be bounded.
I think I was initially lured into searching by rank because it gives
the illusion of providing the "best match". However, in practice, FTS
never gives back "bad" matches with low ranks -- all of the results it
returns will contain your query in some form (most commonly a direct
substring, but they do take some liberties if you have multiple tokens
in your queries). Given that, in general, more recent search results are
in fact more relevant, we can sort by date exclusively and get a better
ordering overall.
Previously, we'd always use the recipient of the message record, which
was incorrect for messages sent to groups. Now we always use the
recipient for the matching thread record.
Fixes#7823
The "contact" option in the attachments tray now brings you through an
optimized contact sharing flow, allowing you to select specific fields
to share. The contact is then presented as a special message type,
allowing you to interact with the card to add the contact to your system
contacts, invite them to signal, initiate a signal message, etc.
There's a chance that the AsyncTask that retrieves a quoted message's
position could finish after the fragment is detached, which would cause
a crash. I've changed it so if this case occurs, the result is ignored.
Also, I noticed that when searching the message table, if a quote can't
be found, we'd end up traversing the entire table. To prevent this from
taking forever on large message tables, I've limited it to searchin only
what is currently present in the adapter.
Fixes#7756
Previously, quotes were not saved to drafts, meaning they would be lost
when leaving the conversation or app. Now, a QuoteId (which represents
the necessary data to restore the QuoteModel) is serialized and stored
in the DraftDatabase.
Fixes#7716Closes#7729
Currently, if you're searching for a contact to start a conversation
with or send a share to (via the Android sharing system), groups do not
appear. With this change, groups will now appear when searching, located
under their own heading.
Fixes#7202.
Closes#7577
When viewing a media in the media preview, you can delete it by pressing
a delete button on the action bar. It will then ask you to confirm your
choice. If you confirm, it will delete the attachment from the database
and from disk. If it was the only attachment for that message, the
message itself will also be deleted.
