* Use the migration's transaction for each migration's operations
* Add check before running each individual migration plus explanatory comments
* Remove potential race with initial schema setup
* Add result return type to migrations
* add explanatory comment
* Update checkmark icons (for selection rows only)
* Use selected/unselected checkmarks on my story privacy settings
* Initially show no setting on my stories privacy. Require setting to select My Story in recipient picker
* Clear my story privacy settings from debug ui
* design request: keep the all connections view button if unselected
* Same size for story privacy rows with and without detail text
This change should have no user impact.
`Error+isRetryable.swift` is now `Error+IsRetryable.swift`, and others
like it.
To find the files, I ran this:
git ls-files | grep -E '\+[a-z]'
_I recommend reviewing this with whitespace changes disabled._
The server's `global.donations.apayDisabledRegions` is a list of regions
(phone number prefixes) where Apple Pay is disallowed. This respects
that.
This change should have no user impact.
Previously, badges stored their raw category string (e.g., `"donor"`).
Now, they store an enum.
We already had this enum but never used it!
This change should have no user impact.
This converts `OWSFakeCallMessageHandler` to Swift (renaming it to
`FakeCallMessageHandler`). It was a mechanical conversion.
Currently, only some `JobQueue` types are initialized during startup
(as part of `Environment`, or `SSKEnvironment`). Initialization is
required, however, for a `JobQueue` type to restart any latent jobs.
That means that, for example, a durable `SendGiftBadge` job that failed,
and should be reattempted at a later date, will not in fact be restarted
since no `SendGiftBadgeJobQueue` will be initialized at launch.
This change adds `SSKJobQueues` and `SignalMessagingJobQueues` types,
which are intended to be singletons that hold within them a singleton
job queue for each of our `JobQueue` types. These wrappers are added to
`SSKEnvironment` and `Environment` (from SignalMessaging) respectively,
ensuring that all the `JobQueue`s they contain are initialized as part
of environment setup. The wrappers also avoid the need to add a new
property to the (already large) environment types for each new future
`JobQueue`.
This change also updates all existing call sites that accessed a
`JobQueue` from an environment object, to direct that access now through
the wrapper type.
Previously, one-time donations were on one screen and monthly donations
were on another. Now, they're on a single screen with a picker.
Most of the interesting changes are in `DonateViewController`.
Other things of note:
- There are some new TODOs here for existing bugs I didn't fix. For
example, one-time donations don't do so well if there are any problems
at all.
- Even though we only support Apple Pay, there's code that alludes to
additional payment methods. For example,
`DonateChoosePaymentMethodSheet`. We'll expand on this in the future.
- Users should only be able to select currencies that the server
supports. For example, you shouldn't be able to select EUR if the
server doesn't support euros. This wasn't working correctly before,
but is fixed here.
We already fixed one part, where users could change to an unsupported
currency (see dab02f30ae). However, if
your _default_ currency is unsupported and you didn't change it,
that's no good. This is unlikely for most users but could happen.
I fixed this by changing it from (effectively)
`Locale.current.currencyCode ?? "USD"`, which might not be supported,
to a preference list, choosing the first one the server likes.
- I skip animations if the Reduce Motion setting is enabled.
- On the donation screen, the logic for the preview badge has changed
slightly. If you already have a badge, we'll always use that.
* Remove "@objc" attribution in places related to ConversationInputToolbar where that is no longer necessary.
* Swiftify LinkPreviewState protocol.
* Convert ConversationScrollButton to Swift.
_This change should have no user impact._
We add some stuff to `String` in `SignalServiceKit`.
Before, we tested this in the `SignalTests` target. Now, it's in the
`SignalServiceKitTests` target.
All I did was move some lines. I didn't change the tests at all.
I think this is a good change on its own but it may be useful in an
upcoming change.
This adds a table of "cancelled group rings", to handle out-of-order
delivery between a cancellation and a ring. (This can happen when the
cancellation comes from a linked device rather than the original
ringer, though it's very unlikely.) Thirty-minute-old cancellations
are cleared lazily.
This also adds a new IncomingCallControls to replace the usual
CallControls in a GroupCallViewController.
And finally, there's a lot of code that was 1:1-call-specific that now
handles group calls as well, either by being more general or by
checking which kind of call we have.
* Encapsulate mutable state of MediaGallerySections.
This is the first baby step toward imbuing
MediaGallerySections with multi-version
concurrency.
* Store rowid for each item in MediaGallerySections
This is necessary for forthcoming asynchronicity
as well as to correct existing problems where an
IndexPath is used as an identifier for an item.
IndexPath is a bad identifier because a database
change can invalidate it at any time. This will be
needed, for example, by an async ensureItemLoaded
method.
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)
