On Sep 12, 2015, at 06:55 , Alex Hall <mehg...@icloud.com> wrote: > > if you need to display an array or dictionary in a table, when that data > source could be updated at a random time or asynchronously, how might you do > it without bindings?
Ah, but what do you mean by “without”? There are two entirely different bindings possible with table views: the content binding of the table view itself, and the cell binding of the cell view prototype. In the table view documentation, “with bindings” means "with a content binding”, but the table view may still have a cell binding. If you don’t use a content binding (my preference), you can (and should whenever possible) use cell bindings to the cell view’s objectValue (a tweet object in your project, probably, or it may turn out to be a custom helper object that provides a reference to the tweet or something like that). Suppose you have incoming tweet updates that change the properties of known tweets. Simply updating the attributes of the relevant object in your tweets property will trigger a UI automatically via the objectValue binding. (And, pleasantly, this will only happen for cells that exist because they’re actually visible in the table view or are still cached. There is no update overhead for stuff that’s well out of view.) In the absence of a content binding, your main manual task is to inform the table view of insertions and deletions. You can use reloadData, or (better) one of the reload variants that affects only specific rows and columns, but reload is crummy because it throws away cell state belonging to the table view itself, things like text selections the user may have made. You can also use a group of fairly new table view methods to remove/insert/move rows. These tell the table view what happened to the model, but because they convey semantic intent, they allow the table view to retain as much state as is preservable. (If a row is moving, an subview’s text selection can travel with it.) If you get updates that *replace* existing tweets — where a new tweet takes the place of an old tweet in a particular row — you have to look a bit harder into app design. Case 1. If the new tweet is entirely new, it’s really a kind of combined remove+insert, so it’s handled as already discussed, with some kind of reload or some kind of direct table update. Case 2. If the new tweet is a new object but it’s really just carrying updated properties for essentially the “same” tweet, you can update the properties of the existing object and then discard the new object. The changes will propagate via objectValue bindings. Case 3. If you really must replace the object in your tweets property with a different object, you’re still not really changing the table structure. In fact, all you usually need to do is push a new objectValue through to the corresponding cell. You don’t need a reload, and you don’t need a remove/insert/move row update. You could simply find the cell object for the row, and change its objectValue property. In cases 1 and 2, you don’t save much by using content bindings instead of manual updates. In case 3, it’s debatable which is better, but case 3 is actually kind of rare. You may be better off to redesign your app so that case 3 becomes case 2. (If you’re into Swift, then note that case 2 is where your tweets have value semantics, and case 3 is where your tweets have reference semantics. Swift loves value semantics.) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
