Is there a difference between only <NSXMLParserDelegate>, only setDelegate method, or the use of both of them?

I noticed that when I do this :

[myParser setDelegate:self];

it works :D (even if I didn't add the code in the header file ... you know, the

<delegateStuff, delega开发者_C百科teOtherStuff> 

in the interface declaration)

When are you supposed to modify the header file to make your delegate work ? Is the setDelegate method enough to make it work ?

Cheers for any help ;)

Gauthier

---

In short, the <NSXMLParserDelegate> in your interface declaration is not required, it's there for error checking at compile time. Calling the setDelegate: method is required if you want to receive delegate messages.

The <delegateStuff> you refer to are protocol declarations. A Protocol in Objective-C is like an Interface in Java: it defines a list of messages (methods) that the class responds to. Unlike Java, however, Objective-C is dynamically typed, meaning any message can be sent to any object and you can only be sure if it will respond to it at run time.

The upshot of this is that if a method like setDelegate: asks for a parameter of type id, you can give it any object whatsoever. The code in NSXMLParser can check if it is able to respond to a specific message before sending it. That way you can implement whatever delegate methods you want. (Because Java has more strict type checking, you must implement all the methods in an interface, whether you need them all or not.)

If setDelegate: instead act for a type id <NSXMLParserDelegate> it is now saying that it wants an object that implements the NSXMLParserDelegate protocol. This is only checked at compile time to help you catch errors, though. If you use a typecast you can send any object in there and, as long as it responds to the required messages, your program will run fine. (Again, in Java, you could use a typecast to compile, but the typecast itself would throw an exception if the object wasn't of the correct type, even if it had the same methods.)

By the way, are you subclassing NSXMLParser? (I assume so, since you are passing self to setDelegate:. That is not the way it is meant to be used! The Cocoa frameworks usually prefer delegates over subclasses. Your delegate class should be a separate class extending NSObject (or something else if you want).

---

When it's required, the compiler will let you know with a warning.

I've noticed that when you add the to the header file, Xcode is able to autocomplete any delegate methods you might want to use. I do it every time just for this reason.

---

The compiler now warns if is missing under iPhone SDK 4.0

---

A "delegate" will always work as long as it implements the selectors that are called at runtime. Declaring a matching delegate protocol is not required, but you can get a compiler warning if the delegate is typed to more than just "id" (e.g., id [SomeDelegateProtocol] delegate).

However... if you declare that a class meets the spec of a particular protocol, then (a) that protocol must exist and (b) your class will be checked for the protocols selectors. The NSXMLParserDelegate that is now included with iPhone SDK 4 will cause older apps to throw a warning; if you add the protocol and then try to backward compile to 3.x you will get a compile error because the protocol does not exist prior to 4 (at least you are unlikely to have included a framework with that protocol in it). I just encountered this as I'm beginning to migrate current apps from 3 to 4. I hate warnings that I cannot easily eliminate.