This fixes 10 of our Xcode warnings:
- `MessageReactionPicker.swift` was declaring a variable and not using
it, leading to "Immutable value 'emoji' was never used". I simply
removed it.
- `Stripe.swift` had a bunch of unnecessary `public`s, which caused
"'public' modifier is redundant for static property declared in a
public extension".
- `SubscriptionManager.swift` had an unnecessary `try`, causing "No
calls to throwing functions occur within 'try' expression".
- `CallService.swift:696` was calling a function and not using its
result, so I annotated that function with `@discardableResult`.
- `MobileCoinAPI+Configuration.swift` declared a variable with `var`
that should've used `let`.
Nothing major here, but wanted to find ones that were easy to fix.
*Most* of the identity store's duties are about the identity keys of
people you talk to, but it also provides the local identity key (and
registration ID), and the local identity key differs by PNI.
This design fetches the local identity key up front in preparation for
supporting Change Number flows better, where you may need to use a
past PNI identity key to decrypt a message. (That's just one possible
implementation strategy, though.)
...if the call was more than five minutes ago. This should help in two
scenarios:
- you've been offline for a while, and you see "missed call" but don't
know when they tried to call
- you hit that NSE bug where a ring gets processed hours or even days
later, possibly when a second call arrives
At launch time, if a primary device doesn't have a PNI identity key,
it should generate one immediately, as well as pre-keys. If a linked
device doesn't have a PNI identity key, it messages the primary to ask
for one; when it gets a response it generates its own pre-keys.
This communicates the PNI identity key to existing linked devices,
which is important for linked devices to initially learn about a PNI,
or for the change of identity that comes with changing your number
(and therefore your PNI). The exact contents of this message will
probably change going forward, but here's a baseline to work off of.
Bulk profile fetching is pretty complicated. It
already limits its impact by throttling the rate
at which it makes requests. I don't think it's
worth trying to make it do batch operations at
this time, so I'm removing this TODO.
This stacks on top of PR #4068
This stacks on top of PR #4065.
This is a simple change that uses the existing
batch profile fetching to get user names.
It adds a test for OWSProfileManager.
Bulk profile fetching is pretty complicated. It
already limits its impact by throttling the rate
at which it makes requests. I don't think it's
worth trying to make it do batch operations at
this time, so I'm removing this TODO.
This stacks on top of PR #4068
This stacks on top of PR #4065.
This is a simple change that uses the existing
batch profile fetching to get user names.
It adds a test for OWSProfileManager.
Updates `UserProfileFinder` to have
`userProfiles(for:,transaction:)` that looks up
many profiles by either UUID or phone number.
Refactors the existing
`userProfile(for:,transaction:)` to use the batch
implementation.
Also adds Refinery.refineNonnilKeys to simplify a
repeating pattern where we need to fetch values
from a database where keys are nonnil. This
provides better type safety versus using
`refine(condition:,then:,otherwise:)` because the
closure can get non-optional keys as input.
Adds tests for the new user profile lookup code.
This stacks on top of PR #4054.
The purpose of this PR is to fetch cached contact
names in a batch. We can fetch their accounts in a
single SQL statement and in the case where many
contacts don't have SignalAccounts, this allows us
to fetch their phone numbers in on SQL statement
as well. There are three cases to consider:
1. There is a signal account: then we just use the
full name on the account.
2. There is a contact we can find by phone number.
Then use the contact's full name.
3. Fail. Other steps will be needed to determine
the full name, such as fetching profiles.
This is the first meaty part of optimizing
fetching display names.
Some contacts fall back to phone numbers as their
display names. This PR fetches them in a single
SQL query via
`OWSContactsManager.phoneNumbers(for:, transaction)`.
To achieve this, this PR introduces
`GRDBSignalAccountFinder.signalAccounts(for:,transaction:)`
to fetch many accounts at once.
In order to fetch many accounts at once, we need
to be able to fetch many values from a
ModelReadCache at once. So this PR introduces
`ModelReadCache.readValues(for:,transaction:)` and
`ModelReadCache.getValues(for:,transaction:,returnNilOnCacheMiss:)`.
Existing methods that operate on a single value
were refactored to use the batch methods.
This PR adds tests for this functionality, which
necessitated changing the visibility of various
private symbols and also improving the fake
profile manager to make it more configurable.
There's also a tiny optimization for Refinery to
avoid calling a closure that has no work to do.
This helps elide do-nothing SQL queries that would
otherwise have been introduced.
'sessionStore', 'preKeyStore', and 'signedPreKeyStore' are no longer
directly accessible; you have to go through
'signalProtocolStore(for:)' instead. This commit mechanically changes
all use sites to use `signalProtocolStore(for: .aci)`, with the
understanding that they will need cleanup in the future.
This is not enough to actually support multiple stores; they still
store in the database under the same keys. That's coming in the next
commit.
