Attachments need to be mapped back to their messages consistently, and
downloaded attachments should be tracked by the MediaGalleryManager
once this is set up correctly.
The purpose of this change is to alleviate the
main source of CPU-grinding after sending a
message to a large group: about 20% of the total
time is spent decoding and re-encoding messages as
they are fetched from the DB and then updated with
info about which recipients have acknowledged
delivery.
Prior to this commit, we decrypted the payload and
then processed the message in a single rather deep
call tree that began in `processNextBatch`. There
are two completely different paths through this
tree that lead to handling a delivery receipt
because server-generated delivery receipts have
the necessary info in plaintext in the envelope
and client-generated delivery receipts have it in
the ciphertext.
The idea here is to break incoming envelope
handling into two parts.
In the first part, each envelope is decrypted and
other common activities (like handling sender key
distribution messages) are performed. A processing
request is created for each. Next, processing
requests are handled. It's easy to examine a
processing request to determine if it is a
delivery receipt, and if so, for what outgoing
message. Doing so allows the new
DeliveryReceiptContext class to cache message
fetches and combine updates to the same message.
Processing requests are grouped together so that
sequential delivery receipt requests enjoy caching
of messages and coalescing of updates into a
single fetch/decode/encode/commit. Other kinds of
envelopes are handled immediately to avoid
increasing memory pressure that caching multiple
messages could cause.
If your Boost badge expires but it's not your primary badge, our current
text doesn't make perfect sense.
After some discussion, we settled on the following copy change:
```diff
-Your Boost badge has expired and is no longer visible on your profile.
+Your Boost badge has expired and is no longer available to be displayed on your profile.
```
You'd expect this argument to signal a boolean return, but it returns a
`RecipientPickerRecipientState`. I renamed the argument to (hopefully)
make it clearer.
The gist is:
```diff
-foo = foo + 1
+foo += 1
```
Most of the violations were in generated files, so I changed and re-ran the generator.
A few of these violations required implementing some new methods, which I added tests for.
See [the docs for this rule][0].
[0]: https://realm.github.io/SwiftLint/shorthand_operator.html
Co-authored-by: Max Radermacher <max@signal.org>
Co-authored-by: igor-signal <98181527+igor-signal@users.noreply.github.com>
The goal of this commit is to build a "skeleton" UI for sending gift
badges.
It's totally possible that I haven't anticipated future changes
correctly, but my goal was to have each future change be a separate,
unrelated commit. For example, we need some logic to determine whether a
recipient has the "giftBadges" capability. That can be done separately
from the commit to send the badge message.
I also added "TODO (GB)" in these spots.
As with many other badge gifting tasks, this is behind a disabled
feature flag, so it should have no user impact.
_I recommend reviewing this with whitespace changes disabled._
This fixes violations of [SwiftLint's `implicit_getter` rule][0] by
removing explicit getters when an implicit one would do.
[0]: https://realm.github.io/SwiftLint/implicit_getter.html
And fix the presented content type and filename for the attachments in
a quote (it should be the type and filename of the original
attachment, not the thumbnail).
The `Emoji` enum had an [orphaned doc comment][0], which SwiftLint reported.
This updates that file's generator to fix the error. (SwiftLint is disabled for most of the file, though—a bit unfortunate, but probably correct for generated files.)
[0]: https://realm.github.io/SwiftLint/orphaned_doc_comment.html
[SwiftLint's `colon` rule][0] says the following:
> Colons should be next to the identifier when specifying a type and next to the key in dictionary literals.
This fixes a few violations of that rule.
[0]: https://realm.github.io/SwiftLint/colon.html
We sometimes attempt to do N operations at once where up to N of them
end up getting caught by the rate limiter. This should *not* turn into
N push challenges, or else we'll get rate limited for that too.
This removes DatabaseChanges.deletedAttachmentIds and replaces it with
a notification that carries more information: the attachment's thread
and original message received-at timestamp in addition to the unique
ID. With this information, we can correctly refresh the parts of
MediaGallery that may be affected by the deletion. (The previous
implementation was correct for the original version of MediaGallery,
but not the rewritten version I implemented last year. My apologies to
all users seeing crashes here!)
In the new model, deletions from outside of MediaGallery's control
result in reloads of the sections containing the items in question.
This may result in refetching other media that was previously loaded,
but avoids the issue in the previous implementation where existing
loaded items would now be at the wrong offsets.
AVCaptureSession isn't thread-safe to reconfigure, and that includes
stopping a current session. Everything else we did with the session
was on a dedicated queue, but the call to stop it was on the main
queue. Fix that by exposing the existing promise-based stop method to
the CaptureOutput helper.
_I recommend reviewing this with whitespace changes disabled._
This is a minor change; it have no direct user impact.
We have a "pending changes action sheet" which shows up to warn users
that their changes may not be saved. The localization key and comment
indicated that its strings were only for groups, but that's not
true—it's used for lots of things, such as editing your profile or
updating a group's metadata.
