Historical errata for Core Data

Now that we have the Recipe NSArrayController built, the last two need
to be configured. The next one follows the same steps as our Recipe
entity but it is for the Type entity. The last one is for the Recipe Ingredient
entity and has one additional change. On the Bindings tab of the
inspector enable the Content Set in the Controller Content and point it
at the Recipes NSArrayController with a Controller Key of selection and a
Model Key Path of ingredients.

Most of this paragraph makes no sense. Please be explicit when giving instructions. The explanation for the first ArrayController was fine but these last 2 are very confusing.

This view is a NSTableView that is configured with one column,
no horizontal scrollbar, an automatically displaying vertical scroll bar
an the highlight set to Source List. All of those settings are configured in
the inspector for the NSTableView once it has been added to the window.

There are no settings for scrollbars in the attributes for NSTableView.

Now that the source list is built, we can “wire up” the buttons under
the NSTableView. Each of these buttons is using a built-in image and we
are going to bind them directly to the Recipe NSArrayController. The plus
button will be bound to the -add: action and the subtract button will be
bound to the -remove: action on the Recipe NSArrayController. With those
small changes we can now add and remove Recipe entities at will.

What buttons? We haven’t added any buttons.

Why does File’s Owner, rather than Application, link to AppDelegate? On the surface, it seems more intuitive to link to it from Application. Maybe a little explanation here could help some of us Cocoa newbies.

The horizontal scroll bar is actually a property of the NSScrollView, not the NSTableView

Building the Recipe Source List
The first part of this inter face that we are building is in the upper right
cor ner.

Should be upper left corner

“fraction of a section” should be “fraction of a second”

“as opposed some” should be “as opposed to some”

There are a few cases like this: “we are going to be adding the ability” which could be made stronger as “we are going to add the ability”

“we will be creating” could be “we will create” Etc.

“creating a NSOperation” should be “creating an NSOperation”

In the section Building the Spotlight Importer, “This tells XCode […]” should be “This tells Xcode […]”.

Section head “Why isn’t Core Data thread safe” is missing a question mark; should be “Why isn’t Core Data thread-safe?”

The term “thread safe” should be replaced with “thread-safe” everywhere.

The term “multi-threading” should be “multithreading” everywhere - the Apple Publications Style Guide (2008) rule for the prefix “multi-” is “no hyphen, except before the letter i.”

2nd sentence first paragraph “These details, specifiall”

supposed to be specifically?

2nd par 4th sentence “Dragged a NSImageView onto our window”

should be “Drag a NSImageView”

“The first part of this interface that we are building is in the upper right corner”. I am fairly new to this, but I am pretty sure the NSTableView is in the upper LEFT corner, referring to figure 2.7.

In my case, the filename under Models is “Name of my Project”_DataModel.xcdmodel. That is, my project name is prepended. Why the difference?

“While this similarity is not exact, it is a good point
to start. To add our first Entity to our data model,”
The blank data model must first be opened, otherwise the Design menu items are disabled. Don’t make newbie readers discover these things on their own, especially at the beginning of the book. Be more explicit.

In the paragraph about the delete rule… is the reader supposed to make a change to the setting? If so, which of the options (No Action, Nullify, Cascade, Deny) should the reader choose.

It may be a house style thing, in which case I apologise, but I find the boxed text, as in ‘Joe Asks’ on page 14 unpleasant and difficult to read. Increasing the line spacing would help. It looks too cluttered as it is.

Figure 2.1 looks in the wrong place. It’s floating there on page 9 with no reference to it. Then page 14 refers back to it. It would be better to either explain it on page 9 or move it to page 14. As it is it appears before the project has even been created.

type set to a optional String with a default value of “Meat”

Can we have a vegetarian option, please?

The NSMigrationManager has a NSDictionary calls userInfo that is perfectly suited for this purpose.

Should probably be…

The NSMigrationManager has an NSDictionary called userInfo that is perfectly suited for this purpose.

This makes almost no sense at all.
This entire chapter needs images that are more closely connected to text as well as MUCH more explicit detail. This reads more like a brain storm or a passing thought. I cannot begin to imagine this being any better than the Core Data docs themselves at this point.

This is not in beta. This is not even a rough draft.

With the Source List in place, it is time to add the details about the
Receipe. These details, specifiall the name, serves, description and type,
will tie to the now valid selection Controller Key on the Recipe NSArray-
Controller. That way when a user clicks in the list, the relevant details of
that Recipe will be selected.

What?
Let’s try diagramming the images. Let’s also try to put them on the same page as the content that refers to them.
Where are we adding the details?
There is way too much glossed over here.
Core Data is way cool, but I think it will be impossible to presume that this stuff can be followed without far more explicit detail. Describing Bindings in a book requires more detail and ideally screenshots. I cannot make heads or tails of what this is expecting me to do at this point.

Of course it is beneficial to download the code samples, but I shouldn’t have to download the samples to follow the lesson from the book.

At this point, this is an pre-Alpha book at best and needs a lot more work to be useable. The layout of the book is far less of an issue than the content at this point.
The writing is good, but the details are not there yet.

There is no mention that changing a default value won’t change the entity hash in the “Changes that do not alter the entity hash” section.

For more information on UTIs I would suggest reviewing .

The reference is missing. I am guessing it is a reference to an Apple developer document.

“…the base data objects (called NSManagedObject)
are more that sufficient for our needs.”

that should be “than”

When setting up the array controllers, the Prepares Content box needs to be checked to make sure the content is fetched when the app starts up (I think!).

The Adding the Subproject steps in the Quick Look generator refer to the Spotlight plugin instead of the QuickLookPlugin. Steps 3 and 4 look a bit to similar to steps 4 and 5 from the Spotlight plugin steps.

In this declaration:

- (void)addImageSheetDidEnd:(NSOpenPanel*)openPanel
returnCode:(int)returnCode
contextInfo:(NSManagedObject)recipe

The ‘int’ should be ‘NSInteger’, to be 64bit clean.

With regard to … “While we will go through all of these settings in greater detail later, for now set the default value to ”untitled“, make sure it is not optional and that its type is set to String.”

Since its a walk through it might be better to tell people to set the type to String fist, since you can’t set a default value while the type is undefined.

Sentence beginning “You’ll launching Xcode and proceed” is missing a word.

“type set to a optional String” should be “an optional String”

Figure 2.1 shows an attribute named “type” in RecipeIngredient, but the instructions on pp 12-13 don’t say anything about creating an attribute named “type”.

“There are a lot of features that we could add to this application but we wont.” should be “won’t”

“Upon opening the MainMenu.xib and depending on the whims of the
templates within Xcode, the AppDelegate may already be in the xib file.
If it is, great!”

In my project, the automatically created AppDelegate is named “Grokking_Recipes_AppDelegate”. Because the long name is truncated, “AppDelegate” doesn’t show up in the main IB window. You might want to encourage the reader to examine all the objects carefully before adding an AppDelegate. Hand-holding, yes, but at this early stage many readers will appreciate it.

“This view is a NSTableView” shouldn’t that be “an NSTableView”? It’s possible I pronounce it wrong, I don’t know any other Cocoa programmers to talk about this with.

“Dragged a NSImageView onto our window” Maybe point out that this is called “Image Well” in IB 3.1.

“Each of these buttons is using a built-in image and we
are going to bind them directly to the Recipe NSArrayController. The plus
button will be bound to the -add: action and the subtract button will be
bound to the -remove: action on the Recipe NSArrayController.”

Aren’t those “connected”, not “bound”?

The second sentence of the first paragraph of section 2.1 says “You’ll
launching Xcode and proceed…” but should read “You’ll
launch Xcode and proceed…”

First sentence of 2.4 reads “Core Data has a lot of similarities with database driven applications…”. This seems obvious and incorrect at the same time. Surely, a Core Data app is a data driven app, rather than having similarities with one? Also in the phrase “Core Data has” you’re saying that Core Data itself has similarities with data driven apps whereas, Core Data is a framework not an app.

The sample code for the migration fails to compile for me, “modelName” is used before it has been declared, and the code linked to on the page is illegible.

“Once the destination path is build” should be “Once the destination path is built”

in -addImage:, recipeArrayController is used, but there are no instructions for creating it (or imageView) and connecting it in Interface Builder.

“In the -addImageSheetDidEnd: returnCode: contextInfo: we have grabbed” should be “In -addImageSheetDidEnd: returnCode: contextInfo: we have grabbed”

“The menu item is now bound to our new action. ”

The menu item can’t be bound until the -addImage: method is declared in AppDelegate.h

