Design para sincronizar dados no Android

Vi duas implementações para sincronizar dados entre o servidor e o cliente na maioria dos aplicativos. Isso pressupõe que nenhum GCM esteja configurado: -

1. Executando um serviço de intenção periodicamente, que baixa os dados da rede e armazena no banco de dados.
2. Implementando um adaptador de sincronização que é executado periodicamente.

Qual das opções acima você recomendaria ter no seu aplicativo e por quê?

Nota: Os adaptadores de sincronização são executados de forma assíncrona, portanto, você deve usá-los com a expectativa de que eles transfiram dados com regularidade e eficiência, mas não instantaneamente. Se você precisar fazer a transferência de dados em tempo real, faça isso em um AsyncTask ou em um IntentService. - fonte .

Basicamente, se você precisar de transferência em tempo real, use IntentService (a primeira opção), caso contrário, o SyncAdapter. No entanto, prefiro um IntentService porque parece mais personalizável, mas uma abordagem mais trivial seria usar um SyncAdapter.

Depende muito de que tipo de sincronização você precisa.

Periódico

Se seu aplicativo for um aplicativo de notícias que publica postagens em um determinado horário todos os dias (digamos às 7h45 todos os dias), você executa uma tarefa periódica em um serviço em segundo plano, às 8h.

por exemplo : Drippler. Eles me notificam uma vez por dia (por volta das 18h30). Eu acredito que eles usam uma tarefa periódica.

Evento desencadeado

Se sua transferência de dados for acionada pela ação do usuário, use um serviço em segundo plano ou um AsyncTask para a transferência de dados.

por exemplo : DropBox / Evernote. Eles são sincronizados quando interajo com o aplicativo.

Instantâneo

Se o seu aplicativo executar mensagens importantes / e-mails / atualizações importantes não periódicas , você precisará de notificações por push, porque deseja alertar o usuário imediatamente. Use GCM ou Parse para este caso. por exemplo: WhatsApp / bate-papo do Google. Como você mencionou explicitamente que não deseja usar o GCM, explicarei por que você deve usar um provedor de notificação por push padrão em vez de escrever o seu:

As notificações por push funcionam instantaneamente - há muito pouco atraso (na ordem de segundos, raramente minutos). Se você implementasse sua própria solução / biblioteca para fazer isso - em um modelo ingênuo, você executaria ping no servidor a cada segundo ou 5 segundos ou um minuto para verificar o status. Isso é muito ineficiente, pois consome CPU (e, portanto, bateria), largura de banda no celular e carga no servidor. No entanto, no GCM / Parse, eles sempre mantêm uma porta aberta com o servidor (veja aqui ). Esta é a maneira padrão e mais eficiente. Além disso, se 10 aplicativos usam o GCM, você não precisa de 10 conexões abertas, apenas uma por dispositivo. E você realmente não deseja desenvolver sua própria solução, a menos que tenha uma razão / fundos / tempo válidos para fazê-lo.

Uma observação sobre o adaptador de sincronização : o adaptador de sincronização funciona bem nos três casos acima. Verifique Executando um adaptador de sincronização e você verá que ele depende do GCM ou de seu próprio mecanismo (gatilho de evento ou solução personalizada) ou disponibilidade de rede (gatilho de evento) ou evento periódico. Em suma, esta é uma boa classe conveniente para sincronizar dados sem ter que fazer uma longa lista de inicializações todas as vezes ou implementar todos os casos acima em um só lugar.

Há um aspecto de um SyncAdapterque não foi mencionado pelas outras respostas.

O SyncAdapterpadrão requer que você tenha uma autoridade específica do ContentProvider com a qual sincronizar e um tipo de conta específico (consulte Autenticador ) que será sincronizado. Portanto, a menos que você já tenha esses componentes em sua arquitetura (por exemplo, porque você concede acesso a outros aplicativos aos seus dados ou precisa suportar contas), SyncAdapterisso causará uma sobrecarga significativa na implementação.

Quando se trata de sincronizar dados que envolvem conectividade, você também pode escalar. Acredito que a maneira recomendada de fazer isso é usar o adaptador de sincronização.

Também parece ser assim se você verificar o guia de traning para Android: Criando um adaptador de sincronização

O componente do adaptador de sincronização no seu aplicativo encapsula o código para as tarefas que transferem dados entre o dispositivo e um servidor. Com base na programação e nos gatilhos fornecidos no aplicativo, a estrutura do adaptador de sincronização executa o código no componente do adaptador de sincronização ...

Os adaptadores de sincronização devem ser usados, a menos que você precise de dados em tempo real, pois automatiza a transferência de dados com base em vários critérios, como alterações de dados, tempo decorrido, hora do dia etc. Centraliza todas as transferências de dados para que sua transferência seja feita em conjunto com transferências de dados de outros aplicativos, o que reduz o uso da bateria.

Para tarefas instantâneas que podemos usar,

O AsyncTask para tarefas de curta duração pode levar de 3 a 4 segundos.

IntentService para tarefas de longa execução.

Como estamos falando de design, devemos mencionar o gerenciamento do SyncAdapters, o objeto SyncResult e o que acontece depois.

Na verdade, eu uso um SyncAdapter para dizer à minha biblioteca para fazer chamadas da web do IntentService para o meu servidor. Gerenciar esta operação de "sincronização" é complicado.

Uma abordagem que estou adotando agora é renunciar completamente ao objeto SyncResult e usar apenas um serviço para registrar os resultados de cada "Sincronização" individual