Could someone please explain to me in a simple and easy to understand with example, how to perform delegations in ASOC, and why and when it must be implemented.
Thanks,
t.
Hi,
delegates are a kind of notification callbacks.
The delegate is the object to send the notification to
For example, if you implement the NSApplicationDelegate protocol in your class,
your class becomes the delegate of NSApplication.
Then you can implement the optional methods
applicationDidFinishLaunching
applicationShouldTerminate
applicationShouldTerminateAfterLastWindowClosed
. and a few more
to get (asynchronously) informed about state changes without polling repeat loops
Hello.
With cocoa/Obj-C 2.0 delegates has to implement a protocol, is there anything wrong in declaring the delegate to be of type (protocol) instead of (id), in order to get the dreaded compiler warnings to go away? 
Yes, it’s wrong, the type of the delegate is always id.
What compiler warning do you get?
You have to add the protocol in the @interface line, for example
@interface AppDelegate : NSObject <NSApplicationDelegate>
and implement all required methods
Hello!
I haven’t implemented the protocol that way. ( I picked a tutorial written in ObjC 1.0 ! )
I get a lot of: “no -method found” errors, but now I know that by “implementing” the protocol, I can make them go away!
In this specific case I think I’ll have to implement my own protocol, as it is not from the appkit, maybe I’ll have to redesign the tutorial slightly.
The setting of the delegate is done by a setDelegate call, after getting a reference from an IBOutlet.
This was how it was: The NSDocument, that probably should have been subclassed with the protocol, got its hand on NSView via IBOutlet, then it used that to setDelegate.
When my NSView calls the methods via [[self delegate] "method"] ;
I get a warning.
I’ll have to come back to this eventually, the project is broken, as the CVS broke down for me in XCode (probably my fault).
I think I’ll solve this, by implementing a protocol, and subclass NSDocument with it. Then, I’ll somehow tell the subclassed NSView, that the delegate adheres to the protocol when I set it.
Thanks Stefan!
Edit
I wonder if this is the right way to go, to subclass NSDocument, what can I say, I am green!
I am sort of creating a drawing application as an exercise.
I have a panel with tools, the tools are queried by notification from my DrawView.
The model with the objects that is drawn is inside NSDocument, (In order to be saved and such) I have methods like “objects”, and “selected_objects”, that returns the drawing objects into my view, wich is in 1:1’ correspondence with the NSDocument so that I can check if one is under my mouse, so that I can select them and such.
The model inside NSDocument, is what I query via the delegate from NSDrawview subclass, I think using a controller to be a bad idea. I am not totally sure of subclassing NSDocument either, therefore I ask.
Would subclassing NSDocument be the right way to go, or just write that NSDocument implements a protocol so and so.
This is no big deal really, but it would be nice to know, as it is much to read and many corners to pass.
( I should probably reread “Model Object Implementation Guide”.)
But for now. how would you solve that?
An (informal) protocol is actually a category, but you have to subclass the sending class to be able to send the notifications.
If the protocol methods are optional, you should check for delegate != nil and for the existence of the method
if (delegate != nil && [delegate respondsToSelector:@selector(theMethod)]) [delegate theMethod];
Hello!
Thank you very much.
I’ll create the category for my model, then I’ll include it formally (I think) when I subclass NSDocument.
But inspecting my code, it seems to me, that what I have done wrong, and what I’ll try first, is to include the declarations of my methods inside the interface declaration of MyDocument.h, and see if that helps, (after I have rebuilt the xib file). I’ll see how far I can push this, without making a controller. I really want to add an inspecter and connect to my view, one for the shapes, and one for the background. (Canvas!)
Thanks for your efforts and trouble. I didn’t think of using the “respondsToSelector@(selector(Method))” as a way of avoiding this. Although I think I should!
Edit
It seems to me that implementing a formal protocol, is the best way to do it, since it then sticks as much as possible with the intent of the tutorial, and leads to the least changes of the original source code.
(It’s Wikidraw.)
While I am at it, the best book about design patterns I ever read, (because it gave such a good overview, compared to wikipedia, and the “Gang of Four” book, that delves into much more detail) is “Design Patterns for Dummies”, if you can get hold of a copy somehow. (General you, not you Stefan! )
Hi Stefan - Thank you for your reply. I have learnt some aspect of using delegation in the methods which you listed. What I would like to know is when say in an action handler, a setDelegate: method is implemented for example. If you can provide a code it will be greatly appreciated.
Regards,
t.
what is your definition of “action handler” ?
Something that is connected to an IB.
Usually the delegates of IB outlets are bound in IB to the receiving class
Thank you Stefan.
t.