Modello di progettazione per l'app Core Data iPhone

Question

Sto creando un'app che utilizzerà un modello di dati di base. Sono piuttosto nuovo all'Obiettivo C e i miei soliti schemi di progettazione non si applicano davvero ai Core Data e all'Obiettivo C, almeno non riesco a trovare esempi che confermino che lo faranno.

Ho esaminato gli esempi di Apple Developer e diverse fonti sugli intertubes.

Sembra che per sfruttare i Core Data sia necessario passare il managedObjectContext a ciascuno dei miei viewController, avere il viewController implementare NSFetchedResultsControllerDelegate e quindi implementare ciascuno dei metodi per eseguire un recupero e successivamente implementare

NSFetchedResultsChangeInsert

NSFetchedResultsChangeDelete  NSFetchedResultsChangeMove  NSFetchedResultsChangeUpdate

Questo aggiunge circa 100+ righe di codice in ogni viewController ed è il 90% dello stesso codice che scrivo ancora e ancora. Inoltre devo passare tutto e tenere traccia della sua impronta di memoria.

In altre lingue avrei creato un modello singleton di alcune classi che conteneva metodi per mantenere e distribuire dati su richiesta, disponibili da qualsiasi luogo. Sembra che non riesca ad adottare questo approccio nell'Obiettivo C. Se dovessi costruire una classe statica che prendesse un managedObjectContext e mi restituisse ciò di cui avevo bisogno, avrei comunque dovuto passare il managedObjectContext in ogni vista e non sarebbe come in modo asincrono quando implemento metodi delegati che vengono appena chiamati quando un risultato è pronto.

Spero che questo abbia senso e che qualcuno possa confermare che non esiste un altro modo ragionevole per farlo o aiutarmi a indicarmi una direzione per concludere in modo positivo.

Grazie:)

Answer 1

I dati di base non sono così complicati come li descrivi.

Generalmente, un'app per iPhone ha un " principale " contesto degli oggetti gestiti, generalmente di proprietà del delegato dell'app. Finché è possibile ottenere il delegato dell'app (suggerimento: [[UIApplication sharedApplication] delegate] ) si ha accesso al contesto dell'oggetto gestito. Mi piace definire una variabile globale statica per contenere un riferimento al delegato della mia app per semplificare la vita.

Esiste generalmente una corrispondenza uno a uno tra le istanze NSFetchedResultsController e le istanze UITableView . A parte il popolamento delle viste delle tabelle, è estremamente raro che tu abbia bisogno di un NSFetchedResultsController . Se hai un numero di visualizzazioni simili (ad esempio una barra delle schede che ti consente di visualizzare gli stessi dati in diversi modi sull'app per iPod), ti consigliamo di creare una singola classe di base che configura NSFetchedResultsController e da ciò derivano i controller di visualizzazione specifici.

Ora, quando crei controller di visualizzazione per modificare un oggetto, è generalmente una buona idea farlo in un contesto di oggetto gestito separato. Se l'utente annulla, basta scartare il contesto e le modifiche scompaiono. Ancora una volta, non hai davvero bisogno di un NSFetchedResultsController perché queste viste riguardano solo un singolo oggetto.

Al termine della modifica, salva: 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 della tabella. Ancora una volta, questo può essere implementato in una classe base in modo da poter generalizzare questa funzionalità per i controller di vista correlati.

Answer 2

Devi assolutamente usare un modello CoreData o funzionerebbe qualcosa usando un NSCoder (NSArchiver, NSKeyedArchiver, ecc.)? Ho scoperto che CoreData è eccessivo per la maggior parte delle applicazioni.

Inoltre, potresti chiarire perché non riesci ad adottare un approccio usando i singoli? Ho usato fabbriche singleton in una serie di applicazioni senza problemi. È abbastanza facile definire metodi a livello di classe che operano su un'istanza condivisa (singleton).