Previously we were downloading a full sized GIF for each cell, which can
take dozens of seconds on a slower connection. Now we download a smaller
GIF for the picker view, and only download the full sized GIF for the
selected cell.
Some stats:
Before:
Scenario: search "Cat" and no scrolling, no picking
~10 MB
Scenario: search "Cat" and no scrolling, then pick
~10 MB
Scenario: search "Cat" and scroll 3 screens, no picking
~30 MB
Scenario: search "Cat" and scroll 3 screens, then pick
~30 MB
After:
Scenarios: search "Cat" and no scrolling, no picking
~1.0 MB (savings 90%)
Scenarios: search "Cat" and no scrolling, then pick
~3.5 MB (savings 65%)
Scenarios: search "Cat" and scroll 3 screens, no picking
~3.0 MB (savings 90%)
Scenarios: search "Cat" and scroll 3 screens, then pick
~5.5 MB (savings 81%)
// FREEBIE
When viewing a longer message, to avoid the risk of the user not being
aware they can scroll down, we scroll to the last couple lines of the
message, ensuring they can see the meta-data.
// FREEBIE
- Include table index for contacts
- Fix extra spacing in OWS table view
- Separate search results into contact/invite sections
- Include groups in search results when composing new message
- Compose Screen search matches on group member names
// FREEBIE
When awakened by a voip push, we get some arbitrary amount of background
time to connect the call (in practice this is ~30s) before the app is
suspended.
Though we were properly terminating the call upon being suspended, we
were not notifying the user that they had missed a 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
