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
There are multiple places in the codebase we present a conversation.
We used to have some very conservative machinery around how this was done, for
fear of failing to present the call view controller, which would have left a
hidden call in the background. We've since addressed that concern more
thoroughly via the separate calling UIWindow.
As such, the remaining presentation machinery is overly complex and inflexible
for what we need.
Sometimes we want to animate-push the conversation. (tap on home, tap on "send message" in contact card/group members)
Sometimes we want to dismiss a modal, to reveal the conversation behind it (contact picker, group creation)
Sometimes we want to present the conversation with no animation (becoming active from a notification)
We also want to ensure that we're never pushing more than one conversation view
controller, which was previously a problem since we were "pushing" a newly
constructed VC in response to these myriad actions. It turned out there were
certain code paths that caused multiple actions to be fired in rapid succession
which pushed multiple ConversationVC's.
The built-in method: `setViewControllers:animated` easily ensures we only have
one ConversationVC on the stack, while being composable enough to faciliate the
various more efficient animations we desire.
The only thing lost with the complex methods is that the naive
`presentViewController:` can fail, e.g. if another view is already presented.
E.g. if an alert appears *just* before the user taps compose, the contact
picker will fail to present.
Since we no longer depend on this for presenting the CallViewController, this
isn't catostrophic, and in fact, arguable preferable, since we want the user to
read and dismiss any alert explicitly.
// FREEBIE
Attachment downloads can fail on slow networks or if the app crashes.
It's unlikely that the users response to this would be to delete the
attachment pointer, so it doesn't make sense to surface that as a
primary action.
If a user does want to delete the attachment, as always they can
long-press to delete.
// FREEBIE
