I love paper books, but I’m not a fetishist. I’ve gone almost entirely digital for my technical books since they tend to be relatively massive and become outdated quickly.
E-Readers are such different experiences from paper books, but we seem to have already settled on interface paradigms that carry over so much paper baggage. For a while now I’ve noticed that I have adopted a few counter-intuitive e-reading practices that others haven’t.
When it comes to Core Data, many application developers don’t even think about migration between versions. Even for those who do consider it, most testing usually ends up limited to a few simplistic scenarios: It’s tedious to repeatedly set up a single known state for a data store, and working against a full matrix of viable scenarios is just onerous.
Fortunately, there is functionality within Xcode to make it easier to manage and maintain a number of scenarios and restore them readily. This functionality will allow you to test your migration code from any past data model version to the current version, debug custom migrations, even profile migrations in Instruments.
Unfortunately, it’s not very well documented and, while you can preload to a device or simulator, the data package must first be created on a device.
Update 2015-04-20: This worked great in Xcode 5. Unfortunately Xcode 6 (through 6.3 as of this writing) does not behave as described for the Simulator (it does load a device just fine). Versions <6.3 will tell you “The application data package will be installed the next time you run your app in the Simulator”—every time. Version 6.3 will just silently fail to load the package. I have reported this as rdar://20622011 / Open Radar
In my “Core Data Potpourri” talk, I recommend declaring constant NSStrings of NSManagedObject attributes (that’s the correct Core Data term, but I’m just going to call them “properties” from here on out) for use in NSPredicates and KVC. Via Twitter, Riley Testut suggested an alternative:
@pgor have you considered using NSStringFromSelector(@selector(property)) when having to hardcode a property string? Seems cleanest to me
— Riley Testut (@rileytestut) March 22, 2014This does look like it would be cleaner. There’s not a “magic string” involved, and with the “Undeclared Selector” warning (GCC_WARN_UNDECLARED_SELECTOR) you would be warned if a property changed and your @selector wasn’t updated. Upon closer examination, though, there are a few problems.
I am honored to be on the latest installment of “The Record” podcast with Brent Simmons and Chris Parrish. Since they interviewed me last summer, I’ve been eagerly waiting to hear what they talked about with other interviewees. The first four episodes with Luke Adamson, John Nack, Greg Robbins, and Gus Mueller have been great. It’s rather intimidating to think that I might be counted among them.
I don’t remember most of what we discussed; I didn’t even remember much of it immediately afterward, it flowed so smoothly. One thing I do remember is that I said Metrowerks was integral to the Intel transition—instead, they were part of the earlier PowerPC transition. I’m not a historian of any kind and I don’t pretend to be. I misspoke and know it, so I don’t need to be set straight. Thanks.
Now I guess I should listen to the episode to be reminded of what I said, even if it involves the agony of listening to my own recorded voice.
Update: Huh, I did correctly say “PowerPC”. See, I’m not even a good historian of things that happened less than a year ago.
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.)
Brent Simmons wrote a great defense of his proposed “Cocoa Sin” of “Passing model objects to a UITableViewCell subclass”, expanding on the one apparently contentious item in his great list of 20 sins. Go read both posts, he’s so completely right.
Except I disagree.
What comes to mind when I say the word “success”?
Even though I installed the Path app and set up an account, I never really used it. It never really clicked with me; I really only signed up because many people I know were trying/using it. So it wasn’t anything close to a “hardship” for me to ask them to delete my account when it was revealed that they were uploading the contents of my address book to their servers. Still, I’m disappointed.
Last fall, we were in the crunch-time week for a client’s app before the iOS 5.0 submission deadline. I was profiling it in Instruments, trying to find where we could improve its launch-time performance, when I found a noticeable amount of time was spent in Address Book queries by a third-party video tracking library.
Few depart this world having left a piece of themselves in so many others. I shall cherish my tiny share.
Thank you, Mr. Jobs. Thank you, Jobs family, for sharing him with us.
As I understand it, the intent of a patent is to protect the value of the invention to the inventor by giving them exclusive control of the rights to use said invention. In return, they are asked to encourage future innovation by sharing that information with the world instead of keeping it a proprietary secret. Pretty simple and straightforward, and I really have a hard time disagreeing with that being a desirable goal.
Most of the complaints about the patent system being “broken” come down to a few points: