TODO
-[x] respect order of queue
-[x] replacements
-[x] those w/o completion handler
-[x] basic send+log operation persists
-[x] send+ui completion
-[x] share extension
-[x] update state jobs
-[x] App Lifecyle
-[x] settable
-[x] Mark as ready on startup
-[x] Fail appropriate jobs on startup
NICE TO HAVE
-[x] concurrent per senders
-[ ] longer retry (e.g. 24hrs)
-[ ] App Lifecyle
-[x] retry failed jobs on startup?
-[ ] reachability
DONE
-[x] basic passing test
-[x] datamodel
-[x] queue/classes
There are multiple places in the codebase we present a conversation.
We used to have some very conservative machinery around how this was done, for
fear of failing to present the call view controller, which would have left a
hidden call in the background. We've since addressed that concern more
thoroughly via the separate calling UIWindow.
As such, the remaining presentation machinery is overly complex and inflexible
for what we need.
Sometimes we want to animate-push the conversation. (tap on home, tap on "send message" in contact card/group members)
Sometimes we want to dismiss a modal, to reveal the conversation behind it (contact picker, group creation)
Sometimes we want to present the conversation with no animation (becoming active from a notification)
We also want to ensure that we're never pushing more than one conversation view
controller, which was previously a problem since we were "pushing" a newly
constructed VC in response to these myriad actions. It turned out there were
certain code paths that caused multiple actions to be fired in rapid succession
which pushed multiple ConversationVC's.
The built-in method: `setViewControllers:animated` easily ensures we only have
one ConversationVC on the stack, while being composable enough to faciliate the
various more efficient animations we desire.
The only thing lost with the complex methods is that the naive
`presentViewController:` can fail, e.g. if another view is already presented.
E.g. if an alert appears *just* before the user taps compose, the contact
picker will fail to present.
Since we no longer depend on this for presenting the CallViewController, this
isn't catostrophic, and in fact, arguable preferable, since we want the user to
read and dismiss any alert explicitly.
// FREEBIE
callUIAdapter is not a singleton (for better or for worse)
No one should hold a reference directly to it, but rather via the
CallService, which is a singleton
Wait a bit longer for initial call screen before terminating. Especially
first call can hit this limit.
When call *does* take too long to show, terminate properly to ensure
we're not left with a phantom call
// 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
Michael Kirk
Matthew Chen
Michael Kirk
Matthew Chen