• Choose a category
• All
• Classic-Fiction

Time to Run

Before we’re ready to go further, we need to make one small change to the application’s source code. In the current version, the app tries to load data from its data store, and if the structure of the stored data doesn’t match the structure described in the latest version of the data model, problems will occur, and the app will show the user an error. To fix this, and make the application upgrade the data store, all we need to do is pass in a configuration option to the method that loads the data store. Open up MythBase_AppDelegate.m, and locate the persistentStoreCoordinator method. Toward the end of that method, you’ll see a group of lines that look like this:

What we’re going to do is create a dictionary of options to pass along in that method call. This dictionary contains a single key-value pair, which tells the store coordinator that it should try to update existing data to match the current data model. Replace the lines shown above with the following:

With the above in place, you should be able to build and run your application, and it will “just work!” You’ll see the old data that you had previously stored with the Chapter 7 version of MythBase, now converted to our app’s newest data model. Of course, you won’t see any of the new entities we’ve created in the model—in fact, if all goes according to plan, you won’t see anything different from Chapter 7 at all—but the underlying structure has now been modified to include the new entities and relationships.

So how did that happen? You may recall, from Chapter 7, the following method call in MythBase_AppDelegate’s persistentStoreCoordinator method:

It may not be obvious, but that method call is what triggers the data migration to occur. When the code shown previously is executed, what normally happens is that the data store is opened up and prepared for use. However, if the structure of the data store doesn’t match the structure of the coordinator’s data model (which is the current version we specified in Xcode), then a whole different chain of events takes place. Core Data will look for the existence (within the app’s bundle) of a mapping model that can convert the data store from the old structure to the new structure. In our case, MythBase now contains that mapping model, so the migration is performed automatically, with the old data file first being backed up in case something goes terribly wrong. Thanks to this automatic procedure, our users don’t need to worry about importing or converting data. When they run a new version of our app, their previously stored data is converted automatically and, except in the case of a really huge data store, quickly.

Updating the GUI

Now that we have our updated data model ready to go, it’s time to move on to create the GUI. We’re going to leave the existing window almost intact, and add a couple of new windows, one focused on MythicalBands, and one focused on MythicalVenues.

Create the Band Window

First, we’ll create a new window to show a list of MythicalBands. Open up MainMenu.xib in InterfaceBuilder, and create a new NSWindow. Use the Attributes Inspector to name this window Mythical Bands. We’re going to use Xcode’s built-in Core Data GUI creation assistant again, so switch back to Xcode. Bring up the latest version of the data model, and drag the MythicalBand entity from the graph paper area to the new window you just created in Interface Builder (remember, if you can’t see that new window after you’ve started dragging, you can switch back to Interface Builder by pressing ⌘Tab). When you release the entity over the window, you’ll see the New Core Data Entity Interface assistant appear, just like when you started creating the GUI for Chapter 7. Select Master/Detail View from the popup list, and click to enable the Search Field and Add/Remove checkboxes (this time leaving the Details Fields checkbox unchecked), then click Next. The next window asks which attributes we want to display. Now our

MythicalBand entity has some relationships,