I'm writing a quick simple table view app. I've declared the view I'm creating the table view in to be a subclass of UITableViewController. UITableViewController conforms to the UITableViewDelegate and UITableViewDataSource protocols.
My question is, does my view which is the subclass of UITableViewController, also need to state it conforms to these protocols?
Also what is the advantage on conforming to a protocol, meaning putting after the subclass? The code I write works provided the methods are there regardless of the protocol being mentioned in the header.
Does it make a difference if I added a UITableView into a UIViewController subclass?
Since you inherit from a class that conforms to those protocols, no, you do not need to state that you conform to them in your subclass.
The advantage to stating that you conform to your protocol is that some delegate properties will require an instance of a class that explicitly states it conforms to them. Also, it's just a good idea to state that you conform to a protocol if you, in fact, do.
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.
Suppose I have a class Foo which declares a delegate protocol with 3 methods. I would like to subclass Foo into a class called Bar and completely override these methods.
Should I declare them in the subclass header again?
When I implement these 3 methods inside of Bar's delegate, do I have to take any precautions to make sure Foo's implementation will not be used?
Should I declare them in the subclass header again?
That won't be necessary, as your Bar.h will import Foo.h and therefore know it conforms that protocol.
When I implement these 3 methods inside of Bar's delegate, do I have
to take any precautions to make sure Foo's implementation will not be
used?
The only precaution you need to take is to not call [super delegateMethod]; on your implementations, and you're good to go.
This might be a straight forward answer, and I know that you don't have to set NSObject as the Superclass when creating a new class.
But say, for example, I wanted to create a class which held a set of custom CABasicAnimations. Although it may be perfectly ok for me to use CABasicAnimation as the superclass, is it recommended that I follow the unwritten rule and still use NSObject or would you, if you were writing such a class, use CABasicAnimation as the Superclass?
I would assume that it wouldn't matter as long as the Class only contained properties and methods relative to CABasicAnimation.
It would be interesting to here your thoughts!
The rule is to subclass whatever object you are trying to extend. NSObject is used for many subclasses because it is the root object, but if I was going to write a class that was very similar to NSTableView, then I would subclass NSTableView.
In your case, if you are writing a custom animation that you want to call, then you should consider subclassing from CABasicAnimation. On the other hand, if you animation is really just a collection of pre-exisiting CA animations, then NSObject would be fine.
a class which held a set of custom CABasicAnimations.
In this case, I'd like to use Category instead of Subclass.
I need all my view controllers to be able to show the Message compose view controller (MFMessageComposeViewController) and also handle MFMessageComposeViewControllerDelegate method to see whether a message was sent/cancelled/failed. So my idea was to subclass UIViewController impement these methods in this view controller. And then have all my view controllers that need to be able to send messages subclass the above view controller.
So like BaseMessageViewController : UIViewController
And then ViewController1 : BaseMessageViewController, ViewController2 : BaseMessageViewController and so on...
So when I was at it, I thought I would create a protocol like this:
#protocol MessageProcessing
#required
- (void)presentMessageCompose;
- (void)processMessageCancelled;
- (void)processMessageSent;
- (void)processMessageFailed;
#end
But I'm not sure if BaseMessageViewController should conform to this protocol or if my "concrete" view controllers should conform to it?
One thought was that if my BaseMessageViewController conforms to it then my concrete view controllers would automatically conform to it because of class inheritance? But I'm not seeing any warnings in my concrete view controllers that they are not implementing a required method.
Can someone please give me a helping hand here :)
If these are messages that BaseMessageViewController sends to self, there's no reason to define a protocol. Just declare the methods in BaseMessageViewController, and comment the declarations to describe when they are sent.
You will also need to provide implementations of the methods in BaseMessageViewController to suppress a compiler warning. If you want every subclass to implement the methods, you can define the methods in BaseMessageViewController using this pattern:
- (void)processMessageCancelled {
[self doesNotRecognizeSelector:_cmd];
abort();
}
This is a classic example of the Abstract Base Class vs protocol question.
Use an Abstract Base Class (in Cocoa these are called Class Clusters) when you'd like to define a framework, with some common concerns encapsulated by the framework and some specific concerns to be handled by sub-classes. An example could be a message parsing framework.
Use a Protocol to define a common contract for classes that need their own object hierarchy. An example might be a media player, where 'play' and 'stop' are completely different depending on the type of media.
Alternatively, for something in-between, Justin Spahr-summers defines the 'concrete protocol' in libextobjc. . . https://github.com/jspahrsummers/libextobjc (similar to concrete interfaces in Java 8).
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".