This change also fixes a bug when bottom buttons in the crop screen
were not visible. That happened because ImageEditorBottomBar by default
had its controls hidden (with the intent that they are animated in once
view controller's view is visible). That was a poor design choice on my
end and is fixed in this commit.
This disgusting hack removes GRDB's notification
center observers, which prevents it from calling
`DatabasePool.releaseMemory()`.
`releaseMemory` is harmful because it places all
future reads behind a dispatch barrier. The effect
is that even very short reads block on any db
reads that precede the barrier. Some of those can
be very slow, such as orphan message handling.
The practical effect of this barrier is that the
main thread gets stuck on what should be a very
quick operation, such as loading your own avatar
data. iOS can kill the app with 8badf00d.
This change is a temporary workaround. A proper
solution has been added to a PR that I sent to
GRDB, which you can see here:
https://github.com/groue/GRDB.swift/pull/1253
Once that is accepted upstream we should update
GRDB and revert this commit.
This change should fix IOS-2474 and doubtless many
other issues.
This are unused since things got refactored in ec66f3b21e. It
appears as though `contentDescription` is just called directly rather
than calling these wrappers.
This block is the system-level block for the contact. Extends the previous
work dropping calls for Do Not Disturb, where RingRTC is prevented from
sending a Hangup message, which allows other devices to continue ringing.
This snoozes the megaphone as soon as we *might* charge your card, even
if it ultimately fails. Even if that job fails, you probably already
know you can donate.
A couple of codegen scripts had an `--intermediates` flag. While I was
playing around with this (fixing something else), I noticed that these
flags don't work and cause a crash.
Instead of fixing those bugs, I thought it'd be better to just delete
this flag because I don't think anybody uses it.
Tested this by running `make` in the `sds_codegen/` directory, with
success.
Previously, sending a gift badge was not a durable operation, which
meant that crashes/failures could cause users to have their payment
methods charged without actually sending the badge.
Now, the flow is split up into two steps: non-durable parts before the
charge is attempted, and durable parts afterward.
The high-level flow is:
1. Prepare the payment, which involves a couple of repeatable network
requests.
2. Enqueue a job with the prepared payment, that:
1. Charges the payment method (idempotently)
2. Requests a receipt credential (idempotently)
3. Enqueues a gift message, and optionally a text message
3. When the job completes, open the conversation in the UI.
The `bottomBar.height` value includes the layout margin at the bottom,
and the `presentToast` method will count this as well, resulting in the
view being placed too high on devices with a notch/home indicator.
The database writes are ultimately serial, so there’s little benefit to
scheduling each of these on its own queue. If another slow-ish write is
already happening, there’s a chance that we may see thread explosion,
with many threads waiting to write to the database.
Previously, we checked capabilities on the "choose gift recipient"
screen. If you had stale profile data, people might _seem_ incapable,
but a later profile refresh would render them capable. We could have
solved this in a few ways, but I matched Android: check the capability
right before sending.
The pseudocode used to be something like this:
```python
def allowed_candidates(all_recipients):
for recipient in all_recipients:
if recipient.is_locally_capable:
yield recipient
```
The pseudocode is now something like this:
```python
def press_donate_button():
if recipient.is_locally_capable:
is_capable = True
else:
fetch_profile(recipient)
is_capable = recipient.is_locally_capable
if is_capable:
authorize_apple_pay_and_send_badge()
```
