This change may improve performance slightly but should have no other
user impact.
`myString.isEmpty` is faster than `myString.count == 0` or equivalent,
because computing `count` may require iterating over the string.
I tried to fix all occurrences of this.
Tested this by sending a message in a group and doing a full
re-registration, just in case I broke something there.
If we queue N UUIDs [1, 2, ..., N], we’ll send a request to fetch all of
them. If we queue those same N UUIDs again, we’ll stop processing after
the first one, without sending any fetch request.
We’ll start processing again the next time `process()` is called. This
could happen in response to network availability changing, or it could
happen in response to scheduling the N+1’th UUID. (Though, we won’t
necessarily fetch the N+1’th UUID in this case -- we’ll fetch the 2nd.)
These cached results also expire after a few minutes or a few hours,
depending on the most recent result. Therefore, this fetcher may behave
somewhat erratically, where it fetches profiles, stops for a few
minutes, then starts fetching profiles again.
As far back as 823927685d, the profile
updates were asynchronous. At that point it time, it didn’t matter
because there wasn’t a completion block; callers couldn’t know when the
updates *should* be complete, so it didn’t matter when they finished.
However, in 856fef7664 a Promise result
was added, presumably to allow callers to know when it was safe to check
GV2 capabilities. Now, a cursory reading of the API would suggest that
all changes were persisted once the Promise was resolved.
This can result in bugs, such as [this example][0], where we fetch the
profile and then check a capability in the database. Even though it’ll
*probably* be the case, there’s no guarantee that the updated profile
will be persisted when we try to fetch the latest capability.
[0]: 465d00664b/Signal/src/ViewControllers/AppSettings/Donations/BadgeGiftingConfirmationViewController.swift (L69-L88)
This change should have no user impact.
We commonly pair a currency, like USD, and an amount, like 1.23. This
adds the `FiatMoney` struct. It's a simple struct with two fields.
After adding it, I tried to use it everywhere. (It's possible I missed a
spot.)
I think this is a useful change on its own, but it'll be nice for an
upcoming change, too.
See also: [Android's equivalent class][0].
[0]: cb65347bb3/core-util/src/main/java/org/signal/core/util/money/FiatMoney.java (L1)
* fix story views + replies sheet header update when swiping
* fix my story privacy show more off-by-one
* Disable story sends when hiding a group story. Unhide when enabling story sends to a group story.
* More consistent story tab bar badge offset
* Observe story viewed ring changes in ConversationAvatarView itself
* Manage ConversationAvatarView's story observation based on the context
* remove story state from thread view model, now unused
* pr feedback renames
We use RequestMaker in three places: fetching pre keys, sending
messages, and fetching profiles. In the former two cases, we want to
kick off profile fetches when certain errors occur.
However, in the latter case, we’re already doing a profile fetch, so we
don’t need to kick off another.
- If the UD request fails for a profile fetch, the next thing we try
will be a non-UD profile fetch. In the prior version of the code, we’d
also kick off a fresh profile fetch; since we just marked UD as
disabled, this would initiate a redundant non-UD profile fetch.
Instead, we can just rely on the non-UD request that’s underway.
- When a UD request succeeds & we didn’t know the UD access mode, we
update the access mode to the one we used. In the prior version of the
code, we’d also kick off a profile fetch with this access mode.
However, if this is part of a profile fetch, we’ve *just* gotten the
latest profile with the access mode we just saved, so there isn’t a
reason to immediately initiate another fetch.
* Shuffle code around, adding UnsentTextAttachment
* Replace usages of TextAttachment with UnsentTextAttachment where applicable, creating an actual TextAttachment (and associated OWSlinkPreview image TSAttachment, if applicable) only per-recipient
* Only upload one text story link preview image attachment and propagate it to the individual TSAttachments created for each destination
* update comments so I don't lose my mind the next time I read this code
* Dedupe text stories sent to the same person via multiple private threads
* fix non-compiling tests
* pr feedback
* remove unecessary owsFailDebug
* fix context menu icon positioning
* fix layout of custom context menus near the left side of the screen in RTL languages
* UX tweaks for my story cell
* status
* apply theme changes to tab bar that happened while it was hidden
* pr feedback 1
* pr feedback 2