First sentence, second paragraph:
Fortunately, Apple has made a huge advances in Sync Services in Leop-
ard. -> Fortunately, Apple has made huge advances in Sync Services in Leop-
ard.

“In this chapter we are going to walk through the construction of our project and how to build its data model.”

Better might be:

“In this chapter we will walk through the construction of our project and how to build its data model.”

I did a search on “are going to” and found 57 matches. They can probably all be replaced with “will” — for a savings of 114 words. :)

There is inconsistent capitalization — sometimes titles use capitals mostly, as in “Advanced Readers” and “Build the Data Model.” And sometimes there are lower-cased words, as in “Our application design” and “Putting it all together.”

“Other Interface Elements that utilize KVO, KVC and Core Data”

I suggest “use” instead of “utilize” — and it should probably be capitalized, as:

“Other Interface Elements that Use KVO, KVC and Core Data”

“We will build a basic application and in the chapters following, look back through it to understand what the pieces actually do.”

I think there are two missing commas: “We will build a basic application, and, in the chapters…”

“data objects that we want to be using” could be “data objects that we want to use”

“Core Data is going to be using” could be “Core Data will use”

“ERD (Entity Relationship Model)” — should be “ERM” instead?

“Xcode will be compiling it directly” could be “Xcode will compile it directly”

“select Design -> Data Model” could be “choose Design -> Data Model”

(The old rule is that you select text, graphics, etc. — but that you choose menu items. You select a noun/object, then choose a verb/command to run on it.)

“Just like an Entity has a lot of similarities to a Table” could be “Just as an Entity has a lot of similarities to a Table”

I think the “like” is a little too colloquial. But this could be a nit. :)

“Properties are further broken down into several subtypes, the two most relevant are Attributes and Relationships.”

Comma splice, I think. Could be “Properties are further broken down into several
subtypes; the two most relevant are Attributes and Relationships.”

“Apple recommends this inverse relationship recommendation for many reasons”

Maybe better just as “Apple recommends this inverse relationship for many reasons”

Example GrokkingRecipes_v1 appears to have some significant problems with Ingredients. These problems persist through v2 & v3.
Unable to add ingredient to a recipe.
- Drop down list appears but will not hold change in ingredient name column.
Unable to quit (and save) successfully when ingredients added. Seems to be a validation error but dialog cancel option results in quit anyway!

Figure 2.4 showing the first pass at the MOM for Grokking Recipes has “ingredients” as the first attribute in the Attributes section of the RecipeIngredient entity. On page 13 under Creating Our Second Entity, that attribute (“ingredients”) is not mentioned. Was it left out on page 13 or added by mistake in the diagram on page 16?

The diagram at the top does not correspond to the point #5 below it. Add a diagram to show the results of pt #5 here.

The last paragraph reads weirdly. Is NSOutlineView supposed to be mentioned twice? Once as a class and once a section header? Perhaps its stylistically correct to use the full Section #, Title, page # reference but it reads weirdly, imo.

paragraph 1: “..and they will [be] easier to grasp at that time”

If its not out of scope, can we have more discussion on what is File’s Owner? Or perhaps a reference to a 3rd party tutorial/url?

This whole chapter has been a long slog of reading, without much coding. Perhaps add the NSSearchField to our application to filter recipes?

More on NSSearchField suggestion.

Figure 3.7 could perhaps show an NSSearchField configured for Recipes, with a Predicate Format of “name contains $value”, instead of just displaying an untouched form.

Also, how do I make my predicate case insensitive? Can I use “and” and “or”?

para 3: “remove the Meat and Fish entries” - where in the preceding sections did we actually get to add Type instances? My “type” popup is empty and I’m not sure how to add Types yet.

I found these instructions for creating the Mapping Model missing information about what buttons/menu items to press.

I eventually figured out to create the second RecipeToRecipe (I called it FishMeatRecipeToRecipe) with the small + button at the bottom. And then I found the Design > Mapping Model > Add Missing Property Mappings menu item; then removed the “author” option again.

Also, I couldn’t set the new Recipe type to “Entrée”. It rejects it with “Unable to parse the format string ”Entrée == 1"

When I run the application I get a “Can’t merge models with two different entities named ‘Recipe’ (RuntimeError)” error in the debugger. I actually got this error before I created the Mapping Model too, and not the errors you mention in the book.

I am doing the exercises with MacRuby. My -persistentStoreCoordinator method looks like http-gist.github.com/42172 after I added the non-nil options variable. But I got the error above both before and after this change too.

Thoughts? I’ll post this on the forum too.

This might be obvious to more experienced cocoa developers but…

I had to fish around to see if I was going crazy or not but when you drag an NSTextView object onto the window by default it is rich-text as I was discovering while building the initial Grokking Recipe interface. So the binding “value” option is not there. You have to unselect the rich-text option to see it.

You may want to note that on page 21 under Adding The Recipe Details.

This section is a little unclear as to what to remove exactly and why…

“Second, we can remove the inverse of the relationship between the
Receipe entity and the RecipeIngredient entity. Because this relation-
ship is two sided (as strongly recommended by Apple), we do not need
to migrate both sides of the relationship. Therefore, we can remove the
RecipeIngredient side of the relationship. This will also remove a poten-
tial issue with the next change.”

“The two primary APIs that we will be looking into is” should be are

“and allow us” should be “and allows us”

“if the target object does not have an accessor nor an iVar” That should be either “if the target object has neither an accessor nor an iVar” or “if the target object does not have an accessor or an iVar”

“a NSArrayController” should be “an NSArrayController”. There are lots of these scattered throughout the current beta. You’re going to do a global search-and-replace on “a NS” before publication, right?

The -metadataFolder: method isn’t introduced in earlier pages

What is Spotlight/Info.plist for? Its not referenced on p74 in the surrounding text (except at the end where the reference is the subsequence sample of the file).

Do we type this info in somewhere? Are we starting a new file/new bundle?

‘The “UTExportedTypeDeclarations” section is probably very familiar’ -> to who? Cocoa developers who already would know Core Data anyway? If it is familar to the book’s readers, where would I have seen it before in this book?

I get the feeling that this information should be introduced and then discussed in more detail after the next subsection “Xcode Subproject”, if this Info.plist is to go into there.

Figure 7.3 shows references to PPImageView.m/h A search of the PDF of “PPImageView” doesn’t show any results. Perhaps these files are introduced in the unwritten chapters?

In the Source Code tarball, the Spotlight application cannot successfully create RecipeIngredients via its popup box. Then when the application is restarted there are data errors.

The pop up button does not function using the bindings that you show on this page and describe earlier in the PDF. The problem may be that the attribute Type.name does not appear to be populated anywhere in the code. Therefore the binding Type.arrangedObjects.name cannot provide content values to the list displayed by the button. I use Xcode ver. 3.1.1.

You should mention that for the Integer Fields serves and quantity a number formatter is needed. Without these the Program is not working. You mention this on page 36 NSNumberFormatter but that’s too late for “beginners” following the examples.

I don’t think there is a NSTreeView, I believe it should read NSTreeController in the sentence “While combining it with the NSTreeView does work and will display the data properly…”

in para 3 “In version 2, we we will” delete the second we

in “Lastly, we we will remove the Meat” remove the second we.

In “In version 3, we we will normalize” remove the second we.

In “In addition, we we will add the concept” remove the second we.

first regular paragraph: “make it easier to insure we pick” should read “ensure”

You should definitely make a search for “we we” and replace with “we” - another occurence: “Finally, we we will extract”

Closing para 9.6 should be stronger: NSManagedObjectID is the only documented/Apple-blessed way to uniquely distinguish NSManagedObject instances.

It would be nice to point out within this chapter that “import” isn’t limited to importing from another CD datastore. The techniques you use are equally useful for, say, bulk import from a delimited ASCII text file, or for a long-running process that captures data from external hardware sensors and stores it in the CD datastore.

3 lines from end: “This lets us”, not “let’s”.

para 3, sentence fragment. Suggest “…reader application, when the CocoaTouch application…”.

Having not worked with NSOperation/NSOperationQueue myself, I was puzzled by the choice of name for the -main method, and also by the switching between the “main context” and the “-main method” of the secondary thread. Perhaps expand the gray box on 114 to mention that method name? If I had been reading paper version offline it would have been quite frustrating; however, AppKiDo saved the day.

The import section could use a nod to memory management, for those who are doing data capture in a long-running app. The main thread’s autorelease pool won’t get drained if there’s no keyboard activity. An autorelease pool within the import loop is helpful, especially if you’re using single-thread mode and context locking. If the newly imported instances aren’t -released you can run out of process memory (don’t ask me how I know…).

