Condividi tramite

Sincronizzazione dei dati offline nelle app per dispositivi mobili di Azure

Che cos'è la sincronizzazione dei dati offline?

La sincronizzazione dei dati offline è una funzionalità SDK client e server di App per dispositivi mobili di Azure che semplifica per gli sviluppatori la creazione di app funzionali senza una connessione di rete.

Quando l'app è in modalità offline, è comunque possibile creare e modificare i dati, che vengono salvati in un archivio locale. Quando l'app è di nuovo online, può sincronizzare le modifiche locali con il back-end dell'app per dispositivi mobili di Azure. La funzionalità include anche il supporto per il rilevamento dei conflitti quando lo stesso record viene modificato sia nel client che nel back-end. I conflitti possono quindi essere gestiti nel server o nel client.

La sincronizzazione offline offre diversi vantaggi:

  • Migliorare la velocità di risposta dell'app memorizzando nella cache i dati del server in locale nel dispositivo
  • Creare app affidabili che rimangono utili in caso di problemi di rete
  • Consentire agli utenti finali di creare e modificare i dati anche quando non è disponibile alcun accesso alla rete, supportando scenari con connettività scarsa o assente
  • Sincronizzare i dati tra più dispositivi e rilevare conflitti quando lo stesso record viene modificato da due dispositivi
  • Limitare l'uso della rete su reti a latenza elevata o con tariffazione a consumo

Le esercitazioni seguenti illustrano come aggiungere la sincronizzazione offline ai client per dispositivi mobili usando App per dispositivi mobili di Azure:

Che cos'è una tabella di sincronizzazione?

Per accedere all'endpoint "/tables", gli SDK client per dispositivi mobili di Azure forniscono interfacce come IMobileServiceTable (SDK client.NET) o MSTable (client iOS). Queste API si connettono direttamente al back-end dell'app per dispositivi mobili di Azure e hanno esito negativo se il dispositivo client non dispone di una connessione di rete.

Per supportare l'uso offline, l'app deve usare invece le API della tabella di sincronizzazione , ad esempio IMobileServiceSyncTable (SDK client.NET) o MSSyncTable (client iOS). Tutte le stesse operazioni CRUD (Create, Read, Update, Delete) funzionano con le API della tabella di sincronizzazione, tranne che ora leggono o scrivono in un archivio locale. Prima di eseguire qualsiasi operazione della tabella di sincronizzazione, è necessario inizializzare l'archivio locale.

Che cos'è un negozio locale?

Un archivio locale è il livello di persistenza dei dati nel dispositivo client. Gli SDK client per le app mobili di Azure offrono un'implementazione predefinita dell'archivio locale. In Windows, Xamarin e Android si basa su SQLite. In iOS si basa su Core Data.

Per usare l'implementazione basata su SQLite in Windows Phone o Microsoft Store, è necessario installare un'estensione SQLite. Per altre informazioni, vedere Piattaforma UWP (Universal Windows Platform: Abilitare la sincronizzazione offline). Android e iOS vengono forniti con una versione di SQLite nel sistema operativo del dispositivo stesso, quindi non è necessario fare riferimento alla propria versione di SQLite.

Gli sviluppatori possono anche implementare il proprio archivio locale. Ad esempio, se si desidera archiviare i dati in un formato crittografato nel client mobile, è possibile definire un archivio locale che usa SQLCipher per la crittografia.

Che cos'è un contesto di sincronizzazione?

Un contesto di sincronizzazione è associato a un oggetto client mobile (ad esempio IMobileServiceClient o MSClient) e tiene traccia delle modifiche apportate con le tabelle di sincronizzazione. Il contesto di sincronizzazione gestisce una coda di operazioni, che mantiene un elenco ordinato di operazioni CUD (Create, Update, Delete) che viene successivamente inviato al server.

Un archivio locale è associato al contesto di sincronizzazione usando un metodo di inizializzazione, IMobileServicesSyncContext.InitializeAsync(localstore) ad esempio in .NET Client SDK.

