0

Suppose I have a setting in NSuserdefaults that should affect a property for a lot (but not all) UIView objects, for example the font size. The setting can also be changed from a 'main' viewcontroller and should be 'distributed' to UILabel objects that live in a UIView in a UITableviewcell inside a UITableView inside a UINavigationController inside a UISplitviewController and so on...

If I create this property on all levels of the controller and view hierarchy, and set the property when the property in the parent is set, this costs a lot of code. Apple seems to prefer this pattern to manage the managedObjectContext by handing it to the child controller along the chain. But this seems like overkill. Lot of code is just for passing around the value of the property, while nothing is done with it. I do however use this pattern to set properties in all subviews of a view at once (by recursively walking through all subviews).

Delegation seems to be just as bad, except maybe not if the delegate would be top level parent view controller. But then I would be passing the delegate around to all child view controllers.

Should I go with Notifications instead? I already have a controller listening to (all) changes in the NSUserDefaults via the NSUserDefaultsDidChangeNotification. Should that controller post a specific notification when my setting is changed? In that case, who should listen to it? Should it be the view controller that is responsible for the views involved?

Bjinse
  • 1,339
  • 12
  • 25

1 Answers1

0

After some more reading, I found advise in the book Cocoa Design Patterns from Buck / Yacktman, as they state: As a general rule, use notifications when there are potentially many objects that may observe the notification. Use delegates when exactly one object is given an opportunity to influence or react to changes as they are happening.

So notifications is the answer.

Bjinse
  • 1,339
  • 12
  • 25