Proper memory management by an application is key to stability of an application. Doing it incorrectly can cause a myriad of bad things to happen! The side effects can include corrupting application data, crashing the application, locking up use of the computer or device, or even crashing the system or causing it to reboot.  Thus, memory management concerns are always in the back of the mind of every programmer (and, if they are unfortunate, the front of their mind), especially when they learn a new language. This article introduces programming issues related to memory management. In my next article I will get more technical with best memory management practices in programming iOS/CocoaTouch View Controllers.
In older, procedural programming languages that allow memory allocation (non-object based languages such as C or  Pascal), managing memory was pretty straight forward:
[sourcecode language=”c” light=”true”]
int appFunction(int size)
{
int *array = malloc(size * sizeof(int));
â‹®
free(array); // Done with the dynamically allocated memory
} // appFunction()
[/sourcecode]
Example: C-language memory allocation.
With object-oriented programming, application designers tend to structure their designs as a fluid interaction of objects. The syntax of object-oriented languages (such as C++ or Objective-C) helps programmers to avoid memory management mistakes easier than procedural languages, particularly in more complex application designs.
Since Objective-C was invented along with the APIs and frameworks used for environments like iOS and Mac OS X, Apple assumes its use with a class hierarchy and, for all practical purposes, a dependence on the NSObject base-class. This class determines a whole gamut of conventions that are nearly indistinguishable from the Objective-C language itself, so it is hardly worth discussing the use of Objective-C without NSObject.  While it looks complex, the important thing is that the allocation and deallocation is handled at well-known locations in the code that will be used for other purposes, the initializer and deinitializer.
[sourcecode language=”obj-c” light=”true”]
– (id)init:(int) size
{
self = [super init];
if (self)
_array = [[NSArray alloc] init];
return self;
} // -init
â‹®
– (void)dealloc
{
[_array release];
[super dealloc]; // Done with the dynamically allocated memory
} // -dealloc
[/sourcecode]
Example: Objective-C memory handling
Just as, with C, where you need to internalize when you should call malloc() and free(), with Objective-C  you should internalize “object ownership” and when to send retain and release. These retain/release messages (sending a message is analogous to a function or method call, in other languages) implement reference-counting—a way of keeping track of how many objects are referring to the object.
Internalize this rule: If you do alloc, retain, or copy on an object, you own it and it is your job to release it… otherwise it isn’t.
In Objective-C, objects allocate other objects for its use or other’s use. These allocations are memory allocations. Cocoa (used in Mac OS X) and CocoaTouch (the Cocoa variant used for iOS) programming frameworks assume a clear understanding of who owns an object. Any number of objects can retain ownership another, either explicitly or implicitly. If one object allocates another, then there is an implicit ownership of that object.
stringOwner implicitly owns the allocated object, so it must release it.
[sourcecode language=”obj-c” light=”true” highlight=”1,2,3″]
NSString *stringOwner = [[NSString alloc] init];
â‹®
[stringOwner release];
[/sourcecode]
tempString does not get ownership, but it can use it for the duration of the method.
[sourcecode language=”obj-c” light=”true” highlight=”1,2,3″]
NSString *tempString = [NSString string];
[/sourcecode]
stringOwner has claimed ownership via retain, so it must release it.
[sourcecode language=”obj-c” light=”true” highlight=”1,2,3″]
NSString *stringOnwer = [[NSString string] retain];
â‹®
[stringOwner release];
[/sourcecode]
If an object is passed as a parameter to another method, it is possible that the other method may claim ownership of the object. In this case, the sender (AKA “caller” in other languages) can release the object if it won’t need it, later.
[sourcecode language=”obj-c” light=”true” highlight=”1,2,3,4,5,6″]
NSString *stringOnwer = [[NSString string] retain];
â‹®
[existingArray addObject:stringOwner]; // array is also, now, an owner
â‹®
[stringOwner release]; // Not needed by this method (or class any longer)
[/sourcecode]
The problem is that, despite Apple’s simple set of rules (or, better yet, the Rules of Thumb), it is often not clear which of their APIs retain ownership of the objects passed in, even by reading the official documentation. I usually find that if I am at all unsure, I need to google it—which often leads to the most reliable advice coming from Stack Overflow.
Apple must know this because they provide their excellent (though not perfect) Instruments tool that works with their Xcode development environment to help ferret out memory bugs and leaks.
Next, I will write about memory usage as it relates to iOS CocoaTouch View Controllers (because that also isn’ve very apparent).
Resources — The Basics
I Just Want to Submit a Frickin’ iPhone App to the App Store! (Part 3)
Way back in in “I Just Want to Create a Frickin’ iPhone App! (Part 1),” I walked you through the logistics of joining the developer program (no, you didn’t miss “Part 2,” I have not written it yet). Fast-forward a couple of months and it’s time to submit to the app store! For a company that has built a reputation on simplicity, Apple has concocted an arcane process and made it worse by not providing any complete nor accurate information to help with the application submission process.  Apple’s minimalistic approach is of no help… you often feel like your flying blind as you try to make your way through the process. I’ll try to give some heads-up and clarity if you, too, are going through this for the first time.
So, let’s hope I can remember all that I went through.
.plist file, so you can access its “CFBundleIdentifier” (aka “Bundle identifier”) explicitly. The value in the app should be the reverse domain name, for example, “com.handthingsdown.htdmobile”; do not prefix the “Bundle Seed ID” to the bundle identifier in the app.Resources
Posted in Commentary, Technical