Funzionamento della sincronizzazione offline

Quando si usano tabelle di sincronizzazione, il codice client controlla quando le modifiche locali vengono sincronizzate con un back-end dell'app per dispositivi mobili di Azure. Nulla viene inviato al back-end finché non viene eseguita una chiamata per eseguire il push delle modifiche locali. Analogamente, l'archivio locale viene popolato con nuovi dati solo quando è presente una chiamata per eseguire il pull dei dati.

  • Push: il push è un'operazione nel contesto di sincronizzazione e invia tutte le modifiche CUD dall'ultimo push. Si noti che non è possibile inviare solo le modifiche di una singola tabella, perché in caso contrario è possibile inviare operazioni non in ordine. Il push esegue una serie di chiamate REST al back-end dell'app per dispositivi mobili di Azure, che a sua volta modifica il database del server.

  • Pull: il pull viene eseguito per ogni tabella e può essere personalizzato con una query per recuperare solo un subset dei dati del server. Gli SDK client per dispositivi mobili di Azure inseriscono quindi i dati risultanti nell'archivio locale.

  • Push impliciti: se un pull viene eseguito su una tabella con aggiornamenti locali in sospeso, il pull esegue prima un oggetto push() nel contesto di sincronizzazione. Questo push consente di ridurre al minimo i conflitti tra le modifiche già accodate e i nuovi dati dal server.

  • Sincronizzazione incrementale: il primo parametro dell'operazione pull è un nome di query usato solo nel client. Se si usa un nome di query non Null, Azure Mobile SDK esegue una sincronizzazione incrementale. Ogni volta che un'operazione pull restituisce un set di risultati, il timestamp più recente updatedAt da tale set di risultati viene archiviato nelle tabelle di sistema locali dell'SDK. Le operazioni pull successive recuperano solo i record dopo tale timestamp.

    Per usare la sincronizzazione incrementale, il server deve restituire valori significativi updatedAt e supportare anche l'ordinamento in base a questo campo. Tuttavia, poiché l'SDK aggiunge il proprio ordinamento nel campo updatedAt, non è possibile usare una query pull con la propria clausola orderBy.

    Il nome della query può essere qualsiasi stringa scelta, ma deve essere univoco per ogni query logica nell'app. In caso contrario, diverse operazioni pull potrebbero sovrascrivere lo stesso timestamp di sincronizzazione incrementale e le query possono restituire risultati non corretti.

    Se la query ha un parametro, un modo per creare un nome di query univoco consiste nell'incorporare il valore del parametro. Ad esempio, se si filtra l'id utente, il nome della query può essere il seguente (in C#):

      await todoTable.PullAsync("todoItems" + userid,
      syncTable.Where(u => u.UserId == userid));

    Se si vuole rifiutare esplicitamente la sincronizzazione incrementale, passare null come ID query. In questo caso, tutti i record vengono recuperati in ogni chiamata a PullAsync, che è potenzialmente inefficiente.

  • Eliminazione: è possibile cancellare il contenuto dell'archivio locale usando IMobileServiceSyncTable.PurgeAsync. L'eliminazione potrebbe essere necessaria se sono presenti dati non aggiornati nel database client o se si desidera eliminare tutte le modifiche in sospeso.

    Una rimozione cancella una tabella dalla memoria locale. Se sono presenti operazioni in attesa di sincronizzazione con il database del server, l'eliminazione genera un'eccezione a meno che non sia impostato il parametro force purge .

    Come esempio di dati non aggiornati nel client, si supponga che nell'esempio "elenco delle cose da fare" Device1 recuperi solo gli elementi non completati. Un elemento todoitem "Buy milk" viene contrassegnato come completato nel server da un altro dispositivo. Tuttavia, Device1 ha ancora l'attività "Acquista latte" nel negozio locale poiché sta recuperando solo gli elementi che non sono contrassegnati come completati. Una purga elimina questo elemento obsoleto.

Passaggi successivi

  • Last updated on