Looks like idArray should be NSArray, not NSMutableArray? It’s referred to as NSArray in text.

Like Dr. Nic I first had trouble creating the “Meat and Fish” Mapping. (I first created a second MappingModel. After reading Dr. Nic’s errata I got it right but also got the “Can’t merge models with two different entities named ‘Recipe’ (RuntimeError)” Once I executed "BuildClean All Targets" the error disappeared maybe this should be mentioned.

The caption “Figure 6.5: Version 2 of the Managed Object Model (MOM)” Should read Version 3, because version 2 is on page 48.

paragraph 2: “A allows us to control” - should be “A NSEntityMigrationPolicy allows…”

paragraph “createDestinationInstancesForSourceInstance:”: “RecipeIngredient and it would expected that” should either be “would be expected” or “would expect”

paragraph “createDestinationInstancesForSourceInstance:”: “incoming [RecipeIngrdient] as a result.” -> RecipeIngredient

3rd paragraph: “The NSMigrationManager has an NSDictionary [calls] userInfo that” -> called

paragraph: How Data Migration Works: “Core Data handles data migration [is] a very straightforward manner.” -> in

paragraph 1: “checks all of the validation rules to [insure]” -> ensure

Paragraph 1: “Spotlight is here to stay and users [we] will be using it more often and in more creative ways.” -> delete the “we” or “users”

“pretend that there [we] will be thousands” -> a recurring problem that instead of will there is a we will -> check all occurences of “we will”

first Text para: “from the [NSSerachPathForDirectoiesInDomain( )] method and” -> SSerachPathForDirectoriesInDomain( )

Para Xcode Subproject: “Our Spotlight importer is actually [is] own application” -> it’s

Step 5 of Adding the NSArrayController Objects is somewhat confusing.
Maybe replace the word enable with under or open
(enable sounds like I am checking a box)
Replace point with bind
(or add a parenthetical comment to clearify that point = bind)

More of a question, Is there any difference to ctrl-shift-click and shift-right click?

For those new to IB, how does one connect the the add and remove buttons to the Recipe NSArrayController.

Repeated word “we” in sentence starting: Therefore, to make Spotlight happy. Third to last line on the page in the beta.

Adding an Attribute. (second paragraph from the bottom). The Add Attribute menu option is only enabled when the Recipe entity is selected.

Section - Adding the Recipe Details. Last word of the first sentence should be Recipe not Receipe.

As well as binding the AppDelegate to the array in IB, I think you also need to mention dragging from the AppDelegate to the imageWell to connect that outlet as well.

Maybe I’m being too picky, but your first @property declaration:

@property (retain) NSString *myString

Isn’t it better to use (copy) instead of (retain) for copyable objects?

In the Content Values bullet item:
You: “Content Values - An array of string that are displayed at…”

I think the ‘at’ should be an ‘as’

“If the accessor methods we will be implemented at runtime…”
should be:
“If the accessor methods will be implemented at runtime…”

“In this section we we will discuss…” delete the second we.

In the first paragraph of Section 3.3 the sentence “In this section we we will discuss each of those interface objects” has “we” twice.

Second-to-last paragraph “For example, by apply an NSNumberFormatter to the quantity column…” should read “by applying”

“…within CocoaTouch, we we will build…” Just one we, please.

‘handles the creation of the underling sqlite’ Should be underlying.

Code for -tableView numberOfRowsInSection: is shown twice, instead of also showing code for -tableView cellForRowAtIndexPath:

It seems the NSImageView IBOutlet is referenced (see: “Once the NSImageView is in place bind the imageViewIBOutlet of the AppDelegate to it”) before the IBOutlet is actually defined in the AppDelegate header file. Might confuse some. Maybe you should place this instruction somewhere after telling the reader to define it in the header file?

" To insure that we…“. Better to say ” To ensure that we…"

for (NSString *name = [desc attributeKeys]) is wrong. It should be for (NSString *name in [desc attributeKeys])

“We we will be learning through doing.” (para 2 of the Getting Started chapter) has too many “we”s.

It is misleading to say “bind” the imageView outlet of the app delegate in the last sentence, as that suggests using the Bindings tab. A more correct term would be “connect”.

In para 3, “Along side” should be “Alongside”.

In the first para of “Cocoa Bindings And Core Data”, “interface builder” should be capitalized “Interface Builder”.

The penultimate para refers to “… the Recipe Ingredient NSArrayController,” which was earlier named “Recipe Ingredients” (ie plural).

For consistency the “Type” array controller should be plural (Types) too.

There’s a space missing in “state.It expects” in the first para.

The NSSearchField works with the principle not principal of an NSPredicate, in the first line on the page. That phrase sounds a bit clunky anyway - perhaps it just works using an NSPredicate?

In section 5.2 para 1 “must be used with delicate hand” should be “must be used with a delicate hand”.

The last full sentence of the page gives instructions to drag to the AppDelegate to connect the add: and remove: actions. Instead, one needs to drag to the Recipe array controller.

Shouldn’t “for each record in the first table there can only be no more than one entity in the second table” be changed to “for each record in the first table there can only be no more than one record in the second table”?

In the bulleted list for “Adding An Attribute Property”, the ‘serves’ attribute does not say optional or non-optional like all other attribute descriptions do.

Instead of (void)addImage you want to have (IBAction)addImage, just like you do in the blue code section below.

You don’t want to end that first line of code with a semicolon.

I find the sudden usage of “iVar” a little strange, because it’s used all of a sudden without any introduction to what it is. Why does it start with an ‘i’?

You seem to be forgetting to mention that an NSNumberFormatter should be attached to the “serves” text field.

in line 1:
thank Tom Harrington for turn me onto Core Data in the first place
should perhaps be:
… turnING me onto Core Data…

“These buttons can be bound to their actions by holding down the control key and clicking on the button and dragging to the AppDelegate.” should be Recipe NSArrayController

- (IBAction)addImage:(id)sender; <— no semi-colon
{
/…/
}

The formatting of the aphorisms adorning each chapter (eg “The journey of a thousand miles begins with one step. Lao Tzu”) needs to be changed so it doesn’t look like part of the body text in the epub edition.

The code snippets are truncated on the right hand side in the epub edition. Rotating the iPhone will show slightly more of the code, but never enough :-)

The text says..:

Building The Recipe Source List

The first part of this interface that we are building is in the upper left
corner. This view is an NSTableView that….

But the NSTableView is not in the upper left, but the lower left corner, according to Fig. 2.8

In section 3.2 you say that the context parameter is used to pass a object reference. In the WWDC 2008 session 392, Cocoa Tips and Tricks, they say that the context is not optional and should be used to distinguish your observations from others. The details start at 10:00.

“we can insure that” should be “we can ensure that”
The insure/ensure thing seems to be a common typo in this book, might be worth searching all occurrences of “insure”.

Code block doesn’t actually do anything with the index variable, it just increments it each time without using it in the string.

“quite a bit of code involved in the export.”
should be
“quite a bit of code involved in the import.”

mentioning OmniGroup’s franework
Shoul be “mentioning OmniGroup’s framework”

There is no explanation of where the Type entity gets the data that it is populated with, e.g Meat, Fish, desert, etc…

At the bottom of the page, you say to bind the imageViewIBOutlet to the Image well. You don’t add code to the AppDelegate class till the next page, so this might be confusing.

At the top of this page, you mention wiring up the IBOutlet of recipeController. This would also be a good place to mention wiring up the imageView IBOutlet to the image well.

The model diagram for version 2 seems to be missing the imagePath attribute in the Recipe entity

The word ‘extend’ at the end of the second paragraph on page 50 should be ‘extent’.

The line: NSMutableSet *ingredients = [recipe mutableSetForKey:@“ingredients”];

should read:

NSMutableSet *ingredients = [recipe mutableSetValueForKey:@“ingredients”];

There is semi-colon at the end of the persistentStoreCoordinator getter method:

- (NSPersistentStoreCoordinator*)persistentStoreCoordinator;

Following the close of the sentence, “…in a fairly orga-
nized state.” there is a lack of proper spacing before the beginning of the next sentence. For an actual copy and paste: “…in a fairly orga-
nized state.It expects each parent (or branch) to have…”

Fantastic book!!!

You stated in the book, “Just as an Entity has a lot of similarities to a Table, a Property has quite a few similarities to a column in that table. This similarity breaks down very quickly when we start adding relationships, but to begin with it is sufficient.”

I am someone who is fairly new to CoreData and many its associated and supporting concepts, but who is also very familiar with database concepts and design. One HUGE obstacle I am facing while trying to learn CoreData is understanding how to properly model my objects (specifically their relationships). It is hard for me to know how to properly model a relationship that I could otherwise easily do with a few db tables and a handful of primary-foreign key relationships.

To be completely honest I haven’t quite figured that issue out yet and it remains a problem for me.

Even if you do not include a section in you book that should bridge the gap between DB design concepts and object mapping, it would be awesome if you could point me to some other resources! (Unfortunately, I’m having difficult finding the the answers online)

A sentence in section 5.2 is missing an a: “Also, Entity Inheritance, a power ful
feature of Core Data, must be used with delicate hand as the underlying
structure may be surprising.”

should say: “Also, Entity Inheritance, a power ful
feature of Core Data, must be used with a delicate hand as the underlying
structure may be surprising.”

I found the placement of Figure 2.5 to be confusing…I assumed (incorrectly) that it went with the previous pages instructions. Perhaps placing it after it is referenced in the text would save others from this mistake.

The sentence “There are a number of things that we can within the User Interface to help performance as well.” is missing do after we.

“There are a number of things that we can do within the User Interface to help performance as well.”

Section 1.1, second paragraph: “That is where Core Data comes it.” “it” -> “in”

The second paragraph adds a step to the Bindings that we create, but it does not give a reason for this deviation. Either an explanation of reasoning or a note that the reason will be made clear later would be very helpful to the reader. (Novice reader thinks: “Wait, why did we do it that way this time and not before? This is what’s so frustrating!”)

The last sentence on the page instructs the reader to bind to an imageViewIBOutlet that does not yet exist. Also, the text uses the word ‘bind’, which implies that this will be a Cocoa Binding, when instead, it will be a Connection, so ‘connect’ would be the better word here.

Actually, we can’t start inputting recipes yet. The Types popup menu is connected to an empty dataset, so attempting to set the recipe type will throw an exception.

warning: ‘RecipeGrokker_AppDelegate’ may not respond to ‘-applicationSupportFolder’. In some cases, it is okay to use code that generates warnings, but when we do, it is advisable to justify the decision or explain how to properly handle the warning.

In the third paragraph it currently says: “The two primary APIs that are looking into are Key Value Cod-
ing and Key Value Observing.” which doesn’t make sense. Should that actually read: “The two primary APIs that we are looking into are Key Value Cod-
ing and Key Value Observing.” or something along those lines?

In the -setValue:forKey: section it reads “Normally, we would change the name attribute on an Recipe object by calling the setter method.” It should read “Normally, we would change the name attribute on a Recipe object by calling the setter method.”

Second paragraph says: “Once we have confirm the existence”. It should read: “Once we have confirmed the existence”

“This is the first time we have added a model version, Xcode is going
to create a new bundle for us called DataModel.xcdatamodeld and put
the original MOM inside of along with a new copy of the original MOM.”

“… inside of along with …” - awkward. :-)

First paragraph on the page..

“Fortunately, Core Dat handles all of the keys…”

Should be Core Data, of course..

There is no mention of one of the single most important scenarios: What happens when a user opens a version 2 document with version 1? Even assuming you don’t want to allow a “reverse migration”, how do you intercept this and inform the user?

“These are classes that were added to Objective-C/Cocoa …”

No, they are classes that were added to Cocoa. Objective-C is the language. Cocoa is the API to which the new classes were added.

I’m not sure whether my suggestion would be too basic for the intended audience of this book. But I for one would have appreciated a full example in chapter “4.1 NSManagedObject” that shows how to fetch the managedObjectContext and how to create a new NSManagedObject and set its properties. The code examples in the book always only display three dots (“…”), and real code examples for this are only given later (and only in different contexts). Being a beginner with Cocoa & Core Data I had a hard time figuring this out.

In other words, it would be great if chapter 4 would include some more detailed code examples along these lines:

To create a new Recipe object and set its properties:


NSManagedObjectContext *context = [self managedObjectContext];
NSManagedObject *newRecipe = [NSEntityDescription insertNewObjectForEntityForName:@“Recipe” inManagedObjectContext:context];

[newRecipe setValue:“My Recipe Name” forKey:@“name”];


Or, to add a new ingredient object to a recipe’s ingredients (to-many) relationship:


NSManagedObject *recipe = …;

NSMutableSet *ingredients = [recipe mutableSetValueForKey:@“ingredients”];
[ingredients addObject:newIngredient];


Thanks, Matthias

I may be confused, but is this correct?
NSManagedObject *ingredient = …;
NSManagedObject *recipe = …;
[ingredient setValue:recipe forKey:@“ingredient”];

Shouldn’t the forKey value actually be @“recipe”?

The part of this sentence: “…in this final chapter I share one of my lazily secrets that I used in…”. Seems like some editing was done around “lazily secrets” and needs to be cleaned up more.

In the section titled “Deleting”: Forward reference to Chapter 6 for “reviewing our data model”. If we haven’t seen it yet, it’s not a review. Did something get reordered?

addImage:(id)sender; should read(IBAction)addImage:(id)sender
without the semi-colon. This is the implementation, so there should be nothing but whitespace between “sender” and the “{”

This is the last line on the page, with the opening “{” on the following page

Text refers to the “Recipe” NSArrayController, however it is called “Recipes” in Figure 2.6 “The Main Menu xib”

Reference to dotMac should be changed to MobleMe.

“For example, if we were merging recipe data from two computers
via dotMac and we were looking at the Author entities, we would com-
pare the name attribute of each Author.”

Figure 9.1 is referenced on page 159 to be showing linking up Export Recipes, instead it shows linking up Import Recipes.

The flow diagram of the copy should be moved to after the copy method. It’s confusing to see it here a few pages before the copying is even discussed.

Final para: Apple seems to write “ivar” instead of “iVar”. I’d also suggest moving the 2nd footnote into the main text.

setMyString: will leave “myString” locked if you send the message twice with the same argument. (ie if [string isEqualToString:myString] is true.)

First line: “work surprising well” should be “work surprisingly well”. Or perhaps “surprisingly, work well” ;-)

Running the app before turning on automatic data migration does not produce the error shown in Figure 6.2 “Error when we have changed model”. Instead, you get an exception and the following’s logged:

2009-04-19 16:27:43.058 Grokking Recipes[2369:10b] An uncaught exception was raised
2009-04-19 16:27:43.062 Grokking Recipes[2369:10b] Can’t merge models with two different entities named ‘Recipe’
2009-04-19 16:27:43.064 Grokking Recipes[2369:10b] * Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘Can’t merge models with two different entities named ’Recipe’’

Instead of saying “require writing a custom NSEntityMigrationPolicy”, it might be more helpful to say “require writing a custom NSEntityMigrationPolicy subclass”.

A screenshot (and more detailed description) of the v2 to v3 mapping model would be helpful, as it is rather more complicated than the earlier one.

Last sentence of the second paragraph ends with, “it does not seek to duplicate functionality that already exists in other parts of overall API but instead uses it to its full extend.”

That last word should be “extent.”

The screenshot caption reads, “Figure 6.2: Error when we have changed model”

Perhaps it should read “…changed the model”.

What is NSPredicateWithFormat? Should probably be NSPredicate predicateWithFormat

[NSEntityDescription entityWithName:inManagedObjectContext:] should possibly be [NSEntityDescription insertNewObjectForEntityForName: inManagedObjectContext:]

4.4 NSManagedObjectModel

The NSManagedObjectModel can be considered a compiled, binary, version of the data model that we created in XCode.

Should be “Xcode”.

“Fortunately, Core Dat handles all of the keys and integrity for us…”

Core Data is missing it’s a at the end :)

“uses it to its full extend” at the end of the second paragraph should be “extent.”

The user needs to deselect the header in the NSTableView as well.

On the third NSArrayController section I would follow the exact same convention and specify using the name “RecipeIngredient” rather than referring to it as Recipe Ingredients with no quotes, a space and plural. I just make this recommendation for someone new who is following each step and might be easily confused.

Shouldn’t the instructions for the popup bindings say bind to the name “Type” instead of the generic NSArrayController if we previously named our controller? This could confuse a new person following along when they don’t see the generic name in the binding pulldown.

Same as my previous submitted remark on this page. The binding instructions for the type popup selected value needs not to be the generic array controller name. But the recipies controller.

In the 4th sentence of the first paragraph in section 4.6, it should read “When the property is accessed…”.

And in the second paragraph of section 4.6, the last sentence should read “Usually when a situation would call for a Fetched Property it tends to be easier…”.

