Thursday, February 28, 2013

View Unloading into the Future!

When Apple released iOS 6, they stated that developers were having "trouble" with properly using viewDidUnload and viewWillUnload and decided that ultimately the memory hit from releasing objects in these methods wasn't enough of a concern to keep those methods and they were deprecated.  It was basically a nice way of saying that a lot of developers are so terrible at view lifecycle management that they were just going to remove the unload methods so that developers didn't continue to mess up their app by not knowing what they were doing.  Now I personally applaud Apple for taking into account this problem and dealing with it in a way that doesn't hurt legacy apps.  However, I do believe that all APIs are tools that when wielded appropriately can be useful for building something that works well.  So when viewDidUnload and viewWillUnload were deprecated, one of the first things I set out to do was port them so that I could continue to use these "tools" into the future.  Now, if you don't want to use viewDidUnload or viewWillUnload and want to conform to Apple's recommended application life cycle design guidelines then this article won't likely help you, and I must credit your wisdom.  For the rest of you, let's jump into memory warnings!

viewWillUnload and viewDidUnload ported to iOS 6


Wednesday, February 27, 2013

A Better NSData Description

NSData has not always returned the HEX string of its data.  There was a time when it behaved far more modestly (and usefully in my opinion) when it just indicated it's pointer and length.  Let's take advantage of the method swizzling tools we learned about in a previous post so that we can get NSData's description to be something more useful than a data dump - and we'll make it configurable too so that at runtime you can decide how NSData's description should behave.  I'll also throw in an optimal NSData-to-hex-string method for good measure, hopefully to help counteract the awful practice some developers have adopted of using the NSData description for that serialization.

Putting NSData's description on a diet!


Method Swizzling

Objective-C is an amazing language.  So many possibilities with dynamic runtime typing and built in polymorphism.  But one of my favorite features of mutable runtime objects is the ability to Method Swizzle, which is effectively the ability to add a method or exchange 2 methods.  The usefulness of method swizzling is vast, such as adding a method to an older SDK that the newer SDK has or perhaps changing the functionality of an existing method.  In this post, I'll just give a quick implementation for method swizzling that can be reused over and over. A word of warning though, method swizzling can be very dangerous as you are effectively modifying the way existing code that has already been vetted works. 9 times out of ten, you can solve a problem without modifying the runtime and using object oriented patterns. Only when you have no choice should you consider method swizzling - and even then, you probably shouldn't.

Swizzling Methods for the win!



Monday, February 25, 2013

Better Reference Counting (Safe Release)

When it comes to manually managing memory, it's absolutely fantastic to have coding patterns for making your memory management duties...well...manageable.  Reference counting is one such pattern that is widely used throughout computer programming.  COM (which is on top of C++) uses it extensively, and thus the underlying system of memory management in C# uses it, but so does Core Foundation (C level API on Mac OS X and iOS) and, even more noticeably, is that the Objective-C language has the reference counting memory management pattern built in.

At this point, I assume everyone knows what reference counting is and how to use it. If not, you should verse yourself with Apple's Memory Management Overview.  Now since Apple has introduced Automatic Reference Counting (ARC), objective-c memory management has reached near trivial levels as that of managed memory languages like Java and C#.  But for those of us that need to support older platforms, work in legacy code bases or develop public libraries that require non-ARC support, being elegant with reference counting is very important.  And even those of us that are converted over to ARC, we still need to be aware of Core Foundation memory management which does not have ARC.

So that was a serious introduction to nothing it would seem! Well, what this post will actually cover is the pitfall of recursive (aka reentrant) code that can lead to crashing in a ref counted world.   Basically, we'll deal with releasing an object that leads to it being released again.

The problem: reentrant releases!