Some feedback on CoreData chapter


#1

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:

Page 322

My immediate question was about this inverse column I was asked to modify. What does it do exactly?

Page 323

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:

[ul]
[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.

Page 324

[self setPrimitiveValue:tn forKey:@"thumbnail"];

My question was what is the reason for using setPrimitiveValue:forKey: instead of

[self setThumbnail:tn];

Does it have something to do with thumbnail being a transient property?

Page 333
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.


#2

I too feel that the Core Data chapter requires a more detailed and leisurely presentation and better motivation of concepts alongside the code samples. Like you, the code raised questions for me that the text didn’t address right there (unlike previous chapters). I haven’t finished the chapter yet (hopefully I’ll do it today) so hopefully some of the things will clear themselves up further along, but judging by the high standards the book has set for itself so far, I think this chapter could use some rewriting. Hopefully the authors will work on it some more for the iOS6 edition. :slight_smile:


#3

Use the book so that you learn how to crawl first, not as a substitute for Apple’s documentation.

If the book tried to cater for the needs of all readers, it would qualify as a door stopper. :slight_smile:

Apple has good documentation on CoreData:

  • Core Data Programming Guide
  • Model Object Implementation Guide
  • Core Data Utility Tutorial

But, BNR has the final say on this. I am just one of BNR books’ fans and I understand the discomfort you are experiencing.


#4

[quote=“ibex10”]Use the book so that you learn how to crawl first, not as a substitute for Apple’s documentation.

If the book tried to cater for the needs of all readers, it would qualify as a door stopper. :slight_smile:

Apple has good documentation on CoreData:

  • Core Data Programming Guide
  • Model Object Implementation Guide
  • Core Data Utility Tutorial

But, BNR has the final say on this. I am just one of BNR books’ fans and I understand the discomfort you are experiencing.[/quote]

Thanks for the reply but…

I’m not really looking to the book as a replacement for Apple’s documentation. In fact, I’d rather avoid having to pore through Apple’s copious documentation as much as possible because there’s already enough to take in. Following the chapter’s code is not a problem per se, but I feel some of it could’ve been better motivated, and more thoroughly related to the big picture. I think after I finish this chapter and clear up any points I find doubtful or insufficiently motivated, I’ll mention them here.

I’m a fan of this book too, and I respect that it’s not possible to make everyone happy all the time, but nothing is perfect, and some (hopefully) constructive feedback won’t go wrong.


#5

I’m with you folks, this chapter was a LOT to chew on. I just finished it, but will have to go through it at least twice more to get a better handle on it.


#6

Can someone provide answers to some or all of jamiemcd’s original questions? After reading this chapter, I needed clarification on these same points.


#7

If assetType is a relationship from BNRItem to AssetType, and the inverse relationship, items, is from AssetType to (many) BNRItems, the following is true:

  1. Setting a BNRItem’s assetType automatically adds the BNRItem to that AssetType’s items.

  2. Adding a BNRItem to an AssetType items automatically sets the BNRItem’s assetType to that AssetType.

Using scalar properties allows you to use non-objects to represent certain types of values. Either is fine, I prefer scalar because I don’t want to convert from NSNumber to a primitive with -intValue or -floatValue all over the place.

The properties are dynamic because NSManagedObject takes care of the storage, so there aren’t really instance variables behind them, so to speak.

We could have probably used setThumbnail:

Yes, the valueForKey: stuff was for the lesson.