Last Thursday (Feb 13, 2014) I presented a talk to Seattle Xcoders entitled “Core Data Potpourri”. On Friday I posted a PDF version of the slides, primarily so those in attendance would have them. These slides aren’t really intended to stand alone—hell, I wrote them up the day of the presentation—so I didn’t intend to announce them outside Xcoders until the video was posted. (I’m not in charge of the encoding, so I don’t know yet when it will be posted.)
Update: Video is now live. -18mar14
Then Brent Simmons linked to them and I feel like I’ve been fielding questions, comments, and a pleasant number of kudos ever since. I feel like I should post some clarifications here now.
This talk was pretty much a complete last minute change from what I’d prepared and presented internally to Black Pixel coworkers two days earlier because I wasn’t happy with the boring textbook feel of that talk. If you don’t feel it was a polished set of slides, you’re absolutely correct.
Please keep in mind the last few slides on Core Data multithreading are woefully inadequate. I’d intended to cover it more thoroughly as part of the “potpourri” concept but the list of “best practices” grew to pretty much be a list of many things I’ve been ranting about to others for the last year or so, and that I’d been sprinkling throughout client projects. I was tempted to ignore it (like I did the empty slides on performance optimization and multiple persistent stores) but felt I should reward people for sticking it out through the talk.
I warned the audience before discussing it that there would be a lot of handwaving and no code examples were ready—but that surely doesn’t come across in static slides.
The “Why Not mogenerator” slide has been the lightning rod, as I’d feared—I’ve learned you can expect that whenever you call something out in any negative light. Hopefully when you see the actual talk, it will come across as I intended: A response for when someone asks me why I do this “by hand”, not a screed trying to wipe mogenerator from the face of the Earth.
By the way, there’s one response to “how do you handle when you have to regenerate classes” that I didn’t even manage to get out during the presentation: Git diff. Honestly.
This is multifold. First, I consider my “enlightenment” regarding multithreaded Core Data to have come during a project targeting iOS 5.1. The new contexts weren’t an option on the project, and seeing coworkers fight the nightmares of that initial release of contexts convinced me to not bother looking into it for a while. Since then, I’ve become comfortable enough in the “one reader context, multiple serial writer contexts” mechanism that I haven’t found many compelling reasons to make parent-child my default.
Second, I strongly believe that understanding the implications and combinations of the rules “each MO belongs to only one MOC”, “MOCs are not threadsafe”, and—perhaps most importantly—“loaded MOs need to refresh somehow” are key to writing successful multithreaded code. After that, parent-child contexts can make great tools but too many developers treat them as the cure-all that will let them just ignore these aspects. Parent-child and thread containment can work together, it doesn’t have to be either-or.
It was pointed out after the talk that my “+newInstance…” method for managed objects returns an autoreleased object and will break MRC conventions. Totally correct. This is mostly due to me having tried to clear out MRC space in my brain for new knowledge, but also because I threw together the talk with code examples from numerous different projects, and my naming conventions have tended to change over time. I’m sure there are other such problems in the slides—you’re free to “Be Better Than Sample Code”. :)
“NSManagedObject Is the Real Top of the Stack” might imply that you don’t have to worry about keeping a strong reference to that parent MOC. Don’t forget that -managedObjectContext is a weak reference and if a MOC is deallocated, any of its MOs are now invalid. In practice, I rarely have an issue with this since I’m keeping one readonly MOC around for all my UI needs, but this is definitely something to be aware of. I still feel it’s not worth the confusion of passing/configuring them separately.
I hope this clarifies some issues people have had. I hope you watch the video when it’s released but be warned that it will probably run about 100 minutes with talk and Q&A. (I’m told Q&A was actually truncated due to SD card storage limits.)