views:

36

answers:

2

Here's my situation, and it's probably fairly common but I have yet to find a satisfactory way to do it.

I am developing an iPhone application that will have a read-only, pre-loaded Core Data database stored in the app's bundle. I completely understand how to deploy such a thing. That isn't my problem.

My problem is How do I pre-load the Core Data database as a part of my build process? I can imagine several ways to do this, but I'm looking for a solution that integrates best with Xcode and has the least amount of hackery.

So far, my #1 choice is to create a project for a command-line tool that shares the Core Data Model with the iPhone project. This tool could then be run as a part of a shell script phase of the iPhone project's build process. What sucks is that, because one is an iPhone project and the other an OS X command-line tool, they cannot share the same project or even be referenced from one to the other. They must be completely separate. :(

Any suggestions?

+1  A: 

Depends on where you are getting the data from. Sounds like you are pulling the data from somewhere else automatically. In that case I would build a command line tool as you have guessed but don't rebuild it. Just create a command line tool and then execute it in a shell script as part of the build process for the iPhone application.

There should not be any reason to re-build that command line tool unless your model is updated.

Marcus S. Zarra
I suspected as much. This is exactly what I intended to do barring any other responses. Unfortunately I suspect my model will change a fair amount during the early stages of development, which could make this a mildly annoying process, but that's the way it goes.
Gregory Higley
if your data is changing slightly during development just let automatic migration take care of it as much as possible. Then when you are nearly done do a new data file.
Marcus S. Zarra
+1  A: 

because one is an iPhone project and the other an OS X command-line tool, they cannot share the same project or even be referenced from one to the other

That's a limitation in the new Xcode; it used to be perfectly possible to build a command line tool to run tests on OSX (and, in fact, it still works with xcodebuilder, just not in Xcode itself).

EDIT: A very terrible hack is to use PyObjC so you can run things in Python, but that's probably not suitable if you need to use compiled things.

A workaround is to do the data conversion on first launch.

tc.
Yeah, I thought about using a compiler flag so that it would do the data conversion on first launch, but I think the approach of using a separate app is probably best.
Gregory Higley