First, the 3rd edition of the iOS Programming book is excellent. I am coming from a Flex/ActionScript 3 skill-set and your book was listed as “Hands down the best iOS book” in the “Objective-C for AS3 Programmers” session at the 360|Flex conference. Good job!
I am on Chapter 16 Core Data and I have a few suggestions for the 4th edition. Whereas previous chapters did a great job of anticipating my questions and answering them in context, this chapter seems rushed to get in all the code necessary to move Homepwner to CoreData in 23 pages. I know CoreData is a huge topic and there are books dedicated just to it, but I do think this chapter could be expanded to better explain what we are doing in a couple of sections.
Here are some examples:
My immediate question was about this inverse column I was asked to modify. What does it do exactly?
My question was what is the effect of checking versus unchecking this. Would I want to do this in my own apps? I left it unchecked and observed that it made the following changes:
[li]valueInDollars was type NSNumber instead of int32_t[/li]
[li]dateCreated was NSDate instead of NSTimeInterval[/li]
[li]orderingValue was NSNumber instead of double[/li][/ul]
Also, up until now all @property declarations were matched with @synthesize in the implementation file. However in this case we have @dynamic. I think it should be mentioned why.
[self setPrimitiveValue:tn forKey:@"thumbnail"];
My question was what is the reason for using setPrimitiveValue:forKey: instead of
Does it have something to do with thumbnail being a transient property?
Because the BNRAssetType is using NSManagedObject instead of a subclass, we have lots of code like this:
NSString *assetLabel = [assetType valueForKey:@"label"];
This is great to show how to use Key Value Coding, but I was wondering if the only reason I should subclass NSManagedObject would be to add methods. I saw in the Stanford video lecture on CoreData that another reason for subclassing is to avoid the “messy” valueForKey: approach using plain NSManagedObject and instead declare properties. I think it would be good to state that in your book too.