This question already has answers here:
Explaning syntax for #property id<delegateName>
(3 answers)
Closed 7 years ago.
I am currently in the process of learning ObjectiveC.
I wanted to know what the following statement means
id <SampleProtocolDelegate> _delegate;
I got this from here
I know that id is the type but what is <SampleProtocolDelegate> ?
The type is not id, the type is id <SampleProtocolDelegate>. Which effectively means _delegate is a reference to an object which implements the protocol of type SampleProtocolDelegate.
If you don't know fully what a delegate is and the delegate pattern then read up about them then come back to the code later.
A delegate is not something specific to Objective-C, a delegate is a common pattern in many languages.
What is specific to Objective-C is that id <SampleProtocolDelegate> is Objective-C's syntax for declaring the reference to the object implementing the SampleProtocolDelegate "protocol" i.e. its API.
If my explanation is confusing, just read up about the delegate pattern from a high level point of view first.
<SampleProtocolDelegate> means that the object (_delegate) conforms to the SampleProtocolDelegate.
I.e. it implements the required methods of the protocol.
"SampleProtocolDelegate" is a protocol.
A protocol is a list of method declarations. If your class adopts the
protocol, then you have to implement those methods in your class.
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.html#//apple_ref/doc/uid/TP40011210-CH11-SW1
"_delegate" is object of some class that conforms to "SampleProtocolDelegate" protocol.
Related
Trying to understand protocols and their use... having a hard time of it. The more I read, the less I am able to even formulate questions about them. I've read the statement "a protocol is a contract" a hundred times, but it just doesn't click.
I "only" want to develop really simple apps, so assume that I would not myself create a protocol for any of my classes.
I do want to use Apple's Scenekit framework, for example, and understand that I am required to implement some methods to do this - for example the SCNSceneRendererDelegate. The compiler enforces this, and it knows to do that because in my header file I have inserted:
#interface AAPLGameViewController : UIViewController <SCNSceneRendererDelegate>
the bit between the angle brackets specifically.
For the prototypes of the functions I have to implement, I go look for a
#protocol
...
#end
section in the SCNSceneRendererDelegate header file.
But now I've come across some #protocol sections (e.g. in the UIApplication header file) that contain #properties!! I thought #protocol was only about implementing certain methods, what is a property doing there?
I also came across in one of the answers here that specifying a protocol name when creating an instance of an object allows me to use objects that I know nothing about. I would be very grateful to get a few simple practical examples of where this would be useful.
And finally, in Java, the counterpart to (Obj-C) #protocols are called interfaces. Is there a counterpart in Java to (Obj-C) #interface?
Thanks much, cheers.
Adhering to a protocol tells other classes that your class has a specific set of characteristics. Usually protocols are used to define what methods a specific class should have so that it can be the delegate of another class, meaning the class adopting the protocol is guaranteed to have defined the required methods that the delegate class will call in a callback. If the protocol defines a property, it simply means any classes adopting the protocol are expected to also have that property. For example:
#protocol MyProtocol <NSObject>
#required
#property (readonly) NSString *title;
#optional
- (void) someMethod;
#end
I can now define a method anywhere that takes an object conforming to MyProtocol and safely access the title property because it is guaranteed to exist for all classes adopting MyProtocol.
-(void)printTitleOfObject:(id<MyProtocol>)object {
NSLog(#"%#", object.title);
}
So even though id can be any object, since we know that it conforms to our protocol we know that it has the title property. When people say "a protocol is a contract", what they mean is even if we don't know specifically what class is adopting the protocol, we know it at least has the methods and properties listed as required in the protocol. Specifying a protocol for a class allows us to know some information about it, even if we don't know what class it is.
Apple has written documentation for protocols they've written, like the SCNSceneRendererDelegate you mentioned in your question.
But now I've come across some #protocol sections (e.g. in the
UIApplication header file) that contain #properties!! I thought
#protocol was only about implementing certain methods, what is a
property doing there?
Properties are methods. A property declaration is simply a declaration for a getter-setter method pair (or if a readonly property, just a getter method), and allows the compiler to turn a dot notation access into a call to this getter and setter. That's all a property is. How the getter/setter is implemented (whether manually implemented or synthesized), and whether it reflects an underlying value or not (or is computed from other things) are private implementation details of the getter/setter methods.
I'm going through the book about Cocoa and Objective C ("Aaron Hillegass, Adam Preble - Cocoa Programming for Mac OS X - 2012") and when I did the example with NSTableView, I noticed that it really doesn't matter if I define my class as conforming to NSTableViewDataSource, NSTableViewDelegate protocols or omit them, only methods matter. (looks like sort of duck typing)
That is, the application works fine with both definitions:
#interface SpeakLineAppDelegate : NSObject <NSApplicationDelegate, NSSpeechSynthesizerDelegate, NSTableViewDataSource, NSTableViewDelegate>
and
#interface SpeakLineAppDelegate : NSObject <NSApplicationDelegate, NSSpeechSynthesizerDelegate>
It only yells at me at runtime if I don't implement 2 essential methods which are defined in NSTableViewDataSource, and in any case it doesn't matter at all if I put these protocols in class definition or not. So, what is the point in having them in the language? If they are only for documentation, we could put their names in comments as well, right? Or I'm missing something important here?
Protocol conformance can be checked at compile-time and runtime. Like most people said in the comments, protocol conformance is checked at compile-time. If you assign a type that doesn't conform to the protocol (other than id) to a variable of type bracketed with that protocol, the compiler should give you a warning. So in order to be able to pass an object that doesn't conform to a protocol to a parameter of that parameter type, you must have either 1) ignored a warning, or 2) gone through type id, which turns off static type checking.
The API you call also could (if it wanted to) check at runtime whether your objects formally conform to the protocol or not, using conformsToProtocol:. However, the convention in Cocoa is that the APIs never check for formal conformance to the protocol, but rather only check that it responds to a given selector when it needs to call it. This gives more flexibility to the user to, for example, use a class object (metaclasses can't formally conform to protocols, other than the ones conformed to by the root class) as a delegate.
The declaration of NSTextFieldDelegate really confuse me a lot.
In Xcode, I click "jump to defination" of NSTextFieldDelegate, and found:
#protocol NSTextFieldDelegate <NSControlTextEditingDelegate> #end
I have known that if we add a <...> syntax after a NSObject type (such as "id") declaration, that means this object comforms to the protocol specified in "<>".
However, books of Obj-C I have do not mentioned what it means when the "<>" means when it follows a protocol declaration...
So, Question 1: What does "<>" means when it is after a declaration of protocol?
I continued look into the NSControlTextEditingDelegate, and found several methods begin with "control:...". But what attracted me most was the text above the NSControlTextEditingDelegate defination:
#interface NSObject(NSControlSubclassNotifications)
- (void)controlTextDidBeginEditing:(NSNotification *)obj;
- (void)controlTextDidEndEditing:(NSNotification *)obj;
- (void)controlTextDidChange:(NSNotification *)obj;
#end
Oh, here comes new questions:
Question 2: What is the syntex "NSObject(NSControlSubclassNotifications)" means? What is NSControlSubclassNotifications actually?
Quesiont 3: What are the relationships among NSObject, NSControlSubclassNotifications and NSControlTextEditingDelegate? The apple doc simply says: "The NSTextFieldDelegate protocol adopts the NSControlTextEditingDelegate protocol and currently does not extend it further." But I could not understand its meaning...
It means that the protocol conforms to ("adopts") another protocol, so basically the protocol contains all the methods in both protocols. It's somewhat similar to subclassing.
It's a category, in this case used as an informal protocol. It fulfills pretty much the same purpose as a (formal) protocol here (though that's just one use case of categories), you'll mostly see this style in older APIs.
NSControlSubclassNotification is a category on NSObject. It basically adds new methods to all classes that inherit from NSObject. NSTextFieldDelegate is effectively the same as NSControlTextEditingDelegate, just with a different name, but it's possible that new methods might be added to it in the future that are unrelated to NSControlTextEditingDelegate, so that's probably why it's designed as a separate protocol.
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Conforming protocol privately
A class of mine tries to register itself as the delegate to a NSXMLParser object that it creates. However, I don't think I want my class to publicly disclose that it implements the NSXMLParserDelegate protocol, since that NSXMLParser object is a private variable used only from within the class.
Am I right to avoid disclosing the protocol, and if so, how do I implement the protocol without making it public that the class does so?
Try putting this in your .m file:
#interface MyClass (Private) <NSXMLParser>
#end
The specific category name (Private) doesn't matter – in fact you can use an empty set of parentheses (see below) – but I think this should require you to implement the required methods and tell the compiler that your class implements the protocol, at least in that file.
If that doesn't work, try simply removing <NSXMLParser> from your .h file, and casting self to id<NSXMLParser> if necessary, when setting the parser's delegate.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the meaning of id?
I am the newbie to Ios programming.
I saw the following declaration
- (id)init
what does (id) mean here?
id denotes a type which is compatible with any object. The notation
- (id)init
means the init instance method of your class; typically it's used to initialize the instantiated object after memory allocation (usually done using alloc). In Objective-C, methods' return type is declared by putting the type in parentheses before the method name. So, here it means that the init method may return any Objective-C object.
But you should really, really google an Objetive-C tutorial and read it. This is such a fundamental thing for which there is no excuse for not reading a tutorial or other documentation.
id is the plain C compatible type that represents an Objective-C object. This allows C source code to store, and interact with, Objective-C objects.
The reason for it to be of type 'id' is that the -init method is inherited all the way up from NSObject (in objective-C you can not overload methods, hence you can not change the argument/retrurn value types when subclassing). Since 'id' works with any object, this is OK.
EDIT It seems that specifying a concrete class as the return type of -init is OK, even though you are ultimately overriding '-[NSObject init]'.
I guess the use of 'id' is just a custom?
The fact that 'id' acts as a "generic Objective-C object pointer" that accepts any object type on assignment remains unchanged, though.
-(id)init is called to initialize the variables inside an object and do any necessary setup (it's basically the constructor).
A possiable duplication can be
What's the -(id)init method good for?