Remember A protocol adds no code to the compiled app -- it only enforces the
fact that your class must implement the methods to be considered " conforming" to
the protocol. A good use of this would be to generate a group of classes with all the
same way of operating: or , etc.
So you could create a category for iinstance:
@protocol plays
-(void) play;
-(NSString*)type;
@end
and then a class that conforms to MUST implement
the play and type methods. If it doesn't the compiler issues a warning but compiles the class anyway. In your code you check:
if ( [obj conformsTo: @protocol(plays)] ) [ obj play];
A category actually adds new methods dynamically to your class. These methods are globally accessible to the runtime as selectors and can be called by name as in @selector(foo)
and
[object foo:bar];
The category Idea is to add special new code to a class even if you don't have the source code for that class. So of course there may be security problems and you could create memory leaks in classes, etc.
In your case maybe: in a separate file AVAudioPlayerDelegate_TrackOps.m
#import "AVAudioPlayerDelegate.h"
@implementation AVAudioPlayerDelegate (TrackOps)
{
- foo {
// do foo stuff;
return bar;
}
@end
Putting it as a category of NSObject
makes all classes respond to foo. Foo can be a stand alone method Objc_perform_selector(@selector(foo))
as well.
Bottom Line: use a category to add a quick method to a class, protocols for enforcing
method implementations, and sublcasses to specialize existing classes like adding member variables or major new functionality. categories can also be used to override a method or two when a subclass is not needed and wanted, but usually if you want to add functionality to a class you make a subclass.
read the Objc book and do some examples.
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html