Push Notification - Firebase

Oi Felipe, boas observações, vou separar por tópicos, acredito que dessa forma fique mais fácil

Firebase em produção

O módulo de Cloud Messaging e Analytics você pode usar sem nenhum problema, ambos são free e funcionam relativamente bem. Entretanto, se optar por usar outros serviços deles, como é o caso do Realtime Database, aí eu recomendo que tome cuidado, primeiro com o preço, segundo com a forma na qual a sua App funciona, pois já vi alguns desenvolvedores, como também amigos que atuam como desenvolvedores Android reclamar de problemas que tiveram com o Realtime Database por questões de lentidão. E pior ainda, pelo fato de não termos a possibilidade de modificar a forma como o Firebase funciona ficamos suscetíveis a qualquer problema que apresentar... Resumindo, usar o Cloud Messaging e Analytics não vejo problema algum, porém, as demais ferramentas eu recomendo que avalie muito bem.

Token do Firebase no servidor

Quando enviamos o token para o servidor, permitimos que o servidor tenha a capacidade de enviar as mensagens para os dispositivos. Basicamente é realizada uma requisição via HTTP com o token, pois é por meio do token que conseguimos mandar as mensagens para os dispositivos. É claro, nessa requisição precisa seguir alguns padrões que são descritos nessa parte da documentação do FCM. As principais informações para realizar a requisição são:

• token: para poder direcionar a mensagem para o dispositivo.
• chave do firebase: para ter a autorização do serviço Firebase criado por você.

Possíveis implementações para o seu cenário

Considerando o que você disse sobre notificar o motorista quando for cancelado é algo que deve acontecer no servidor mesmo. Em outras palavras, por meio do token recebido e gravado no banco de dados no servidor, você vai fazer uma requisição para o Firebase conforme mencionei acima e assim ele vai ser notificado.

Envio do token

Você pode enviar no momento que achar necessário, mas enviar o token não significa que ele vai receber uma notificação sem nenhum motivo, portanto, não vejo motivo para enviar o token para o servidor apenas quando logar, afinal, o servidor que vai controlar quando ele deve ou não receber uma notificação.

Sugestões para a sua necessidade

Considerando todos os detalhes que passou, o que recomendo que você faça nesse exato momento é verificar a documentação do Firebase para realizar essas requisições via HTTP no lado do servidor. E então, depois de compreender como funciona, tente implementar da forma que faça sentido para você o momento de enviar as notificações. Apenas lembre-se que tanto a chave de acesso do Firebase quanto os tokens gerados pelos dispositivos são importantes para que uma notificação seja enviada.

Caso tiver mais um dúvida específica é só mandar :)

Abraços.

A chave de autenticacao do Firebase tb deve ser enviada pelo app, ou posso deixar no lado do servidor? Acredito que no lado do servidor, certo?! Outra coisa, entendo que o servidor recebe o token e armazena-o para enviar o push somente quando for necessario, e que quem de fato envia a requisicao para o FCM e o meu servidor e nao o app. Porem o que nao consegui resolver ainda eh o momento do envio do token para o servidor. Pois como falei, para mim so faz sentido receber a informacao completa no servidor (ou seja, com o iddomotorista que esta se logando). Como nao compreendi ainda o momento que o metodo onTokenRefresh eh chamado, nao consigo garantir o envio da informacao completa. Ou seja, algumas vezes acontece de cair no onTokenRefresh e nao haver nenhum motorista logado. Teria alguma maneira de chamar esse metodo? Pelos meus testes aqui, o app so chama o onRefreshToken uma unica vez...... A nao ser quando se apagam os dados..

Exato, a chave de autenticação deve ficar apenas no lado do servidor mesmo, é aquela que usamos naquela página de configuração do Firebase. O objetivo dessa chave é de autorizar o uso do Firebase em si.

Compreendi agora a sua necessidade. Considerando o que disse, recomendo que, dentro do onTokenRefresh() você salve o token em um Shared Preferences, assim, mesmo que desinstale a App ou o FCM gere um novo token, você vai manter um novo. Então, quando o motorista logar e você tiver as informações dele também, você manda o token que foi salvo junto com as informações dele.

O onTokenRefresh() é um service e ele vai funcionar apenas quando ele conseguir estabelecer uma comunicação com o Firebase, portanto, pode acontecer os casos dele conseguir logar e ainda não ter o token. Portanto, recomendo que antes de mandar a requisição para o servidor com o token e as informações do motorista, veja se o dado que você salvou no Shared Preferences é de fato o token esperado.

E o mais importante de todos, todas as vezes que salvar o token no Shared Preferences, também salve uma outra informação no Shared Preferences para indicar se o token foi enviado ou não. Em pseudo código ficaria assim:

onTokenRefresh {
    //salva token
   //marca que token não foi enviado
}

metodoQueEnviaTokenAposLogar {
    //tenta enviar token junto com as informações do motorista
        callback da requisicao
            onResponse
                //marca a informacao de envio de token como verdadeira
            onFailure
                //Tenta realizar novamente a requisição para enviar o token até conseguir.   
}

Basicamente esses são os passos que você vai ter que lidar. A maior preocupação que você vai ter que ter é de sempre garantir que se falhar esse envio, mesmo que ele mate a App você vai tentar novamente.

Abraços.

Legal, professor. Vc é muito FERA!

Só uma última dúvida... no onFailure como eu tento realizar novamente a requisição?! Seria como fiz abaixo? Simplesmente chamando novamente o próprio método que contém o Call? (Uma chamada do método dentro do próprio método?!

metodoQueEnviaTokenAposLogar {
    //tenta enviar token junto com as informações do motorista
        callback da requisicao
            onResponse
                //marca a informacao de envio de token como verdadeira
            onFailure
                metodoQueEnviaTokenAposLogar();
}

Isso mesmo Felipe! Você pegou o esquema!

A princípio chame novamente o mesmo método, porém, tem um detalhe, veja que se a comunicação falhou provavelmente é porque teve algum problema, ou seja, pode ser que mandar uma nova requisição imediatamente não faça sentido.

Portanto, recomendo que adicione um delay que vai aumentando conforme as requisições forem feitas. Esse delay você pode fazer por meio do método postDelayed() da classe Handler do Android. Ele vai criar uma thread separada na qual vai ser executada depois do tempo que definir e você pode passar um número diferente a cada execução.

Abraços.

Ok, professor. Muito obrigado. Vou dar uma olhada nisso sim!