When we use any predefined delegates like UITableViewDelegate, UITextFieldDelegate, we are not calling the required/optional methods explicitly or programatically. But incase of custom delegates we are calling the delegate methods using delegate object. Just want to know is there any difference between the mechanism of custom delegate and predefined delegate?
No, there is no programmatic difference between letting Interface Builder / Xcode automatically specify your delegates or you manually assigning your delegates in code or Interface Builder.
Related
I've seen several Obj-C tutorials. The delegate classes all inherit from NSObject. For example, the applicationDidFinishLaunching delegate method, in some tutorials, it inherited from NSObject but NSApplication to implement it. The reason I don't think it should inherited from NSObject is that I didn't find any delegate protocol declaration in it, but I found that delegate protocol declaration in NSApplication. My Objective-C toy environment is GnuSep.
Here is some code:
#interface browserController : NSObject //here. inheriting from NSObject,but NSObject don'have any protocols declaration about applicationDidFinishLaunching.
{
NSBrowser *browser;
}
#end
#implementation browserController
- (void)menuAction:menuItem
{
..............................
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSWindow *win;
ActiveBrowserDelegate * abd;
WindowDelegate *wd;
NSRect wf = {{100, 100}, {600, 500}};
NSRect bf = {{10, 10}, {580, 350}};
.............................
}
It is called informal protocol (though GNUstep declared it anyway as GSAppDelegateProtocol for documentation purpose) NSApplication will simply check it at runtime if your delegate object will respond to the message, (using -respondsToSelector:) A delegate can be a view, a string, a proxy, anything as long as you make it responds to the selector. You don't need to make your delegate implement every method in such protocol since all verifications would be done at runtime. To make it looks cleaner you could just redeclare -applicationDidFinishLaunching: in #interface though you don't really need to, just make one in the #implementaiton is enough.
A delegate may inherit from anything appropriate. It is usually supposed to implement a certain protocol.
A protocol is a way of implementing a formal communication interface between two classes.
However, it is most unlikly that a delegate will inherit from its communication partner class.
With other words: Protocols are often used to overcome the unavailability of multiple inheritance. (Pretty much like interfaces in Java)
Example: A UIViewController subclass' instance controls a view that contains a UITableView. Rather than subclassing the UITableView for the implementation of its look or data, there are two delegates assigned to the table view object. One delegate serves as provider for custom layout (provides items such as the header view) and another (?) delegate provides the data that is being displayed.
Now, this delegate could be any object, inheriting from NSObject and implementing the two protocols. This object cold then be instanciated by the view controller and assigned to the table.
However, it is common practice that the view controller itself serves as delgate for the table(s) that it controls. That is a good pattern but strictly spoken not required. It could be any object.
Now the custom view contoller inherits from UITableViewController (which already implements the protocols and inherits from ViewController) and serves as delgate for the table view. The table view itself could be any subclass of UITableView. (Although this is a bad example here because subclassing UITableView is normally not advisable)
If the delegate does not need to inherit from any class and just implements the protocol, then it shold at least inherit from the cocoa base class NSObject. That ensures that it inherits all the usual capabilites and behaviour of any object. (init method, copy method, description method etc.) That may be required to work properly with other classes of the framework such as beeing used as an object within an NSArray, NSLog etc.
I need to call a method and pass an object from my custom UITableViewClass implementation to my UITableViewController class. I realize creating an instance of the tableViewController in the custom tableViewCell and calling tableViewController's method is a bad practice.
What is the proper way of doing this?
Two magical concepts in Objective-C are Delegation and Notifications.
Delegation allows you to have your controller hook into a weak object referenced in the cell, which avoids a retain cycle, while still allowing you to send messages to it.
Notifications allow your Cell to broadcast a general notification to any classes that are active and listening for it.
Pick one, and whichever is easiest, stick with it. The two are basically equal in this situation.
Having a reference of the tableController inside the cell is indeed Bad practice
You could fix this by implementing a special #protocol for your UITableViewClass
And add a delegate method to it, and then implment the method inside UITableViewController, and since your UITableViewClass delegate is your UITableViewController, then you would call it like
in your UITableViewClass.m
[delegate someMethod:data];
I have a class 'EditingField' extending the NSTextField. The textfields are variables in my AppDelegate.
I wish to do something after the user has ended editing the textfield. Apparently i am to use the controlTextDidEndEditing or textFieldDidEndEditing. Which one am i to use?
Furthermore where exactly am i to implement the methods and how do i set a delegate if that is required?
If you're using NSTextField (i.e. are developing for OS X) then you'd use controlTextDidEndEditing. If you're using UITextField (i.e. are developing for iOS) then you'd be using textFieldDidEndEditing.
The delegate methods can be implemented in any class you wish, in a very small application perhaps even in the app delegate, otherwise you'd probably implement them in the controller responsible for the part of the UI containing the text field.
To set a delegate, use the setDelegate: method.
I was checking some video at Lynda.com about iphone development.
The guy was adding custom data to a picker, but to add the data he was not declaring the methods in the header file. He was checking which nethods he needed on the documentation and copying pasting those methods declarations in his controller class.
For exampe this method
-(int) numberOfComponentsInPickerView: (UIPickerView *) pickerView
Why doesn't we need to declare those methods on the header file?
If those methods pertain to the picker class, why do we declare them in the controller class instead of simply calling them in the picker IBOutlet instance?
TIA
When you declare in your header that you follow a certain protocol, you are essentially saying that you agree to implement the methods defined in the protocol.
I'll bet he added something like this to the header:
<UIPickerViewDataSource>
That means that he is implementing the UIPickerViewDataSource protocol.
So, by implementing the UIPickerViewDataSource protocol, you are implying those methods, therefore, they do not need to be prototyped.
If those methods pertain to the picker class, why do we declare them in the controller class instead of simply calling them in the picker IBOutlet instance?
The method you quoted does not belong to the UIPickerView class, but rather to the UIPickerViewDataSource protocol. Your controller acts as a "helper" for the picker, so the picker is calling your controller if it needs to figure out how many components it should display. You are usually not calling this method yourself.
As another answer pointed out, by declaring that you implement the protocol, the methods of that protocol are implicitly declared. By adding <UIPickerViewDataSource> to your interface, you're basically saying "I can act as a data source for a picker view and I'm ready for any picker that wants to call the methods that are declared in the protocol".
I have defined an objective-c protocol that declares a method that is tagged with IBAction. I implemented a UIViewController that implements the protocol.
In Interface Builder I created a nib file with the UIViewController as the file's owner. However the protocol method is not visible under the Received Actions section although it is tagged as IBAction.
I assume that protocol methods are not visible in Interface Builder. Is that correct? Thanks.
IBAction is only a #define statement; this tag is not inherited when you implement a protocol.
You need to explicitly mark the implemented methods in your class with IBAction so Interface builder can pick them up when parsing the header file.