Getting Xcode to drop "No XXX method found" warning when delegating

Question

This could be me doing the design pattern wrong.

I'm implementing asynchronous delegation in an application that uses NSURLConnection. An object wraps the NSURLConnection and handles its delegated messages; that works fine. Now I'm defining my own delegates in the object that uses it (NSURLConnection messages ConnectionWrapper, ConnectionWrapper messages NeedsToUseConnection, you get the idea), and that works as well, however, Xcode emits this warning:

No '-request:finishedWithResult' method found

This is, presumably, because I'm declaring the delegate I'm calling like this:

id<NSObject> delegate;

...and Xcode is checking what NSObject declares in the Foundation framework. My custom delegate message is not there. I am properly insulating the call:

if([delegate respondsToSelector:@selector(request:finishedWithResult:)])
    [delegate request:self finishedWithResult:ret];

Aside from turning the warning off -- I like to work with as many warnings on as possible -- is there a way to communicate (either syntactically or via a compiler directive) that I am aware this message is undeclared? Should I, instead, be using an interface design pattern for this á la Java? Using id<WillReceiveRequestMessages> or something?

Open to suggestion.

Answer 1

A better way of doing it would be to create your own delegate protocol:

@protocol MyControlDelegate <NSObject>

@optional
- (void)request:(MyControl *)request didFinishWithResult:(id)result;

@end

Then, you would declare your delegate like this:

id <MyControlDelegate> delegate;

The compiler will no longer complain when you write this:

if ([delegate respondsToSelector:@selector(request:didFinishWithResult:)])
    [delegate request:self didFinishWithResult:result];

The <NSObject> syntax is important in the protocol definition because it tells the compiler to incorporate the NSObject protocol. This is how your protocol gets methods like respondsToSelector:. If you left that out, the compiler would start complaining about respondsToSelector: instead.