This will be the interface used for storing IDs of group calls in the
future; for now there should be no functionality change, except if
there's an address mentioned with no associated thread. Previously
that thread would be created if needed; now the call action will fail.
This seems reasonable given that threads only go away if the user
explicitly deletes them.
While here, we don't need to save both the UUID and phone number of a
user's address; the UUID always wins anyway. Only worry about phone
numbers if there's no UUID.
(unless preferences say we shouldn't)
Previously we only gave the callee's phone number to CallKit, which is
fine...when the callee is in your system contacts. Now we match the
behavior of incoming calls and always provide Signal's name for the
callee, though in the system call log a system contact name will
always win.
This should have no user impact.
A pretty mechanical change.
Most notably, I stopped getting a global queue by priority (because it's
deprecated) and switched to QOS. I switched from "high priority" to
"QOS: user initiated" based on [this documentation][0].
[0]: https://developer.apple.com/documentation/dispatch/dispatch_queue_priority_high
RingRTC hasn't initialized the camera right when the call starts, so
it marks the call as not having local video at the point when we
report it to CallKit. Check the offer type instead.
Previously, archived groups didn't show up in the "Add to Another Group"
view. Now, they do!
This also orders groups entirely by recency.
This view used `ThreadViewHelper`, which (1) omitted archived groups
(2) had a bunch of dormant database observation code. I removed this
class and replaced it with some inline code that fetches groups.
Group calls don't normally have stable IDs, but we need an opaque ID
to represent a particular ring for CallKit or notifications.
The next commit will drop the localId on IndividualCall, but right now
it's still needed for presenting notifications.
This change should have no user impact.
Neither Xcode nor `git grep isThreadPinned` yield any relevant results
for this method. At a glance, it seems like its last usage was removed
in d57bc7fe26.
This change should have no user impact.
This commit:
- Rewrites the tests in Swift
- Removes some redundant tests
- For North American phone numbers, uses `555-01XX` phone numbers
(because "only 555-0100 through 555-0199 are now specifically reserved
for fictional use; the other numbers have been reserved for actual
assignment)
* Add OnboardingStoryManager
* mark onboarding story viewed
* Add tests and fix issues that came up from testing
* up test timeout for slower CI
* rename SystemStoryManager and put into dependency injecton container
* Use viewed state on StoryMessage itself. Have SystemStoryManager observe app lifecyle events to automatically manage the onboarding story
* use iOS assets which are now in s3
* todo cleanup
* increment timestamp for uniqueness
* pr comments
* change literal delimiter
* Add ChainedPromise utility, tests, and use in SystemStoryManager
* discretionarily observe app backgrounding in SystemStoryManager
* renaming from PR comments
When calculating layout size of the photo overlay text max width is capped at
how wide UITextView was during editing, with the purpose of preserving wrapping
between editor (UITextView) and overlay (CATextLayer).
Previously though, UITextView was set to auto-shrink its width to content size,
which caused max width to not be not enough after changing the font to a bolder variant.
The fix is to pin UITextView's width to view margins so that all available width
is always used when measuring text overlay height.
If "Speak Selection" is enabled in your iOS settings, you can now choose
to speak the message.
See [#5417][0] for more details.
Co-Authored-By: Evan Hahn <evanhahn@signal.org>
[0]: https://github.com/signalapp/Signal-iOS/pull/5417
- Refactor the enum RingMode into an option set RingRestrictions
- Keep track of whether the call is empty in RingRestrictions rather
than by directly inspecting peek info every time
- Set the initial callInProgress restriction by looking for unended
calls in the database (the same thing used to show the "Join Call"
button in the conversation view)
- Use the more-reliable callInProgress restriction everywhere we need
to check if there's a call in progress
- If we think there's a call in progress but don't have peek info,
wait until we get peek info to show status text in the call lobby
This provides a more orthogonal model for ring restrictions, which is
important for tracking "group too large" and "call in progress"
independently. Either can change but the state of the other still
determines how the UI should be updated.
TEST CASES:
Restoring from the old enclave:
- Register on the old code.
- Delete the app.
- Register with the new code, restoring with a PIN.
Migrating to the new enclave & restoring:
- Register on the old code.
- Update and run the new code.
- Delete the app.
- Register with the new code, restoring with a PIN.
Registering a new account:
- Register with the new code, setting up a brand new account.
Registration lock via the old enclave:
- Register on the old code (#1) & enable registration lock.
- Delete the app.
- Register on the new code (#2).
- Run change number (#2 -> #1) on the new code.
- Confirm both enclaves were checked.
Registration lock via the new enclave:
- Register on the new code (#1) & enable registration lock.
- Delete the app.
- Register on the new code (#2).
- Run change number (#2 -> #1) on the new code.
- Confirm only the new enclave was checked.
This updates our libPhoneNumber dependency. See [the libPhoneNumber-iOS
commit][0].
According to [the upstream libphonenumber release notes][1], they
updated the formatting for +49 numbers. That caused a test to break, so
I updated it (and tested a few additional dialing codes).
[0]: 8b6f552682
[1]: 90503ecef3/release_notes.txt (L21)
Allow to set just the gradient colors, without locations, relying on CAGradientLayer's
uniform color distribution logic.
Also update all the uses of GradientView to only specify colors because all the
places were using just two locations: 0 and 1.
