Patrón de diseño para la aplicación de iPhone Core Data

Question

Estoy creando una aplicación que utilizará un modelo de Datos Core. Soy bastante nuevo en Objective C y mis patrones de diseño habituales no se aplican realmente a Core Data y Objective C, al menos no puedo encontrar ejemplos que confirmen que lo harán.

He examinado los ejemplos de desarrolladores de Apple y diferentes fuentes en los intertubos.

Parece que para aprovechar Core Data necesito pasar el managedObjectContext a cada uno de mis viewControllers, hacer que viewController implemente el NSFetchedResultsControllerDelegate y luego implementar cada uno de los métodos para realizar una búsqueda y luego implementarlo

NSFetchedResultsChangeInsert

NSFetchedResultsChangeDelete  NSFrechadoResultadosCambiarMover  NSFetchedResultsChangeUpdate

Esto agrega aproximadamente 100 líneas de código en cada viewController y es el 90% del mismo código que escribo una y otra vez. Además, tengo que pasarlo todo y hacer un seguimiento de su huella de memoria.

En otros idiomas, crearía un modelo de varias clases que contenía métodos para mantener y entregar datos a pedido, disponibles desde cualquier lugar. Parece que no puedo adoptar ese enfoque en el Objetivo C. Si construyo una Clase estática que tomó unObjectContext administrado y me devolvía lo que necesitaba, todavía tendría que pasar el CorredorContenido gestionado a todas las vistas y no sería de forma asíncrona, como cuando implemento métodos de delegado a los que solo se llama cuando el resultado está listo.

Espero que esto tenga sentido y que alguien pueda confirmar que no hay otra forma razonable de hacerlo o ayudarme a orientarme en una dirección para concluir esto de una buena manera.

Gracias :)

Answer 1

Los datos básicos no son tan complicados como los describe.

En general, una aplicación de iPhone tiene un " main " contexto de objeto gestionado, que generalmente es propiedad del delegado de la aplicación. Mientras pueda obtener el delegado de la aplicación (sugerencia: [[UIApplication sharedApplication] delegate] ), tendrá acceso al contexto del objeto administrado. Me gusta definir una variable global estática para mantener una referencia a mi delegado de aplicación para hacer la vida más fácil.

En general, existe una correspondencia uno a uno entre las instancias de NSFetchedResultsController y las instancias de UITableView . Aparte de rellenar las vistas de tabla, es extremadamente raro que necesite un NSFetchedResultsController . Si tiene una cantidad de vistas similares (por ejemplo, una barra de pestañas que le permite ver los mismos datos de diferentes maneras a la aplicación del iPod), le convendría crear una clase base única que configure el NSFetchedResultsController y derivar sus controladores de vista específicos de eso.

Ahora, cuando creas controladores de vista para editar un objeto, generalmente es una buena idea hacerlo en un contexto de objeto administrado separado. Si el usuario cancela, simplemente descarta el contexto y los cambios desaparecen. Nuevamente, no necesita un NSFetchedResultsController para esto porque estas vistas solo se refieren a un solo objeto.

Cuando haya terminado de editar, guarda: el contexto del objeto gestionado. Los objetos que administran sus otros contextos de objetos administrados deben implementar los métodos NSFetchedResultsControllerDelegate para mantener la vista de tabla sincronizada. Nuevamente, esto se puede implementar en una clase base para que pueda generalizar esta funcionalidad para los controladores de vista relacionados.

Answer 2

¿Es absolutamente necesario usar un modelo CoreData o algo que funcione con un NSCoder (NSArchiver, NSKeyedArchiver, etc.) que funcione? Descubrí que CoreData es una exageración para la mayoría de las aplicaciones.

Además, ¿podría aclarar por qué no puede adoptar un enfoque utilizando singletons? He usado las fábricas de Singleton en varias aplicaciones sin problemas. Es bastante fácil definir los métodos de nivel de clase que operan en una instancia compartida (singleton).