Advantage of delegates

Question

I've got a kind of genereal question about the delegate concept. I've seen an code example where basically (VC = ViewController) VC1 opens VC2 and passes, via segue, an object to it. VC2 modifies the object and passes it back to vc1, then closes itself.

VC2 has got a @property (assign, nonatomic) id<DismissViewDelegate> delegate; property. Before VC1 opens VC2 via segue, it sets VC2.delegate = self;. VC1 and VC2 both implement the following protocol:

DismissViewDelegate.h

@protocol DismissViewDelegate <NSObject>

-(void)dismissWithProdukt:(Produkt*)produkt;

@end

My question is, as I'm new to self created delegates and protocols, how is this approach different than giving VC2 a weak pointer to VC1, like:

@property (weak, nonatomic) VC1 *firstVC;

So that I could say:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {

    VC2 *vc2 = *dvc = segue.destinationViewController;
    vc2.firstVC = self;
}

Then, after modifying the object, I would, from VC2, pass the object like firstVC.object = self.object and then close VC2.

Are these two approaches different from the result? Or does the second solution work at all? Where would the advantage of the delegate approach be? Thanks a lot!

`@property (weak, nonatomic) VC1 *firstVC;` should give you a clue, why delegates is much better and more elegant: the different View Controllers must know each other. with delegates not, they just must trust each other that the delegates protocol is implemented. — vikingosegundo, Dec 25 '13 at 17:27

score 2 · Answer 1 · answered Dec 25 '13 at 17:26

When you pass on instance of VC1 to VC2 you are coupling VC2 to a specific implementation.

If you use a delegate, the difference is that it can be of any class, as long is it responds to the methods of the protocol.

This loose coupling means that the delegate can be an instance of any class, but in your first example it has to be an instance of VC1 or a subclass. This means your interface is more flexible.

score 2 · Accepted Answer · answered Dec 25 '13 at 17:26

You can always give a weak pointer of one controller to another but the purpose of a delegate is more than that of having that weak link. You can associate methods to the delegate among other things, giving you a well organised code. Though you can always give the weak pointer and then perform methods using that weak pointer (though not an acceptable practice)

score 0 · Answer 3 · answered Dec 25 '13 at 17:30

0

In your example when you use:

@property (weak, nonatomic) VC1 *firstVC;

it can failed if your first controller will be dealocated.

Let's imagine you create VC1 and after that you add VC2 on the view hierarch with vc2.firstVC = self; after that your app can do lots of stuff in VC2 (maybe you add another VC3 to view hierarchy). ARC can deallocate your VC1 and in this scenarion firstVC property in VC2 will be nill and your app will crash. With delegate you are safe. For your example you can consider using block rather than delegate.

answered Dec 25 '13 at 17:30

Greg

25,317
6
53
62

Thank you for your answer! What do you mean with block? – Linus Dec 25 '13 at 17:35
@LinusAn check this out I had explained it before [link](http://stackoverflow.com/questions/20522030/how-do-i-transfer-information-back-to-a-view-controller-from-a-view-controller-i?answertab=active#tab-top) – Greg Dec 25 '13 at 17:39
I thought a bit about your answer. If VC1 get's deallocated, woudn't id fail as well? – Linus Jan 04 '14 at 09:43

Advantage of delegates

3 Answers3