Re: [androidbrasil-dev] Melhor abordagem para executar tarefas de tempo em tempo (estilo WhatsApp)

Engraçado que o app de mensagem do Facebook não envia automaticamente quando a conexão volta após você ficar sem conexão (ex: mandando a msg de dentro da garagem de um prédio). Já o Whatapp é tranquilo, você pegou a conexão de rede ele automaticamente envia a mensagem e aparentemente com um baixo impacto no consumo de bateria.

[]s Daniel

www.neoage.com.br

On Wednesday, January 14, 2015 at 4:22:32 PM UTC-2, Gink Labrev wrote:

Pessoal,

Vlw a todos pela colaboração.

Segue alguns pontos sobre o tópico.

1) Adotei uma solução de gravar as msg em um pool persistente (pode ser SQLite) e sempre que houver uma nova msg, iniciar o AlarmManager para tentar enviar até conseguir. Quando identifica que todas foram enviadas, cancela o AlarmManager poupando recursos. Tb é ativado por boot.

2)  Percebi que muita gente tem falado sobre GCM. Creio que possam não ter entendido bem a questão. O GCM, até onde sei, garante a entrega servidor-cliente. Mas estamos falando de cliente-servidor mesmo. Em um chat, é necessário garantir o envio da msg mesmo sem estar conectado ou com conexão lenta. Não faz sentido o usuário digitar e mensagem e aparecer "Falhou a tentativa de conexão. Tente mais tarde". Ele espera que seja enviada automaticamente. Um broadcast para detectar rede não resolve a questão pq pode falhar por vários motivos, msm com rede. É necessário um mecanismo de persistência e infinitas tentativas até conseguir.

3) Com base em uma breve pesquisa, o SyncAdapter parece uma boa para sincronizar com um Content Provider, mas não é apropriado quando envolve rede ou operações que devem persistir msm após a app fechar ou o dispositivo desligar. O WhatsApp, por exemplo, usa o SyncAdapter para sincronizar a lista de contatos, mas não o usa para o sistema de mensagens.

[]'s

Em 14 de janeiro de 2015 15:34, Luiz Gavioli <lui...@gmail.com> escreveu:

Cara, eu uso um service que cria uma thread chamada por uma TimeTask. Já é o segundo aplicativo que uso essa abordagem e tem funcionado muito bem.

Luiz Gavioli

Em 14 de janeiro de 2015 15:16, William Lopes <williaml...@gmail.com> escreveu:

Acredito que aplicativos mais avançados tecnologicamente fatalmente utilizam esse serviço, ou algo do tipo. Por isso, também citei no início dessa thread.

Abraços!

Em Wed Jan 14 2015 at 3:03:30 PM, Ernani Joppert Pontes Martins <jop...@gmail.com> escreveu:

Será que eles não fazem uso de GCM ou algo como o GCM?

Acredito que seja a melhor maneira de evitar polling!

Abraço,

Ernani

2015-01-11 3:40 GMT-02:00 Gink Labrev <gink....@gmail.com>:

Pessoal,

O Sync Adapter já não resolve este problema ?

Em 10 de janeiro de 2015 01:15, Gink Labrev <gink....@gmail.com> escreveu:

@marcelo

Acho que o whatsApp envia de todas conversa msm se a app estiver fechada ou em background.

Se não, o usuário teria que ficar acessando a conversa toda hora para garantir o envio ao invés de simplesmente esperar a resposta.

@willian, @luciofm

Só conhecia o uso do Handler para atualizar a main thread. Comecei a pesquisar e vi que está relacionado com Looper e MessageQueue. Não entendi nada ainda rs, mas a julgar pelo nome, parece que este é o caminho certo.

A melhor solução que imagino com meus humildes conhecimento é justamente um sistema de fila persistente. Ou seja, o sistema envia as mensagem para uma fila. Se a mensagem for enviada com sucesso, é retirada da fila, caso contrário executada novamente até encontrar rede ou receber a confirmação. Há um loop que fica constantemente processando a fila.

