Modello di progettazione per l'app per iPhone Core Data

Question

Sto costruendo un'app che utilizzerà un modello Core Data. Sono piuttosto nuovo all'Objective C ei miei soliti schemi di progettazione non si applicano in realtà ai Core Data e all'Obiettivo C, almeno non riesco a trovare esempi che confermino la loro volontà.

Sono stato attraverso gli esempi di Apple Developer e diverse fonti sugli intertubes.

Sembra che per sfruttare Core Data ho bisogno di passare la managedObjectContext a ciascuno dei miei viewControllers, avere la viewController implementare il NSFetchedResultsControllerDelegate e quindi implementare ciascuno dei metodi per fare un'operazione di recupero e successivamente attuare

NSFetchedResultsChangeInsert 

NSFetchedResultsChangeDelete NSFetchedResultsChangeMove NSFetchedResultsChangeUpdate

Questo aggiunge circa 100+ linee di codice in ogni viewController ed è il 90% dello stesso codice che scrivo ripetutamente. Inoltre devo passare tutto e tenere traccia del suo footprint di memoria.

In altre lingue creerei un modello singleton di alcune classi che contenevano metodi per il mantenimento e l'invio di dati su richiesta, disponibili da qualsiasi luogo. Sembra che non possa adottare questo approccio in Objective C. Se io dovessi costruire una classe statica che prendesse un oggetto ManagedObjectContext e mi restituisse ciò di cui avevo bisogno, avrei comunque dovuto passare a objectObjectContext su ogni vista e non sarebbe stato asincrono come quando implemento metodi delegati che vengono appena chiamati quando un risultato è pronto.

Spero che questo abbia un senso e che qualcuno possa confermare che non esiste un altro modo ragionevole per farlo o che mi aiuti a indicarmi una direzione per avvolgerlo in un buon modo.

Grazie :)

Answer 1

Core Data non è così complicato come si descrive.

In genere, un'app per iPhone ha un contesto di oggetto gestito "principale", generalmente di proprietà del delegato dell'app. Finché è possibile ottenere il delegato dell'app (suggerimento: [[UIApplication sharedApplication] delegate]) è possibile accedere al contesto dell'oggetto gestito. Mi piace definire una variabile globale statica per mantenere un riferimento al mio delegato dell'app per semplificare la vita.

Generalmente esiste una corrispondenza uno a uno tra istanze NSFetchedResultsController e istanze UITableView. A parte la visualizzazione delle tabelle, è estremamente raro che sia necessario un NSFetchedResultsController. Se si dispone di un numero di visualizzazioni simili (ad esempio una barra delle schede che consente di visualizzare gli stessi dati in modi diversi a l'app iPod), sarà necessario creare una singola classe base che configura lo NSFetchedResultsController e ricavare i controller di vista specifici. da quello.

Ora, quando si creano i controller di vista per modificare un oggetto, è generalmente consigliabile farlo in un contesto di oggetto gestito separato. Se l'utente annulla, basta semplicemente scartare il contesto e le modifiche spariscono. Anche in questo caso, non è necessario uno NSFetchedResultsController perché queste viste riguardano solo un singolo oggetto.

Al termine della modifica, è save: il contesto dell'oggetto gestito. Gli oggetti che gestiscono gli altri contesti degli oggetti gestiti devono implementare i metodi NSFetchedResultsControllerDelegate per mantenere sincronizzata la vista tabella. Di nuovo, questo può essere implementato in una classe base in modo da poter generalizzare questa funzionalità per i controller di vista correlati.

Answer 2

È assolutamente necessario utilizzare un modello CoreData o qualcosa che utilizza un NSCoder (NSArchiver, NSKeyedArchiver, ecc.) Funziona? Ho trovato che CoreData è eccessivo per la maggior parte delle applicazioni.

Inoltre, potresti chiarire il motivo per cui non puoi adottare un approccio utilizzando i singleton? Ho usato fabbriche singleton in un certo numero di applicazioni senza problemi. È abbastanza facile definire metodi a livello di classe che operano su un'istanza condivisa (singleton).