Can an object be a delegate for multiple delegators?

Question

I'm not sure about my terminology here, but:

I have a ViewController in an iPhone app that needs to be a delegate for two other objects (delegators).

Is this possible? This does not work:

@interface my_projectViewController : UIViewController <DelegatorOne> <DelegatorTwo> {
  ...
}

Answer 1

Your syntax isn't quite right, but it is very possible to have one object act as a delegate for multiple clients.

Something like:

@interface MyViewController: UIViewController <protocol1, protocol2> 
{
}
@end

...should work

Answer 2

The proper plural is delegates and yes, absolutely, you can have your class be the delegate for different protocols.

The syntax however is like this:

@interface my_projectViewController : UIViewController <DelegatorOne, DelegatorTwo> {
  ...
}

I have one that looks like this:

@interface MyViewController : UIViewController<UITextFieldDelegate,UIWebViewDelegate,UINavigationBarDelegate,UIActionSheetDelegate,URLDownloaderDelegate> {

}

Best regards,

Answer 3

Slightly pedantic but important difference: what you provide in your question isn't an object being a delegate of multiple delegators, but instead an object conforming to multiple protocols. In most cases, a delegate will have a protocol associated with it (UIActionSheetDelegate, UITextFieldDelegate), but not all delegates have protocols, and not all protocols imply delegates.

In a very contrived example, you could have an object that delegates to another object that conforms to no protocols:

#import "ObjectB.h"

@interface ObjectA : NSObject {
    ObjectB *delegate;
}
@end

// ...

@interface ObjectB : NSObject { }
 - (void)delegateMethod;
@end

In this example, instances of ObjectA expect an instance of ObjectB as their "delegate", even though ObjectB isn't really a protocol, but a class interface! The existence of an object as a delegate is more a frame of mind than a strict requirement to have a protocol - it's just that most (ok, nearly all) developers will take the delegate methods and break them out into a protocol so that multiple objects can become delegates for instances of ObjectA, rather than requiring the delegate be an instance (or subclass) of ObjectB. This also removes the need for ObjectA to "know about" ObjectB in the sense of #importing its header file.

In a slightly less-contrived example, an object can conform to a protocol without being a delegate. Think about the NSCopying protocol as a great example of this - all that the protocol says is objects that implement it can be copied using the copy method. People don't consider copy a "delegate" method, since no object is just going to say [delegate copy] without then doing something with that copy, so objects that implement NSCopying aren't really "delegate" objects.

In the end, just remember: a protocol doesn't imply a delegate, and a delegate doesn't always (but usually does) imply a protocol.

Answer 4

In addition to what's been said about implementing multiple delegate protocols, Cocoa's delegation pattern makes it easy for an object to become a delegate for multiple objects of the same type. This is why most delegate methods include a pointer to the calling object as either a parameter, or the object of an NSNotification. You can use it to get more information about the object, or compare it to an instance variable in order to figure out what action to take.