Errata for Programming iOS 4
Submit your own errata for this product.
The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update
| Version |
Location |
Description |
Submitted By |
Date Submitted |
Date Corrected |
| PDF |
Page 26
middle |
(In Xcode 3.2.x, you can even choose Build → Preprocess to confirm that this is true.)
could be replaced by:
(In Xcode 4.1.x, you can even choose Product → Generate Output → Generate Preprocessed File to confirm that this is true.)
Note from the Author or Editor: True. At the time the book was written, there was no Xcode 4.1.x. In Xcode 4.0.x, to which the book was written, there was no (easy) way to see the preprocessor output (one of many major backward steps from Xcode 3).
|
Peter Olsen |
Sep 30, 2011 |
|
| Printed, PDF |
Page 10
bottom half |
When talking about int *intPtr versus int* Ptr, and going into the syntax of multiple declarations, it would be good to explain the C syntax where
int* intPtr1, intPtr2, intPtr3;
only declares the first variable as a pointer (and maybe recommend avoiding multiple declarations when dealing with pointers).
Note from the Author or Editor: Not a bad point. In general my pedagogical rule is not even to show the reader something s/he doesn't need to know and/or which could lead to a pitfall. One wonders, therefore, why I even revealed the existence of the multiple pointer declaration syntax. As far as I can tell it isn't used later in the book; if that's the case, this is needless information.
It would have been better if I had not boxed myself into a corner by writing this:
"I don’t generally use that second form when declaring a pointer, but it does come in handy when declaring several variables of the same type in a single statement."
This is misleading on two counts - I don't use the multiple pointer declaration syntax so there's no point showing it to the reader, as I've just said, plus I *do* write the asterisk next to the name rather than after the type, numerous times, throughout the book. Mostly this happens when the code is somehow inherited from Apple code that does it, like the declaration for AudioSessionSetProperty later in the same chapter. But I'm perfectly capable of doing it almost accidentally, as in this code from Chapter 10:
NSDateFormatter *df = [[NSDateFormatter alloc] init];
So it would have been better if I'd contented myself with saying that the two forms for declaring a pointer are interchangeable, and that I generally prefer the former, but I do occasionally use the latter, and Apple's own code uses it quite a lot, so that both forms appear, indifferently, throughout the book.
|
Peter Olsen |
Sep 23, 2011 |
|
| Printed |
Page 103
Figure 6.5 |
Most figures showing Xcode screenshots are much too small to read. Figure 6.5 on page 103 is just an example.
I would appreciate if (larger versions of) the figures were made available for download.
Note from the Author or Editor: Here are the original screenshots:
https://github.com/mattneub/Programming-iOS-4-Book-Examples/tree/master/screenshots
|
Klaus Werner Wirtz |
Aug 19, 2011 |
Aug 26, 2011 |
| PDF |
Page 783
second code snippet |
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.
|
 Matt Neuburg
|
Jul 25, 2011 |
Aug 26, 2011 |
| PDF |
Page 747
first code block |
Would have been nice to include memory management:
// ... do something with result
CFRelease(src);
[result release];
|
 Matt Neuburg
|
Jul 13, 2011 |
Aug 26, 2011 |
| PDF |
Page 744
first full code block |
In this line:
[people addObject: [self.child person]];
It would be good to cast self.child to a MyPersonParser, to quiet the compiler.
|
 Matt Neuburg
|
Jul 11, 2011 |
Aug 26, 2011 |
| PDF |
Page 711
first code |
Really should include dealloc implementation as well.
|
 Matt Neuburg
|
Jun 29, 2011 |
Aug 26, 2011 |
| PDF |
Page 681
warning |
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.
|
 Matt Neuburg
|
Jun 27, 2011 |
Aug 26, 2011 |
| PDF |
Page 663
last code block |
At start of last code block, need to say where the variable "item" comes from:
AVPlayerItem* item = p.currentItem;
|
 Matt Neuburg