Essa é a abordagem utilizada por javascript/Node.js com o EventLoop.

Por isso, os nomes MessageQueue e Loop me chamaram atenção. Imagino que caso o mecanismo desse Loop seja o mesmo do EventLoop do JS, será muito mais eficiente que AlarmManager.

Mas o que encontrei até agora googlando não parece indicar esta semelhança. Ainda achei complexo o uso do combo Loop + MessageQueue + Handler.

O Exponencial Backoff é uma opção. Só espero conseguir manter a implementação simples.

Em 9 de janeiro de 2015 17:46, luciofm <luc...@gmail.com> escreveu:

Se você usar o AlarmManager ou um Handler para fazer retentativas, sugiro utilizar um exponential backoff para não drenar a bateria...

On Fri Jan 09 2015 at 5:39:27 PM Marcelo Quinta <marceloric...@gmail.com> wrote:

Até onde eu sei, WhatsApp tenta reenviar somente a da conversa em questão. 

A arquitetura seria a mais simples neste caso. Ao entrar em uma conversa, veja as mensagens que não foram enviadas (previamente cadastradas no banco) e envie-as ao servidor. Não resolve?

Você tem que tomar cuidado com AlarmManager e correlatos. Pode ser uma solução gulosa de bateria se você não tomar cuidado com os Wake Locks. Vai te dar mais problemas do que soluções. Eu já tive problema com isso antes e este link me ajudou:

https://stackoverflow.com/questions/14076468/android-correct-way-to-use-alarmmanager-without-draining-battery

[]s.

Em sexta-feira, 9 de janeiro de 2015 11:23:40 UTC-2, William Lopes escreveu:

Se você vai utilizar a cada poucos segundos, porque não um Handler?

Eu acredito que o WhatsApp, assim como qualquer outro aplicativo, tenham alguns Receivers cadastrados, como para conexão de dados, presença do usuário (USER_PRESENT), alarmes, algo nesse sentido.

Isso não tem muito segredo, exceto em casos em que são utilizados mensagens PUSH, onde o servidor é que tenta enviar algum sinal para o cliente, tal como uma nova mensagem chegou, etc., assim o cliente poderia entender que a 'porta está aberta'.

Referência: https://developer.android.com/google/gcm/index.html

Em Fri Jan 09 2015 at 11:09:51 AM, Gink Labrev <gink....@gmail.com> escreveu:

@William

Valeu. Faz sentido.

A maioria dos exemplos que vejo em AlarmManager trabalham com escala de minutos ou horas. Neste caso, precisa ser no máximo, a cada poucos segundos. Isso drenaria a bateria ? 

Alguém aqui chutaria como o Whatsapp funciona em relação à isso ?

Como este garante a entrega de mensagem mesmo após uma falha no envio.

Em 9 de janeiro de 2015 10:51, William Lopes <williaml...@gmail.com> escreveu:

Acredito que um alarme seria a melhor alternativa, a abordagem vai depender de cada caso. Você poderia, por exemplo, colocar um alarme com um delay crescente em caso de falha (tendo um limite e uma inteligência no delay, obviamente), ou em casos mais simples, tentar 3 vezes a cada 1, 3 ou 10 minutos.

Não existe a melhor forma de fazer isso, você deve ver sua necessidade e restrições, tal como: preciso que a mensagem seja enviada o quanto antes, preciso controlar o consumo da bateria, etc..

Em sábado, 3 de janeiro de 2015 01:45:39 UTC-2, Gink Labrev escreveu:

Pessoal,

Como o whatsApp fica tentando reenviar uma mensagem mesmo se ocorrer um erro ?

Qual a melhor abordagem para isso ? AlarmManager + IntentService ?

Abs,

--

You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/androidbrasil-dev/BqLqVlIaxEQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to androidbrasil-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/androidbrasil-dev/BqLqVlIaxEQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.