Page 117 - Delegates vs Segues

📚 Official Books iOS Apprentice
1

I’m quoting page 117:

Data transfer between view controllers works two ways:

  1. From A to B. When screen A opens screen B, A can give B the data it needs. You simply make a new instance variable in B’s view controller. Screen A then puts an object into this property right before it makes screen B visible, usually in prepare(for:sender:).
  2. From B to A.To pass data back from B to A you use a delegate.

I was wondering, when should I use delegates to pass data right away as in number 2 and when should I use segues to send the data right away as in number 1? As far as I know, both methods require the use of delegates anyways, but when should I use method 1 and when should I use method 2? The only difference I see is that method 1 loosely couples A and B but method 2 doesn’t as we hard code the variables of B in A.

2

Maybe it wasn’t clear from the description but these are not two different ways you can choose from.

1 is for going from screen A to B, where B is the new screen that is opened.

2 is for sending data back from B to A, usually at the time with screen B is closed again.

3

I’m not completely sure why we didn’t make B a delegate of A so when A opens B it would send it the same way as we did from B to A.

Does it have something to do with the fact that B is modally presented?

4

A delegate is often used when you don’t care or don’t want to know what object performs this role.

If screen “A” opens screen “B”, then obviously A knows it is dealing with an object of type B.

However, you don’t want B to know it is dealing with an object of type A, only that there is some object that performs the role of “B delegate”.

So let’s say you also have a screen “C” that opens screen B too. Both A and C will be a delegate for B.

But B doesn’t have to be a delegate of A or C. You could make it so, but you don’t really gain anything from it.

I hope that’s not too vague. :smiley: