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.
 
 
 
Search WWH ::




Custom Search