CODEWITHSUNDEEP
objective-cprotocols
W S
W S

Reputation: 115

Who does what with protocols in objective-c?

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.

Upvotes: 0

Views: 282

Answers (2)

newacct
newacct

Reputation: 122439

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.

Upvotes: 0

Morgan Chen
Morgan Chen

Reputation: 1217

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.

Upvotes: 1

Related Questions