Fixed an issue where jumbomoji were not properly being rendered
when using system emoji. Also fixed an issue where the text
content wasn't properly being recalculated when the view is
resized.
Fixes#7875
1. Switch to using default text rendering if there's no emoji present in
the string.
2. Reduce redudant redraws by skipping of setText() calls for identical
strings.
Together, these two changes should reduce the vast majority of
flickering we see with EmojiTextView ellipsizing.
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.
If a search result snippet spans two lines, we only show the first line.
For the purpose of display, we first remove all newlines in order to
make the full snippet visible.
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
Glide will use the dimensions of the target ImageView as the dimensions
for the image it's loading. This caused problems in the case of
ThumbnailView, as we were constantly changing the ImageView dimensions,
meaning Glide may not have the most recent values (it may be called in
between measure calls, for instance).
To solve this, we now will always override the default image dimensions
when we load an image. If no dimensions are present, we will default to
the layout_width and layout_height of the ThumbnailView.
Fixes#7810
Notifications for replies will no longer display as a "Media Message" if
they do not contain media. Instead, they will just contain the reply
text.
Fixes#7798
Sending shared contacts isn't backwards-compatible, so we want to have a
few releases where receiving is enabled, but not sending. That way, when
we enable sending, most users should be able to properly receive the
shared contact messages.
When you share a vCard from an external app (like the Contacts app) into
Signal, we'll now convert it to a pretty Shared Contact message and
allow you to choose which fields of the contact you wish to send.
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
Did a refactor to better organize the camera flipping code. Also, I
wanted to make sure we handle the cases where the user doesn't have two
cameras (or no cameras, for that matter). In these cases, we just don't
show the appropriate buttons.
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
Unfortunately, the change wasn't as simple as just switching to use our
EmojiTextView. That view only supported single-line text. I added
support for multi-line text.
Fixes#7704.
We now check if _any_ text is selected when doing a batch selection
to determine if we should show the copy option. Also, previously it
was putting in empty lines for messages that don't have any text. I
changed it so empty messages have no effect on the text that is copied.
Fixes#7472
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
Previously, we were always rendering images as squares. Instead of doing
that, we now render them as close to true-to-size as possible (within
reasonable min/max width/height boundaries).
Strip all EXIF metadata from all JPEGs by re-encoding the JPEG. This
will keep all of the necessary visual effects of the tags (by encoding
them directly in the image data) while stripped the EXIF tags
themselves.
It is now possible to batch-delete media in the "media overview" screen.
You can long press to enter multi-select mode. Then a delete button
appears on the menu bar. After pressing delete, you will get a
confirmation, and if the user confirms, the items will delete while a
progres dialog shows.
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.
In a number of locations in the code, there were conversions of message
expiration times from seconds to milliseconds, and then assigned to `long`
contexts. However these conversions were being done as integer multiplication
rather than long multiplication, meaning that there was a potential for
overflows.
Specifically, the maximum value that could be represented before overflowing
was (2^31 / 1000 / 60 / 60 / 24) days = 24.8 days (< 1 month). Luckily the
current allowed timeouts are all less than that value, but this fix would
remove the artificial restriction, effectively allowing values of 1000x greater
(68 years), at least for android.
Related #5775Closes#7338
