Reputation: 2563
I'm using a UISplitViewController in my app for the first time. The master view controller is a table view controller, and the detail view controller is just a plain view controller.
For communication from master to the detail I set the detail as a delegate of the master. But I also need the master to be able to respond to changes in the detail (The corresponding table view cell's content would update to reflect the change.)
Is it OK for the master to also be a delegate of the detail? Or is this bad programming practice? Is there a better approach for this?
Thanks for any suggestions.
Upvotes: 2
Views: 827
Reputation: 726899
You could provide a delegate protocol specific to your model, which is shared by both your controllers. This protocol could have methods such as itemContentDidChange:withIndex:
and so on, providing listeners with info on what's changed in the model. If you register both controllers as delegates for your shared model, both implementing this shared protocol, the cross-controller dependency would be removed without introducing any new dependencies.
However, this is only my opinion, which is rather subjective. Your approach is perfectly fine, too - I think it is absolutely OK for the master to be a delegate of the detail at the same time as the detail is a delegate of the master. It is better than giving each controller a pointer to the other one, because you do not need to think about retain cycles.
Upvotes: 1
Reputation: 15442
It's perfectly fine for them to be delegates of each other. There's no ownership involved, so no cyclic references.
Upvotes: 0
Reputation: 246
It sounds like you only need one delegate, as the detailView will only ever need to tell the masterView to 'reloadData' on the list. The data they are both using should really be shared and can therefore be passed to the detailView as a pointer upon creation, which it can then amend itself prior to telling the masterView tableView to reloadData when done.
Upvotes: 0