Punto de uso de NSPersistentStoreCoordinator?

Question

En la conferencia Core Data del curso de iPhone Stanford 193P en iTunes, el instructor codificó un proyecto de muestra con Core Data sin usar NSPersistentStoreCoordinator y lo cargó con NSManagedObjectModel. Pero al mirar otras muestras de código y el libro Big Nerd Ranch sobre el desarrollo de iPhone, están creando un NSManagedObjectModel y PersistentStoreCoordinator y configurando el NSManagedObjectContext de esa manera.

Mi pregunta es ¿cuál es el propósito de hacerlo de esta manera, y cuáles son los pros y los contras de ambos enfoques?

Answer 1

Seguí la misma serie de conferencias muy de cerca. Este ejemplo particular extrae datos (fotógrafos y fotos) de Flickr y los carga en CoreData. No era realmente necesario utilizar CoreData en esta aplicación, ya que necesita obtener datos nuevos de flickr en cada carga de la aplicación, por lo tanto, no tiene sentido guardar de forma persistente. El prof solo usaba la aplicación Flickr fetching de la demostración anterior como punto de partida, ya que los estudiantes ya estaban familiarizados con ella (lo que le permite concentrarse en explicar CoreData). Sin embargo, como se mencionó, las grandes ventajas de usar datos básicos sin guardar el contexto en el disco son enormes.

Como Pablo explicó en la conferencia antes de la demostración, una base de datos central puede ser creado (en iOS5) ya sea por:

1. Al hacer clic en "datos de uso núcleo" de una plantilla de aplicación cuando se crea un nuevo proyecto.
2. Usando UIManagedDocument

La idea detrás del primer enfoque es que Xcode pondrá un montón de código en AppDelegate para configurar el directorio de documentos/coordinador de almacén persistente/y modelo. Luego pasará el objeto gestionado CONTEXT a su controlador de vista inicial (que debe tener una propiedad NSManagedObjectContext en la API pública) y desde allí puede pasar el contexto como una botella de cerveza cuando se segue a otros controladores de vista. Pasar el contexto es el procedimiento correcto para acceder a la base de datos central.

El uso de UIManagedDocument es muy similar, excepto que su AppDelegate se deja solo. Usted crea un UIManagedDocument (tal vez en su controlador de vista inicial) usando una ruta URL desde el directorio de documentos de su aplicación (Nota: debe verificar manualmente si el archivo ya existe, existe pero no está abierto o no existe). Entonces puede usar el contexto de este documento de la misma manera que arriba.

Otra nota: es una buena idea crear un puntero a su contexto en su AppDelegate para que pueda guardar su contexto explícitamente (¡solo cuando esté listo!) Cuando la aplicación se cuelga o termina.

El coordinador de tienda persistente se configura automáticamente para usted y puede configurarlo utilizando su propiedad persistentStoreOptions (y de hecho lo necesitará para guardar el contexto persistentemente), o subclasificando UIManagedDocument y reemplazando los métodos deseados.

Lea la introducción en la documentación UIManagedDocument http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIManagedDocument_Class/Reference/Reference.html

Ambos métodos funcionan de la misma manera y le proporcionará el mismo control y acceso. Con UIManagedDocuments puede crear múltiples bases de datos en múltiples archivos sqlite, también puede esperar para crear/configurar la base de datos hasta que sea necesaria. La opción "usar datos básicos" le proporciona una única base de datos central que configura en la carga de la aplicación, le permite centralizar cosas de CoreData en AppDelegate, ahorra tiempo de codificación y es bueno para una aplicación de seguimiento rápido. Me gusta UIManagedDocument.

Si inició su aplicación sin la opción de datos centrales marcada y desea agregarla a AppDelegate, simplemente cree un nuevo proyecto con los datos centrales marcados y copie todo el código a su AppDelegate (solo deberían ser 3 propiedades y sus accesorios así como un método de conveniencia para acceder al directorio de documentos). Tendrá que apuntar a su controlador de vista inicial, modelo, etc.

ACTUALIZACIÓN: Solo quería agregar otra conveniencia. Si el contexto de objeto gestionado se almacena en su AppDelegate, se puede acceder a él en cualquier lugar de su aplicación sólo mediante el uso

NSManagedObjectContext* context = [[(AppDelegate*) [UIApplication sharedApplication] delegate] myManagedObjectContext]; 

Esto niega tener que pasar por ahí.

Para cualquier aplicación CoreData, si realiza algún cambio en su modelo, ASEGÚRESE DE ELIMINAR MANUALMENTE LA APLICACIÓN EN EL SIMULADOR antes de volver a compilar. De lo contrario, obtendrá un error en la siguiente compilación, ya que usará el archivo anterior.

Answer 2

Sin un coordinador de tienda persistente no podrá guardar sus resultados en un área persistente (base de datos, archivo, etc.) ... por lo tanto, si desea un administrador de datos persistente que es completamente inútil, omita NSPersistentStoreCoordinator. ¿Estás seguro de que el proyecto no lo estaba usando? ¿Cómo fue el profesor guardando los datos? Cuando crea un nuevo proyecto de Datos centrales, esta lógica se autogenera por usted.

EDITAR: Lo tengo ahora, el profesor está utilizando UIManagedDocument, que utiliza su propio coordinador de tienda persistente internamente (según el tipo de archivo) por lo que no hay necesidad de crear uno explícito (a menos que no esté satisfecho con el defecto). Entonces, al final, no se trata de usar o no un coordinador, es si lo creaste o no explícitamente.