And rewrite and simplify the rest of deletion logic appropriately.
(Thanks to Nora for the strategy.)
There is one tough case here: database updates have happened
/externally/ (say, from a disappearing message expiring), in which
case the database will be updated but the MediaGallery model will not.
In this case we've broken the invariant that we have the correct count
for each month-section, and need to put a hold on database access
until the model has been updated. The only effect of this is in the
page-based media VC, where we'll exit out of the browser rather than
advancing to the next item if the item we were looking at was deleted
/and/ the next item hasn't been loaded yet. (This can happen if you're
at the start of a message with many items and the whole message gets
deleted.)
...rather than a flat list of loaded MediaGalleryItems. This is
similar to the ad hoc approach in MediaTileViewController in the
previous commit, but is consistent across MediaPageViewController as
well.
Still not handled yet: deletions, also avoiding redundant database
access
- Measure an entire section all at once, so items don't jump around
- Load individual items lazily by section instead of by plain index
- Search for more sections by enumerating timestamps
Does not handle deletes yet. Also I haven't removed all the old APIs.
- Now a struct, meaning no need for a clone() method
- Now a RandomAccessCollection indexed by Int
- Removed the subscript setter that EarlyMessageManager was using to
make the reordering behavior more explicit
- Generalized insert(key:value:isAppend:) to insert(key:at:value:)
- Added removeSubrange(_:)
The most significant change here is we defer initial loading of
collision interactions. We shouldn't block the main thread during
conversation presentation.
Instead, we'll perform it at UserInitiatedQoS. Once complete, we'll call
-ensureBannerState. Subsequent banner state updates will use the cached
interactions to find name collisions.
