Core Data Tutorial: How To Preload/Import Existing Data

Failed Banks Preloaded Data with Core Data

Failed Banks Preloaded Data with Core Data

This is the second part of a three part series to help get you up to speed with the basics of Core Data quickly.

In the first part of the series,
we created a visual data model for our objects, ran a quick and dirty
test to make sure it works, and hooked it up to a table view so we could
see a list of our objects.

In this part of the series, we’re going to discuss how to import or
preload existing data into Core Data so that we have some good default
data when our app starts up.

In the final part of the series, we’re going to discuss how we can
optimize our app by using NSFetchedResultsController, to reduce memory
overhead and improve response time.

Preloading / Importing Existing Data

So how do we preload data into a Core Data store, anyway? Well, there are two popular solutions to this problem:

  • Fill in Core Data on startup from external source. For
    this the app can start up, notice that the database hasn’t been imported
    yet, and start reading in data from an external source (such as an
    SQLite database or XML file) and then start inserting the data into Core
    Data.
  • Provide pre-filled in SQLite database. For this we’ll let
    Core Data create the database structure for us based on the model, and
    then we populate the database with a utility app. The utility app could
    be a Mac or iPhone app that uses Core Data to populate the database via
    Core Data APIs, or some kind of program that fills in the SQLite
    database directly. Once the database is populated, just include it with
    the app and make the app use it as the default database if no database
    already exists.

We’re going to go with option 2 because it’s simple and more
efficient. To populate the database, we’ll just extend our Python
script a bit since we have that working already.

Note that by using a Python script to import the data rather than
working with a utility app that uses Core Data APIs, it’s more likely to
break in the future because we’re kind of going under the hood here…
but for this tutorial I thought a) it’s a better learning experience
since we just covered SQLite and it shows how things are working more
clearly, and b) it is simpler!

So, let’s grab a copy of the sqlite database that was generated by
our project. The easiest way to find the file is to set a breakpoint
inside the application delegate, inside the persistentStoreCoordinator
function, below the storeUrl line. You can examine the storeUrl
variable to see a full path to where the sqlite backing file resides.
So find this and copy it to the directory your Python script is in.

Once you have the database, use sqlite3 to take a peek at how the database looks:

Here’s a quick description of what’s in here. Z_METADATA contains
some information about the Model that Core Data needs to function.
Z_PRIMARYKEY contains (among other things) information on the max key
that is currently used by each entity.

As for ZFAILEDBANKINFO and ZFAILEDBANKDETAILS, those are our main
data tables! Z_PK is the unique id for each, Z_ENT is their entity id
(same as what’s listed in the Z_PRIMARYKEY table), and finally there are
our normal fields.

Now, let’s create a Python script to populate this database by
reading in the contents of our old database, and creating the
appropriate rows in the new database. Create a Python script like the
following:

This should be pretty straightforward. The only tricky thing we
needed to do here was to convert the dates from the format they were
stored in our old database (a string) to the format they are stored in
the new databaes (epoch seconds). Update: Jeff R. pointed out
that NSDate uses a difference reference date than Python does so we have
to convert that – see the comments section for more information.

Give the Python script a whirl and if all works well you should be able to see your DB populated with data:

Once you’re satisfied the data is in the database correctly, drag the
populated database file into your XCode project in the Resources
folder. Then open up FailedBanksCDAppDelegate.m, navigate to the
persistentStoreCoordinator function, and replace the storeUrl line with
the following:

All this does is check to see if the sqlite file already exists in
the documents directory, and if it doesn’t (i.e. it’s the first time the
app has run) it copies the included database from the bundle into the
documents directory. Then Core Data will start using the preloaded data
and we’re good to go!

Delete the old SQLITE3 file from the iPhone simulator directory (or
click iPhone SimulatorReset Contents and Settings to clear everything),
and re-run your app. If all works, you should now see the prepopulated
list of banks!

Failed Banks App With Core Data

Where to Go From Here?

At this point, we have a detail view that works pretty much as
efficiently as the way it did in our SQLite example. However, with Core
Data, with just a couple more steps we can make it even more efficient.
So next time we’re going to cover how to do that by using
NSFetchedResultsController!

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注