Mayank Tripathi

Total Post:397

Posted by  Mayank Tripathi
 907  View(s)
Rate this:

I know how delegates work, and I know how I can use them.

But how do I create them?

  1. Mayank Tripathi


    Re: How do I create delegates in Objective-C?

    An Objective-C delegate is just an object that has been assigned as a delegate of another. There's no special process for creating them; you simply define a class that implements the delegate methods you're interested in. (Though with delegates that use a formal protocol, you must declare your delegate to implement that protocol; see below.)

    For example, suppose you have an NSWindow. If you'd like to implement its delegate's windowDidMove: method, you could create a class like this:

    @implementation MyClass
    - (void)windowDidMove:(NSNotification*)notification { 
        // ... 
    Then you could create an instance of MyClass and assign it as the window's delegate:

    MyClass *myDelegate = [[MyClass alloc] init];
    [window setDelegate: myDelegate];
    On the NSWindow side, it probably has code similar to this to see if the delegate responds to the windowDidMove: message using respondsToSelector: and send it if appropriate.

    if([[self delegate] respondsToSelector:@selector(windowDidMove:)]) {
        [[self delegate] windowDidMove:notification];
    The delegate property itself is typically declared weak (in ARC) or assign (pre-ARC) to avoid retain loops, since the delegate of an object often holds a strong reference to that object. (For example, a view controller is often the delegate of a view it contains.)

    To define your own delegates, you'll have to declare their methods somewhere. There are two basic approaches, discussed in the Apple Docs on protocols:

    1) An Informal Protocol

    This can be done, as NSWindow does, in a category on NSObject. For example, continuing the example above, this is paraphrased from NSWindow.h:

    @interface NSObject(NSWindowNotifications)
    - (void)windowDidMove:(NSNotification *)notification;
    // ... other methods here
    You would then use -respondsToSelector:, as described above, when calling this method. Delegates simply implement this method, and they're done. This method is straight-forward and common in Apple's libraries, but new code should use the more modern approach below.

    2) A Formal Protocol

    The newer option is to declare a formal protocol. The declaration would look like this:

    @protocol NSWindowNotifications <NSObject>
    - (void)windowDidMove:(NSNotification *)notification;
    // ... other methods here
    This is analogous to an interface or abstract base class, as it creates a special type for your delegate, NSWindowNotifications in this case. Delegate implementors would have to adopt this protocol:

    @interface MyDelegate <NSWindowNotifications>
    // ...
    And then implement the methods in the protocol. For methods declared in the protocol as @optional (like most delegate methods), you still need to check with -respondsToSelector: before calling a particular method on it. Apple recommends this method, because it is more precise, doesn't mess with NSObject and can provide better tool support.

    Speed Optimizations

    Instead of checking whether a delegate responds to a selector every time we want to message it, you can cache that information when delegates are set. One very clean way to do this is to use a bitfield, as follows:
    @protocol SomethingDelegate <NSObject>
    - (void)something:(id)something didFinishLoadingItem:(id)item;
    - (void)something:(id)something didFailWithError:(NSError *)error;
    @interface Something : NSObject
    @property (nonatomic, weak) id <SomethingDelegate> delegate;
    @implementation Something {
      struct {
        unsigned int didFinishLoadingItem:1;
        unsigned int didFailWithError:1;
      } delegateRespondsTo;
    @synthesize delegate;
    - (void)setDelegate:(id <JSSomethingDelegate>)aDelegate {
      if (delegate != aDelegate) {
        delegate = aDelegate;
        delegateRespondsTo.didFinishLoadingItem = [delegate respondsToSelector:@selector(something:didFinishLoadingItem:)];
        delegateRespondsTo.didFailWithError = [delegate respondsToSelector:@selector(something:didFailWithError:)];

    Then, in the body, we can check that our delegate handles messages by accessing our delegateRespondsTo struct, rather than by sending -respondsToSelector: over and over again.



Enter your email address here always to be updated. We promise not to spam!