|
Jun 25, 2011 |
Aug 26, 2011 |
| PDF |
Page 662
last code block |
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.
|
 Matt Neuburg
|
Jun 25, 2011 |
Aug 26, 2011 |
| PDF |
Page 648
first paragraph of Audio Player section |
Need to be clearer that use of AVAudioPlayer requires that you link to AVFoundation.framework and import <AVFoundation/AVFoundation.h>.
|
 Matt Neuburg
|
Jun 24, 2011 |
Aug 26, 2011 |
| PDF |
Page 650
bottom |
Need another bullet point specifying that the app must have a Playback audio session policy.
|
 Matt Neuburg
|
Jun 24, 2011 |
Aug 26, 2011 |
| PDF |
Page 638
1st and 3rd listVariable para |
Instead of "your app delegate will", I really should have put "your app delegate will then" - the point being that if the user taps Close, not the action button, your app won't be notified at all. This is implicitly clear but "then" would make it more explicit in this context.
|
 Matt Neuburg
|
Jun 23, 2011 |
Aug 26, 2011 |
| PDF |
Page 614
middle |
"if is smaller"; insert "it", or (better) delete "is"
|
 Matt Neuburg
|
Jun 22, 2011 |
Aug 26, 2011 |
| PDF |
Page 581
last code block |
Forgot final closing curly brace.
|
 Matt Neuburg
|
Jun 20, 2011 |
Aug 26, 2011 |
| PDF |
Page 576
1st paragraph of second section |
Be nice to suppress extra space after paragraph.
|
 Matt Neuburg
|
Jun 19, 2011 |
Aug 26, 2011 |
| PDF |
Page 101
first section |
Might have been nice to add a TIP about Hide All Issues to get rid of those annoying issue bubbles that appear in the Editor after compiling with issues.
|
 Matt Neuburg
|
Jun 17, 2011 |
Aug 26, 2011 |
| PDF |
Page 28
Next to last paragraph of first sectio |
Would have been nice to add mention of the #warning directive here. This is a good way to remind yourself of something that needs doing: if it is present, compiling will trigger the warning.
|
 Matt Neuburg
|
Jun 17, 2011 |
Aug 26, 2011 |
| PDF |
Page 512
code at bottom |
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.
|
 Matt Neuburg
|
Jun 12, 2011 |
Aug 26, 2011 |
| PDF |
Page 459
code at bottom |
As earlier in this chapter, I think instead of comparing against UIDeviceOrientationLandscapeRight and UIDeviceOrientationPortrait, it would be clearer to compare against UIInterfaceOrientationLandscapeRight and UIInterfaceOrientationPortrait.
|
 Matt Neuburg
|
Jun 08, 2011 |
Aug 26, 2011 |
| PDF |
Page 450
first code |
UIDeviceOrientationLandscapeRight should be UIInterfaceOrientationLandscapeRight; the device orientation and the interface orientation are the reverse of one another so it makes a difference.
|
 Matt Neuburg
|
Jun 08, 2011 |
Aug 26, 2011 |
| PDF |
Page 446
first code |
v.bounds should be self.view.bounds (twice)
|
 Matt Neuburg
|
Jun 08, 2011 |
Aug 26, 2011 |
| PDF |
Page 444
middle |
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.
|
 Matt Neuburg
|
Jun 08, 2011 |
Aug 26, 2011 |
| PDF |
Page 393
second code snippet |
Name of first parameter to actionForLayer: should be layer, not "lay" (so that it agrees with the variable name two lines later).
|
 Matt Neuburg
