Database Reference
In-Depth Information
Figure 4—The Core Data stack
The
NSManagedObjectContext
itself is fairly straightforward to initialize. As of iOS
5 and Mac OS X 10.7, the initialization accepts a parameter to define what
type of context we are constructing. The different types of contexts are dis-
cussed in detail in
Chapter 5,
Threading
, on page 77
. For now, we will be
constructing an
NSMainQueueConcurrencyTypeNSManagedObjectContext
. That parameter
tells Core Data that the
NSManagedObjectContext
we are initializing can be used
only from the main (UI) queue of our application.
Once the
NSManagedObjectContext
has been initialized, we only need to set the
NSPersistentStoreCoordinator
that it is going to access. From there, it is ready to be
used. Therefore, we hand off the reference to it to our
AppDelegate
so that the
rest of the application can access it.
If you look at our sample application, you will notice that the order in which
I described these events is different from the order they appear in the code.
In the code, I actually initialize the
NSManagedObjectContext
prior to kicking off
the block to add the
NSPersistentStore
to the
NSPersistentStoreCoordinator
. The reason
for this is one of potential order. I want to guarantee that the
@property
for the
NSManagedObjectContext
is set before the
NSPersistentStore
is added and before the
-contextInitialized
method is called. While it is highly unlikely that the block on
the queue would complete before the method we are in, there is no reason to
risk it.