This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Delegates, can't get my head around them
Hi friends,
What is mean by delegate in objective C? Why we need it? When should we use it? Is there any types in it? How to use it?
Please friends, use simple words and examples to explain. I saw so many articles, forums.. But still i can not catch the exact explanation of it..
Thank you
A delegate is a way to modify the behavior of a class without requiring the class to be subclassed. Often you don't want to dramatically change behavior, but tweak it a bit; subclassing would be overkill, so that's where delegates come in to play.
Look at it this way: a teenager represents a class, and her parent the delegate. The teenager's friend calls her to come hang out at the mall, but the teenager has to ask her parents if it's okay first. The parent -- the delegate -- can say yes or no. That's how delegates work in Cocoa.
Is there any types in it?
Delegates can generally be of any type. In 10.6, many delegates implement protocols with optional methods, so you'll see types like id <BlahClassDelegate>, but that wasn't common before 10.6.
Related
I just try to figure out the upside of categories compared to subclassing... I do understand how they are implemented, but the only upside I see right at the moment is, that it saves you from refactoring your whole code, if you wanna extend a used class in a later stage, which normaly shouldn't happen with a good planning. Otherwise it takes about the same time to implement as a subclass and it doesn't really bring different functionality. So for my knowledge about subclasses vs. categories I don't see a reason why to use categories. Can someone please wash my head and explain the reason for the existence of categories? I'd be very thankful :)
You're focusing on objects that you create, in which case, subclassing is fine. But what if you're calling some Cocoa method that returns some standard object. Do you want to have to create a new instance of your subclass everytime just so you can use your new method? No, it's much more convenient to be able to create methods that you add to existing class via category.
Also, you might want your new methods to be available to not only the base class, but all of its subclasses, too (e.g. if you add extension to NSString, it's available to NSMutableString instances, too).
For more information, see the discussion in Customizing Existing Classes in the Programming with Objective-C guide.
A major difference is that categories can not add instance variables, subclasses can.
Additionally there are classes that are very difficult to subclass such as NSString, see the subclassing notes. Here is an excerpt: "It is possible to subclass NSString (and NSMutableString), but doing so requires providing storage facilities for the string (which is not inherited by subclasses) and implementing two primitive methods." As soon as you see but you know it will not be easy.
Try adding a new method to the NSString class. Try doing it by subclassing NSString and by adding a category. One of these takes two minutes, the other you are never going to get working properly. That will then answer your question.
This question already has answers here:
How do I create delegates in Objective-C?
(20 answers)
Closed 8 years ago.
I am a beginner so I need a simple example of custom delegates. How we can create, use and call? Step by step explanation would be appreciated. i know that the question asked many times before but still confused.
Thanks in advance.
A delegate is little more than a property or ivar to another object that may be called to perform specific methods.
Normally, a Protocol is created defining optional and required method declarations for this delegate object and the delegate object implements at least the required ones.
This API contract ensures you can rely on delegating some business logic to the delegate object.
Your object does not need to know how the delegate will make decisions.
It just sends messages to the delegate and can rely on the results if any are returned.
The delegate does not need to know the precise object it is delegating for unless the method includes it as an argument.
The idea is that the delegate can know things the other object doesn't ever need to know about.
Essentially it makes delegates tend to be controller classes but not always.
It enables objects such as views and controls to be generic and reusable.
It also enables event driven programs with ideas like "hey delegate should I do this now?" Or "hey delegate what kind of thing should I display? X, Y or Z?" Or "delegate give me an object that makes sense to you under ABC criteria"
NSMenuDelegate is a great example NSApplicatonDelegate and UIApplicationDelegate are great examples.
NSTableView and UITableView (and other collection views) also give great delegate examples. They also show how this pattern can have other names containing things like "DataSource" for doing more specific things like providing data for the collection.
I would like to extend the ASIHTTPRequest class, yes I know it's not being developed anymore, but I have it through out my project and I don't have time to totally replace it yet. My reason for extending it is to provide a list of fail-over hosts.
My question has to do with the ASIHTTPRequest delegate methods, how do I inherit them in my extended class? Do I need to create another protocol?
I was in the same situation as you about 8 months ago. I decided to bite the bullet and switch to AFNetworking and am sure glad I did. Working with those delegate methods is a pain. To answer your question, you would have to declare your class as a delegate for the methods you want to handle.
If you need help switching, check out my NetworkClient class that I wrote to replace all the delegate method stuff in ASI.
This question already has answers here:
Is there any reason to declare ivars if you're using properties exclusively in Objective-C?
(4 answers)
Closed 8 years ago.
If an ivar is to be used globally within the class, but will never be accessed by other classes, are we still supposed to use properties?
It is generally a good idea, as the generated accessors will take care of things like memory management and KVO for you. You can put the property in a class extension so other classes can't use it.
For me, it depends on what the instance variable will be used for.
If it's an object representing some data, then I will always use a property.
If it's just a simple BOOL for some internal bookkeeping by a couple of methods in the class, then I won't create a property for it.
This question already has answers here:
Where and how should I instantiate an object which will be used globally in an IOS app?
(3 answers)
Closed 8 years ago.
i'm working on a little iOS project, and i stumbled across a problem with variable scoping.
what i need is an object that is initialised at launchtime, and is available to all controllers until the application closes.
the object will hold data that is loaded either from a database (sql) or from local storage - im not 100% sure yet what to do here.
i need all viewControllers to access that data-holding object at all times, and i need the object to retain when the app enters the background.
is this possible to achieve? and if, then how would i do it?
for simple variables i know i can use extern variables, but does it also work for complete objects?
thanks for an answer,
sebastian
This is one of the more common questions here. I would advise to stay away from extern variables and singletons, see my answer for this related question and this sample Xcode project for a better solution. (The sample project is very bare-bones at the moment, I will add more common scenarios later.)
A possible point of initialization could be your app delegate's didFinishLaunching:withOptions: method, or would that be too late? You could also reference the data via the app delegate (like [[UIApplication sharedApplication] delegate]). Edit: Just to be clear, one can do, but I would not recommend storing and accessing arbitrary data this way.
You can also reference objects using external references, as in extern NSString *gGlobalString;. You need a safe place for initialization, though. A singleton could be a better solution.