" to use when taking about us" should be " to use when talking about us"

Regarding your design that uses metadata files for integration with Spotlight and Quick Look, it seems there might be some user confusion regarding these files. Users could easily conclude that these files actually contain all of the data for the recipes. This could lead users to do things like send them to friends as email attachments, delete them, rename them, etc. with various unexpected results and confusion. You might want to mention these potential drawbacks in the book. It would be great if Apple provided a more direct method to integrate Spotlight and Core Data.

[NSAutoreleasePool drain] is the same as [NSAutoreleasePool release] in a reference counted environment. In other words, [pool drain] releases (and thus destroys and pops) the NSAutoreleasePool. Using [pool drain] within a loop like this will not work as you’re expecting.

Line 4 on the page says “Fortunately, Core Dat handles”

Should be Core Data I guess?

For the first NSArrayController, we are told “Click on the name of the NSArrayController and when it is editable rename it to Recipes.” (note the plural) which is also reflected in Figures 2.5 and 2.6. However, from page 27 on, this controller is referred to as “Recipe” (singular).

Where in the first paragraph it says, “For instance, it is not a very good experience to be displaying currency…”, I would suggest to add the word “user” for clarity, as “not a very good user experience”.

In Chapter 6, …..
In this chapter will explore how to handle
‘we’ is missing

NSEntityDescription entityWithName:@“Recipe”
inManagedObjectContext:moc

I cannot find a class method entityWithName:inManagedObjectContext:
This should be
NSEntityDescription entityForName:@“Recipe”
inManagedObjectContext:moc

In the supplied code the mapping name for ‘Fish & Meat’ -Relationship Mapping ingredients is set to RecipeIngredientToRecipeIngredient and that mapping name doesn’t exist.

‘That way our importer only has to touch the metadata files and does not need to initialize the entire Core Data “stack” (NSManagedObjectContext, NSPersistentStoreCoordinator and the NSManagedObjetModel).’ <-NSManagedObjectModel

You might consider pointing out the ‘+’ buttons for adding entities and properties. These also alleviate the need to double click the Name as it is preselected.

It would be helpful to be more explicit in the creation of the buttons. I used Round Rect Buttons, resized to be circles (you may want to specify the dimensions), with NSAddTemplate and NSRemoveTemplate Images respectively. You refer to a built-in image, but the user has to do some work to figure out what to do specifically.

At least for Xcode V3.1, Figure 2.10 is not consistent with the instructions on p.33 in the first paragraph of “Binding The Action”. It appears as though you replaced the “Save As…” menu item with “Add Recipe Image” rather than adding a new menu item.

“Normally, we would change the name attribute on an Recipe object…” should read “Normally, we would change the name attribute on a Recipe object..” (“an” should be “a”).

You write that if the AppDelegate is already in the xib file then you can move on to the next section. But in the instructions for adding the AppDelegate to the xib file you write that the delegate outlet from the Application object needs to be connected to the AppDelegate object.

In my Xcode the object Recipe_AppDelegate was already created, but it did not have a connection set between the Application delegate and the Recipe_AppDelegate. Instead the Recipe_AppDelegate has referencing outlets for the Delegate set to (1) file’s owner and (2) window. Does it also need a connection set with the Application? Or does the File’s Owner connection take care of it? (I think it probably does.)

In home page description of book, “principals” should be “principles”.

“Fault” is first mentioned on this page with a cross-reference to page 98. Faults are not discussed on page 98. Page 106 would be a better cross-reference.

The sentence “This allows the binary data to remain a fault until it is actually needed” uses the term “fault” before it has been defined and explained on page 106. Consequently, the sentence is inscrutable to me as I read the book cover to cover.

Section 6.4 opens “Firing faults individually is one of the most common…” The phrase “firing faults” makes no sense based on the explanation of a fault as an NSManagedObject that has not loaded its properties from the data store.

Since this was the third instance where the term “fault” or one of its derivatives was used in a new and baffling way without proper introduction, I cracked open Apple’s Core Data Programming Guide for clarity and was relieved to learn that “Core Data faults are analogous to virtual memory page faults—they are simply scoped to objects instead of memory pages” (page 99 of PDF version 2009-03-04). That analogy explains all of the terminology, including the verbs “faulting” and “faulted” and what it means for a fault to fire. I wish I could have learned that without scanning Apple’s source material.

“This book has been completely revised in response to tech review the
iPhone”

Looks like two sentences have been run together without punctuation in the description of Beta 6.

In the first sentence of the first paragraph of section 2.6, “from” has been written “form.”

First para:
“You know form your experience developing Cocoa apps”
Should be ‘from’

“As discussed, a NSFetchedResultsController takes a NSFetchResult as part
of its initialization. This NSFetchResult is used to deter mine what enti-
ties are to be included in the NSFetchedResultsController.”

Both occurences of ‘NSFetchResult’ should read ‘NSFetchRequest’.

In the litany of what the forthcoming chapters will cover, Chapter 6 is listed before Chapter 5.

The last sentence “Plus, if Core Data ever becomes avail-
able on iPhone, we will have a huge leg up over those who skipped this
technology. ” is now out of date. (especially with chapter 10 previously described :-)

“user with an usual issue” should be “user with an unusual issue”

Section: Adding the Last Entity

desert should be dessert

On the previous page, page 186, you state ‘To demonstrate using Core Data on the iPhone, we will be using the “Navigation-based Application” template with the “Use Core Data for storage” box checked as shown in Figure 10.1’.

Figure 10.1 doesn’t actually show the box checked, so either the image or the text is wrong here.

(This is using XCode 3.1.3, as shipping with iPhone 3.0 SDK.)

For the rest of the chapter you then go on to create a whole bunch of code to load the Core Data stack, etc.

However, if you’ve used the template with the Core Data checkbox ticked most (all?) of this is already there in the templates, with enough subtle differences to make it very confusing as to what you should be adding or editing to actually create the final project.

If you are using a pre-supplied template file, your own code should certainly use it as a basis for any extensions that you need to make, otherwise only the most proficient developer will be able to self-edit the code examples to create a binary that compiles.

If you aren’t using the existing template, you need to be a lot clearer that while the option is there, you aren’t using it in your demo, so you can add only that code that you actually need.

While we don’t have access
to Core Data on iPhone, yet, that doesn’t stop us from taking advantage
of it to some degree to make our iPhone development lives a little easier.

Since 3.0 has been released and you have rewritten the chapter on the iPhone and Core Date, this sentence needs to be changed as well as the last sentence on the page as noted in a previous errata report.

Fourth paragraph - ‘the’ is repeated twice in the following sentence:
“The one shown in the previous example accepts a SQL like NSString and can accept any number of parameters after the the NSString.”

I think in the sentence above, you should perhaps hyphenate ‘SQL’ and ‘like,’ so that it makes more sense to read them together; e.g. “…example accepts a SQL-like NSString and…”

This is also the case in the sentence above: “One of the most common ways to use an NSPredicate is to construct a SQL like query such as the following example:”

“rewrite” should not be hyphenated.

“The client can choose not to participate in the sync at that time but generally it is a good idea to be apart of the sync.”

The sentence is missing a couple of commas, and ‘apart’ should be ‘a part’.

The client can choose not to participate in the sync at that time, but generally, it is a good idea to be a part of the sync.

The combo box of Types has 5 entries, but the screen shot only shows 4, and the text doesn’t seem to mention what all the types are. I know I can just put something there, but I’d feel I’d be missing some cool or clever.

It’d be nice if we could copy and paste code out of the book. Right now, copied code from Preview in 10.6 (10A421), like -addImage:, enters Xcode somewhat mangled (the close brace on the wrong line, strange whitespace characters that cause compiler errors)

The second phrase of 1st paragraph says:
For each recipe that we find we request its metadatan NSDictionary …
Should’nt it say “metadata”?

In the last paragraph, NSManagedObjectContextNSManagedObjectContextDidSaveNotification should be NSManagedObjectContextDidSaveNotification

The last paragraph should refer to the “attributes” of the object rather than the “properties”. This appears in 3 of the sentences.

NSFetchResult is referenced twice — seems like a typo for NSFetchRequest.

In the box “What Is One-To-Many?” one sentence reads:
—- A one-to-one relationship means that for each record
in the first table there can be no more than one entity in the second table. —-

Maybe better to use “…no more than one record…”?

The search will not work if you follow the instructions (and the screenshot).
In fig.3.7 the Model Key Path should be empty and the Predicate Format should be “name contains[c] $value” (At least that’s how I got it to work)

