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

  • Artigo

O que é sincronização de dados offline?

Offline data sync é uma funcionalidade SDK de cliente e servidor de Aplicações Móveis Azure que facilita aos desenvolvedores criar aplicações que são funcionais sem uma ligação de rede.

Quando a sua aplicação está em modo offline, ainda pode criar e modificar dados, que são guardados numa loja local. Quando a aplicação está novamente online, pode sincronizar as alterações locais com o backend da Azure Mobile App. A funcionalidade também inclui suporte para detetar conflitos quando o mesmo registo é alterado tanto no cliente como no backend. Os conflitos podem então ser tratados no servidor ou no cliente.

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

  • Melhorar a capacidade de resposta da aplicação ao caching dados do servidor localmente no dispositivo
  • Criar aplicações robustas que permanecem úteis quando há problemas de rede
  • Permitir que os utilizadores finais criem e modifiquem dados mesmo quando não há acesso à rede, suportando cenários com pouca ou nenhuma conectividade
  • Sincronizar dados em vários dispositivos e detetar conflitos quando o mesmo registo é modificado por dois dispositivos
  • Limitar a utilização da rede em redes de alta latência ou de contadores

Os seguintes tutoriais mostram como adicionar sincronização offline aos seus clientes móveis usando aplicações Azure Mobile:

O que é uma mesa de sincronização?

Para aceder ao ponto final "/tabelas", os SDKs clientes Azure Mobile fornecem interfaces como IMobileServiceTable (.cliente NET SDK) ou MSTable (cliente iOS). Estas APIs ligam-se diretamente ao backend da Azure Mobile App e falham se o dispositivo cliente não tiver uma ligação de rede.

Para suportar a utilização offline, a sua aplicação deve, em vez disso, utilizar as APIs de tabela sincronizada , tais como IMobileServiceSyncTable (.CLIENTE NET SDK) ou MSSyncTable (cliente iOS). Todas as mesmas operações CRUD (Criar, Ler, Atualizar, Excluir) funcionam contra APIs de tabela sincronizada, exceto agora que lêem ou escrevem para uma loja local. Antes de qualquer sincronização de operações de mesa, a loja local deve ser inicializada.

O que é uma loja local?

Uma loja local é a camada de persistência de dados no dispositivo cliente. Os SDKs clientes Azure Mobile Apps fornecem uma implementação padrão da loja local. No Windows, Xamarin e Android, é baseado no SQLite. No iOS, baseia-se em Dados Core.

Para utilizar a implementação baseada em SQLite em Windows Phone ou Microsoft Store, é necessário instalar uma extensão SQLite. Para obter mais informações, consulte Plataforma Universal do Windows: Ative a sincronização offline. O Android e o iOS enviam uma versão do SQLite no próprio sistema operativo do dispositivo, pelo que não é necessário fazer referência à sua própria versão do SQLite.

Os desenvolvedores também podem implementar a sua própria loja local. Por exemplo, se desejar armazenar dados num formato encriptado no cliente móvel, pode definir uma loja local que utiliza o SQLCipher para encriptação.

O que é um contexto de sincronização?

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

Uma loja local está associada ao contexto de sincronização utilizando um método de inicialização, como IMobileServicesSyncContext.InitializeAsync(localstore) no cliente .NET SDK.

Como funciona a sincronização offline

Ao utilizar tabelas de sincronização, o código do cliente controla quando as alterações locais são sincronizadas com um backend da Azure Mobile App. Nada é enviado para o backend até que haja uma chamada para empurrar as mudanças locais. Da mesma forma, a loja local é povoada com novos dados apenas quando há uma chamada para retirar dados.

  • Push: Push é uma operação no contexto de sincronização e envia todas as alterações cud desde o último empurrão. Note que não é possível enviar apenas as alterações de uma tabela individual, pois caso contrário as operações poderiam ser enviadas fora de ordem. Push executa uma série de chamadas REST para o backend da App Azure Mobile, que por sua vez modifica a base de dados do servidor.

  • Pull: Pull é realizado numa base por tabela e pode ser personalizado com uma consulta para recuperar apenas um subconjunto dos dados do servidor. Os SDKs clientes Azure Mobile inserem os dados resultantes na loja local.

  • Impulsos Implícitos: Se um puxão for executado contra uma tabela que tenha atualizações locais pendentes, o puxão executa primeiro um push() no contexto de sincronização. Este impulso ajuda a minimizar os conflitos entre as 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 utilizar um nome de consulta não nulo, o Azure Mobile SDK executa uma sincronização incremental. Cada vez que uma operação de puxar retorna um conjunto de resultados, o último updatedAt relógio deste conjunto de resultados é armazenado nas tabelas do sistema local SDK. As operações de atração subsequentes só recuperam registos após o tempo de estamp.

    Para utilizar sincronização incremental, o seu servidor deve devolver valores significativos updatedAt e também apoiar a triagem por este campo. No entanto, uma vez que o SDK adiciona o seu próprio tipo no campo DeAt atualizado, não é possível utilizar uma consulta de puxar que tenha a sua própria orderBy cláusula.

    O nome de consulta pode ser qualquer string que escolher, mas deve ser único para cada consulta lógica na sua aplicação. Caso contrário, diferentes operações de puxar podem substituir o mesmo tempo de sincronização incremental e as suas consultas podem devolver resultados incorretos.

    Se a consulta tem um parâmetro, uma maneira de criar um nome de consulta único é incorporar o valor do parâmetro. Por exemplo, se estiver a filtrar o userid, o seu nome de consulta pode ser o seguinte (em C#):

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

    Se quiser optar por uma sincronização incremental, passe null como ID de consulta. Neste caso, todos os registos são recuperados em cada chamada para PullAsync, o que é potencialmente ineficiente.

  • Purga: Pode limpar o conteúdo da loja local utilizando IMobileServiceSyncTable.PurgeAsync. A purga pode ser necessária se tiver dados antigos na base de dados do cliente, ou se pretender descartar todas as alterações pendentes.

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

    Como exemplo de dados antigos sobre o cliente, suponha que no exemplo da "lista de todos", o Device1 apenas puxa itens que não estão concluídos. Um todoitem "Comprar leite" é marcado no servidor por outro dispositivo. No entanto, o Device1 ainda tem o todoitem "Comprar leite" na loja local porque está apenas a puxar itens que não estão marcados como completos. Uma purga limpa este item velho.

Passos seguintes