> On Mar 7, 2017, at 9:28 AM, Michael Gardner via swift-users
> <swift-users@swift.org> wrote:
>
> The general approach would be to run a diff between your old and new arrays.
> Something like https://github.com/jflinter/Dwifft
> <https://github.com/jflinter/Dwifft> could help, though I haven't used it
> personally.
I’ve implemented something like this in the past. It’s fairly expensive,
though; that library does claim to use an optimized algorithm, but the cost is
still a lot higher than just posting a notification. (And my own experience of
using KVO is that notifications can become significant hot spots in
performance, because they happen a lot.)
On the other hand, if the array is expected to change often, more often than
you want to redraw the GUI, it could make sense to ignore the fine-grained
changes and just set a timer to trigger after a few hundred ms, which would
then compare the old and new arrays this way and apply a minimal update to the
view.
> Another approach is to build a wrapper around your source array with limited
> modification methods and a KVO-like notification system. The notifications
> can map cleanly to UITableView updates, and there's no extra diffing
> calculations involved. Of course, this method won't work if your source array
> needs to be modified by code you don't control.
I would favor this, even though Swift’s strict typing [and lack of inheritance
in struct types] means this class can’t interoperate with regular arrays. (Vs.
Objective-C, where you can either subclass NSMutableArray, or even make an
unrelated class that walks & quacks like an NSArray.)
This seems likely to have been created by someone already; I wonder if there’s
an implementation floating around Github?
—Jens
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
