I know of a couple of rules regarding Objective-C categories:
Category methods should not override existing methods (class or instance)
Two different categories implementing the same method for the same class will result in undefined behavior
I would like to know what happens when I override one of my own category methods in the same category. For example:
#interface NSView (MyExtensions)
- (void)foo; // NSView category implementation
#end
#interface MyClass : NSView
{ }
#end
#interface MyClass (MyExtensions)
- (void)foo; // MyClass category implementation
#end
With these interfaces defined, which method will be executed when I run the following code?
MyClass * instance = [[MyClass alloc] initWith...];
[instance foo];
[instance release];
Note: With my compiler, the MyClass implementation takes precedence, but I'm not sure if that is guaranteed to occur, or simply one specific flavor of undefined behavior.
To extend on drawnonward answer:
It's matter of hierarchy. Categories are really just a means of organizing source files. When compiled, all the methods of a class, including the ones defined in any category, end up in the same file.
Anything you could do in a regular class interface you can do in a category and anything you shouldn't do in a regular class interface you shouldn't do in a category.
So:
Category methods should not override
existing methods (class or instance)
You can use methods defined in the regular class interface to override inherited methods so you can override inherited methods in a category.
However, you would never try to have to two identical method definitions in the same ordinary interface so you should never have a method in a category that has the same name as a method in either the ordinary interface or another category on the same class. Since all the method definitions end up in the same compiled file, they would obviously collide.
Two different categories implementing
the same method results in undefined
behavior
That should be rewritten to say "Two different categories implementing the same method for the same class results in undefined behavior." Again, because all the methods for any one class end up in the same file, having two methods in the same class would obviously cause weirdness.
You can use categories to provide methods that override superclass methods because a class and its superclass are two distinct classes.
If your ever confused about whether a category will cause problem just ask yourself this: "Would the methods in the category work if I copied and pasted them all into the class' .h/.m files?" If the answer is "yes" then you're in the clear. If "no", then you've got problems.
Each method of each class has an implementation. A category adds or replaces a method for a specific class. That means the behavior you are seeing, where MyClass has one foo and NSView has another foo, is well defined. Any instance of MyClass will have a different foo than any instance of NSView that is not a MyClass, just as if foo had been defined in the main implementation and not a category. You should even be able to call [super foo] from MyClass to access the foo defined for NSView.
Related
In a category I got from a book, there is a protocol specified. It requires one method and declares that method in the category as well.
If I implement the protocol in another object (a table view cell), my understanding is that I MUST include the required method. However, other than the title of the method being the same as the one in the category, do I inherit any of the code from the category version? That code is meaningful because only after that code completes do I want to do something.
category: .m
#protocol DownloadHelperDelegate <NSObject>
-(void)didCompleteDownloadForURL:(NSString *)url withData:(NSMutableData *)data;
#end
- (void)didCompleteDownloadForURL:(NSString *)url withData:(NSMutableData *)data{
// doThis
// doThat
// readyToDoSomethingElsewhere
}
In tableviewCell: .h
#import "category.h";
#protocol category
.m
-(void)didCompleteDownloadForURL:url withData:data;
{
// Did doThis happen?
// Did doThat happen?
// If so, I want to do Something
}
Since the category is a category on UIImageView, it only adds methods to that class.
Since your class is derived from UITableViewCell and that does not derive, directly or indirectly, from UIImageView, it does not inherit an implementation of -didCompleteDownloadForURL:withData: from the category.
I'm guessing the category's method would not be an appropriate implementation of the protocol method, anyway. It has the same signature, but I suspect it has a different purpose. In particular, I suspect the category method's purpose is, at least in part, to forward the call along to a delegate which implements the protocol. So, it wouldn't make sense for the delegate itself to inherit that implementation.
It's just a coincidence that the category method and the protocol method have the same signature. In fact, I would suggest that the category method be changed to start with a unique prefix so that there's no chance that it collides with a method on UIImageView, which might be private to Apple or added in a future version of UIKit.
I am trying to understand Class type in Objective-C. May I ask what is the different between Class type and NSObject type? It sounds like Class type does something similar like NSObject correct?
I believe this has been asked several times... but I couldn't find any old instance, so anyway.
Unlike C++-like languages, classes are actual regular object instances in OBJC.
When you call [NSObject class], it returns a live object which contains class methods and extra informations. These are synthesized by compiler, and this actually provides all the class related features.
Class is the type for for these class objects.
One more thing. Because the Class objects are objects, they also have class object, and these are called meta-class. See here for more details:
http://www.cocoawithlove.com/2010/01/what-is-meta-class-in-objective-c.html
Also, you may be confused because most of types in Cocoa are using NSObject as a root class. But it is just a convention, and actually a class doesn't have to subclass NSObject.
No NSObject is not the same as Class.
In Objective C, classes are objects. A class like NSObject in an instance the Class type. It is correct to say NSObject is of type Class, just like you would say an instance of NSObject is of type NSObject.
Class is a an object also, but it's type is the meta-class which really isn't for beginners.
A class is a template, e.g. a human
An object is an instance of a class, e.g. bob the human
an NSObject is the root class of most Objective-C classes (e.g NSTextField, NSButton, etc)
So, NSButton inherits the properties from NSObject, and is also a class (a child class). If you create a button, that button is now an instance (object), of type NSButton (class), which inherits from: NSControl : NSView : NSResponder : NSObject in that order, descending.
More info:
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html
I'm following a tutorial on how to create a popover in Iphone here
what is (overrides) this code:
#interface UIPopoverController (overrides)
+ (BOOL)_popoversDisabled;
#end
#implementation UIPopoverController (overrides)
+ (BOOL)_popoversDisabled
{
return NO;
}
#end
This is an objective-C category. A category is a way of providing extra methods on a class, and they're useful in the following situations:
Extending a library class with domain-specific functionality. ie providing some extra features that will be useful for your application. This works whether or not you have the source-code for that class. For example, you could implement an [NSString asCreditCard] method or [UIColor applicationThemeColor].
Categories are also invaluable for grouping related functionality in a complex class.
Objective-C categories have the restriction that you cannot define additional ivars, and thus ivar-backed properties, on a category, although you can easily work around this using associative references - a run-time feature allowing you to link an object to a given class.
Associative References
To 'fake' a property or ivar on a category class use the following:
Define a 'key' to reference the associated property.
static char const* const carNamekey = "com.myObject.aKey";
The key doesn't necessarily have to have a value, since its the memory address of the object that is actually used.
Now, Implement the properties:
- (void) setCar:(Car*)car
{
objc_setAssociatedObject(self, &carNamekey, car, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}
- (Car*) car
{
return objc_getAssociatedObject(self, &carNamekey);
}
If you wish you can add an #property declaration on the interface definition for the category, as an invitation to users of the class to use property-style (ie class.property = xxx) syntax.
Class Extensions
Another feature that is very similar to Objective-C categories is the class extension. A class extension is defined in the implementation block for a class like so:
#interface MyClass()
Some people refer to these as 'empty categories', but this is not quite correct. Unlike a category, a class extension will allow you to define additional properties and ivars on a class, without using associative references. This is useful for making a readonly property, internally writable, and things like that.
There - now you probably know more about categories than a lot of folks :)
Jasper Blues' answer explains categories nicely, so I'll just add that you should avoid using categories to override methods in the class to which you're adding the category. The reason is that the order in which categories are added to a class is undefined, so you can't know for certain whether the class will get your version of a method or one defined in another category. If you need to override methods in a class, create a subclass and put your overrides there.
However, people sometimes use categories to organize the methods in a class definition. If that's the case here, the method(s) in the overrides category are probably meant to override methods in the superclass, which is fine.
Let's say I have this class and its subclass
#interface MySuperClass
- (void)open:(id)type value:(id)value;
- (void)openWebpage:(NSURL*)url;
#end
#interface MySubClass
- (void)openWebpage:(MyBookmarkClass*)bookmark;
#end
and that calling [someMySubclass openWebpage:someBookmark] calls [super open:BookmarkClass value:self.url]. And open:value calls [self openWebpage:url].
I realize this is very contrived, but I ran into a similar situation. My confusion is that even though [self openWebpage:url] is being called in MySuperClass, when it gets executed openWebpage: is being run in the context of the caller, MySubClass, which doesn't know what to do with an NSURL.
So my question is: is there any way to force something to be called in its original context? Or make it as though it calls super as many time as it can up the chain and find the method closest to the top?
There is only one context. There's a single object. Its class is MySubClass.
It is a mistake to have overridden the method with a different incompatible type. Don't do that. This is not C++ with function overloading. There's no dispatch based on the type of arguments.
The convention is to name methods by what they're acting on. So, you may have a method named -openWebpageURL: in MySuperClass and another method introduced in MySubClass named -openWebpageBookmark:. Note that MySubClass would still have a method named -openWebpageURL: inherited from MySuperClass.
What is the difference between a Category and a Class Extension. I believe both are used to add custom methods in existing classes. Can someone throw light on this? Examplification with code will be really appreciated.
A category is a way to add methods to existing classes. They usually reside in files called "Class+CategoryName.h", like "NSView+CustomAdditions.h" (and .m, of course).
A class extension is a category, except for 2 main differences:
The category has no name. It is declared like this:
#interface SomeClass ()
- (void) anAdditionalMethod;
#end
The implementation of the extension must be in the main #implementation block of the file.
It's quite common to see a class extension at the top of a .m file declaring more methods on the class, that are then implemented below in the main #implementation section of the class. This is a way to declare "pseudo-private" methods (pseudo-private in that they're not really private, just not externally exposed).
Category
=> In Objective C, when you want to add some more functionality to a class without inheritance, you simply use category for it.
=> it comes with its own .h and .m file
=> Category uses to add new method not properties.
Class Extension
-> In Objective C, when you want to make behaviour of some property private you use class extension.
-> it comes with **.h** file only.
-> mainly for properties.
Note: when we add a new file and select a option of objective c
category shows category and "category on" not "subclass of" so it
shows like
#interface className (categoryName)
#end
-You will get two file .h and .m with file name as (className+categoryName.h and className+categoryName.m)
and in extension case you will get
#interface className()
#end
-You will get only one file with name as className_extensionName.h
In category you don't own the class but in extension you are.
Category is a way to add methods to a class whether or not source code is available, meaning you can add category to foundation classes like NSString and also to your own custom classes.
Extension can only be added to the classes whose source code is available because compiler compiles the source code and extension at the same time.
We can add extra instance variables and properties in class extension but not in category.
Any variable and method inside the extension is not even accessible to inherited classes.
Category and extension both are basically made to handle large code base, but category is a way to extend class API in multiple source files while extension is a way to add required methods outside the main interface file.
Use category when you have to break your same class code into different source files according to different functionalities, and extension when you just need to add some required methods to existing class outside the main interface file.
Also, when you need to modify a publicly declared instance variable in a class, for example,
readonly to readwrite, you can re-declare it in extension.
Extension: To make methods private and to add properties of our own custom class, not of Apple class.
Category: To add more methods in existing class not the property, it can be used for both custom class and Apple class like NSString.
We can also have properties Using set associated property in category class.
#interface SomeClass (Private)
#property (nonatomic, assign) id newProperty;
#end
NSString * const kNewPropertyKey = #"kNewPropertyKey";
#implementation SomeClass (Private)
#dynamic newProperty;
- (void)setNewProperty:(id)aObject
{
objc_setAssociatedObject(self, kNewPropertyKey, aObject, OBJC_ASSOCIATION_ASSIGN);
}
- (id)newProperty
{
return objc_getAssociatedObject(self, kNewPropertyKey);
}
#end
Refer : http://inchoo.net/dev-talk/ios-development/how-to-add-a-property-via-class-category/
#interface SomeClass ()
- (void) anAdditionalMethod;
#end
I think it is not the way to declare Category.
Category must have a name
#interface SomeClass (XYZ)
- (void) anAdditionalMethod;
#end
for example
#interface NSMutableArray (NSMutableArrayCreation)
+ (id)arrayWithCapacity:(NSUInteger)numItems;
- (id)initWithCapacity:(NSUInteger)numItems;
#end
Declared for NSMutableArray by Apple
ios extension similiar to c#,java abstract class or interface
ios category similiar to c#,java class extension
Categories
Categories are used when you are creating file containing large number of methods.So they provide you with the facility to break a single class into different modules.Also if any changes are made to the categories the compiler does not waste time to compile the entire project.Categories are not able to add new variable or properties and look upto their parent class .You can override a method in a category but it isnt a good idea because the method cannot further be overridden.Also the flow can be effected because all categories have the same hierarchial level and hence two categories belonging to same parent class may exist at run time.Also protected methods can be created using categories
Extensions
Extensions enable you to override the property or add new property to the existing parent class.Syntatically same to categories they do not have name and are represented as #interface class()
No .m file is present and method declared in extension have to be implemented in #implementation of parent file
More help at this link
Here is my understanding :
Extensions are usually used to add extra features to our own "custom class". We can add private methods or properties extending the class interface which can be used within the implementation of the class.
Extensions are to be written within the same file as the class. Hence you cannot write extensions for pre defined types like String, Float, etc.
On the other hand Categories can be used to add extra methods to a pre existing classes. Example we can create our own methods by extending String class. Note that we cannot create extra properties in the categories. Also main advantage of categories is we can write the categories in any other file, outside the file where your class exits.
Also while creating categories you are supposed to give a name for it within the brackets.
But for extension no name is required. Hence some times they are also called anonymous categories.
Categories and Extensions
A category allows you to add methods to an existing class—even to one for which you do not have the source. Categories are a powerful feature that allows you to extend the functionality of existing classes without subclassing. Using categories, you can also distribute the implementation of your own classes among several files. Class extensions are similar, but allow additional required APIs to be declared for a class in locations other than within the primary class #interface block.
Adding Methods to Classes
You can add methods to a class by declaring them in an interface file under a category name and defining them in an implementation file under the same name. The category name indicates that the methods are additions to a class declared elsewhere, not a new class. You cannot, however, use a category to add additional instance variables to a class.
The methods the category adds become part of the class type. For example, methods added to the NSArray class in a category are included as methods the compiler expects an NSArray instance to have in its repertoire. Methods added to the NSArray class in a subclass, however, are not included in the NSArray type. (This matters only for statically typed objects because static typing is the only way the compiler can know an object’s class.)
Category methods can do anything that methods defined in the class proper can do. At runtime, there’s no difference. The methods the category adds to the class are inherited by all the class’s subclasses, just like other methods.
The declaration of a category interface looks very much like a class interface declaration—except the category name is listed within parentheses after the class name and the superclass isn’t mentioned. Unless its methods don’t access any instance variables of the class, the category must import the interface file for the class it extends:
#import "ClassName.h"
#interface ClassName ( CategoryName )
// method declarations
#end
Note that a category can’t declare additional instance variables for the class; it includes only methods. However, all instance variables within the scope of the class are also within the scope of the category. That includes all instance variables declared by the class, even ones declared #private.
There’s no limit to the number of categories that you can add to a class, but each category name must be different, and each should declare and define a different set of methods.
Extensions
Class extensions are like anonymous categories, except that the methods they declare must be implemented in the main #implementation block for the corresponding class. Using the Clang/LLVM 2.0 compiler, you can also declare properties and instance variables in a class extension.
A common use for class extensions is to redeclare property that is publicly declared as read-only privately as readwrite:
#interface MyClass : NSObject
#property (retain, readonly) float value;
#end
// Private extension, typically hidden in the main implementation file.
#interface MyClass ()
#property (retain, readwrite) float value;
#end
// Notice that (in contrast to a category) no name is given in the parentheses in the second #interface block.
It is also generally common for a class to have a publicly declared API and to then have additional methods declared privately for use solely by the class or the framework within which the class resides. Class extensions allow you to declare additional required methods for a class in locations other than within the primary class #interface block, as illustrated in the following example:
#interface MyClass : NSObject
- (float)value;
#end
#interface MyClass () {
float value;
}
- (void)setValue:(float)newValue;
#end
#implementation MyClass
- (float)value {
return value;
}
- (void)setValue:(float)newValue {
value = newValue;
}
#end
The implementation of the setValue: method must appear within the main #implementation block for the class (you cannot implement it in a category). If this is not the case, the compiler emits a warning that it cannot find a method definition for setValue:.
For official documentation follow this link: source