Design per la sincronizzazione dei dati in Android


23

Ho visto due implementazioni per la sincronizzazione dei dati tra il server e il client sulla maggior parte delle app. Ciò presuppone che non sia stato impostato alcun GCM: -

  1. Esecuzione periodica di un servizio di intento che scarica i dati dalla rete e li archivia nel database.
  2. Implementazione di un adattatore di sincronizzazione che viene eseguito periodicamente.

Quale delle precedenti raccomandazioni consiglieresti di avere nella tua app e perché?

Risposte:


12

Nota: gli adattatori di sincronizzazione vengono eseguiti in modo asincrono, quindi è necessario utilizzarli con l'aspettativa che trasferiscano i dati in modo regolare ed efficiente, ma non istantaneamente. Se è necessario eseguire il trasferimento dei dati in tempo reale, è necessario farlo in un AsyncTask o in un IntentService. - fonte .

Fondamentalmente, se hai bisogno di un trasferimento in tempo reale usa IntentService (la prima opzione), altrimenti SyncAdapter. Preferisco un IntentService perché sembra più personalizzabile, ma un approccio più banale sarebbe usare un SyncAdapter.


18

Dipende fortemente dal tipo di sincronizzazione di cui hai bisogno.

periodico

Se la tua app è un'app di notizie che pubblica post ogni giorno a una determinata ora (diciamo alle 7.45 ogni giorno), allora esegui un'attività periodica in un servizio in background, diciamo alle 8:00.

ad es . : Drippler. Mi avvisano una volta al giorno (intorno alle 18.30). Credo che usano un compito periodico.

Evento attivato

Se il trasferimento dei dati è attivato dall'azione dell'utente, utilizzare un servizio in background o un AsyncTask per il trasferimento dei dati.

ad es . : DropBox / Evernote. Si sincronizzano quando interagisco con l'app.

Istantaneo

Se la tua app esegue messaggistica istantanea / mail / aggiornamenti importanti non periodici , allora hai bisogno di notifiche push, perché vuoi avvisare immediatamente l'utente. Utilizzare GCM o Parse per questo caso. ad esempio: chat di WhatsApp / Google. Dato che hai esplicitamente menzionato che non vuoi usare GCM, ti dirò perché dovresti usare un provider di notifiche push standard invece di scrivere il tuo:

Le notifiche push funzionano istantaneamente: il ritardo è molto ridotto (nell'ordine dei secondi, raramente dei minuti). Se dovessi implementare la tua soluzione / libreria per farlo - in un modello ingenuo, esegui il ping del server ogni secondo o 5 secondi o un minuto per verificare lo stato. Questo è molto inefficiente in quanto consuma CPU (e quindi batteria), larghezza di banda sul cellulare e carico sul server. Tuttavia, in GCM / Parse, mantengono sempre una porta aperta con il server (vedi qui ). Questo è il modo standard ed efficiente. Inoltre, se 10 app utilizzano GCM, non sono necessarie 10 connessioni aperte, ma ne serve solo una per dispositivo. E davvero non vuoi sviluppare la tua soluzione se non hai un motivo / fondi / tempo validi per farlo.

Nota sull'adattatore di sincronizzazione: l' adattatore di sincronizzazione funziona bene per tutti e tre i casi precedenti. Controlla Esecuzione di un adattatore di sincronizzazione e vedrai che dipende da GCM o dal tuo meccanismo (trigger di evento o soluzione personalizzata) o dalla disponibilità di rete (trigger di evento) o evento periodico. Tutto sommato, questa è una buona classe conveniente per sincronizzare i dati senza dover fare ogni volta un lungo elenco di inizializzazioni o implementare tutti i casi di cui sopra in un unico posto.


Come domanda estesa, se devo aggiornare i risultati in diretta di una partita, lo scenario istantaneo è quello giusto per questo contesto? Ho una schermata con i dettagli della partita e mentre l'utente è su quella schermata, i punteggi dovrebbero essere automaticamente aggiornati senza sincronizzazione o aggiornamento manuale. Quindi gcm sarebbe il giusto passo avanti?
gaara87,

@AkashRamani Non vedo un motivo per cui non dovresti usare GCM / Parse per questo caso. Tuttavia, GCM è gratuito mentre Parse ti addebita oltre un certo punto. Se i tuoi aggiornamenti sono entro 4096 byte, puoi inviarlo direttamente. Se gli aggiornamenti dei tuoi punteggi sono molto frequenti, il polling potrebbe essere una buona idea anziché GCM (diciamo, per i punteggi di cricket). Suggerirei di testare / profilare sia polling che GCM per latenza e consumo di CPU / batteria.
Sundeep

AWS ha anche una soluzione di notifica che è multipiattaforma e cross market. Vedi: docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html
Brill Pappin

3

C'è un aspetto di un SyncAdapterche non è stato menzionato dalle altre risposte.

Il SyncAdaptermodello richiede che si disponga di un'autorizzazione ContentProvider specifica con cui si sincronizza e un tipo di account specifico (consultare Autenticatore ) che verrà sincronizzato. Pertanto, a meno che non si disponga già di tali componenti nella propria architettura (ad es. Perché si consente ad altre app di accedere ai propri dati o non è necessario supportare gli account), si SyncAdapterotterrà un notevole sovraccarico di implementazione.


2

Quando si tratta di sincronizzare i dati che coinvolgono la connettività, si vorrebbe poter scalare anche. Credo che il modo consigliato per farlo sia usare l'adattatore di sincronizzazione.

Sembra anche essere così se dai un'occhiata alla guida al traning di Android: Creazione di un adattatore di sincronizzazione

Il componente dell'adattatore di sincronizzazione nella tua app incapsula il codice per le attività che trasferiscono i dati tra il dispositivo e un server. In base alla pianificazione e ai trigger forniti nella tua app, il framework dell'adattatore di sincronizzazione esegue il codice nel componente dell'adattatore di sincronizzazione ...


2

Gli adattatori di sincronizzazione devono essere utilizzati a meno che non siano necessari dati in tempo reale perché, Automatizza il trasferimento di dati in base a una varietà di criteri, come le modifiche ai dati, il tempo trascorso, l'ora del giorno, ecc. Centralizza tutti i trasferimenti di dati in modo che il trasferimento dei dati venga eseguito insieme a trasferimenti di dati da altre app, il che riduce l'utilizzo della batteria.

Per le attività istantanee possiamo usare,

AsyncTask per attività di breve durata, può essere 3-4 secondi.

IntentService per attività di lunga durata.


Ottima ripartizione per le scelte della regola empirica.
Brill Pappin,

0

Dal momento che stiamo parlando di design, dovremmo menzionare la gestione di SyncAdapters, l'oggetto SyncResult e cosa succede dopo.

In realtà uso un SyncAdapter per dire alla mia libreria di effettuare chiamate Web IntentService sul mio server. La gestione di questa operazione di "sincronizzazione" è complicata.

Un approccio che sto adottando ora è quello di rinunciare completamente all'oggetto SyncResult e utilizzare semplicemente un servizio per registrare i risultati di ogni singolo "Sync"

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.