Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Mobile Development

Datos principales de Scratch: pila de datos básicos

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Core Data from Scratch.
Core Data from Scratch: Data Model

Spanish (Español) translation by Juan Pablo Diaz Cuartas (you can also view the original English article)

Introducción

El marco de Data Core ha existido por muchos años. Se usa en miles de aplicaciones y por millones de personas, tanto en iOS como en OS X. Core Data es mantenido por Apple y muy bien documentado. Es un marco maduro que ha demostrado su valor una y otra vez.

Core Data aprovecha el lenguaje Objective-C y su tiempo de ejecución, y se integra perfectamente con el framework de Core Foundation El resultado es un framework fácil de usar para administrar un gráfico de objetos que es elegante de usar e increíblemente eficiente en términos de uso de memoria.

1. Prerrequisitos

Aunque el marco de Core Data no es difícil per se, si eres nuevo en el desarrollo de iOS o OS X, te recomiendo que primero veas nuestra serie sobre el desarrollo de iOS. Le enseña los fundamentos del desarrollo de iOS y, al final de la serie, tendrá los conocimientos suficientes para abordar temas más complejos, como Core Data.

Como dije, Core Data no es tan complejo o difícil de recoger como la mayoría de los desarrolladores piensan. Sin embargo, aprendí que una base sólida es fundamental para estar al día con los datos centrales. Debe comprender correctamente la API de datos centrales para evitar malas prácticas y asegurarse de no tener problemas al utilizar el framework.

Cada componente del framework de Core Data tiene un propósito y función específicos. Si intenta utilizar Core Data de una manera que no fue diseñada, inevitablemente terminará luchando con el framework.

Lo que cubro en esta serie en Core Data es aplicable a iOS 6+ y OS X 10.8+, pero el foco estará en iOS. En esta serie, trabajaré con Xcode 5 y iOS 7 SDK.

2. Curva de aprendizaje

El marco de Data Core puede parecer desalentador al principio, pero el API es intuitivo y conciso una vez que comprenda cómo encajan las distintas piezas del rompecabezas. Y ahí es exactamente donde la mayoría de los desarrolladores encuentran problemas. Intentan usar Core Data antes de haber visto ese rompecabezas proverbial, no saben cómo las piezas del rompecabezas encajan y se relacionan entre sí.

En este artículo, te ayudaré a familiarizarte con la llamada pila de datos básicos. Una vez que comprenda a los jugadores clave de la pila de Datos básicos, el marco se sentirá menos desalentador e incluso comenzará a disfrutar y apreciar la API bien elaborada del framework.

A diferencia de frameworks como UIKit, que puede usar sin entender el framework en su totalidad, Core Data exige una comprensión adecuada de sus componentes básicos. Es importante reservar un tiempo para familiarizarse con el marco, lo cual haremos en este tutorial.

3. ¿Qué es Core Data?

Los desarrolladores nuevos en el marco de Core Data a menudo lo confunden y esperan que funcione como una base de datos. Si hay algo que espero que recuerde de esta serie, es que Core Data no es una base de datos y no debe esperar que actúe como tal.

¿Qué es Core Data si no es una base de datos? Core Data es la capa modelo de su aplicación en el sentido más amplio posible. Es el modelo en el patrón Modelo-Vista-Controlador que impregna el SDK de iOS.

Core Data no es la base de datos de su aplicación ni es una API para la persistencia de datos en una base de datos. Core Data es un marco que administra un gráfico de objetos. Es tan simple como eso. Core Data puede persistir ese gráfico de objetos escribiéndolo en el disco, pero ese no es el objetivo principal del framework.

4. Pila de datos básicos

Como mencioné anteriormente, la pila de Datos centrales es el corazón de Core Data. Es una colección de objetos que hace que Core Data marque. Los objetos clave de la pila son el modelo de objetos gestionados, el coordinador de tienda persistente y uno o más contextos de objetos gestionados. Comencemos echando un vistazo rápido a cada componente.

NSManagedObjectModel

El modelo de objetos gestionados es el modelo de datos de la aplicación. Aunque Core Data no es una base de datos, puede comparar el modelo de objetos gestionados con el esquema de una base de datos, es decir, contiene información sobre los modelos o entidades del gráfico de objetos, qué atributos tienen y cómo se relacionan con unos y otros.

El objeto NSManagedObjectModel conoce el modelo de datos al cargar uno o más archivos del modelo de datos durante su inicialización. Veremos cómo funciona esto en unos momentos.

NSPersistentStoreCoordinator

Como su nombre indica, el objeto NSPersistentStoreCoordinator conserva los datos en el disco y garantiza que la (s) tienda (s) persistente (s) y el modelo de datos sean compatibles. Media entre la (s) tienda (s) persistente (s) y el (los) contexto (s) de objeto gestionado y también se encarga de cargar y almacenar en caché los datos. Está bien. Core Data tiene un caché integrado.

El coordinador de tienda persistente es el conductor de la orquesta Core Data. A pesar de su importante papel en la pila de datos básicos, rara vez interactuamos directamente con él.

NSManagedObjectContext

El objeto NSManagedObjectContext administra una colección de objetos modelo, instancias de la clase NSManagedObject. Es perfectamente posible tener múltiples contextos de objetos gestionados. Cada contexto de objeto gestionado está respaldado por un coordinador de tienda persistente.

Puede ver un contexto de objeto gestionado como workbench en el que trabaja con sus objetos de modelo. Usted los carga, los manipula y los guarda en workbench La carga y el almacenamiento están mediados por el coordinador de tienda persistente. Puede tener múltiples bancos de trabajo, lo que es útil si su aplicación es multiproceso, por ejemplo.

Mientras que un modelo de objetos administrados y un coordinador de tienda persistente se pueden compartir entre subprocesos, nunca se debe acceder a los contextos de objetos gestionados desde un subproceso diferente al que se creó. Analizaremos varios subprocesos con más detalle más adelante en esta serie.

5. Explorando la pila de datos básicos

Paso 1: plantilla de Xcode

Exploremos la pila de Datos centrales con más detalle echando un vistazo a la plantilla Xcode de Apple para Datos centrales. Cree un nuevo proyecto en Xcode 5 seleccionando Nuevo> Proyecto ... en el menú Archivo. Elija la plantilla de la aplicación vacía de la lista de plantillas de aplicaciones de iOS a la izquierda.

Asigne un nombre a los Datos principales del proyecto, configure Dispositivos en iPhone y marque la casilla de verificación Usar datos principales. Indique a Xcode dónde desea almacenar los archivos del proyecto y pulse Crear.

Paso 2: descripción general

De forma predeterminada, Apple pone el código relacionado con los datos principales en la clase de delegado de la aplicación, la clase TSPAppDelegate en nuestro ejemplo. Comencemos explorando la interfaz de TSPAppDelegate

Como puede ver, el delegado de la aplicación tiene una propiedad para cada componente de la pila de Datos centrales, así como dos métodos de conveniencia, saveContext y applicationDocumentsDirectory.

Tenga en cuenta que las propiedades de Core Data están marcadas como de solo lectura, lo que significa que las instancias no pueden ser modificadas por objetos que no sean la aplicación delegada.

La implementación de TSPAppDelegate es mucho más interesante y nos mostrará cómo funcionan juntos el modelo de objetos gestionados, el coordinador de tienda persistente y el contexto de objetos gestionados. Comencemos desde arriba.

Debido a que las propiedades en la interfaz de la clase TSPAppDelegate se declaran como de solo lectura, no se crean métodos setter. La primera directiva @synthesize le dice al compilador que asocie la variable de instancia _managedObjectContext con la propiedad managedObjectContext que declaramos en la interfaz de la clase. Este es un patrón común para cargar objetos de forma perezosa.

Puede lograr el mismo resultado utilizando una extensión de clase privada en el archivo de implementación de la clase. Eche un vistazo al siguiente fragmento de código. Las directivas @synthesize no son necesarias si usa una extensión de clase privada.

Aunque usualmente uso y prefiero una extensión de clase privada, nos quedaremos con la plantilla de Apple para este tutorial.

La configuración de la pila de datos básicos es bastante sencilla en términos de los métodos que deben implementarse. Apple no usa métodos de configuración especiales para crear la pila de Datos básicos. Los tres objetos clave de la pila de Datos centrales se crean cuando son necesarios. En otras palabras, están cargados o instanciados.

