dati delle applicazioni mobili gestione

Question

La mia domanda circonda circa un unico punto - la gestione dei dati in applicazioni mobili . Ho creato un'applicazione mobile in cui i dati provengono dal server. I dati includono sia testo che immagini. Di seguito sono riportati i passi che sto facendo per questo:

Primo lancio:
1. dati del server Get.
2. Salvare i dati del server nel database Sqlite.
3. Mostra dati Sqlite.

Prossime lanci:
1. Mostra dati Sqlite.
2. Ottieni i dati del server in background.
3. Eliminare i dati Sqlite precedenti.
4. Salvare i nuovi dati del server nel database Sqlite.
5. Mostra dati Sqlite.

Ho paio di domande su questi passaggi: 1.
È questo l'approccio giusto? Un altro modo potrebbe mostrare i dati ogni volta dal server ma ciò non visualizzerebbe immediatamente i dati sullo schermo (a seconda della velocità di internet).
2. Ho anche pensato di confrontare i dati Sqlite con i nuovi dati del server. Ma ha affrontato una grande sfida. I nuovi dati del server potrebbero avere nuovi record o record cancellati. Inoltre, non sono riuscito a trovare un approccio appropriato per confrontare ogni campo del database con i dati JSON.
Così Qual è l'approccio migliore per confrontare Sqlite dati locali con i nuovi dati del server?
3. Ogni volta che cancellare i dati Sqlite e inserire nuovi dati e quindi aggiornare la schermata (che ha un UITableView), lampeggia per un secondo che è ovvio. Come evitare questo problema se i passaggi 3, 4, 5 sono seguiti?
4. Come dovrei procedere con l'aggiornamento dei dati nel caso in cui torno sullo schermo ogni volta o quando l'applicazione diventa attiva? Sono molto consapevole di NSOperationQueues o di utilizzare GCD per quella materia. Ma cosa succede se sono pazzo e andare avanti e indietro per lo schermo ancora e ancora. Ci sarà un numero di NSOperations nella coda.

Answer 1

È una sfida sincronizzare i dati del server, l'ho già fatto in precedenza e, se riesci a trascorrere del tempo, direi che è la soluzione migliore.

potrebbe essere necessario la creazione e le date di modifica su oggetti sia server e locali, per confrontarli - questo vi permetterà di decidere quali oggetti da aggiungere, aggiornare e cancellare. Se il server invia solo gli oggetti aggiornati di recente, è possibile risparmiare molto traffico e migliorare le prestazioni (ma gli oggetti eliminati saranno più difficili da rilevare).

Se i dati vengono modificati solo nel server, è più semplice, quando l'app può modificare anche i dati diventa più complicato (ma sembra che non sia il tuo caso). Dipende anche da quanto sia complesso il database, ovviamente.

Se non si vuole investire un po 'di tempo nel fare ciò, anche il recupero di tutti i dati ogni volta funziona anche se non è l'ideale! Invece di mostrare i vecchi dati e lampeggiare, puoi semplicemente far aspettare all'utente 2-3 secondi durante l'immissione, mentre ottieni i nuovi dati.O invece puoi recuperare i dati solo quando avvii l'app, e così quando arrivi a quel controller di visualizzazione sarà già pronto.

Si tratta di un problema complesso che tutti volti ad un certo punto, quindi sono curioso di vedere quello che gli altri vi suggerirà :)

Answer 2

ne dite di questo:

