* Substitute unread view for unseen view until unseen view is ready.
* Register as many views as possible async.
* Perform blocking, safe migrations before async registration of views.
* Add debug settings view for internal app stats.
* Show blocking overlay until async registration of database views is complete.
* Convert version migrations to use AppVersions.
// FREEBIE
previously, edit menu was only positioned correctly for text bubbles,
and centered for media bubbles.
It wasn't that noticable for images/videos since those usually extended
to the middle of the conversation view, but with narrower media bubbles
(like arbitrary attachments) this became a bigger problem.
// FREEBIE
coordinate SignalProtocol encryption/decryption on a single serial
queue. Previously message sending encrypted on the sending thread, while
message receiving decrypted on the main thread.
// FREEBIE
* Ensure NotificationsManager has dependencies
Otherwise it's easy to mess up the order of the required dependencies.
* move AccountManager into Environment, it's heavy to construct
// FREEBIE
Hack to fix https://github.com/jessesquires/JSQMessagesViewController/issues/1885
This doesn't happen often, but is reproducible under simulated message
churn (~50 insert/update/deletes randomly spaced over 10 seconds).
During performBatchUpdates, the collectionViewLayout can call
layoutAttributesForElementsInRect which can reference the just-deleted
item's
view. (The view presumably hasn't been deleted yet, but will be by the
time
performBatchUpdates is complete).
It's opaque how layoutAttributesForElementsInRect get's it's list of
views. I
can only speculate how this works based on debugging, but it seems that
the
CollectionFlowLayout keeps an internal list of item frames, which when
crashing
still contain items corresponding to the to-be-deleted items.
In any case, it seems like a bug that JSQMVC would ever attempt to get
layoutAttributes for an item which doesn't exist in the datasource.