En la práctica, esto significa que la implementación de la clase TSPAppDelegate tiene un aspecto similar al que esperaría en una clase de delegado de aplicaciones, a excepción de los métodos saveContext y applicationDocumentsDirectory, y los métodos getter de managedObjectContext, managedObjectModel y persistentStoreCoordinator. Es en estos métodos getter que ocurre la magia. Esa es una de las bellezas de Core Data, la configuración es muy simple e interactuar con Core Data es igual de fácil.

Paso 3: contexto de objetos administrados

La clase que usará más a menudo, además de NSManagedObject, cuando se interactúa con los datos principales es NSManagedObjectContext. Comencemos por explorar su getter.

Las primeras tres líneas de su implementación son típicas para un getter que carga la variable de instancia de forma perezosa. Si el objeto NSManagedObjectContext no es nulo, devuelve el objeto. El bit interesante es la instanciación real del objeto NSManagedObjectContext.

Primero hacemos referencia al coordinador de la tienda de persistencia llamando a su método getter. El coordinador de la tienda persistente también está cargado de forma perezosa, como veremos en un momento. Si el coordinador de tienda persistente no es nulo, creamos una instancia de NSManagedObjectContext y establecemos su propiedad persistentStoreCoordinator en el coordinador de tienda persistente. Eso no fue muy difícil. ¿Que era?

En resumen, el contexto del objeto gestionado gestiona una colección de objetos modelo, instancias de la clase NSManagedObject y mantiene una referencia a un coordinador de tienda persistente. Tenga esto en cuenta mientras lee el resto de este artículo.

Paso 4: Coordinador de tienda persistente

Como vimos hace un momento, el método managedObjectContext invoca el método persistentStoreCoordinator. Eche un vistazo a la implementación de persistentStoreCoordinator, pero no permita que le asuste. En realidad no es tan complicado.

Casi siempre querrá almacenar el gráfico de objetos de Core Data en el disco y la plantilla de Xcode de Apple usa una base de datos SQLite para lograr esto.

Cuando creamos el coordinador de tienda persistente en persistentStoreCoordinator, especificamos la ubicación de la tienda en el disco. Comenzamos creando un objeto NSURL que apunta a esa ubicación en la zona de pruebas de la aplicación. Invocamos applicationDocumentsDirectory, un método auxiliar, que devuelve la ubicación, un objeto NSURL, del directorio Documents en el sandbox de la aplicación. Agregamos Core_Data.sqlite a la ubicación y lo almacenamos en storeURL para su uso posterior

De forma predeterminada, el nombre de la tienda en el disco es el mismo que el nombre del proyecto. Sin embargo, puedes cambiar esto a lo que quieras.

Como mencioné hace un momento, la extensión .sqlite insinúa que la tienda en el disco es una base de datos SQLite. Aunque Core Data admite varios tipos de tiendas, SQLite es, con mucho, el tipo de tienda más utilizado debido a su velocidad y fiabilidad.

En el siguiente paso, crearemos una instancia del coordinador de tienda persistente invocando initWithManagedObjectModel: y pasando una instancia de NSManagedObjectModel. Tomamos una referencia al modelo de objetos gestionados al invocar el método managedObjectModel, que exploraremos a continuación.

Ahora tenemos una instancia de la clase NSPersistentStoreCoordinator, pero todavía no hay tiendas asociadas a ella. Agregamos una tienda al coordinador de tienda persistente llamando a un método bastante impresionante, addPersistentStoreWithType:configuration:URL:options:error.

El primer argumento especifica el tipo de tienda, NSSQLiteStoreType en este ejemplo. Core Data también admite almacenes binarios (NSBinaryStoreType) y un almacén de memoria (NSInMemoryStoreType).

El segundo argumento le dice a Core Data qué configuración usar para la tienda persistente. Pasamos nulo, lo que le dice a Core Data que use la configuración predeterminada. El tercer argumento es la ubicación de la tienda, que se almacena en storeURL.

El cuarto argumento es un NSDiccionario de opciones que nos permite alterar el comportamiento de la tienda persistente. Retomaremos este aspecto más adelante en esta serie y pasaremos en nulo por ahora. El último argumento es una referencia a un puntero NSError.

