We were opening a write transaction before our sync extensions were
registered. This seems to have caused our views to rebuild themselves
once they did register, which in turn can cause device timeout.
Instead of opening transcations in `init`, we only build the
localProfile once it's needed.
A future PR will ensure transactions
aren't being created before syncViews are registered.
// 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