As promised, here are the slides and code that I used in last night’s presentation on Core Data.
Thanks to everyone who attended my talk. I thought the Q&A and conversation made the presentation much better than just me standing and talking to the room (although it also made the presentation go longer than I had planned).
Anyone in the Houston area doing iOS work that is not taking advantage of this great meetup is missing out.
This is not a very lengthly post but it might help someone out. I like to use mogenerator and Xmo’d to generate my core data model classes rather than using the standard code generator included in xcode.
Usually everything works beautifully with my classes generating as expected when I save my data model. However, I have run into two cases where the old classes are removed but the new classes are never generated. When this happens, looking at the crash in console.app won’t be of much help because the location of the crash in the mogenerator source simply states that the model failed to load with no reason given.
Both of the causes were errors on my part. The first being I added an attribute to an entity but did not assign a type to it. The second being I apparently added an entity that had some sort of name collision. The entity in question was named “List” and when I renamed it to “DSList”, the model classes generated without an issue.
Hopefully this will save someone time and give them an idea of what to look for.
Recently, I tried to create a versioned data model for an application I had created earlier this year and had some issues with Subversion not being able to commit the changes.
When xcode creates a new versioned data model, the existing data model essentially gets moved into a .zip file format consisting of the current version (named the same as the un-versioned model) and any older versions that might be there named with sequential numbers appended to the name (only 1 in the beginning).
The problem with svn occurs because apparently the svn integration in xcode 3.2.x doesn’t perform a move into the .zip. Therefore, when you try to commit the code, svn will complain that the new data model within the .zip has the same name as an already existing file.
The workaround I implemented is to go to finder and duplicate the model before versioning it. Then switch back to xcode and create the versioned data model. Afterwards, rename the duplicated file back to the original data model file name. If you look at the file system in finder, you should see both the newly created version data model and the old data model.
Now expand the versioned data model and delete the file of the same the name as the original data model inside. Afterwards perform an svn move of the un-versioned data model to inside the versioned data model. Now you can commit the changes without an issue and everything will work fine.
Hopefully xcode 4 will fix this because it caused me a little pain before I figured out how to workaround the issue.
I will be speaking at the next Houston iPhone Developer Meetup. I will be using almost the same slides as I did for the Core Data presentation at the Houston Techfest this past Saturday but I will have a little more time to present and the Q&A that goes on during the presentations is often the best part.
If you are in Houston, this is a great way to meet other iOS developers. We are fortunate in Houston, there are usually several individuals in attendance who have presented talks at national and regional conferences.
As promised, here are the presentation slides (keynote) and the code from the presentation I gave today at the Houston Techfest. Thanks to everyone who attended my talk.