Sincronização de Dados Offline em Aplicações Móveis do Azure

2016-10-30

O que é a sincronização de dados offline?

A sincronização de dados offline é um recurso do SDK de cliente e servidor dos Aplicativos Móveis do Azure que facilita para os desenvolvedores a criação de aplicativos funcionais sem uma conexão de rede.

Quando seu aplicativo está no modo offline, você ainda pode criar e modificar dados, que são salvos em um repositório local. Quando o aplicativo estiver online novamente, ele poderá sincronizar alterações locais com o back-end do Aplicativo Móvel do Azure. O recurso também inclui suporte para detetar conflitos quando o mesmo registro é alterado no cliente e no back-end. Os conflitos podem então ser tratados no servidor ou no cliente.

A sincronização offline tem vários benefícios:

Melhore a capacidade de resposta do aplicativo armazenando em cache os dados do servidor localmente no dispositivo
Crie aplicativos robustos que permanecem úteis quando há problemas de rede
Permitir que os usuários finais criem e modifiquem dados mesmo quando não há acesso à rede, suportando cenários com pouca ou nenhuma conectividade
Sincronize dados em vários dispositivos e detete conflitos quando o mesmo registro é modificado por dois dispositivos
Limitar o uso em redes de alta latência ou com tarifação

Os tutoriais a seguir mostram como adicionar sincronização offline aos seus clientes móveis usando os Aplicativos Móveis do Azure:

O que é uma tabela de sincronização?

Para aceder ao endpoint "/tables", os SDKs de clientes móveis do Azure fornecem interfaces, tais como IMobileServiceTable (SDK do cliente .NET) ou MSTable (SDK do cliente iOS). Essas APIs se conectam diretamente ao back-end do Aplicativo Móvel do Azure e falham se o dispositivo cliente não tiver uma conexão de rede.

Para dar suporte ao uso offline, seu aplicativo deve, em vez disso, usar as APIs da tabela de sincronização , como IMobileServiceSyncTable (SDK do cliente .NET) ou MSSyncTable (cliente iOS). Todas as mesmas operações CRUD (Criar, Ler, Atualizar, Excluir) funcionam em APIs de tabela de sincronização, exceto agora elas leem ou gravam em um armazenamento local. Antes que qualquer operação de tabela de sincronização possa ser executada, o armazenamento local deve ser inicializado.

O que é uma loja local?

Um armazenamento local é a camada de persistência de dados no dispositivo cliente. Os SDKs de cliente de Aplicativos Móveis do Azure fornecem uma implementação de armazenamento local padrão. No Windows, Xamarin e Android, é baseado em SQLite. No iOS, ele é baseado em Core Data.

Para usar a implementação baseada em SQLite no Windows Phone ou na Microsoft Store, você precisa instalar uma extensão SQLite. Para obter mais informações, consulte Plataforma Universal do Windows: habilitar a sincronização offline. Android e iOS vêm com uma versão do SQLite no próprio sistema operacional do dispositivo, portanto, não é necessário fazer referência à sua própria versão do SQLite.

Os desenvolvedores também podem implementar sua própria loja local. Por exemplo, se você deseja armazenar dados em um formato criptografado no cliente móvel, você pode definir um armazenamento local que usa SQLCipher para criptografia.

O que é um contexto de sincronização?

Um contexto de sincronização é associado a um objeto de cliente móvel (como IMobileServiceClient ou MSClient) e controla as alterações feitas com tabelas de sincronização. O contexto de sincronização mantém uma fila de operações, que mantém uma lista ordenada de operações CUD (Criar, Atualizar, Excluir) que é enviada posteriormente ao servidor.

Um armazenamento local é associado ao contexto de sincronização usando um método de inicialização, como IMobileServicesSyncContext.InitializeAsync(localstore) no SDK do cliente .NET.

Como funciona a sincronização offline

Ao usar tabelas de sincronização, o código do cliente controla quando as alterações locais são sincronizadas com um back-end do Aplicativo Móvel do Azure. Nada é enviado para o back-end até que haja uma chamada para enviar as alterações locais. Da mesma forma, o armazenamento local é preenchido com novos dados somente quando há uma chamada para extrair dados.

Push: Push é uma operação no contexto de sincronização e envia todas as alterações CUD desde o último push. Observe que não é possível enviar apenas as alterações de uma tabela individual, porque caso contrário, as operações poderiam ser enviadas fora de ordem. O Push executa uma série de chamadas REST para o back-end do Aplicativo Móvel do Azure, que, por sua vez, modifica o banco de dados do servidor.
Pull: o pull é realizado por tabela e pode ser personalizado com uma consulta para recuperar apenas um subconjunto dos dados do servidor. Em seguida, os SDKs do cliente móvel do Azure inserem os dados resultantes no armazenamento local.
Pushes implícitos: Se um pull for executado numa tabela que tenha atualizações locais pendentes, o pull primeiro executará um no contexto de sincronização. Esse push ajuda a minimizar conflitos entre alterações que já estão na fila e novos dados do servidor.
Sincronização incremental: o primeiro parâmetro para a operação pull é um nome de consulta que é usado apenas no cliente. Se você usar um nome de consulta não nulo, o SDK Móvel do Azure executará uma sincronização incremental. Cada vez que uma operação pull retorna um conjunto de resultados, o carimbo de data/hora mais recente updatedAt desse conjunto de resultados é armazenado nas tabelas do sistema local do SDK. As operações pull subsequentes recuperam apenas registos após essa marca temporal.

Para usar a sincronização incremental, o servidor deve retornar valores significativos updatedAt e também deve oferecer suporte à classificação por esse campo. No entanto, como o SDK adiciona sua própria classificação no campo updatedAt, você não pode usar uma consulta pull que tenha sua própria orderBy cláusula.

O nome da consulta pode ser qualquer cadeia de caracteres que você escolher, mas deve ser exclusivo para cada consulta lógica em seu aplicativo. Caso contrário, operações de pull diferentes podem sobrescrever a mesma marca temporal de sincronização incremental e as suas consultas podem retornar resultados incorretos.

Se a consulta tiver um parâmetro, uma maneira de criar um nome de consulta exclusivo é incorporar o valor do parâmetro. Por exemplo, se você estiver filtrando em userid, seu nome de consulta pode ser o seguinte (em C#):
```
  await todoTable.PullAsync("todoItems" + userid,
      syncTable.Where(u => u.UserId == userid));
```
Se você quiser desativar a sincronização incremental, passe null como a ID da consulta. Nesse caso, em cada chamada para PullAsync, todos os registos são recuperados, o que é potencialmente ineficiente.
Limpeza: Você pode limpar o conteúdo do armazenamento local usando IMobileServiceSyncTable.PurgeAsync. A limpeza pode ser necessária se você tiver dados obsoletos no banco de dados do cliente ou se desejar descartar todas as alterações pendentes.

Uma limpeza limpa uma mesa da loja local. Se houver operações aguardando sincronização com a base de dados do servidor, a purga lança uma exceção, a menos que o parâmetro force purge esteja definido.

Como um exemplo de dados obsoletos no cliente, suponha que no exemplo da "lista de afazeres", o Device1 só extrai itens que não foram concluídos. Um todoitem "Comprar leite" é marcado como concluído no servidor por outro dispositivo. No entanto, o Device1 ainda tem o todoitem "Comprar leite" na loja local porque está apenas puxando itens que não estão marcados como completos. Uma limpeza limpa este item obsoleto.

Partilhar via