|
Jun 06, 2011 |
Aug 26, 2011 |
| Other Digital Version |
462
NSValue section |
The word "by," or the word "through," should be removed from the following sentence, depending on the author's intention; since these convenience methods are made available via a category, "through" seems most appropriate:
Convenience methods provided by through the NSValueUIGeometryExtensions category...
Note from the Author or Editor: Page 211 in the printed edition. I think I'd delete "by".
|
Scott Gardner |
Jun 01, 2011 |
Aug 26, 2011 |
| Other Digital Version |
439
Last paragraph |
The word "takes" should be removed from the sentence:
Cocoa itself takes does this.
Note from the Author or Editor: Page 201 in the printed edition.
|
Scott Gardner |
Jun 01, 2011 |
Aug 26, 2011 |
| Other Digital Version |
200
Last sentence |
Missing "to" after "have" in the following sentence:
This powerful flexibility is possible because Objective-C is such a dynamic language that a message to be sent to an object does not have be formed...
Note from the Author or Editor: Page 87 in the printed book.
|
Scott Gardner |
May 31, 2011 |
Aug 26, 2011 |
| Other Digital Version |
104
Mid-page |
Missing "the" after "one of" in the following sentence:
When a target explodes, one of things its explode instance method will do is send an increase message to the score object.
Note from the Author or Editor: Page 41 in the printed book.
|
Scott Gardner |
May 30, 2011 |
Aug 26, 2011 |
| PDF |
Page 364
2nd paragraph, below "setAnimationStartDate:, setAnimationDelay:" |
I think that the word "of" might be missing from the phrase "These are both ways postponing the start of the animation;", i.e. between "ways" and "postponing".
Note from the Author or Editor: Good catch! Should insert "of" as described.
|
kendalllister |
May 21, 2011 |
Aug 26, 2011 |
| PDF |
Page 504
Last sentence in the Last Paragraph |
in the line which says, "the runtime isn't going alter our setting afterward," did you mean to say, "going TO alter" ?
Note from the Author or Editor: Should be p. 515. Change "going alter" to "going to alter".
|
tambay |
May 20, 2011 |
Aug 26, 2011 |
| PDF |
Page 86
code examples |
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).
|
 Matt Neuburg
|
May 17, 2011 |
Aug 26, 2011 |
| PDF |
Page 121
Figure 7.2 (top of page) |
Many/most of the Figures in the PDF ebook are either teeny or blurry (beyond legibility).
A good example of this is Figure 7.2.
There are large bounding boxes on these graphics but the graphics themselves are too small to read, even if you zoom in.
Possibly to either:
- make the graphics larger in the PDF? or
- make the PDF graphics higher-res?
(btw, fantastic book so far)
Note from the Author or Editor: The figures on the Early Release edition were not the real figures; the figures in the actual book have all been redrawn or approved by the Illustration department at O'Reilly.
|
jchas |
May 05, 2011 |
Aug 26, 2011 |
| Other Digital Version |
160
2nd paragraph |
Chapter 6, The Navigator Pane, Symbols Navigator, paragraph 1, reads "two icons in the in the filter....".
Note from the Author or Editor: Should delete second "in the". Boy, are these hard to spot! This got past several proof-readings.
|
tgblank |
Apr 25, 2011 |
Aug 26, 2011 |
| Other Digital Version |
129
1st paragraph |
Chapter 5, Polymorphism, Paragraph 6, reads "typecasting doesn't convert magically convert anything...."
Note from the Author or Editor: Should delete first "convert".
|
tgblank |
Apr 25, 2011 |
Aug 26, 2011 |
| PDF |
Page 15
3rd code block in Example 1-1 |
The else if example has unbalanced braces. As this is meant to be a quick reference this should be fixed/clarified.
Note from the Author or Editor: Insert } (left curly brace, and space) before the words "else if")
|
John Charlesworth |
Apr 22, 2011 |
Aug 26, 2011 |
| Other Digital Version |
12.3
The Golden Rules of Memory Management |
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.
|
Nigel Perry |
Mar 16, 2011 |
May 15, 2011 |
| PDF |
Page 195
end of 2nd paragraph |
both 'copy' and 'mutableCopy' have "produces an immutable copy" in parentheses. Presumabley, mutableCopy produces a mutable copy
Note from the Author or Editor: FIXED in the actual book (published May 2011).
|
Anonymous |
Dec 16, 2010 |
May 15, 2011 |
|