Delegates & Protocols iOS

A complex subject to wrap your head around, i agree!  But its pretty cool once you get a working example going.

Ive been studying the iPhoneCoreDataRecipes sample code to understand CoreData but ran into the delegate/protocol subject which long ago i browsed over and labelled it as “understood” or “whatever, ill pick it up l8r”.  Given, the iPhoneCoreDataRecipes sample code is not the best place to learn about the subject but its a good enough example to wanna make you understand the concept.  If you want a simple enough example to begin to understand it, check out this tutorial!  Its the best one ive found online so far.

If you’re like me, and you learn visually, you will want to NSLog and/or add breakpoints all over the RecipeListViewController, RecipeAddViewController and RecipeDetailViewController.  I like to know where the program thread or logic is going at every step of the way, i like to think of there being a cloud above my head representing memory space holding certain variables in order to really understand whats going on in every line of code.

So here’s the scoop!  You must envision a Calling Class and a Protocol Class.  The Protocol Class has a special method, that doesnt actually reside in itself (method D).  Its declared here, but its implemented in, or by whoever calls upon it (the Calling Class).

The Protocol Class has a delegate ivar or property which whoever wants to use the protocol, will have to define.  So the Calling Class will at somepoint say, “I am the delegate for the Protocol Class!”. {I guess to me it sounds kinda of like an NSNotificationCenter where whoever wants to know about it, registers as a listener.}  Here the Calling Class is saying, whenever the Protocol Class does something, tell me about it.

In the end the Protocol Class calls back to the Calling Class in order to tell it something has happened, and to pass it some data obviously.  In essence, its like a detour, the Protocol Class has a method D, which it protocolizes.  The Calling Class is running some method A where it calls the Protocol Class.  Method A calls method B, which calls method C(optional)inside the Protocol Class.  Finally Method B(or C) will callback to Method D inside the Calling Class.

A picture is worth a thousand words right?  I hope my picture is clear enough.  Any corrections are welcome.  One I noticed myself, an omission really, is that sometimes the Protocol Class Object calls a Protocol Class method directly, whereas other times, the Protocol Class Object is created and as soon as the delegate is set to self, thats enough to get the ball rolling.  You can see the difference in both sample codes mentioned above:

A) iPhoneCDRecipes, the Calling Class add method instantiates the Protocol Class object, addController and presents it modally.  No real protocol public method is called but since the addController is on top of the VC stack, the save method callsback directly to the protocol method recipeAddViewController in the Calling Class.

B) ClassWithProtocol, the Calling Class appDFLaunching method instantiates the PCObject, sets itself as delegate and that newly instantiated object calls a public class method which calls another method which calls the protocol method which returns to the Calling Class.

iPhoneCDRecipes was not the best example because the delegate/protocol is used only to clean up the UI.  Which is fine, instead of the app presenting a big VC to fill out with name, pic, instructions, prep time, ingredients, category etc all in one screenfull, which is discouraged by the Human Interface Guidelines, it splits up the form into 2 VCs which is neater.

But delegate/protocol designs are vital to processes like the UIImagePicker for example, where in the UIKit, its defined along with a delegate protocol.  That delegate is adopted by the Settings when selecting a pick for the background, the facebook app or twitter apps when selecting a pic to upload and the iLuvMe app for example.  This way, the apps dont have to worry about more coding and the protocol doesnt have to worry about who is implementing it, it just does what its designed to do whenever someone calls upon it.