Usinig the new ShareViewDelegate to dismiss the share extension, might
have broken the "import with signal" functionality. But because we
want to remove it anyway, I've done that now, rather than fix it up.
// FREEBIE
== 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
The only reason a notification wakes/launches the app is to fetch
messages.
However, upon launching, especially if the app had been killed, it can
take a second or two before being notified of the notification that woke
us. Rather than wait, just fetch messages ASAP.
// FREEBIE
* Send read receipts to senders.
* Honor "send read receipts" preference.
* Process read receipts from recipients.
* Refactor "mark as read" logic.
* Serialize and apply recipient read receipts received before sync transcript.
* Show recipient read receipts in conversation view.
// FREEBIE
didBecomeActive is too late in the case of launching from a
notification.
Also, start tracking when app setup is complete, and prevent certain
actions from occurring in that case. Eventually we'll enqueue these
actions rather than ignoring them, but we'll want to do more testing
before releasing that. In the meanwhile, if the environment isn't setup
at this point, a crash would be eminent anyway.
// FREEBIE