Most of the UI work for the new support flow. This still needs some
tuning, but I wanted to checkpoint some of this work. This adds a couple
new views and view controllers to facilitate the new support flow.
What's left to be done:
- Putting together the send-message infrastructure
- Attach actions to all of the buttons
- Make sure the colors all match up with the spec
- Reach out to design for feedback
- Testing with various accessibility settings
The NSE should only run on iOS 13.3 or later where the "filtering" entitlement
is available since our notifications don't contain any content and will often
not trigger any user visible content. We control this by setting the deployment
target to iOS 13.3.
This does not handle calls as it's currently impossible to wake the main app or
launch CallKit from within the NSE. Should we reach a point where we need to use
this extension in production the service will need to be able to differentiate
between call and non-call messages and deliver them as VOIP or Vanilla pushes as
appropriate. Alternatively, Apple may introduce some way for us to signal the
main app that a call message has been received.
This does not currently address the potential for the NSE and the main app to be
running and trying to process messages at the same time. As long as the
websocket is connected and the main app is processing messages in a timely
fashion the NSE will never be called since the service will not send pushes for
these messages, but censorship circumvention users and users where the websocket
is disconnected for some reason will legitimately receive pushes and we will
want to process those messages. How we will handle these cases requires further
thought since just terminating the NSE when the app launches is not sufficient.
We could potentially do something like terminate the NSE everytime the main app
runs the message fetcher job which should only happen if either the user
pulls-to-refresh on the conversation list or the websocket is actively connected
and receiving messsages. I plan to address this in a follow-up pull request.
Currently this code will not ever be run since the service never sends vanilla
push notifications. Eventually we will need to add logic into the main app to:
a) detect we're on iOS 13.3 or later and b) update a flag on the service telling
it to stop using VOIP pushes for non-call messages. The API for requesting this
from the service does not yet exist.
== Account Registration ==
Not complete until push tokens are uploaded
== Remote Notifications Registration ==
Extracted from PushManager
- wait for notification-settings registration to complete before
requesting push tokens, otherwise it's possible token requests will
be ignored.
- Less state required for push notification callbacks, specifically, we
no longer need to ensure we've created a promise before the
registration delegate methods get called.
- no more TOCFuture in Signal-iOS (still in SSK for now). It's not in
cases of inexplicable behavior - one a recently, push notification
premature free, in redphone, and more popular use, and I've seen two
futures inexplicably being nil. Instead, let's consolidate around
PromiseKit for popularly used, maintained, strongly-typed futures.
- separate logic for registering for vanilla push/voip notifications
(few dependencies) from responding to UILocalNotifications (lots of
dependencies). Ultimately I'd like to consolidate the remaining
UILocalNotifications logic with the existing NotificationsManager
== Misc ==
more debug logging
more uniform logging
remove stale logic around newly registered user
// FREEBIE
