Today was the second day dedicated to iOS development, day four of learning, and day five since leaving home. Scott continues to remind us that energy management and pacing is key. This is like an iron man competition for the mind, where we test the agility and endurance of our neurons and see just how much they learn and remember. Like a little app on an iPhone, our brains can only hold on to so much.
True to its roots in C, memory management of dynamically allocated objects in Objective-C is fundamentally manual. Nowadays Objective-C programmers have some help from the compiler to simplify things, but there is no thorough system of garbage collection like in .Net and while a programmer can forget objects, the program will not, and it will cause your app to leak resources.
Objective-C doesn’t utilize the venerable malloc and free functions, instead classes have class methods for allocation and objects have the ability to free their own memory. They maintain an internal reference count, incremented by the retain method and decremented by the release method. When the reference count is zero, they free themselves. I was familiar with this pattern from programming with COM in C++ at Seagull; it was a dark time full of lonesome orphans. Luckily, Apple has implemented some helpful features to make this object life-cycle easier to manage.
For a long time, Objective-C programmers have had “sorta automatic” garbage collection in the form of the autorelease pool. This is involves instantiating an object and marking it by calling the autorelease instance method. This would cause it to be automatically cleaned up in the next cycle of the event loop, or the next time the thread has its pool manually release (such as by exiting an @autoreleasepool block). This provided a simple solution for situations where functions must return an object, but the receiver had no interest in keeping it around. It was not a complete solution for all objects.
Automatic Reference Counting (or ARC) was introduced with OS X 10.6 and iOS 4. This is a methodology, primarily in the compiler, that enables standard pointers to objects to automatically call the retain and release methods on objects in the natural context of their use. It reminds me of the underlying concept of the std::auto_ptr class in C++, but with compiler and runtime support to make it far more magical. This frees the author from writing a lot of the code to manage the objects, but beware. Just because you don’t need to write code doesn’t mean you don’t need to think.
The .Net runtime implements automatic garbage collection, meaning the programmer does not need to think about handling memory resources. It’s rather efficient and very hands-off. The bad news is any dedicated .Net programmers may find themselves mourning the loss of it while picking through Objective-C using Instruments to find a memory leak.
The good news is that digesting some Objective-C might force them to cogitate on what the runtime is doing to help them with memory, and what the compiler is not doing to help them with other resources. Non-memory resources, such as network connections and file handles, are tied to lifetime of their parent object if left up to the capricious and lazy garbage collector. I imagine time in Objective-C will make a .Net programmer happy to get back to the good old days of IDisposable and using while teaching them good habits about purging their resources.
I’ve had a lot of time this week to consider what happens to think when they’re forgotten, but not gone. “The Ranch” is in Historic Banning Mills, Georgia, which is full of ruins from the 1800s, which reminds us constantly what happens when something is made and then just left behind.