Pedro fiz a solução baseado na sua ideia 2 e vi o site também (muito legal)
Veja se consegue me ajudar com mais esta (abro a quem mais puder ajudar..rsrss)
Como eu disse no primeiro post, queria montar uma classe que funcionasse assim por exemplo:
BlaAPI api = ServiceGenerator.createService(BlaAPI.class, Bla.class);
api.FazAlgo("321").enqueue(new Callback<Dispositivo>()....);
Esta chama no header esta indo o token, se este estiver válido, coisa linda,
Mas se ele for inválido o programador no Callback vai ter o erro de autenticação e preciso fazer uma nova chamada para o
loginAPI.GerarToken(user).enqueue(new Callback<Token>()...)...
Para pegar um token válido. E ai depois fazer uma nova chamada para o api.FazAlgo...
Eu queria encapsular isso, e o programador só faz a chamada que deseja, e caso o erro seja por conta do token esta classe se encarrega de buscar um novo e concluir a chama original, neste exemplo a api.FazAlgo
Obrigado,
Tiago Grillo
2016-06-02 10:18 GMT-03:00 Tiago Grillo <tijgrillo@gmail.com>:
Olá,Pedro gostei do site, quanto a ideia eu acho que entendi, vou fazer uns testes aqui e absorver ela melhor e volto com (mais duvidas) um feedback...Obrigado2016-06-02 9:17 GMT-03:00 pedrofsn <pedrokra@gmail.com>:Bom dia,--Estou utilizando o Retrofit2, encontrei um local com os melhores tutoriais pra esta library (https://futurestud.io/blog/retrofit-token-authentication-on-android).Encontrei duas saídas pra resolver este problema, ainda não acho que são as melhores, mas são funcionais.
- Colocar o servidor pra retornar um erro no protocolo e tratar este erro em cada response.
- Todos os seus objetos que forem retornados de uma requisição, devem extender um objeto "Erro" em que nele você tenha as propriedades das suas mensagens de erro (ex.: erroInterno, mensagemUsuario, mensagemLog). Nesta classe você pode determinar um atributo que sempre que for um erro vai existir (ex.: erro = true). Então quando retorno.isErro() for true, quer dizer que efetivamente ocorreu um erro e então você tratará. Como utilizo o retrofit 2, criem um CustomCallBack onde tenho o meu tratamento.
Este segundo caso é uma alternativa ao primeiro por questões de padrões mesmo. Por exemplo, se o seu erro for a validação de cadastro, o server não tem que retornar um erro HTTP, ele vai retornar SUCESSO/200 e o seu JSON de erro (que é algo do SEU sistema e não do protocolo). O primeiro caso é ruim por conta disto, mas se não se importar, é até mais fácil de tratar hehehe.Att.
Em quarta-feira, 1 de junho de 2016 16:54:50 UTC-3, Tiago J. Grillo escreveu:Olá,Minha app faz chamadas síncronas e assíncronas a um servidor que fornece e pede um token no header.Até ai tudo bem, minha duvida é:Qual a melhor maneira de implementar para que caso minha chamada ao servidor seja rejeitada (por que o token mudou ou esta inválido) eu já fazer uma chamada ao serviço que me dá um novo token e chamar novamente a requisição que originou tudo de forma transparente para o usuário (nas síncronas)?Faço isto no Interceptor, se é q posso fazer uma nova chamada aqui?Deixo dar erro e faço o tratamento no onFailure?
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.
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.
0 comentários:
Postar um comentário