Domanda sul modo ottimale di organizzare i dati per un'app per iPhone simile a un libro

Question

Vorrei iniziare a lavorare su un'app per iPhone che non faccia altro che visualizzare il contenuto di un libro da leggere.Il contenuto del libro è disponibile online ed è completamente open source, ma vorrei renderlo disponibile localmente.Con le app su cui ho lavorato in precedenza, in particolare con iPhone OS 2.X, creare (o trovare) un database .sql e quindi eseguire semplicemente query per i dati dall'interno dell'app ha funzionato davvero bene.Con l'avvento di Core Data (con cui non ho molta familiarità) il vecchio metodo SQL potrebbe non essere l'ideale.Quindi la mia domanda è:Qual è il modo migliore per passare dai contenuti Web online ai contenuti leggibili sull'iPhone archiviati localmente?Indipendentemente dall'approccio che adotto, avrò bisogno di un db (giusto?), quindi dovrei togliermene di mezzo il peso e iniziare con l'importazione del contenuto web in un db con tutte le tabelle e le colonne corrette?Immagino che con questa domanda sto solo cercando un punto nella giusta direzione.Se ci fossero suggerimenti sul metodo migliore per iniziare, sarebbe molto apprezzato.Grazie!

Answer 1

Core Data è utile se hai "oggetti" che vuoi rendere persistenti.Nel caso in cui si abbiano molti dati da leggere/scrivere, il vecchio SQLite potrebbe essere più semplice.

Mi dispiace di non poter dare consigli più specifici, ma dipende da quanto sono complicati il ​​modello dati e i modelli oggetto della tua app.Consiglierei di guardare Core Data, ma non usarlo solo perché tutti ti dicono quanto è bello.

Se scegli Core Data, non definirai il tuo schema di database SQL, quindi non iniziare questo percorso finché non avrai preso la decisione.

Answer 2

In realtà seguirei il percorso dei dati di base. I dati principali sono solo un'API fornita da Apple per gestire i dati persistenti indipendentemente dal backend di dati (se è un file plist piatto, un file XML o un file di database SQLite completo).

Nel caso di un libro, puoi abbattere le entità come segue.

Entità del libro

• Titolo che è un attributo stringa
• Autore che è un attributo stringa
• Capitoli che è un rapporto tra entità capitolari

Capitolo

• Titolo che è un attributo stringa
• pagine che è una relazione tra entità di pagina

Entità pagina

• PagEText che è un attributo stringa

Quindi puoi accedere a tutti i valori come se fossero oggetti che utilizzano i dati core senza doversi preoccupare del codice backend SQL e scrivere tutto il codice per tradurre i dati di SQLite su oggetti di cacao che i controller di visualizzazione possono visualizzare.