Hi Kyle, On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
> On Jan 14, 2012, at 2:53 AM, Marcel Weiher <[email protected]> wrote: >> You shouldn't push updates to the UI, the UI should query the model, and it >> should do it at "human speed", not at whatever speed the machine can manage >> to change the state. There are a bunch of reasons for this, not least is >> that UI updating is fairly heavyweight and you can actually impact your >> performance (significantly, in some cases). > > Be careful here. This is good advice in this particular circumstance, but in > general pushing values to the UI is good and common design. While it sure is common, I have a hard time seeing what's good about this design. The sorts of update problems the OP saw are just one symptom of this approach. > The UI will register as a KVO observer, or as an NSNotification observer, or > perhaps the controller will just call -setObjectValue: directly. In my experience and opinion most of these are tempting, but ultimately lead to bad results because of the type of model to view coupling that you are supposed to avoid in MVC. The model should be able to send invalidation notices to the view, but not push values. The view should react to the invalidation notices by requesting new values from the model. At least this is how the original Smalltalk MVC worked ( models are ideally passive and don't even know about views, controllers manage the changes; if that doesn't work, models send "#changed", which then causes the view to take proper action to react to that change). One place where this is illustrated well is view drawing. You don't have the model push to have bits of the view drawn as the updates happen (for example sending drawRect: directly to the view). Instead you have parts of the view invalidated, and invalidations accumulated, until the view is ready to redraw all the invalidated areas at once. > Breaking this pattern should be a conscious decision. I'd say that the opposite is true: in general you should avoid specific model -> view communication as per MVC (apart from invalidation), but in specialized and very simple cases you may be able to get away with it. > For example, you don't push a value to cell-based NSTableViews; you tell the > table view it needs to ask you for the values at certain indexes. This is > because cell-based table views are an optimization that avoids keeping tons > of view objects around. …and another is NSTableView :-) [snip] Marcel _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
