If you’ve been developing with Objective-C for a while you know it’s powerful stuff. While it’s not as elegant looking as some languages, such as Ruby, it does have a rather impressive array of features that make it just flexible as new languages, such as Ruby.<\/p>\n
One of the flexible features of Objective-C is Categories.\u00a0Categories allow developers to snap on methods to classes they didn’t create and don’t have access to their source code. Beyond that, these methods become part of the class hierarchy.<\/p>\n
One complaint that I’ve had with Categories is that you can’t add properties as part of the category snap on. Recently I wanted to extend UITextView so that it would be easier to take advantage of AttributesStrings. My first thought was to create a Category and initially it seemed I was on the right track. That was, until I realized that I wanted to have the UITextView keep track of default fonts. Default fonts mean properties and properties mean so long Category … or does it?<\/p>\n
After building a subclass of UITextView, to do the things I want AND adding new properties, I wasn’t happy with the way thing looked. It’s not that the code wouldn’t do it’s job but it just didn’t feel as clean as it could be. I tried to improve my code by splitting off some capability into a Category.<\/p>\n
As I wrote the Category it just felt right so I started trying to move the rest of my code into the category but still there were these properties. A little research on the net turned over something new, Associative References<\/a>.<\/p>\n Associative References make it possible, like Categories, to attach (or associate) an\u00a0object instance variables to an existing class and as the French would say “et voila” there you go, Categories with Properties.<\/p>\n Ok, so how do you make use of Associative References? First stop is to add properties to your Category:<\/p>\n Now, Xcode will complain that since this is a category you’re going to have to implement the getter and setter for this property. So let’s get to implementing:<\/p>\n Lines 7-9 and 11-13 are the methods that addresses Xcodes complaint. Pretty boiler plate. The magic happens on lines 8 and 12. Line 12 sets the value of the property and line 8 gets the value of the property. In both cases you’ll notice the use of the void pointer from line 3. This is a key that makes the association possible and it needs to be unique per property \u00a0and per class but not per property. This means that a developer simply has to replicate the pattern in line 3 per key.<\/p>\n In general, I would say simply replicate the\u00a0pattern laid out in the code above to add properties to a category.<\/p>\n Happy Hunting<\/p>\n","protected":false},"excerpt":{"rendered":" If you’ve been developing with Objective-C for a while you know it’s powerful stuff. While it’s not as elegant looking as some languages, such as Ruby, it does have a rather impressive array of features that make it just flexible … Continue reading \r\n@interface UITextView (Utilities)\r\n\r\n@property (nonatomic, strong) UIFont *regularFont;\r\n<\/pre>\n
\r\n#import <objc\/runtime.h>\r\n\r\nstatic void *RegularFontKey;\r\n\r\n@implementation UITextView (Utilities)\r\n\r\n- (UIFont *)regularFont{\r\n return objc_getAssociatedObject(self, &RegularFontKey);\r\n}\r\n\r\n- (void)setRegularFont:(UIFont *)regularFont{\r\n objc_setAssociatedObject(self, &RegularFontKey, regularFont, OBJC_ASSOCIATION_RETAIN_NONATOMIC);\r\n}\r\n<\/pre>\n