Simple delegate method or property on destination view controller

Question

This is a question regarding convention/best practice. Say you have two view controllers Foo and Bar . Foo shows a list of things, and each thing has an image associated with it which Bar is used to present. Eg Foo might display a list of people names, and pressing on one of those names brings up a picture of that person using the Bar controller. So Bar requires a simple piece of information from Foo - in this case, an image to display.

There are two ways we could get the image to Bar :

i) set Foo as Bar s delegate, using some kind of BarDelegate protocol we define, and have BarDelegate have a mandatory method along the lines of - (UIImage *)imageToPresent;
ii) have a simple property on Bar , eg @property (nonatomic, weak) UIImage *imageToPresent; and have Foo set this property before segueing to Bar .

Is there a convention or preferred way out of these two?

Best I can tell, the advantage of the delegate approach is that you can make explicit that there are some things that are required for Bar to work. Sure, Foo might forget to set itself as Bar s delegate, but if Bar had say 10 required properties, there's now still only one place to mess up (forgetting to set the delegate) rather than 10. The advantage of just using properties is that it makes the code more terse. I should note that I'm only interested in the case where the property in question is invariant across the destination view controller's lifecycle. I understand that delegation might have additional appeal if the property was variant across the lifecycle and the destination view controller needed to "query" the source view controller for it more than once.

Answer 1

Delegation is commonly used for allowing the delegated object to communicate back to the master object, either for asking for additional data or for performing callbacks.

There's no reason in your case not to immediately provide the delegated object with everything it needs, since you have it available already, so the second option would be the most reasonable way to go.

Generally speaking, the delegation flow goes more or less like this

Foo : "Hi Bar, here's a task for you. Use this data, and do your things"

[later on]

Bar : "Hey boss, this thing just happened!"
Foo : "Oh, nice! Thank you for letting me know"

[later on]

Bar : "Hey boss, I'm gonna need something more to conclude the work"
Foo : "Here is is"

[later on]

Bar : "Hey boss, I'm done! Here's the result of my work"

The definition of a custom BazDelegate protocol would be appropriate in case Baz needs to communicate back to Foo (say, the user performed a choice on the detailed view).

In such case you would usually define something like

@protocol BazDelegate
- (void)baz:(Baz *)baz didFinishSelectingWhatever:(id)whatever;
@end

and then implement it in Foo to receive meaningful callbacks from the delegated object.