* Auto-add new contact threads to profile whitelist when local user sends first message to that thread.
* Ensure dynamic interactions have a non-negative timestamp even if the conversation was empty.
* Only call updateMessageMappingRangeOptions _after_ beginLongLivedReadTransaction and updating messageMappings.
* Improve documentation around how to avoid corrupt mappings in conversation view.
* Fix edge cases around large initial range sizes.
* Always treat dynamic interactions as read.
* Rebuild the “unseen” database views to remove dynamic interactions (see above).
// FREEBIE
* Auto-add new contact threads to profile whitelist when local user sends first message to that thread.
* Ensure dynamic interactions have a non-negative timestamp even if the conversation was empty.
* Only call updateMessageMappingRangeOptions _after_ beginLongLivedReadTransaction and updating messageMappings.
* Improve documentation around how to avoid corrupt mappings in conversation view.
* Fix edge cases around large initial range sizes.
* Always treat dynamic interactions as read.
* Rebuild the “unseen” database views to remove dynamic interactions (see above).
// FREEBIE
When we send the nth message, we retain the footer for the n-1th message
until the nth message is successfully sent.
1. leave the footer on the n-1th message
2. draw the nth message with the "..." footer
3. update the nth message with the "sent" footer and hide the footer for
the n-1th message
In the normal case this all happens very quickly, which results in some
unpleasant flicker every time you send a message.
The concession here is that we'll only print the n-1th footer if the
outgoing message *fails*. So until we implement a design more like
Android's double-check for sent/delivery, the user will not be able to
distinguish between a sent and delivered message *while* their message
is outgoing.
In my opinion the lack of jank in the normal case makes the app
supercedes this use case.
// FREEBIE