2nd paragraph, 4th line, “with an usual issue” s.b. “with an unusual issue.”

Xcode tosses a warning:…/GrokkingRecipes_AppDelegate.m:261:0/GrokkingRecipes_AppDelegate.m:261: warning: ‘copyPath:toPath:handler:’ is deprecated (declared at /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSFileManager.h:172)

Figure 5.5 is referenced as the resulting entity mapping, but it includes the Fish & Meat mapping, which isn’t added for a couple of more paragraphs. I figured I had forgotten a step since I didn’t have it in my mapping model.

I’m having a hard time following the “Fish & Meat” migration instructions. “create a new mapping that is almost identical to the RecipeToRecipe mapping.” - Duplicate is disabled. Do I make copies of each of the property mappings? It’s also not clear how to change the Type attribute - on the attributes I looked at, it’s not editable.

This page has the only mention of the user info keys. It’d be nice to have a blurb about what they are / what they’d be useful for.

Figure 5.7’s Recipe entity is missing the ‘imagePath’ attribute. The text doesn’t mention deleting it.

Section 2.6 reads “You know form your experience”, it should read “You know from your experience”

In the “effective code” at the bottom of the page the methods, myString and setMyString both have a spurious semicolon before the curly brace in the implementation. Also in the formatting of synchronized(self), the ‘d’ in synchronized is not formatted like the rest of the word.

In the second paragraph of the “Adding a Relationship Property” section, the sentence word “it” should be the possessive “its” in the sentence “For this relationship, we will start off by naming it ingredients…”.

This is purely a subjective opinion, but when describing the settings for an attribute, I find it to be less of a cognitive exercise deciphering between terms “optional” and “required”, rather than “optional” and the negated “non-optional”. Or, perhaps, even better would be to use the phrase “uncheck the optional checkbox” rather than “set the attribute to non-optional”.

In the first sentence of the second paragraph of the “Adding The Recipe Detail” section, you state the the first THREE are text fields and the FOURTH is a combo box, but it should be the first TWO are text fields and the THIRD is a combo box.

For the Description field, you specify that the user should use a Wrapping Text Field, but the attributes you go on to specify (as well as the picture of the interface) seem to suggest an NSTextView inside of an NSScrollView instead.

You specify that the Entity attribute of the “Recipe Ingredients” NSArrayController should be set to “RecipeIngredients” (plural) when in fact the name of our Entity is “RecipeIngredient” (not plural).

Under 2.4, “Creating Our XCode Project”, “template and insure that the “Use Core Data for storage” checkbox“, ”insure" should be “ensure”.

3rd paragraph:
“…like the NSOutlineView discussed… on page 48”

Seemed to imply to me that it had been discussed already. Would be clearer to say “to be discussed”

Small point, not a big deal. Great book, very helpful. Thanks for the early access.

“You know form your experience developing Cocoa apps ”

[[NSFileManager defaultManager] copyPath:path toPath:destPath handler:nil];

warning: ‘copyPath:toPath:handler:’ is deprecated.

I think the code should be:

\tNSError *error;
\t[[NSFileManager defaultManager] copyItemAtPath:path toPath:destPath error:&error];
\t[recipe setValue:destPath forKey:@“imagePath”];

In method addImageSheetDidEnd:… the call to [self applicationSupportFolder] should be [self applicationSupportDirectory] for Xcode 3.2 template code.

The last line of the method allRecipesSortedByName which is “return [result sortedArrayUsingDescriptors:sorters]” appears to be superfluous. The result array has already been sorted by the sort descriptors during the fetch process.

The listing for -managedObjectContext should be accompanied by an explanation of how to add the RecipeTypes array and its values to the info.plist, so that -managedObjectContext can load them into a brand new data store.

The first line of the fragment of method -persistentStoreCoordinator (v2) on page 77 shows:

