realm
RLMCollectionChange move notifications
Goals
Use RLMCollectionChange notifications to update table and collection views with moved cell information.
Expected Results
RLMCollectionChange has a moves property with the old/new index paths. (Similar in use to NSFetchedResultsChangeMove).
Actual Results
When a row is inserted in the collection, all following rows are reported as modified. This results in having to tell the table/collection view to unnecessarily reload many rows (hundreds in this case).
Version of Realm and Tooling
ProductName: Mac OS X
ProductVersion: 10.11.4
BuildVersion: 15E65
/Applications/Xcode.app/Contents/Developer
Xcode 7.3.1
Build version 7D1014
Realm (0.101.0)
I am feeling the pain on this one.
Using the changes on the notification to process UI updates ends up in unnecessary row reloads and its a noticeable performance hit.
The good news is, Realm internally already computes move operations. The bad news is, move operations are converted to insertions and deletions at the very end of the change calculation algorithm: https://github.com/realm/realm-object-store/blob/28ac73d8881189ac0b6782a6a36f4893f326397f/src/impl/collection_change_builder.cpp#L35-L38
I vaguely recall this being done due to UITableView APIs not handling move operations very nicely, that they would crash in certain scenarios despite having perfectly valid results. As this never happens with insert/delete pairs, and that this feature would be used to power UITableView's 99% of the time, we opted to "flatten" moves to work around this issue.
I'm fuzzy on the details, so unfortunately I don't recall what those problematic cases were, or if we filed a radar, or what the status of that potential radar would be, so I apologize for that.
@tgoyne would certainly know more, but he's on vacation this week. If one of you were to ping him again next week, he'll hopefully be able to shed more light on the situation.
Moves currently are only calculated for unsorted queries (there's a lot of tracking of row moves done for sorted queries, but they're for the changes in the low-level row numbers, not the order within the sorted results).
The UITableView bug was an iOS 8 thing that was fixed in iOS 9.
@tgoyne Any update on this now that the table view bug has been fixed?
I use the realm collection notifications for a purpose that is not a table view, so having the moves converted to insertions and deletions forces me to perform an extra step to compute which items are actually new, and have not just been moved.
Hi @hhanesand, we agree that this is useful and important, but the functionality still needs to be built on our side, and that hasn't been done yet. We translate moves to insert/delete pairs for some Realm collections, but we'd need to expand that functionality to all types of Realm collections first, and then expand our APIs in order to expose those moves directly. We're not blocked on any external factors, but there's a decent investment of work that needs to happen to accomplish this.
Subscribe to this issue for any updates on the matter.
Subscribe to this issue for any updates on the matter.
Realm team has not posted anything here, so no.
