Questions/remarks


#1

So I’m slowly making my way through the book; I’m finding myself slightly (ok, a lot) overwhelmed - I hope that the questions that pop up in my mind every other paragraph will be answered eventually, but the authors have stopped providing that reassurance a while back. Hmmm.

Case in point (p 108):

This doesn’t really tell me how MKAnnotation is different from a delegate protocol. Correct me if I’m wrong, but I think of protocols in Objective-C the way I think of interfaces in other languages - a contract of sorts between two objects, where object X, interested in functionality provided by object Y, must implement a set of methods/properties/whatever if they are to ‘talk’ to one another. So - what makes MKAnnotation ‘not a delegate protocol’? The following paragraph does not clear up that question. And neither does figure 5.12, which took me a good while to wrap my brains around - I’m not sure why, because once I got it, it made perfect sense. I do think that an additional few words explaining the drawing would have been useful though.

I’m very much enjoying the book so far, I like its hands-on approach, and I recognize that not every little detail can be explained if we are to make progress at a reasonable pace. But I was really scratching my head over this one. (Still am).

D. -


#2

DavidG, I will add that while the authors do a very, very good job at making the text easy to read and understand; I too have run into some paragraphs where the main thought isn’t readily apparent. I’ve been chalking it up to my lack of Objective-C programming knowledge and I have been using Google and Wikipedia to help fill in the learning gaps. Since I’ve made it to Chapter 5, I’ve also been starting to heavily rely on the API and Documentation references.

In the Introduction to this book, the author states that a pre-requisite to the course is knowledge of C and Objective-C (which I lack both). So why did I throw myself into this book? Frankly, it has the best reviews and when I read some snippets from Amazon it had the best writing style. I would really love to purchase the book they reference in the Introduction, Objective-C Programming: The Big Nerd Ranch Guide; however, an online and Amazon search told me it was even published yet!

Oh well, I will continue to work through this book, learn what I can and purchase that introductory book so I can go back and fill in the holes with some brick and mortar. I might even work through iOS programming again after that to help me relearn and understand anew the concepts that are being discussed that I am currently missing.


#3

I think the key there is not to focus on the word “protocol” but instead on the word “delegate”.

You’re correct that MKAnnotation is a protocol. Command-clicking the name in Xcode will bring up its header file which includes:

So yes, it is a protocol.

Now let’s focus on the word “delegate”. Delegates essentially are helper objects. You tell some instance, “use ME as your delegate — here’s my address!” When that instance needs to, it invokes the relevant methods through that delegate variable.

With MKAnnotation, we don’t do that; it’s more in line with how Interface works in Java. If your class implements Comparable, then go ahead, sort those as you wish. There is no helper variable involved; it works directly with your objects.

Delegates are closer to a has-a relationship. The object has something that implements the protocol through another variable (“delegate”), while with MKAnnotation it’s more of an is-a relationship.


#4

gc3182 - thanks for the reply and the explanation. I do see the difference, but at the moment it seems more technical than anything else - i.e., an instance will work directly with an object implementing a protocol, or through the delegate variable. I’m guessing that a protocol guarantees implementation of the required methods, while working through a delegate protocol means that you should check for implementation first… ? Anyhow, what I’m not seeing right now is why you’d want to use one vs. the other, since they both seem to share the same goal - communication between objects. But I’ll pin that last question mark on my lack of experience for now, and I’ll just carry on :slight_smile: Thanks again!


#5

No worries. Most of the time you’ll be using protocols that someone else (usually Apple) has written rather than writing your own anyway. And when you do write your own, you’ll figure out pretty quickly which pattern is more appropriate for your needs.