if (![persistentStoreCoordinator addPersistentStoreWithType: … options:dict …

The previous (v1) version of the method on page 72 uses nil and no dict var has been set up in the book text or listings:

if (![persistentStoreCoordinator addPersistentStoreWithType: … options:nil …

About errata #40726. I found the “missing” code on page 80. My suggestion would be to rearrange this section a bit to make it clearer.

The second code sample on p108
NSArray *relationshipKeys = [NSArray arrayWithObject:"addresses", “addresses.postalCode”, nil];
should use +arrayWithObjects: (plural)

This is just a suggestion to change the screenshots throughout the book to use PNG images rather than JPGs. The screenshots in the PDF have a lot of artifacting. Figure 6.4 on page 112 is an example.

The Xcode project “Spotlight” for the Spotlight chapter doesn’t build with Xcode 3.2 on 10.6. Errors:
* /…/Spotlight/v1_to_v2.xcmappingmodel:0:0 Attribute Mapping “RecipeIngredientToRecipeIngredient”.name — destination entity doesn’t have property named name
* /…/Spotlight/v1_to_v2.xcmappingmodel:0:0 Attribute Mapping “RecipeIngredientToRecipeIngredient”.unitOfMeasure — destination entity doesn’t have property named unitOfMeasure
* /…/Spotlight/AppDelegate.m:260:0 error: ‘object’ undeclared (first use in this function)

The Xcode project “SyncServices” for the Sync Services chapter doesn’t build with Xcode 3.2 on 10.6. Errors:
* /…/SyncServices/v1_to_v2.xcmappingmodel:0:0 Attribute Mapping “RecipeIngredientToRecipeIngredient”.name — destination entity doesn’t have property named name
* /…/SyncServices/v1_to_v2.xcmappingmodel:0:0 Attribute Mapping “RecipeIngredientToRecipeIngredient”.unitOfMeasure — destination entity doesn’t have property named unitOfMeasure

I was wondering if you could elaborate on this further?

“We pass along a context so that we can ensure we are only acting on observations meant for us and not accidently(sp) intercepted.”

The text isn’t clear what the @“PragProgObserver” context is or how it works.

On this page you mention the “arrangedObjects” Controller Key towards the bottom of the page. Maybe it would be helpful if you clarified what a Controller Key is, and what arrangedObjects does? I’m a little confused by it.

I can’t seem to get the image well to display the picture. The “NSError *error; [[NSFileManager…” code looks correct to me also (10.6.1 Snow Leopard - Xcode 3.2). Image files get dumped into my ~/Library/Application Support/Grokking_Recipes directory, so the code works, but the Image Well just doesn’t want to show the image. The “Image View Bindings” are set as: Recipes.selection.imagePath

Transient Properties: - I see that Transient Properties are described. Being new to CoreDate, I really don’t know how to put transient properties to use? I was thinking it would be used to store a summary (sum or average) of values stored in a detail/child relationship entities. It appears that I have to set the transient value, but I don’t understand how and when to calculate and set the value. I’m sure it has to do with faults… but I would like to see the use of the property described better. I also understand it may be better to use a fetched property, but would like to understand transient properties better so as I can make a more informed design decision.

“a small double bracket icon”. It’s actually a dollar sign ($). Still, you made me laugh.

“If we try to run our application after this change we get something new as seen in Figure 5.4.” That’s not the case for me. No gui is presented to me but the log contains a ‘similar’ error: “Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘Can’t merge models with two different entities named ’Recipe’’”

Mac OSX 10.6.1 XCode 3.2

in V1 to V2 migration, shouldn’t we also:
1. Change the plist file so that new files are version 2 files (change the list of types)
2. Migrate Type itself to filter out Fish and Meat.

In regards to Issue 40802. I got the same error even after setting everything up. Nothing was missing from the code/configuration. When I did a Clean All and then a Build. Everything worked as expected - the file was migrated to v2 without issue.

If this is a common occurence, maybe you should mention it.

I’ve been working through the book as needed trying to use CoreDate to support a simple navigation app. The navigation simply traverses down a cascade of one to many relationship properties. The frustrating part is once I get a set of related managed objects (think ingredients for a recipe), I don’t know how to turn that set into a sorted array which I can used to populate my UITableView.

This seems like it would be an extremely common design. Anytime a UITableView is populated, it is just good practice to have the data appear in the same order. I thing is would be good to describe how to turn the set returned by a relationship into a sorted array.

Section 5.5 is basically a repeat of part of 5.1 except for the first two paragraphs, which should probably be moved to 5.1.

You should have told us to save earlier versions of the program or its datastore before doing the migrations.

Section 5.4 implies that we should create two methods, presumably in a class derived from NSEntityMigrationPolicy. But we are never told how to use these methods or these classes. Nor are we told that they will be discussed later in the chapter. And scanning the chapter it doesn’t look like we use them or actually finish the migration from v2 to v3.

Currently there is insufficient information on how to set up a v2 to v3 migration.

At the end of this chapter, given your instructions, the application no longer works. Even if I delete the storedata file I am unable to create new recipes with new ingredients.

This chapter is abysmal.

“The incompatibility between Spotlight and Core Data is going to be corrected in Snow Leopard”
Now that Snow Leopard is out - please explain how this is fixed.

Second paragraph reads “Fortunately it does not take very much code to build up the Core Data stack in existing project.”

Suggest changing to “Fortunately it does not take much code to build up the Core Data stack in an existing project.” or “Fortunately it does not take much code to build up the Core Data stack in our existing project.”

This is a little confusing to me:

“NSFetchRequest is the part of Core Data that causes people to think it is a database API instead of an object hierarchy.”

Is it saying Core Data is like a database with an API, or does it say NSFetchRequest is usually confused as an API to a database, rather than a “searcher” (my crappy word ;) ) for an Object Hierarchy?

The snippet for -(NSManagedObjectContext*)managedObjectContext looks rather different in Core Data apps created using Xcode 3.2 (Snow Leopard). I think Apple just updated their boilerplate code here when going to a newer version of Xcode/OS X.

Ah, I see what you did with the code now. You took the “-(NSManagedObjectContext*)managedObjectContext” method and added in some initialization code. There are still some minor differences in the Xcode 3.2 boilerplate code, but not much. For your custom code, perhaps put in a “Begin book code” and “End book code” comment to block-off your initialization code? I think that’ll make it a little easier to read. :)

I got an error in the code here which dumps to the GCC console (Xcode 3.2 - Snow Leopard). The "DataModel" line for the "NSString *path" should read “Grokking_Recipes_DataModel”, assuming you named your application “Grokking_Recipes”.

I’m am trying to understand how to code a standard library view (as in Mail or iTunes) which has Smart Lists (as in Smart Mailbox or Playlist). It appears that Fetched Properties is the way to do this. I think it would be great to see how to use CoreData and Fetched Properties to support smart lists.

Page 163: “The NSPersistentStore, NSPersistentStoreCoordinator and NSMan- agedObjectModel are all perfectly thread-safe”

Page 165: “While the NSPersistentStoreCoordinator is not thread safe either…”

The direct conflict between these statements is confusing.

The first two are text fields, and the third is a combo box, as shown in Figure 2.7, on page 23. With the exception of the combo box for the type, all of these details are configured the same way. All of them have their Value binding associated with the recipe’s NSArrayController object with a controller key of selection and a model key path of name, serves, and description as appropriate.

“description as appropriate”, should be “desc as appropriate” as we are told when setting up the data model to name the attribute used for the description “desc”.

NSString *destPath = [self applicationSupportFolder];

Note: This is not accurate for projects under Xcode 3.2 / Snow Leopard 10B504 / 64 bit (Xcode IDE 1610.0, Xcode core 1608.0, ToolSupport 1591.0).

NSString *destPath = [self applicationSupportDirectory];

checking the generated Grokking_Recipes_AppDelegate.m file, shows that the method name is indeed -applicationSupportDirectory:, which returns a pointer to an NSString object.

There seems to be a redundant didChangeValueForKey, one on 2nd line before the page break on page 231, and one after it on page 232.
On closer inspection maybe the first one is supposed to be a “willChange..” to prepare for the deletion of the object… but there is already a “willChange.. ” opened above the very first if. in the method.

Penultimate paragraph, second line, first sentence “the names all of …” should be “the names of all …”

“The first two are text fields, and the third is a combo box, as shown in Figure 2.7, on page 25.”

No mention is made of adding the fourth control - Text View

I’m following the project in the book using the latest version of xcode 3.2.1.
The application template has created an AppDelegate object named “Grokking_Recipes_AppDelegate” with the following ivars:

NSWindow *window; NSPersistentStoreCoordinator *persistentStoreCoordinator; NSManagedObjectModel *managedObjectModel; NSManagedObjectContext *managedObjectContext;
These properties are declared as follows:

property (nonatomic, retain) IBOutlet NSWindow *window; property (nonatomic, retain, readonly) NSPersistentStoreCoordinator *persistentStoreCoordinator; property (nonatomic, retain, readonly) NSManagedObjectModel *managedObjectModel; property (nonatomic, retain, readonly) NSManagedObjectContext *managedObjectContext;

The problem comes in section 2.6 in “Adding the NSArrayController Objects”. Step #5 says to use the Bindings tab of the inspector to bind the ManagedObjectContext to the AppDelegate with the model key path of managedObjectContext.

IB simply won’t let me do this, I believe because the managedObjectContext property is defined as read only in the AppDelegate. There are no managedObjectContext’s that I can bind to unless I am supposed to drag one from the object library.

It’s very unclear how I’m supposed to bind this NSArrayController to the AppDelegates managedObjectContext.

In section 4.3 (p. 63) the method allRecipesSortedByName performs a request using an array of sort descriptors which should return the query result sorted appropriately. However, instead of returning this result, it makes a copy and sorts it again (by calling sortedArrayUsingDescriptors). I assume it should just return the result.

Under the heading of Changes that do not alter the Entity Hash there are two bullet items that are then repeated under In addition, the following changes to the properties of an entity will also not change the hash of the entity:.

These items are:
• User info: Adding, removing, or changing the user info keys/values
• Validation predicates: Adding, removing, or changing the valida- tion rules

One of the properties is called description instead of desc. Using “description” puts a load of funky text in the box (presumably the description of the recipe object).

In the second paragraph, there’s a repeat about the Shift+right-click way to drill down in the view. The second paragraph sounds like the information is being introduced for the first time.

“However, unlike the recipe source list, our NSTableView will have three columns, display its headers and its vertical scroll bar”
The change to the recipe table view’s headers is never mentioned above (although the interface image does show it without headers). Also, the recipe table view isn’t unlike the ingredients table view, as they both have horizontal scroll bar set to not show.

I think, that the Figure 2.6 doesn’t show, what is said in the text:
“5. On the Bindings tab of the inspector, bind ManagedObjectContext
to the AppDelegate with a model key path of managedObjectContext.”

I’m not shure, if this is a typo or a technical error or if I misunderstand something here…

common words such as a, the, and etc.

The word “and” should be italicized, but the word “etc” should not. The common word here is “and”, not “etc”.

Figure 3.7:

- Model Key Path should be blank
- Predicate Format should be “name contains[c] $value” (without quotes)

Otherwise the search field won’t work (Xcode 3.2.1, Mac OS X 10.6.2)

“we will review each of them in Section 10.3, Data Change Notifications.”
and

“As we discovered in Section 10.2, Handling Data Changes, on page 190”

Are right beside each other in the text. It doesn’t seem like this reference is needed.

from your book: “-awakeFromFetch
-awakeFromFetch is the counterpart to -awakeFromInsert. […] Because this method is called before
the data is loaded into the NSManagedObject, care should be taken to
not access or change any relationships that are associated with the
NSManagedObject. […]”

Not so - I just checked it with an app I’m working on:
2009-11-20 23:34:38.181 jwsdfg[28930:207] Golden Gate Bridge
2009-11-20 23:34:38.184 jwsdfg[28930:207] Coit Tower
2009-11-20 23:34:38.185 jwsdfg[28930:207] Alcatraz
2009-11-20 23:34:38.187 jwsdfg[28930:207] Painted Ladies
2009-11-20 23:34:38.189 jwsdfg[28930:207] TransAmerica Pyramid

from:

- (void)awakeFromFetch {
\t[super awakeFromFetch];
\tNSLog("%", self.title);
}

this just makes sense, as Apple describes it:

“The managed object context’s change processing is explicitly disabled around this method so that you can use public setters to establish transient values and other caches without dirtying the object or its context. Because of this, however, you should not modify relationships in this method as the inverse will not be set.”

The idea is that you can get your work done w/out making CD think that other objects are dirty. The point is that if you do that, then you need to not update a relationship, as that relationship would be left in a half-state.

for a book dedicated to core data, there really should be a lot more here on subclassing NSManagedObject. Like an example, showing properties in the subclass that aren’t represented in the CD entity, etc.

This section is not much more than the free, online Apple doc.

In the ‘applicationDidFinishLaunching:’ method in ‘AppDelegate.m’ a NSTimer instance is created with a time interval of 5 seconds.
The text states that this timer is used to auto save every 5 MINUTES.
This is not correct, the NSTimer instance should get an argument of 300 seconds to establish 5 minutes. EB

In the call to pathForResource needs to be changed to “Grokking_Recipes_DataModel”.

Once the versioning of the data model is started the call to pathForResource in managedObjectModel needs to be changed to load a resource of type @“momd”

In the following code:

for (NSString *filename in updatedObjects) {
if (![object isKindOfClass:[PPRecipe class]]) continue;
PPRecipe recipe = (PPRecipe)object;

Object is undeclared and no link is done between filename and object. A clean build from the Spotlight version in the code rep fails.

Regards

This section provides sample code for managing the display and updating of a UITableView using an NSFetchedResultsController. The delegate method |controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:| is used to update the table when the managed object context is saved. As written, the code crashes when an object is deleted. This is because the first line creates an array |paths| with the passed-in object |newIndexPath|. According to the official documentation |newIndexPath| is nil for changes of type delete. Thus, |arrayWithObject:| crashes as it attempts to insert a nil object, |newIndexPath|.

Thank you,
Justin

I’m not sure what the Fig 2.6 has to do with the actual settings. It looks like it may have come from a later chapter. If you open the sample code, even that does not match Fig 2.6.

- (NSPersistentStoreCoordinator*)persistentStoreCoordinator;
{
….
}

Should be
- (NSPersistentStoreCoordinator*)persistentStoreCoordinator
{
….
}

Extra ; at end

if (![persistentStoreCoordinator addPersistentStoreWithType:NSXMLStoreType
configuration:nil
URL:url
options:dict
error:&error]) {

dict is not defined until later on page 78:
"Previously we were
passing nil to the addPersistentStoreWithType:configuration:URL:options:error:
method for the options parameter. However, we need to change that to the following:

NSMutableDictionary *dict = [NSMutableDictionary dictionary];
[dict setObject:[NSNumber numberWithBool:YES]
forKey:NSMigratePersistentStoresAutomaticallyOption];
NSError *error = nil;
if (![persistentStoreCoordinator addPersistentStoreWithType:NSXMLStoreType
configuration:nil
URL:url
options:dict
error:&error]) {

At least for Xcode V3.2.1, autogenerated Grokking_Recipes_AppDelegate contain “applicationSupportDirectory” in the place of “applicationSupportFolder”.
The code exemple concerned is: addImageSheetDidEnd at the end of the page.

First line: “…but the underling persistent…” should be “…but the underlying persistent…”

Last sentence on the page: However, since the update of a cell can occur in more than one point in our MainViewController, we have move the implementation to its own method.

Move should be moved.

When discussing the sync settings for the Type entity you talk about the including the relationships on Type in the sync. My code (and the downloaded SyncServices code) does not have any relationships on Type (I assume to the associated recipes). Either you need to migrate from the type attribute on Recipe to a relationship to Type in v3 or correct the text to not refer to a recipe relationship on Type.

Middle paragraph states:

As of the writing of this book, there are still a few exceptions that this process can throw, so we want to be sure to capture those, wrap them up in an NSError, and hand the back to our caller.

It should state “and hand them back to our caller.”

First line of code shown one the page is:

- (NSPersistentStoreCoordinator*)persistentStoreCoordinator;

remove the semi-colon, this is the implementation.

In Figure 6.1, ChildTwoEnitty is misspelled.

Parenthetical aside at the bottom of the page reads, “(or use the + button in the entry area in the top left).” Should be “Entity”, not “entry”. [Using Xcode 3.2.2 on Snow Leopard]

Related to #40794: The final sentence of the paragraph under “Displaying a Picture of the Recipe” should use title capitalization on the words “Value Path” to make it clearer that the binding is to set Value Path, and not the path of Value.

Can not seem to get the image to appear, follows all the book requirements, and made change to the path “folder to ”Directory" but still no image.
Any ideas?

For people who’ve had trouble displaying the image, make sure the connection is to the Image Well (NSImageView) rather than to the Image Cell (NSImageCell) object. This should be made clearer in the text as it seems several are having problems with it.

The last line on this page is covered by the page footer. The last sentence is: “Once the loop is complete, the store has been prepopulated, and we can exit this cycle of the run loop.”

At the end of the second last paragraph: “defined as an Date.” should be “defined as a Date.”

apple doc ‘core data programming guide: managed objects’ expressly states that overriding the description method is discouraged as the results may be ‘unpredictable’ if the method fires a fault.
yet, in introductory material here (chapter 3, p35), that is exactly what is offered and further ‘With this method, I can reuse it in every NSManagedObject subclass that I create rather than having to create a custom -description method for each subclass.’
its disheartening to think that i will have to check this book against apple’s documentation.

see above p35…
now, on page 58 apple’s recommendations for not overriding are stated, and this doesn include not overriding the description method.
please use a different example for page 35.

In the book version: 2009-09-22, P1.0, September 2009: Model key path should be “desc”, instead of “description” when setting the value bindings on the Recipe NSArrayController.

Last line of text is hidden under blue banner saying “Prepared exclusively for…”. Last visible text is “… and we can exit”.

In section 2.4 (“Creating Our Xcode Project”), it specifies checking the “Use Core Data” box in Xcode, but it does not specify whether or not to select “Create Document Based Application”.

Based on the instructions in Section 2.8 (on page 24), it appears that the author used the Document Based Application template (hence, the existence of the “Save As…” menu option that is repurposed as “Add Recipe image…”). However, the document based application template creates different base classes/xib files, so it is not at all clear how this project should be set up in the current version of Xcode (3.24). Clarification would be helpful.

“NSManagedObjetID” should probably be “NSManagedObjectID”.

(“To solve this issue, we retrieve the NSManagedObjetID from the referenced NSManagedObject”)

When setting up the RecipeIngredient Array Controller, it is not mentioned to check “Prepares Content.” It may be somewhat implicit, but I took the directions at face value and ended up with an app that didn’t appear to retain the ingredients for each recipe.

I would suggest that, while building the UI, that the author interjects directions to go ahead and test the app, and what to expect when you run it. I find incremental changes, followed by testing, makes for a more confident learning experience. If I’m expected to build the data model, build the UI, and set up all of the bindings before seeing anything, I find myself getting pretty nervous by then end. If I’ve missed or screwed up a single step, the app doesn’t work, and I have no real idea where to go to look for the error. Personally, I would love it if we broke up the creation of the model, etc, and did thing like “build the recipe, from model to UI” then go back and “build the ingredients, from model to UI” with milestones along the way that we (the readers) can test against. Then, if we’ve made a mistake, we have far less text to go back and review to find our error.

In the second code listing on the page, defining addImageSheetDidEnd:…, there is this line:

NSString *destPath = [self applicationSupportFolder];

I get a warning saying that “applicationSupportFolder” may not exist on the opject. Running it anyways results in an error when we get to that line. I can’t find anything in the docs about this, whether it was deprecated or how to find this value. A bit of Googling leads me to believe that this might be a method added to the class…but I don’t seem to be able to find it.

For reference, I am using Xcode 4 and an edition of the book that was released in September 2009, so I admit perhaps I’m just behind the times in actually getting around to reading this…

A follow up to #46682:

I found it. Xcode 4 must have some modified templates. There is a applicationFilesDirectory method defined in the app delegate. It returns an NSURL, so it would appear that this line is an Xcode 4 worthy replacement:

NSString *destPath = [[self applicationFilesDirectory] path];

While this is supplied by the template, it’s worth noting that the code samples for the book provide that method pointing to a “Grokking_Recipes” folder in the “Application Support” directory, while this one pops that folder right into “Library.”

The text describing how to set up the bindings for the search field reads thus:

“…we bind this NSSearchField to our recipe’s NSArrayController using the controller key of filterPredicate and a model key path of name.”

I couldn’t get this to work until I looked at the XIB in the downloadable code. It would appear that setting a Model Key Path is not what you want to do; instead, you want to set the Predicate Format to “name contains $value”. I can see how saying “using…a model key path of name” could be interpreted as “using a model key path of name IN THE PREDICATE FORMAT field.” But that’s far less obvious than explicitly stating what goes into what fields, for us newbies.

beginSheetForDirectory:file:modalForWindow:… has been depreciated in Xcode 4.2.2. The code as written throws an error that says “implicit conversion of an Objective-C pointer to ‘void *’ is disallowed with ARC.” ah, progress :)

The very last line of this page is obscured in the PDF document.
In the .mobi, I can see that the last line says “and we can exit this cycle of the run loop”; however, the pdf ends with “and we can exit”.

peering slightly above the blue border at the foot of the pdf page, the tops of the textual characters can be seen.

xdzf’">