What is the difference between these two ViewController Pushes?

Question

What are the differences and the implications of the differences between the boilerplate push provided by apple

     <#DetailViewController#> *detailViewController = [[<#DetailViewController#> alloc] initWithNibName:@"<#Nib name#>" bundle:nil];
 NSManagedObject *selectedObject = [[self fetchedResultsController] objectAtIndexPath:indexPath];
 // ...
 // Pass the selected object to the new view controller.
 [self.navigationController pushViewController:detailViewController animated:YES];
 [detailViewController release];

and this method (from PragProg iphone SDK development Book) cabinet controller is added to interface and @synthesize in implementation:

  [self.navigationController pushViewController:self.cabinetController
                                       animated:YES];

i would chalk it up to the newness of the SDK i am working with versus the book...but that seems really different and seems to imply VERY different ownership, if that is the correct word. My main concern, if the question is too convoluted to answer, is whether or not one of these methods is more memory efficient.

EDIT: ok, well, after clearing my vision by posting this question...i don't think there that much of a difference. the boilerplate method allocates memory on demand where the books method makes the cabinet view a property. i think that makes the boilerplate method better somehow...or equal...that part i am still fuzzy on. it seems like both will release just the same but maybe the memory is held earlier using the books method.

Answer 1

The Apple version is more memory efficient, because the detailViewController and it's view will be deallocated when it gets popped from the navigation controller's stack. Unlike the PragProg version, which retains the cabinetController in an instance variable (and therefore prevents it from being deallocated), the Apple code isn't storing a reference to the detail controller it's creating.

The PragProg implementation might make sense if the user is likely to navigate frequently back and forth between the cabinet controller and the view controller that's retaining it, since that avoids a bit of CPU overhead incurred by repeatedly creating and deallocating the objects, but you'd have to profile it to see if that makes any meaningful difference (which it ordinarily wouldn't).

Answer 2

In the second case it would appear that cabinetController is a property of the class indicated by self. In the boilerplate this is not the case.