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.
I’m quite tardy in posting this so I apologize. Here is the code and slides from the presentation I did on Core Data at the Houston iPhone DevCamp on Jan 30. Thanks to everyone that attended.
This was a question asked at the last NSCoder night. I didn’t realize the answer was so easy so I thought I would share it here in case others might not know. Just so appropriate credit is given, Ashley Clark was the one who pointed this out to us.
Go to the XCode Organizer while your device is attached and select your device in the left column. The bottom right panel will display a list of applications installed on the device. Scroll to your app. Because the app is installed using a testing profile it should have an arrow to the left than can be expanded. After expanding it, you should see the Application Data directory with an arrow pointing down to the right of the name. Selecting that arrow will give you a prompt to specify a location for that Application Data directory to be saved to your development machine.
The Application Data directory will contain your SQLite store under the Documents folder in addition to preferences, temp data, and anything else stored in the Application Data directory for the app.
The Houston iPhone DevCamp is going to be held the weekend of January 30-31 in the space next door to CoffeeGroundz. There will be a total of 12 talks during the day Saturday with a happy hour at the end of the day to celebrate the 1st year of the Houston iPhone Developer Meetup.
Starting Saturday evening and going through the night until mid-Sunday morning, there is an iPhone App Jam scheduled. The idea is to develop a complete iPhone app overnight and present what you have developed the next morning. I will be participating and I know of several others that plan on it as well. Don’t be discouraged if you are a newbie to iPhone development as several of the talks will be introductory to help you get started (there will also be advanced talks for those who have been at it a while).
I’ll be giving an introductory talk on Core Data but there will always be two talks going at the same time so you have the opportunity to not have to listen to me if that doesn’t sound attractive. You can sign up on the DevCamp site so I hope to see you there!