I would like to add a property to UITableView in a Class Extension:
@interface UITableViewController ()
@property NSString *entityString;
@end
Then I import the extension and then I use entityString property in a subclass of UITableViewController:
@implementation CustomerTableViewController
- (void)viewDidLoad {
self.entityString = @"Customer";
...
[super viewDidLoad];
}
...
Apple documentation says:
the compiler will automatically synthesize the relevant accessor methods (...) inside the primary class implementation.
But when I try to execute it I get this error:
-[CustomerTableViewController setEntityString:]: unrecognized selector sent to instance 0x737b670
What am I doing wrong? maybe the property cannot be accessed by subclasses?
Try using a category with Associative References instead. It is much cleaner and will work on all instances of UIButton.
//Example usage
The docs state:
When you use
@property
, it is roughly equivalent to declaring accessor methods. So this means you can only do such a thing if you are also the author of the "main"@implementation
block of the class, which with UITableViewController, you are not.Your only option here is Categories, which cannot add instance variables.
The docs link, and note the very last line of that page:
A class extension is used to declare additional interface -- methods and properties -- whose implementation contract will be met within the class's primary
@implementaiton
.Which is exactly why you can't add storage -- add ivars -- via a class extension. A class extension is an interface, no more, no less.
@synthesize
is what creates storage for@property
declarations, but@synthesize
of an@property
can only appear in the@implementation
of the class (whether explicitly or as a default behavior of the compiler).Since you can't recompile the framework class, you can't add ivars to it.
@prashat's answer is one way to add storage to an existing class. However, going that route is generally undesirable; hanging state off of framework classes willy-nilly is a sign of poor design and will make your application significantly more difficult to maintain over time.
Far better to revisit your design, understand why you currently require attaching state to an object that can't directly contain it, and refactoring that requirement away.