Before this change, if an outgoing gift message somehow had multiple
recipients, we'd crash. This could cause the whole app to become
unusable.
This should be impossible, but let's guard against it in case there's a
bug.
Split it based on whether the purpose is “editing” or “sharing”. If
we’re editing, it generally means we have full access to contacts, and
that we’ve checked which of the contacts are registered on Signal. If
we’re “sharing”, we don’t care whether or not they’re registered.
If we’re “sharing”, we check whether or not we’ve prompted for the
contacts permission yet. If not, we’ll show the prompt.
If we’re “editing”, we assume we’ve already prompted (which is already
the case today), so `.notDetermined` isn’t a possible state.
Other things to note:
- The `supportsContactEditing` was always true, so it’s been removed.
- The error when contacts access isn’t allowed is now shown more
consistently. Previously, it was sometimes shown in response to
initializing a view controller.
- Some RecipientPickerViewController code was moved from Obj-C to Swift.
This is probably useful on its own, but it’ll also make it easier to
build some new UI in subsequent commits.
* Enable zooming for photos and videos.
* Shrink media when keyboard is up.
* Fix minor animation issues on iPad.
* Fix "Add Message" placeholder not fading out properly.
The new OWSNavigationController design handles showing/hiding the nav
bar. The code in this class was fighting against it, which caused the
nav bars to appear/disappear unexpectedly throughout the process.
The vc.navigationController.navigationItem.backBarButtonItem.isEnabled
code also appears to be a no-op. A view controller should configure its
own navigationItem (ie vc.navigationItem), not that of its
navigationController. Furthermore, backBarButtonItem isn't set to what's
actually shown -- this is an opportunity to override what should be
shown to our own custom button.
The OnboardingModeSwitchConfirmationViewController bases all of its UI
and behavior on the default mode for the current device. As a result,
the “toggle” behavior is wrong -- it should always override the mode.
Furthermore, if you back out of the override view controller and tap the
normal “Continue” button, that should use the default mode (because you
haven’t gone through the flow to confirm the overridden mode).
This removes the word "gift" from the confirmation screen (except the
server-provided value, which may have changed by the time you read
this), replacing it with things like "donate for a friend".
This is mostly a copy change, with one bit of text removed entirely.
If we hit an HTTP error during the handshake, we’ll get back a
badServerResponse error, and the `response` will indicate the error.
If we run into some other error later in the process, we’ll get back a
non-badServerResponse error, but the `response` will still be set based
on the most recent HTTP response (ie HTTP 101 Switching Protocols),
which isn’t actually the error that occurred.
This adds a string like this to the badge gifting flow:
> Disappearing messages are turned on for this chat. Your donation
> message will disappear in 8 hours.
Because this disrupts the table view, we need to fully re-render its
contents when the disappearing messages timer changes. That required
some refactoring, and also let us remove some instance variables.
Delete the code that would allow "long tap to show context menu" gesture to be
recognized simultaneously with scroll view's pan gesture. That would cause
message context menu to appear whenever user would stop inertia scrolling with
a tap and keep the finger on the screen.
* Add CallEvent sync message proto
* Add CallRecord class and db table
* Renames and comments for clarity
* create and update CallRecord from local device call events
* Handle incoming call event sync messages
* Add outgoing call sync event piping
* Send call event sync messages
* Handle call record sync messages before the app is launched
* Mark TSCall interactions as read and update their status when getting call event sync messages
* Prevent CallKit race conditions by checking state before creating TSCall interactions
* Update chat call event text for unanswered and declined calls
* Remove incorrect debug assert which fires every time a call is missed in the background
* PR comments, mostly nits
* convert old debug assert into a log + task comment
* nit
* Update copy for in chat call logs
* Smaller PR comments
* Add foreign key to CallRecord's interactionUniqueId
* Update write transaction ordering comment
* run genstrings
* fix strings
This was added in ab6c4a4c36, but the
server deosn’t support "v2/keys" via web socket, so the web socket
requests always fail and fall back to the REST endpoint.
We plan to support PayPal and credit/debit cards for gift badges. This
change, invisible to external users, is a step towards that.
Before this change, Apple Pay was always shown as the only payment
method. Now, all supported payment methods are shown.
PayPal and card don't do anything right now—they show an error UI if
tapped.
This change should have no user impact.
`DonateInfoSheetHeaderView` was used in two places: the "choose payment
method" sheet and the "confirm PayPal donation" sheet. However, the
latter was removed in 3404ababe5, meaning
this view was only used in one place.
For clarity, this moves it back into the "choose payment method" sheet
and removes the special view. It is a partial revert of
dc3e588f64.
This change should have no user impact.
A few donation strings were used in two places: the "choose payment
method" sheet and the "confirm PayPal donation" sheet. The string
comment reflected this.
However, the latter sheet was removed in
3404ababe5, so we can update the comments.
