Database Reference
In-Depth Information
It turns out that most of the Core Data setup you had to do in the first section of
the topic comes ready for you to use. Here's a quick overview of the components
that you get in the starter project. It's quite a lot, so I've grouped the files into
categories below:
•
Seed data: seed.json
is a JSON file that contains real-world venue data for
venues in New York City that serve bubble tea. Since this is real data coming
from Foursquare, the structure is more complex than previous seed data used in
this topic.
•
Data model:
Click on
Model.xcdatamodeld
to open Xcode's model editor. The
top-level entity is
Venue
. It contains attributes
for a venue's name, phone number
and the number of specials it's offering at the moment.
Since the JSON data is rather complex, the data model breaks down a venue's
information into other entities. These are
Category
,
Location
,
PriceInfo
and
Stats
. For example,
Location
has attributes for city, state, country, et cetera.
•
Managed object subclasses:
All the entities in your data model also have
corresponding
NSManagedObject
subclasses. These are
Venue.swift
,
Location.swift
,
PriceInfo.swift
,
Category.swift
and
Stats.swift
.
•
App Delegate:
On first launch, the app delegate reads from
seed.json
, creates
corresponding Core Data objects and saves them to the persistent store.
•
CoreDataStack
: As in previous chapters, this object contains the cadre of Core
Data objects known as the “stack”: the context, the model, the persistent store
and the persistent store coordinator. No need to set this up—it comes ready for
you to use it.
•
View Controllers:
The initial view controller that shows you the list of venues is
ViewController.swift
. Tapping the Filter button on the top-right brings up
FilterViewController.swift
. There's not much going on here at the moment.
You'll be adding code to these two files throughout the chapter.
When you first launched the sample app, you saw only static information. However,
your app delegate had already read the seed data from
seed.json
, parsed it into
Core Data objects and saved them into the persistent store.
Your first task will be to fetch this data and display it on a table view. However, this
time you'll do it with a twist.
Stored fetch requests
As previously mentioned, you can store frequently used fetch requests right in the
data model. Not only does this make them easier to access, but you also get the
benefit of using a GUI tool to set up the fetch request parameters.
Let's give it a try. Open
Model.xcdatamodeld
and long-click the
Add Entity
button:
