Objective-C categories are a beautiful thing. They allow you to quickly extend a class’s functionality without creating a subclass. One major shortcoming of categories, however, is their inability to hold extra properties/variables. Kind of lame huh? Well it doesn’t have to be! By leveraging the Objective-C runtime library, we can add extra properties to our categories via magical things called associated objects.
If you’ve ever needed to save dictionaries within your apps, you are undoubtedly aware of their biggest limitation: you can only store generic data types (NSString, NSData, NSDate, NSNumber, NSArray, NSDictionary) within them. To be honest, most of the time those generic data types are all you need; but what if you need to do something a little more… robust? This is where NSCoding comes to the rescue.
I’ve always known about NSBundle’s external code loading capabilities, but have never had the immediate need to leverage it. However, one of my more recent projects required me to develop in a “host-plugin” model – I finally had the excuse I needed to dive into the advanced features of NSBundle.
Often the topic of heated discussions, singletons actually can be fairly useful in the right situation. Though many view the “wasteful” nature of singletons as a deal-breaker, they are not always as evil as they’re made out to be.
I know, I know. Blocks have been lingering around ever since the iOS 4 days. So why write a post on them now? Because they’re awesome. duh. Well, that and I feel they are extremely hard to grasp for newcomers (I surely had a difficult time wrapping my head around them at first; not to mention they’re just plain ugly at times – which is a turn off for some)