8

I've tried to figure this out I promise! There is a wealth of info out there on this and I'm still awash in a sea of abstract concepts! It's like when I was a kid and nobody could explain to me why a country couldn't just print more money and be really rich. I'm not this retarded with most of this stuff, but for some reason I can't wrap my head around this concept, so would really appreciate if someone could spell it out as patronizingly "talking to a 4 year old" slowly as possible!

I think target-action makes complete sense to me. It is a useful way of allowing a view to talk to a controller, without having to do a whole lot. As far as I can make out, a controller object effectively attaches a listener to the view object so that if a particular event occurs on that view (ie button pushed) it fires the controller method. This may not be not technically accurate, but as an abstract explanation it makes sense to me.

So the sequence is:

  1. A target method is created in the controller object.
  2. A view is selected and graphically connected to that method.
  3. An event happens on that view which fires the method from the controller.

Protocols and delegates have me flummoxed. I know it's something to do with allowing objects to talk to each other, but I tried writing out my (lack of) understanding so far below and just deleted it as I think it's best not to unpick the knots in my current thinking but to just wipe the slate and start afresh. If anybody could kindly spend a little time explaining the purpose of

  1. Using delegates/protocols as opposed to target/action
  2. The constituents of the code, and where it lives
  3. The sequence of events which occur when the process is being used

I would be eternally grateful.

Judging by some of the comments on other explanations, I feel I'm not the only one a little bit lost so hopefully this will be of general use. Thanks so much!

Edit:

Okay as I thought maybe if I just lay out my understanding people can correct me, and it might make this easier.

My sample is taken from the Apple Docs, with a Window as the view object and WindowDelegate as the delegate, where a click on the close window button triggers a "should I close?" message to the delegate.

Constituents of the Code: Window (View) WindowDelegate (View Controller?)

  1. Declare the protocol which a delegate can use in the interface section of the Window (View).
  2. Make an instance of the delegate in the Window.
  3. State that the WindowDelegate implements the Window Protocol, by including : in it's interface. (bit wobbly here?)
  4. Write the necessary implementation of the methods in the WindowDelegate (View Controller) implementation section.
  5. On a certain event the Window will send a message to the WindowDelegate with certain information.
  6. The WindowDelegate will process this and return an answer.

Anywhere along right lines?

Alan
  • 4,325
  • 3
  • 21
  • 25
  • 2
    related: http://stackoverflow.com/questions/6148148/delegates-what-are-they-really/6148838#6148838 – justin Jan 12 '12 at 02:06

4 Answers4

3

There is a whole bunch of stuff here and it sounds like you have got a few things confused.

Firstly I'd suggest you go the Apple developer site and download the Learning Objective-C: A Primer and Objective-C Programming Language books. Ignore the target/action interface wiring stuff for the moment because it sounds like you need to understand some basics of Objective C. This is where you will find out all about Protocols, etc and other object orientated stuff.

Secondly there are a number of very good books out there which will take you step by step through developing an application. Beginning iPhone 4 Development: Exploring the iOS SDK is one that is well regarded. THis is also where you will find out about delegates.

Thirdly spend some more time back in the documentation. the SDK documentation has lots of articles outlining how things work from a very basic level and the Apple Developer site has lots as well.

drekka
  • 20,957
  • 14
  • 79
  • 135
  • +1 for 'Learning Objective-C: A Primer'. I remember when learning Objective-C for the first time that this document really helped me a lot! – v1Axvw Jan 06 '12 at 14:16
  • thanks, I'm working my way through the Stanford lectures at the moment, I find them more instructive than the books I have. Am on the 5th one at the moment, have reasonably good grasp of the basics of Objective-C, it's more the application in xCode which I am struggling with. I understand the target-action reference above may seem unrelated, but basically the lecturer described target-action and protocol/delegate as the two methods for controllers and views to communicate, hence why I included it. – Alan Jan 06 '12 at 15:03
  • To some degree they are similar. Target/Action is something that is specific to XCode and Objective C because it basically provides what we call meta-data about your application. When compiling, XCode then uses this information connect things up for you, saving you having to manually write the code to do so. The delegate pattern is language independent. For example I could use it in a Java application. So understanding the concept of the delegate pattern will help you more broadly where as understanding how target/actions work will help you more specifically with an Objective C app. – drekka Jan 07 '12 at 03:29
2

Delegates exist to help you avoid subclassing.

Subclassing is something that you should always try to avoid, since it is a very tight form of coupling. Coupling is when two objects depend on each other to work properly, and the more coupling you have, the more difficult it is to make changes to your program (because whenever you have to change one object, you will be forced to make changes to other objects which depend on it).

The reason subclassing is a form of coupling is because when you subclass from a superclass, your subclass will depend on the superclass's methods (which the subclass inherited). So if you have to change the superclass, then you could possibly have to change all the subclasses with it.

Say you want to have a bunch of objects that are exactly the same, except for what they do with one method. By subclassing, you would have to create a bunch of different subclasses and overwrite that one method on all of them, which would be a lot of subclassing (and unwanted coupling). This is where delegates come in. Rather than subclass a bunch of times, you can simply create the one class, and design it to own an object of the anonymous type id, which will be the delegate object (we'll call it the child). This child object will have the single unique method which was previously in the parent, but now the parent will trigger the method on the child object.

So rather than subclass a bunch of times, we create a bunch of instances of the same class, and give each a different delegate object, which we can do since the type id doesn't specify which type of object we have to use. Each different delegate object implements that method differently, and we avoid subclassing.

user3251270
  • 107
  • 1
  • 8
0

To understand delegates, take a look at the delegates provided by Cocoa. For example NSWindow has a delegate method called -(void)windowWillClose:(NSNotification *)aNotification if you implement that delegate method, you look at the notification to determine which window is about to be closed and perform some cleanup for that window. You are a delegate for the NSWindow object in the sense that you are doing some work for the window object.

All of the Cocoa delegate methods have names that include words such as "did", "will", "should", etc. They give your code the ability to do special things in addition to the normal things that would done by those objects themselves -- hence you are a delegate for those objects.

Jim Merkel
  • 352
  • 2
  • 9
-1

For delegates you might have a look at this question.

For protocols you might want to check this question or look at the documentation.

Hope this helps!

Community
  • 1
  • 1
pmk
  • 1,897
  • 2
  • 21
  • 34
  • thanks, it led to me to a couple of things I hadn't seen yet, still struggling though. – Alan Jan 06 '12 at 15:21