R – How to memory manage UIViewControllers with a navigation controller

cocoa-touchiphonememory-management

So yeah, I'm a Java guy in this crazy iPhone world. When it comes to memory management I stiill don't have a very good idea of what I'm doing.

I have an app that uses a navigation controller, and when it's time to go on to the next view I have code that looks like this:

UIViewController *myController = [[MyViewController alloc] initWithNibName:@"MyView" 
                                                                    bundle:[NSBundle mainBundle];
[[self navigationController] pushViewController:myController animated:YES];

Now according to Apple's fundamental rule on memory management

You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.

To me that means that I should be releasing myController, or giving it an autorelease message. But, whenever I try doing that my application winds up crashing as I push and pop views off of the stack.

This didn't smell right to me, but in running Instruments it claims that I don't have any memory leaks.

So I my question is

Am I doing this right?
Is the Navigation Controller taking ownership of MyViewController, explaining the lack of a memory leak?
Should I assign myController to an instance variable in my root ViewController? In that case it would be marked retain and I would release in the root's dealloc method

Best Answer

@Ben Gottlieb why do you need to autorelease before pushing it? Retain count at object allocation is 1, autorelease before or after pushing doesn't affect the retain count, though generally autoreleasing as a matter of style is applied afer object alloc/init:

[[[object alloc] init] autorelease];

@bpapa,

2) When pushing, the navigation controller will retain the view controller. Later when this view is popped off the navigation controller stack, the navigation controller will release it.

3) Unless there's a explicit reason to hold onto that view no you should not assign it to an instance variable. In general you want your views to exist only as long as you need them.

Compare method

Either you implement a compare-method for your object:

- (NSComparisonResult)compare:(Person *)otherObject {
    return [self.birthDate compare:otherObject.birthDate];
}

NSArray *sortedArray = [drinkDetails sortedArrayUsingSelector:@selector(compare:)];

NSSortDescriptor (better)

or usually even better:

NSSortDescriptor *sortDescriptor;
sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"birthDate"
                                           ascending:YES];
NSArray *sortedArray = [drinkDetails sortedArrayUsingDescriptors:@[sortDescriptor]];

You can easily sort by multiple keys by adding more than one to the array. Using custom comparator-methods is possible as well. Have a look at the documentation.

Blocks (shiny!)

There's also the possibility of sorting with a block since Mac OS X 10.6 and iOS 4:

NSArray *sortedArray;
sortedArray = [drinkDetails sortedArrayUsingComparator:^NSComparisonResult(Person *a, Person *b) {
    return [a.birthDate compare:b.birthDate];
}];

Performance

The -compare: and block-based methods will be quite a bit faster, in general, than using NSSortDescriptor as the latter relies on KVC. The primary advantage of the NSSortDescriptor method is that it provides a way to define your sort order using data, rather than code, which makes it easy to e.g. set things up so users can sort an NSTableView by clicking on the header row.

Objective-c – What increases an object’s retain count

You are correct that the retain count is 2 after adding it to an array. However, you should only worry about the retain counts you add to the item explicitly.

Retaining an object is a contract that says "I'm not done with you, don't go away." A basic rule of thumb (there are exceptions, but they are usually documented) is that you own the object when you alloc an object, or create a copy. This means you're given the object with a retain count of 1(not autoreleased). In those two cases, you should release it when you are done. Additionally, if you ever explicitly retain an object, you must release it.

So, to be specific to your example, when you create the Person, you have one retain count on it. You add it to an array (which does whatever with it, you don't care) and then you're done with the Person, so you release it:

Person *p = [[Person alloc] init]; //retain 1, for you
[array addObject:p]; //array deals with p however it wants
[p release]; //you're done, so release it

Also, as I said above, you only own the object during alloc or copy generally, so to be consistent with that on the other side of things, you should return the array autoreleased, so that the caller of the getPeople method does not own it.

return [array autorelease];

Edit: Correct, if you create it, you must release it. If you invest interest in it (through retain) you must release it.

Best Answer

Related Solutions

Ios – How to sort an NSMutableArray with custom objects in it

Compare method

NSSortDescriptor (better)

Blocks (shiny!)

Performance

Objective-c – What increases an object’s retain count

Related Topic