2009-09-30 12 views
12

Estoy trabajando en una aplicación Core Data no basada en documentos.Guardado automático con Cocoa y Core Data

Me gustaría que los cambios se guarden a medida que ocurren. Esto es lo que el usuario espera en este tipo de aplicación. También es lo que Apple ha implementado en iPhoto o iTunes.

Un enfoque de fuerza bruta sería configurar un temporizador para guardar con frecuencia. El método desencadenado por el ahorro se tragaría todos los errores de validación para no molestar al usuario. Solo al salir, el usuario será molestado para organizar los datos y poder guardarlos. En mi humilde opinión, ese enfoque apesta.

Así que estoy pensando, debe haber una manera de enganchar el ahorro de alguna manera como el protocolo NSEditor. Cada vez que el usuario (o un controlador) finaliza la edición de datos, el delegado de la aplicación debe ser notificado de alguna manera y activar una operación de guardado. La cosa es que no sé exactamente dónde buscar.

Creo que para operaciones más complicadas, que pueden requerir algunas validaciones cruzadas, presentaría al usuario un poco de interfaz vinculada a un NSManagedObjectContext dedicado.

+0

Si ya admite deshacer, simplemente guárdelo cada vez que inserta algo en la pila de deshacer. –

+0

No soporto Deshacer todavía. Solo uso lo que proporciona CoreData. Pero estás defendiendo fuertemente el soporte de Deshacer extendido. –

Respuesta

14

Al final de cada evento en una aplicación AppKit, CoreData ejecutará un -processPendingTransactions por usted.

Un efecto secundario de esto es que si se ha registrado con su NSManagedObjectContext para recibir notificaciones de cambio, se le llamará al final de cada evento.

Por lo tanto, por ejemplo, en su controlador de notificaciones, puede llamar al contexto para guardar.

Sin embargo, puede ser paranoico sobre hacer un guardado en un contexto durante una devolución de llamada desde ese mismo contexto, por lo que probablemente se sentiría mejor si hiciera un Selector de rendimiento: @selector (guardar :) después de Delay: para presionar guardar hasta después de que el -procesoPendingTransactions esté hecho.

Incluso podría hacer una cancelación anterior en el selector -save: la demora será de 5 segundos, por lo que si el usuario o la aplicación se encuentra en medio de un BUNCH de cambios, todos se fusionarán en un solo guardado .

Y, de hecho, así es exactamente como funciona Delicious Library 1.0-1.09.

-Wil

+0

Gracias por el consejo. Tanto su sugerencia como la idea de utilizar el administrador de deshacer parecen excelentes. Por supuesto, su comentario hace una pregunta: ¿por qué las versiones más recientes de Delicious Library ya no usan esta técnica? –

+0

Decidí intentar guardar de inmediato en lugar de después de un retraso, porque estoy ejecutando varios hilos a la vez y cuando, por ejemplo, creas una portada en el hilo principal, REALMENTE deseas que los hilos del gráfico de fondo 'managedObjectContexts' vean la portada inmediatamente, no en tres segundos cuando guardas automáticamente. –

+0

Entonces, ¿todavía llama a performSelector: @selector (save :) afterDelay: en absoluto o está utilizando algún otro método para autoguardar el contexto? –