Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
i need explanation of how could NSObject Class be a delegate to any controller although NSObject is not a controller !?
A delegate is just an implementation of Delegate design pattern. In Cocoa classes it is implemented using Protocols - any class that implements a specific protocol can be a delegate. For example, let's look at the definition of delegate property in UITableView class (in Objective-C, because it's better at showing distinction between classes and protocols):
#property(nonatomic, weak) id<UITableViewDelegate> delegate;
In Objective-C, id is a universal pointer - a pointer to object of any class. You can see that UITableView expects it's delegate to be of any class, but a class that implements UITableViewDelegate protocol
The only requirement for a class to be a delegate for a particular class is to implement the protocol required. It doesn't depend upon its inheritance chain. It could be uiviewcontroller, uitableviewcontroller or simply the NSObject.
If your class confirms to the required protocol then its a fair candidate to be the delegate.
An object can be a delegate without being a controller.
Being a delegate just means that you agree to respond to a set of methods. It doesnt matter what kind of object you are, as long as you understand the methods in the delegate protocol, you can be a delegate.
Say, for example, you have a central table view manager object that knows about mulitple table views throughout your UI. You could make that table view manager the delegate of all the table views in your app. (I don’t know if this would make sense, but you could certainly do it if you had a reason to do so.)
Related
I know there are a lot of similar questions here but I still need some clarification about this concept.
First of all let me start by saying that I do understand what protocols are and how to use them, what I'm having problem understanding is delegation. I do understand that delegation is when one object in a program acts on behalf of another object, sound very simple but hard to see the whole picture.
1- Is delegation just a way to let the compiler know where to look for the code that will be manipulating the object (UITableView etc.)?
2- Do delegation and protocols work together?
3- Can delegation exist without protocols? If yes, can you show me an example.
4- When we declare a protocol and a class conforms to it, can we say that this class conforming to the protocol is delegating on behave of the protocol?
How much of the above is true?
Thanks a lot
1- Is delegation just a way to let the compiler know where to look for the code that will be manipulating the object (UITableView etc.)?
No, delegation is a design pattern. It's just a concept.
2- Do delegation and protocols work together?
Yes they work well together and it's probably the best practice to use protocol for your delegate.
3- Can delegation exist without protocols? If yes, can you show me an example.
Yes you can. Delegation concept is just to remove intellect of an object and put it in the delegate. For exemple an UITableView does not know how many row it has, or what to do when a cell is clicked, so it asks to its delegate.
But the delegate is still another object.
It's better if it implements a particular protocol, but you can do it without.
For exemple :
I've a MyView that is a subview of a MyCustomViewController.
MyCustomViewController.h
- (void)myViewIsTouched;
MyView.h
#property (nonatomic, weak) MyCustomViewController *delegate
MyView.m
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
[self.delegate myViewIsTouched];
}
There is no protocol in this exemple, but it's still a delegate.
(A better way is still using a protocol instead of declaring the method in the .h)
4- When we declare a protocol and a class conforms to it, can we say that this class conforming to the protocol is delegating on behave of the protocol?
I'm not sure about what're saying. But protocols and delegate are not the same thing. An object implementing a protocol does not mean that it's a delegate.
Delegation allows objects to be able to change their appearance / state based on changes in other parts of your application. Setting a
delegate property on an object will allow the compiler to do some
checks at build-time.
Delegation is often achieved by using protocols, since it allows the
delegate object to be of any class instead of a sub-class of a class
with specific behaviour.
Yes, but this would result in your classes becoming tightly coupled since Foo needs to know about Bar and vice-versa. Using protocols allows you to use any class, hence id property, resulting in a loosely coupled system.
Example:
#class Foo;
#interface Bar : NSObject
- (void)respondToSomeAction:(Foo *)obj;
#end
#implementation Bar
- (void)respondToSomeAction:(Foo *)obj {
NSLog("responding to %#",obj);
}
#end
#interface Foo : NSObject
#property (nonatomic, weak) Bar *delegate
#end
#implementation Foo
- (void)someActionTriggered {
[self.delegate respondToSomeAction:self]
}
#end
When a class conforms to a protocol, the class is compelled to adopt the behaviours of the protocol (implement the methods). It only becomes a delegate if it is given some task to do on behalf of another class, e.g. supply the number of rows in a table.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I've been flashing through some questions here about xcode iOS programming, and I've seen more and more people say something like "as the delegate of blabla" things like this:
- (MKAnnotationView *)mapView:(MKMapView *)mapView viewForAnnotation:(id <MKAnnotation>)annotation
{
currentLocationAnnotation = [annotation retain];
}
But I could never help me because I don't understand what this means, and where I have to put it, if I put it in my .m file, it doesn't work, and if I put it in my AppDelegate.m it doesn't work either.
Please help :)
In your code this is the custom delegate what it means it just work like a helper object in which whatever methods had implemented inside custom delegates can be used.
It's a design pattern where you register a object(the delegate), that confirms to a specified protocol, with another instance of some other class that then calls the first objects "protocol methods"(delegate methods) when it wants the delegate to perform some work. This is usually used to avoid unnecessary subclassing when a object just wants to "outsource" part of it's work.
It's a bit hard to get in the beginning. A delegate of a class is like the handler of events of that class. For example, for the map view class, you set a delegate (e.g. your custom class), and in your custom class, start implementing the handlers (it doesn't necessarily need to handle events. For example table view asks its delegate about how many rows it will have, their height etc.). For example, in the example code you've posted, the map view is asking its delegate to return the view for the annotation object that it's sending as a parameter. You need to implement your logic in your class to return the appropriate object.
In English terms, think of it as an email: 'Hello, my delegate, as a part of your job, I'd like you to give me the view for annotation that I'm attaching below, Thanks, Map View.'
Of course, it requires an immediate response from the delegate right now, and the 'attached below' is the 'annotation' parameter. Hope it helps.
I am working on a delegate pattern for authorization in my app.
Most things i've seen before use something like:
#property (weak) id<Delegate> delegate;
Does that make it weaker than say
#property (weak) UIViewController<Delegate> *delegate;
I realize i am asking for any pointer in the first one and in the second I am expecting a typed pointer. But i only want my delegate to be a UIViewController or subclass.
Can anyone explain the differences and pros and cons?
But I only want my delegate to be a UIViewController or subclass.
Then go for the second way - the first one indicates that it can be any object that conforms to the <Delegate> protocol.
There are not real pros or cons. The contract is just different. One says "I don't care what class it is as long as it conforms to that protocol" and the other says "I want a subclass of UIViewController which also conforms to the protocol".
The only thing here is that the idea of the "delegate" pattern in Cocoa is generally to give the client of your API a way to create an object that will customize the behavior of one or several other components.
Since you want this property to be a view controller, the semantic is more than just a delegate so I would not call it a delegate but a xxxViewController with "xxx" being the actual functional relationship between your object and that view controller.
I am learning to program the iphone and I wanted to do some drawing. I followed some example code and subclassed the viewcontroller and it worked fine. Now as I wanted to expand the program I came upon a design question that I could use a little help on.
I subclass myviewcontroller with mynewview. If I have any code in the myviewcontroller how do I call or reference it in mynewview and vice versa? I am not sure if I am asking this right but I am trying to understand the relationship between the class and subclass.
Objective-C objects benefit from inheritance. All classes are subclasses of NSObject, therefore you can call init on any object. If you created a custom class and gave it a method doSomethingAwesome, you are free to then implement doSomethingAwesome in any subclass of your custom class. However, declaring a method in a subclass does not add that method to the superclass. As an aside, I rarely find myself subclass sing my own custom classes. I believe that it is encouraged to maintain what is called a shallow object hierarchy. Usually I subclass the stock cocoa classes, customize to my needs and if I need custom methods in more than one subclass I will declare a category on the superclass rather than relying on inheritance to provide my custom behavior
The messaging system in Objective-C is dynamic. Every object includes a struct with information that the runtime use for introspection. Here the runtime will find a list of methods the object is able to respond. So, let's say you message an instance like this:
[mynewview someMethod];
The runtime will first check the object information to trying to find some method that will be able to respond the message. If nothing is found, then will query the super class, and so on. In fact, the runtime is much more complex, and will give any object more opportunities to respond (that's the dynamic part. For instance, mynewview might not have any method called someMethod and yet, might be able to satisfy the call, but that's something you might not want to worry right now).
From a child class you can call the superclass implementation of a given method with the keyboard super, so if mynewview is a subclass of myviewcontroller you can call myviewcontroller implementation from mynewview with:
[super someMethod];
If someMethod is both present in myviewcontroller and in mynewview, the runtime will automatically only call the child implementation, you have to call the parent implementation (if you have to) from the child implementation.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does a delegate work in Objective-C?
Can Someone Help Me To Understand What Is This "Delegate"?
What is Use of Delegate method in Objective-C
if I do same functionality using subclass method why we use delegate method in Objective-C
You may want to implement more delegates, while obj-c supports only single inheritance.
Anyway, always choose composition and interface/delegates over inheritance.
Think of a delegate method as a method external to the class. Any class can then become useful (become the delegate of) the class by complying with the delegate protocol and implementing the required delegate method(s). Delegation adds flexibility without the restrictions inherent to the parent class being carried over by subclassing.