We expose many of these builders to Objective-C, but Swift is unable
to map forward-declarations of those types (@class) back to the real
Swift classes because they're nested within the protos. Since we're
already using fully-qualified names even in Swift (e.g.
"SSKProtoContentBuilder"), nesting isn't worth the trouble it's
causing.
When someone sends a message to your PNI, your responses (from your
ACI) must include a PNI signature, and the sealed sender certificate
you use during this period should include your phone number. This
confirms to the other user that your ACI is associated with your PNI.
This commit adds the state tracking that and ensures that both
TSOutgoingMessage and OWSUDManager check that state when building 1:1
messages and choosing certificates, respectively. Later commits will
set and clear this flag as needed.
TSOutgoingMessage has an existing overridable method
-dataMessageBuilderWithThread:transaction: that returns an
SSKProtoDataMessageBuilder; this makes it easy for the base class to
add a profile key to every outgoing DataMessage message no matter how
the proto gets built. Similarly, we (sometimes) want to put a
PniSignature on every outgoing message (of any kind), so now we have
-contentBuilderWithThread:transaction:. (The PniSignature part comes
next.)
This adds the first screen for badge gifting. It lets you see the gift
badge, pick the currency, and advance to the next screen.
It also adds a skeleton for the next screen, so there's somewhere to
advance to, but that screen is unfinished.
All of this is behind disabled flags, so this should have no user
impact.
I synced translations in e85c289427.
The `zh_TW` translation had a string that caused the file to be
syntactically invalid.
I ran this to fix it:
git checkout e85c2894278bc5d4929b0adbc5123a849e1db61d~1 Signal/translations/zh_TW.lproj/PluralAware.stringsdict
In the long term, we'll fix this string, and this problem will go away.
If we have a Localizable.strings file for a specific language, we should
also include the PluralAware.stringsdict file, even if less than 80% of
the plural strings have been translated.
When adopting a brand new language, it makes sense to wait for some
threshold of strings across the entire app to be available.
However, the same doesn’t apply for the new PluralAware files. If we
already have some translations for a language, we should include all the
translations that are available.
Assume that `L.lproj/Localizable.strings` already exists. Then:
(1) If `L.lproj/PluralAware.stringsdict` isn’t included, all plurals
will appear in the fallback language.
(2) If `L.lproj/PluralAware.stringsdict` is included but there aren’t
any translations, all plurals will appear in the fallback language.
(3) If `L.lproj/PluralAware.stringsdict` is included and has even a
single translation, that string will shown in the app.
(4) If `L.lproj/PluralAware.stringsdict` is included and has 80% of its
translations, all of those translations will be shown in the app.
This change address (3) without changing the behavior for (1) and (2).
Sealed sender certificates come in two flavors: one with our local
phone number, and one without. Add an automated test for picking the
right one based on our phone number sharing mode (everybody,
contacts-only, nobody).
This commit also adds a convenience helper for tests that want to wait
on promises that might run on the main thread.
The subscription currency picker lets you choose currencies that are
supported by the client but not the server.
For example:
- The client supports USD, EUR, and GPB in its hard-coded list.
- The server only reports USD and EUR.
Before this change, the user could choose GBP, which would cause no
price to be shown (and possibly other bugs; I didn't check).
Now, they cannot choose a currency that isn't supported by both the
client and server.
I tested this by faking a server response and seeing fewer currencies in
the list.
I think this is a useful fix on its own, but it'll also help with badge
gifting.
As of 9662b3cb1e, the app should wait for a week before notifying
users about a new version. However, the “has it been 7 days” marker
isn’t cleared when a user does upgrade, so the prompt can appear too
quickly when the next update is released.
For example:
- Assume it’s Apr 7 and a user is running v5.34.
- On Apr 8, v5.35 is released & the user sets the 7-day marker to Apr 8.
- On Apr 10, the user upgrades to v5.35; the marker isn’t cleared.
- On Apr 15, v5.36 is released.
- On Apr 16, the user launches the app and sees an update banner, even
though the new version has been out for only 1 day.
Context:
- M1, from Apr 2021: `dataMigration_populateGroupMember`
- Inserts TSGroupMembers into the database.
- M2, from Feb 2022: `dataMigration_reindexGroupMembershipAndMigrateLegacyAvatarDataFixed`
- Adds TSGroupMembers to the FTS index.
In the happy path, M1 would have run several months ago, before there
was any FTS support for TSGroupMember objects. Then, when FTS support
was added, M2 would index the existing group members.
In the sad path, both M1 and M2 run at the same time. In this case, M1
knows how to insert group members into the FTS index, so it does. When
M2 tries to do the same thing, it fails the UNIQUE constraint.
Resetting these records is a micro-optimization: while some of the
devices will still have the up-to-date sender key, we don't ever send
messages to just some of a recipient's devices, so updating the record
to be perfectly accurate is equivalent to deleting it altogether. In
either case the set of devices will be checked the next time we try to
send a message, including their registration IDs, but it's ever so
slightly faster to see that there's no record at all. That said, the
best code is no code, and removing this removes an extra database
write that might get blocked behind other work.
[camera] Always allow to turn off multi-mode while in in-app camera.
Previously user couldn't turn off multi-mode if they have already
taken some photos/videos. Now they'll be able to do so after confirming
that all their media drafts will be lost.
FaceTime uses a capital T ("FaceTime" instead of "Facetime"), so we
should capitalize it.
See [Apple's documentation][0].
[0]: https://apple.com/ios/facetime
There are two currency picker views that are nearly identical.
We plan to add a third, so I consolidated them to make that easier. I
think this is a useful change on its own, too.
