Reputation: 3456
I made a NSURLConnection with the calling class as the delegate. I built this on to my test device before realizing I never declared the object as observing the protocol, but it ran (I would say normally, but I think I totally screwed my app around multiple threads).
So is it not necessary to declare an object as implementing a delegate?
I also did not include all the required delegate methods, and it still called the delegate methods.
There are other people on this project, and its fairly large so maybe the delegate protocol is declared somewhere obscure, but I didn't see it while searching for it in the header and implementation declarations.
Upvotes: 2
Views: 162
Reputation: 437702
Despite what the documentation says, if you look at Cocoa's actual definitions of initWithRequest
and connectionWithRequest
, they are defined as follows:
- (id)initWithRequest:(NSURLRequest *)request delegate:(id)delegate;
+ (NSURLConnection*)connectionWithRequest:(NSURLRequest *)request delegate:(id)delegate;
As you'll see, the delegate
parameter is defined as id
without any explicit, formal protocol specified, and as such, you won't get an warning if the object you pass to it doesn't happen to be defined as conforming to any particular protocol.
So, in answer to your question, in this particular case, you don't have to define the delegate to conform to any particular protocol. In many other cases, the delegate
property is defined to take a pointer that conforms to the appropriate protocol, so the compiler will warn you if your object doesn't conform. But not in this case.
Needless to say, you probably should go ahead and define to which protocols you're conforming because it makes you code more clear and you'll enjoy, at the very least, better auto-completion in Xcode when you start to write one of these methods. But your question wasn't whether you should (which you should), but rather whether you must (which you don't).
And just as a clarification, in iOS, there are now two NSURLConnection
protocols, NSURLConnectionDataDelegate
and NSURLConnectionDelegate
. (This may be why they don't define the protocol in the method declarations, to avoid confusion with their shifting of some methods into this NSURLConnectionDataDelegate
protocol.)
Upvotes: 1
Reputation: 16256
I think it depends on how NSURLConnection
is implemented. First, if the setDelegate:
method/property is set to accept an object of type id<NSURLConnectionDelegate>
, then the compiler should warn you. If the NSURLConnection
source code checks the delegate with (for example) +conformsToProtocol:
before calling any protocol methods on it, then your object shouldn't be called back.
EDIT: rmaddy adds that all methods in the protocol are optional. Being that the case, then NSURLConnection
most likely checks with (instance)-respondsToSelector:
instead of (class)+conformsToProtocol:
. In which case, having implemented the method should be enough (but you should still get warnings on -setDelegate:
)
Upvotes: 1
Reputation: 318824
The delegate
parameter of the NSURLConnection initWithRequest:delegate:
method is defined with a type of id<NSURLConnectionDelegate>
.
If you pass an object that does not declare that it conforms to the NSURLConnectionDelegate
, you should get a compiler warning indicating that you are passing the wrong kind of object. Double check to see if you get any sort of warning. If not, then somewhere your class properly declares it conforms to the protocol.
At runtime, the only requirement is that the delegate object actually implements at least the required methods of the delegate. But in this case there are no required methods in the protocol. They are all optional.
You state: "I also did not include all the required delegate methods, and it still called the delegate methods." This doesn't make sense. How can they be called if you don't implement them? Plus, there are no required methods in the protocol.
Upvotes: 4