2013-03-08 6 views
6

Ho un'app che richiede internet per sincronizzare un webservice con un database locale di dati db. Quindi un db fetch locale viene utilizzato per popolare diversi oggetti per un MapView e un TableView in un tabbarcontroller. Sto guardando questi 2 scenari:Qual è il flusso di lavoro più efficace per questa app iOS?

AppFlowLogic

Il vantaggio principale di "A" è che non devo per precaricare l'applicazione con un database, anche se è un piccolo db (circa 100 registrazioni). Il problema è che viene contorto. Se non ci sono connessioni Internet, in MapView, l'utente vede una mappa ma il refreshButton è disabilitato. Quindi questo non è un problema. Ma l'utente può ancora andare al tableview e vedrà una tabella vuota.

Il vantaggio principale di "B" è che con un db precaricato, l'app avrà sempre un'origine dati pronta per la stampa e la quotazione. Non so davvero come precaricare l'app con un db però.

Mi piacerebbe passare il primo percorso, "A". La mia domanda principale è, dato che in questo momento ho disabilitato il refreshButton su MapView in modo che funzioni solo una volta che i dati sono stati ottenuti dal web ... che array ordinati è vuoto al momento del lancio. Quindi se l'utente va al TableVC sarà vuoto. Così com'è, l'utente deve prima toccare il pulsante di aggiornamento prima di andare al tableview.

Qual è il modo più efficace per affrontare questo?

+0

+1 bella spiegazione. – Dilip

+0

Casi di bordo, sono un tale dolore da codificare, ma sono così importanti per l'esperienza dell'utente. Penso che "A" sia la tua migliore opzione (la mia opinione). È possibile bloccare l'utilizzo dell'intera app con "È necessario scaricare i dati, ottenere una connessione Internet" se non si dispone di dati iniziali + nessuna connessione. È possibile scrivere codice per gestire lo scenario "nessun dato" su ogni schermata a cui l'utente può accedere quando non ha dati. La maggior parte delle tabelle contiene un caso "nessun dato" che aggiunge una riga che informa l'utente. La risposta migliore dipende dai casi e dai requisiti di utilizzo e solitamente è influenzata dalle preferenze personali. – DBD

+0

Grazie Dilip, vorrei davvero che ci fosse un modulo xcode per gestire la logica, per mostrarti cosa è in base al tuo codice perché Im molto visivo. DBD, anche se dovrei imparare come codificare per i primi scenari di lancio e così, penso che l'utente debba avere una connessione internet richiesta. Non sono così sicuro di bloccare l'intera app ma almeno lo scenario "nessun dato". Anche se, è essenzialmente la stessa cosa che bloccare l'intera app perché non vedranno nulla tranne la shell. Poi di nuovo, in termini di UX, è meglio lasciargli vedere qualcosa. Quindi sono perplesso :(Immagino di dover seguire la via difficile – marciokoko

risposta

2

Se i 100 record sono abbastanza statici da poter spedire un set predefinito di record con l'app, questa sarebbe la soluzione migliore. L'utente, con o senza internet, ottiene una vista tabella popolata.

Invia i tuoi record come un plist nel pacchetto della tua app. Al primo avvio, apri il plist e aggiungi ogni voce come un nuovo oggetto nei dati principali. Questo tipo di "semina" avviene molto rapidamente. È sufficiente creare una raccolta (array, dizionario) per il plist, quindi eseguire l'enumerazione, associandola agli attributi di ManagedObject.

C'è del codice che mostra come farlo nel video di WWDC 2012 iCloud e Core Data (ignora semplicemente la parte iCloud).

Quindi se c'è una connessione dopo il seeding, è possibile sincronizzare i dati, che aggiornerebbero/sostituiranno/etc i dati pre-compilati.

+0

Ok grazie per il dati precaricati I record sono fondamentalmente posizioni di negozi, un nuovo record viene aggiunto all'incirca ogni mese – marciokoko

+0

Quindi non posso spedirlo con un db Core Data precaricato? – marciokoko

+0

No. I dati principali aggiungono un sacco di tabelle e relazioni e tutti i tipi di cose speciali al database sqlite che possono essere eseguite solo quando si passano effettivamente i dati principali per farlo nella propria app. Fai attenzione a tutti i post del blog che ti mostrano il contrario! Ma non preoccuparti, la semina non è così male come potresti pensare. –