What's the Difference? Delegation, Passing Data, & Protocol Etiquette

Question

I can think of four ways that my code allows ViewControllers to interact:

1. If I am calling a new VC onto the stack, I pass it the data it needs in the prepare for segue, like so:

2. Unwind segues help me when I am going in reverse and heading back to a VC.

3. I can use protocols to call a function in one VC from another VC.

4. I also have a VC I named "ToolBox" and I sometimes reference "Toolbox" functions by doing something like:

var toolBox = ToolBox()
toolBox.fetchReq_taskList_Sorted(currentListEntity)

Initializing my new VC by passing values, like in #1, I think I understand. Using #2, unwind segues, to run a function on unwind but not pass data, I think I understand.

Question

Where I start to get confused is #3 versus #4. They both let me delegate to another class/VC. Why bother with a protocol when #4 is simpler? Just to ensure that the delegate conforms?

And what about when I don't need to delegate the handling of an event? What about when I just need to be passing a variable's value around? That could also be handled by:

• Saving the cell temporarily to CoreData, the recalling it from other VCs
• Or doing that with NSUserDefaults
• Or I could use a Global Variable to remember the cell

On forums, I always see people saying don't use NSUserDefaults for this, don't use Global variables unless "x", etc. So is there a specific, correct decision making tree for all this?

Answer 1

VCs are responsible for parts of the model. They react to user actions by changing the model, and they observe changes in the model to update their views. They communicate with each other indirectly, because they both observe the same shared model.

To recap my answer to your other question, when vcA which presents an array of model objects in a tableview wants to tell vcB on which specific object to operate, it can do so directly by assigning that object to a vcB property which is vcB's part of the model....

    vcA                  vcB
     |                    /
   vcA's model       vcB's model (assigned to it before a segue)
     |                  /
   ----------------    /
   |       |       |  /
 obj0     obj1     obj2


 Before presenting vcB, vcA assigns it part of the model (obj2, in this example).

See how there's no need to "pass back" anything from vcB to vcA? They're both looking at the same thing. While true, this leaves unanswered some questions implied by your post...

vcA probably needs to know if vcB changes the model so it can update its views. Doesn't vcB need to tell vcA about that?

This is a big topic, but the short answer is that vcA can observe the model changing using KVO and notification.

What about delegation? Is that a way for vcs to coordinate?

Yes. Notification is sometimes a little too broadcast-y and KVO is sometimes a little too narrow and verbose. With delegation, vcB says to its delegate: "I'll do my job of changing my part of the model, and you should do whatever it is you do when I do what I do".

This highly rated post on the subject of inter-vc communication does a good job explaining how to implement delegation.

Delegation is a little over-prescribed, imo. I prefer to use it for richer interactions (the way NSURLConnectionDelegate or UITableViewDatasource works), but using it between vcs to communicate about model changes is common practice that works.

How about the "target-action" pattern?

You didn't mention this one, but its another pattern, delegation's hackier cousin. Outside of custom UIControl subclasses, I'd stay away.

What about global variables? Are they bad?

Yes.

A more subtle answer allows for a commonly used few, including a singleton root of your model. But in general, you should avoid globals for the same reason you don't use wooden clubs: for most (non-bludgeoning-related) jobs, they do more harm than good.

What about my ToolBox class or CoreData or NSUserDefaults?

Your ToolBox class might really be part of your model, maybe you just haven't realized it or named it that way. CoreData for persistence of the model between app launches. Not really pertinent here. NSUserDefaults is persistence of user prefs between launches, also not pertinent.

Using these instead of the patterns sanctioned above is like using global variables, except a little worse, because they are often applied as global variables, only renamed to obscure the ill-advised approach.