1. Se esiste dati in SqlLite, carico in "in-memory" copia da mostrare
2. in carico sfondo nuovi dati del server
3. cancellare i vecchi dati SQLite se esiste (si noti che l'in-memory copia rimane)
4. salvare nuovi server di dat a to sqlite
5. carica nuovi dati sqlite nella copia "in-memory" e mostrali.

Se nessun dato è stato trovato nel passaggio 1, visualizzare un "loading" schermo per l'utente durante la fase 2.

Sto facendo l'ipotesi che i dati da SqlLite è abbastanza piccolo per mantenere una copia in memoria da mostrare nella vista UITable (la vista UITable mostra sempre i dati dalla memoria).

Potrebbe essere possibile combinare i passaggi 4 e 5 se i dati sono abbastanza piccoli da contenere contemporaneamente due copie in memoria (si creerà una nuova copia in memoria e si scambierà con la copia visibile una volta completata).

Nota: Non parlo di gestione degli errori qui, ma suggerisco di non eliminare i dati sqlite finché non si hanno nuovi dati con cui sostituirli.

Questo approccio elimina anche la necessità di determinare se questo è il primo avvio o meno. La logica rimane sempre la stessa che dovrebbe renderlo un po 'più facile da implementare.

Spero che questo sia utile.

Answer 3

È possibile fare le stesse cose in modo più efficiente da MultiVersion Concurrency Control (MVCC), che utilizza un contatore (una sorta di "data/ora" molto semplice) per ogni record di dati, che viene aggiornato ogni volta che il record viene modificato significa che è necessario per ottenere quei dati che sono aggiornati dopo l'ultima chiamata di sincronizzazione che riduce molti dati ridondanti e larghezza di banda.

Fonte: MultiVersion Concurrency Control

Answer 4

Questa è una buona domanda.

Personalmente penso che scaricare dati, archiviare localmente e successivamente provare a sincronizzarsi sia uno scenario pericoloso. Facile introdurre bug, padroneggiare < - problemi> slave (quali dati dovrebbe essere padrone, se i dispositivi multipli sarebbero stati utilizzati, ecc)

penso che qualcosa di simile potrebbe essere un approccio di lavoro:

1. Proverò a cercare le possibilità di scaricare i dati dal server su richiesta. Quello è quando un utente ha una vista che dovrebbe visualizzare i dati, caricare quei dati specifici con la creazione di quella specifica vista. Ciò garantisce che i dati siano sempre sincronizzati.

2. Affrontare la necessità di ricaricare i dati dal server da ogni vista, potrebbe essere fatto semplicemente memorizzando i dati scaricati come oggetti in memoria (non usando SqlLite).La vista proverà a caricare i dati necessari attraverso il gestore della cache e la utilizzerà dalla memoria, se disponibile. Se non è in memoria, recupera semplicemente i dati dal tuo server e aggiungili alla memoria cache. La memoria cache potrebbe essere un gestore dati home made che include uno AppDelegate memorizzato su AppDelegate o un altro "Singelton" globale per disporre la gestione/memorizzazione della cache e il caricamento dei dati.

3. 3. Con i dati caricati e la memoria cache pigri, è necessario assicurarsi che eventuali aggiornamenti (modifiche, nuovi record, record eliminati) aggiornino il modello dei dati di memoria e che tali modifiche vengano apportate al server non appena possibile. A seconda delle dimensioni dei dati, ecc. Potresti costringere l'utente ad aspettare, o farlo direttamente come processo in background.

4. 4. Per garantire che i dati siano sincronizzati, è necessario assicurarsi di invalidare (eliminare) periodicamente i record di memoria locale nella cache e quindi forzare gli aggiornamenti dei dati dal server. L'approccio migliore sarebbe probabilmente avere un ultimo timestamp aggiornato per ogni record nella memoria cache. Quindi l'invalidatore periodico eliminerebbe solo "vecchi record" dalla memoria cache (ancora una volta non dal server).

Per salvare il server da un carico di dati non necessario, i dati dovrebbero comunque essere caricati su richiesta quando l'utente ne ha bisogno in una vista e non come parte di "invalidazione cache".

5. A seconda delle dimensioni dei dati, potrebbe essere necessario visualizzare "invalidazione cache". Potrebbe essere semplice come quando vengono archiviati i record xx, iniziare a cancellare vecchi oggetti dalla cache di memoria (non dal server, solo localmente sul dispositivo).

6. Se la sincronizzazione dei dati è assolutamente critica, è possibile che si desideri esaminare la cache di memoria per un record, appena prima di consentire all'utente di modificare i dati. Per esempio. quando l'utente tocca "Modifica" o simili, acquisisci gli ultimi dati dal server per quel record. Questo è solo per assicurarsi che l'utente non ha intenzione di aggiornare un record utilizzando i dati obsoleti e quindi accidentalmente ignorando le eventuali modifiche apportate a distanza, o su un altro dispositivo, ecc

-

mio prendere su di esso. Non credo che ci sia un "perfetto modo giusto" per farlo. Ma questo sarebbe quello che proverei a fare.

Spero che questo aiuti con alcune idee e ispirazione.