Si no aparecen errores, este método devuelve un objeto NSPersistentStore No guardamos una referencia a la tienda persistente, porque no necesitamos interactuar con ella una vez que se agrega al coordinador de tienda persistente.

Sin embargo, si agrega la tienda persistente falla, significa que hay un problema con la tienda persistente de la aplicación y debemos tomar los pasos necesarios para resolver el problema. Cuando esto sucede y por qué sucede es el tema de una futura entrega.

Por el momento, se invoca abortar cuando addPersistentStoreWithType: configuration: URL: options: error: devuelve nulo. Como explican los comentarios en la declaración if, nunca debe llamar a abortar en un entorno de producción porque bloquea la aplicación. Remediaremos esto más adelante en esta serie.

Paso 5: modelo de objetos gestionados

La tercera y última pieza del rompecabezas es el modelo de objetos gestionados. Let's take a look at the getter of the managedObjectModel property.

La implementación es muy fácil. Almacenamos la ubicación del modelo de la aplicación en modelURL y pasamos modelURL a initWithContentsOfURL: para crear una instancia de la clase NSManagedObjectModel.

En este punto, probablemente se esté preguntando a qué modelo apunta modelURL y cuál es el archivo con la extensión .momd.  Para responder a estas preguntas, debemos averiguar qué más ha creado Xcode para nosotros durante la configuración del proyecto.

En Project Navigator a la izquierda, debería ver un archivo llamado Core_Data.xcdatamodeld. Este es el modelo de datos de la aplicación compilada en un archivo .momd. Es ese archivo .momd que el modelo de objetos administrados usa para crear el modelo de datos de la aplicación.

Es posible tener varios archivos de modelo de datos. La clase NSManagedObjectModel es perfectamente capaz de combinar múltiples modelos de datos en uno, que es una de las funciones más potentes y avanzadas de Core Data.

La infraestructura de Core Data también admite el control de versiones de modelos de datos y migraciones. Esto garantiza que los datos almacenados en las tiendas persistentes no se corrompan. Cubriremos versiones y migraciones más adelante en esta serie.

El archivo del modelo de datos en nuestro proyecto está vacío en este momento, lo que significa que nuestro modelo de datos no contiene entidades. Lo solucionaremos en el próximo tutorial que se centrará exclusivamente en el modelo de datos.

6. Poniéndolo todo junto

Antes de concluir este artículo, me gustaría mostrarle un diagrama que ilustra los tres componentes de la pila de Datos centrales.

El diagrama de arriba es una representación visual de lo que exploramos en la plantilla de Xcode hace un momento. El objeto NSPersistentStoreCoordinator es el cerebro de la pila de datos básicos de la aplicación. Habla con una o más tiendas persistentes y se asegura de que los datos se guarden, carguen y almacenen en caché.

El coordinador de tienda persistente conoce el modelo de datos, el esquema del gráfico de objetos si lo desea, a través del objeto NSManagedObjectModel. El modelo de objetos gestionados crea el modelo de datos de la aplicación a partir de uno o más archivos .momd, representaciones binarias del modelo de datos.

Por último, la aplicación accede al gráfico de objetos a través de una o más instancias de la clase NSManagedObjectContext. Un contexto de objeto gestionado conoce el modelo de datos a través del coordinador de tienda persistente, pero no conoce ni mantiene una referencia al modelo de objetos gestionados. No hay necesidad de esa conexión.

El contexto del objeto gestionado le pide al coordinador persistente datos y le dice que guarde los datos cuando sea necesario. Todo esto lo hace el framework de Core Data y su aplicación raramente necesita hablar directamente con el coordinador de tienda persistente.

Conclusión 

En este artículo, cubrimos los factores clave de la pila de Datos centrales, el coordinador de tienda persistente, el modelo de objetos gestionados y el contexto de objetos gestionados. Asegúrese de comprender el rol de cada componente y, lo que es más importante, cómo trabajan juntos para hacer que los Datos Centrales hagan su magia.

En la próxima entrega de esta serie sobre Core Data, nos sumergimos en el modelo de datos. Echamos un vistazo al editor de modelos de datos en Xcode 5 y creamos algunas entidades, atributos y relaciones.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.