There were two symptoms to this bad "leave app while dismissing keyboard"
state...
The first, most noticeable symptom was that the main window no longer respected
the device orientation. This was caused by UIKit temporarily disabling
autorotate during an interactive keyboard dismissal, and not cleaning up after
itself when we hid the window mid dismissal due to our screen protection
feature. This was solved previously in: ca0a555f8
The second symptom remained, and is solved by this commit. Wherein after
getting in this bad state, the interactive keyboard dismiss function behaves
oddly. Normally when interactively dismissing the keyboard in a scroll view,
the keyboard top follows your finger, until you lift up your finger, at which
point, depending on how close you are to the bottom, the keyboard should
completely dismiss, or cancel and return to its fully popped position. In the
degraded state, the keyboard would follow your finger, but when you lifted your
finger, it would stay where your finger left it, it would not complete/cancel
the dismiss.
The solution is, instead of only re-enabling autorotate, to use a higher level
private method which is called upon complete/cancellation of the interactive
dismissal. The method, `UIScrollToDismissSupport#finishScrollViewTransition`,
as well as re-enabling autorotate, does some other work to restore the UI to
it's normal post interactive-keyboard-dismiss gesture state.
For posterity here's the decompiled pseudocode:
```
/* @class UIScrollToDismissSupport */
-(void)finishScrollViewTransition {
*(int8_t *)&self->_scrollViewTransitionFinishing = 0x0;
[self->_controller setInterfaceAutorotationDisabled:0x0];
[self hideScrollViewHorizontalScrollIndicator:0x0];
ebx = *ivar_offset(_scrollViewNotificationInfo);
[*(self + ebx) release];
*(self + ebx) = 0x0;
esi = *ivar_offset(_scrollViewForTransition);
[*(self + esi) release];
*(self + esi) = 0x0;
return;
}
```
By not overriding the initializer for an OWSNavigationController subclass,
we can use the dynamic disaptch intialization chain.
The root difficulty here is that super.init(navBarClass:) wants to call
self.init(nibNam)
* Update proto schema to reflect typing indicators.
* Sketch out OWSTypingIndicatorMessage.
* Add "online" to the service message params.
* Sketch out logic to send typing indicator messages.
* Sketch out OWSTypingIndicators class.
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
Because we were fetching a new thread instance, instead of updating the
existing thread instance, classes which were bound to the old thread instance
weren't updating. This affected the HeaderView.AvatarView.thread and the
ConversationStyle.thread.
- removed timestamp parameter. This wasn't totally obvious, previously we were tracking two pieces of state
1. `unreadIndicator.firstUnseenTimestamp`:
the first unseen timestamp for a conversation that exists in the database
2. `unreadIndicator.timestamp`:
the timestamp of the first interaction *after* the unread indicator that fits in the loading window
We don't actually need to track `2` because it was only used in a comparison like:
viewItem.interaction.timestampForSorting >= unreadIndicator.timestamp
But by definition, unreadIndicator.firstUnseenTimestamp is always less than or
equal to unreadIndicator.timestamp. Put into terms of the `sortId` corallary,
the sortId of the first unseen interaction in the database is always less than
or equal to the sortId of the first unseen interaction that fits in the loading
window.
In other words, there's no situation where
viewItem.interaction.sortId >= unreadIndicator.firstUnseenSortId
We were often using `timestampForLegacySorting`, which is convoluted for when
we actually just want received time.
In some sense this is a superficial change, but it's part of auditing that
we've completed moved away from timestampForLegacySorting.
No change in functionality in this commit, I just broke the signature to have a
systematic audit of the callsites. Added TODO's with the plan for each call.
Historically we would backdate the SN change messages, but since adopting
non-blocking SN changes long ago, they're already sorted properly by creation
time, so backdating has been unnecessary for a while.
I also audited that all other error messages are saved directly after creation.
I applied deprecation attributes as appropriate as I audited.
There is no change in functionality in this commit.
Apart from clarifying what the timestamp means (it's the timestamp of the
*sender*), this intentionally breaks all the call sites, so I could have a sane
way to thoroughly audit wherever we're passing in timestamps, to see where
we're depending on them to affect sort order.
For the sake of a cleaner diff of meaningful changes, instead of "fixing"
everything in this commit, I've just added comments and renamed signatures.
-[ ] UI
-[ ] Conversation Settings
-[x] Show switch for group
-[ ] localize
-[ ] migrate existing localizations? (nice to have)
-[ ] can view conversation settings (but not edit them) in left group
-[ ] special block copy for groups
-[ ] special unblock copy for groups
-[ ] ConversationViewHelper
-[x] Track blocked groups
-[ ] HomeView
-[ ] ConversationView
-[ ] Any others?
-[ ] Rename? Extract BlockList cache?
-[ ] Block List
-[ ] Group Section
-[ ] Unblock group
-[ ] Interstitial interacting with blocked threads (e.g. thread picker)
-[ ] BlockListUIUtils w/ thread
-[x] Block
-[x] Unblock
-[ ] Replace usages where possible
-[x] block manager
-[ ] Sync
-[x] tentative protos
-[ ] confirm protos w/ team
-[x] send new protos
-[ ] Message Processing
-[ ] Drop messages from blocked groups