Question

I am writing an iphone app where in numerous cases a subview needs to talk to its superview. For example:

• View A has a table view that contains
  photos
• A has a subview B which allows users
  to add photos, upon which I want to
  auto append them to A’s table view

So far I have been creating a @protocol in B, and registering A as the delegate.

The problem in my case is that B has a subview C that allows users to add content, and I want actions in C to invoke changes in its grandparent, A.

Currently I am working around this by passing around a self pointer to my base view controller (C.delegate = B.delegate), but it doesn’t seem very proper to me. Any thoughts? (and/or general advice on code organization when all sort of subviews needs to talk to superviews would be greatly appreciated)

Thanks!

Answer 1

I generally have a view controller be the delegate of all views in the view hierarchy it controls. In the case of a table view, the delegate creates the cells and sets itself as the delegate of any views in the cell hierarchy when they are created.

Basically, any views that are created should pass through or be created by the delegate, in which case the delegate can assign itself or another delegate to each view in the hierarchy.

This breaks down a little bit in the case of say being the delegate of two table views, because checking the tableView argument is inelegant at best. But the master delegate could create separate controller instances that fill the role of delegate for a single view.

The overall design goal is that views know how to present data and interact with the user, but not what to do with the data or the interactions. For this they need delegates. Making views the delegates of other views breaks that design goal.