Errata

In your Golden Rules you have omitted "new" and friends. From NSObject:

"f you are using managed memory (not garbage collection), this method retains the object before returning it. The returned object is not autoreleased. The invoker of this method is responsible for releasing the returned object, using either release or autorelease."

So it is alloc, copy, new and retain which require a release, which gives maybe NARC.

[http://www.apeth.com/iOSBook/ch12.html#_memory_management]

Note from the Author or Editor:
FIXED in the actual book (published May 2011). My response to this erratum was to add a note to the sidebar mentioning "new" and changing the mnemonic from CAR to ARC so as to suggest the alternate mnemonic NARC, just as proposed by the submitter. Pedagogically I would have preferred not to mention "new" at all, as it is outdated and rare, but it does actually occur in a few of Apple's own sample projects and the reader probably should be told what it is.

Unfortunately the code examples here are bogus, because the values passed back and forth by key-value coding must be objects, and an int is not an object. Thus, to be correct, I should have said:

NSNumber* n = [fido valueForKey: @"number"];

and

[fido setValue: [NSNumber numberWithInt: 42] forKey: @"number"];

Pedagogically, this is a bit confusing since NSNumber isn't introduced until later in the book.

Note from the Author or Editor:
Any actual fix would need to be a little more elaborate, perhaps requiring some rewording of surrounding paragraphs. We'll want to deal with this again if we do a reprint (electronic or otherwise).

Name of first parameter to actionForLayer: should be layer, not "lay" (so that it agrees with the variable name two lines later).

Thinking about this presentation in retrospect, I now think perhaps I should have said there were *four* ways to specify a UIViewController's view when the UIViewController is instantiated in a nib - since obviously, if this is your UIViewController subclass (as it surely will be), you can create the view in code in loadView, just as we did earlier in the chapter for a UIViewController instantiated in code.

v.bounds should be self.view.bounds (twice)

UIDeviceOrientationLandscapeRight should be UIInterfaceOrientationLandscapeRight; the device orientation and the interface orientation are the reverse of one another so it makes a difference.

As earlier in this chapter, I think instead of comparing against UIDeviceOrientationLandscapeRight and UIDeviceOrientationPortrait, it would be clearer to compare against UIInterfaceOrientationLandscapeRight and UIInterfaceOrientationPortrait.

This line should be cut:

[cell.layer setValue:@"done" forKey:@"done"];

As things stand it does no harm, but it serves no function and is just confusing. My idea here originally was to increase efficiency by not modifying a cell if it is being reused, by structuring the method like this:

if (![cell.layer valueForKey:@"done"]) {
// ... do stuff ...
[cell.layer setValue:@"done" forKey:@"done"];
}

In the end, however, I found this unnecessary and cut out the scaffolding. Unfortunately I left that one line in.

Need another bullet point specifying that the app must have a Playback audio session policy.

Would be nice to add, however, that when calling UISaveVideoAtPathToSavedPhotosAlbum it really is nicer to supply a completion handler; that way, we don't dismiss until the saving is finished.

At start of last code block, need to say where the variable "item" comes from:

AVPlayerItem* item = p.currentItem;

The warning needs to be broader, since the same problem exists if the UIImagePickerController is presented in a modal view on iPhone and dismissed with animation. Until the animation is over, the UIImagePickerController's media player still exists and the chosen movie cannot be played elsewhere in the interface. The solution here is to use delayed performance.

Really should include dealloc implementation as well.

In this line:

[people addObject: [self.child person]];

It would be good to cast self.child to a MyPersonParser, to quiet the compiler.

Would have been nice to include memory management:

// ... do something with result
CFRelease(src);
[result release];

self.undoer should be self.undoManager. This is because the example at this point supposes that we are no longer using a "private" undo manager, self.undoer; instead, we have made the undoManager property writable, so that we can have our own undo manager and at the same time have the responder chain be able to find it.