Retrofit com Coroutines e LiveData no Android

• Então usamos um repositório para realizar a chamada a partir do enqueue() da Call<Endereco>:

Se for a sua primeira vez com o uso do Retrofit, recomendo conferir este artigo que explica com mais detalhes essa implementação.

Basicamente, devolvemos o endereço quando temos uma resposta de sucesso e um null caso contrário para limpar a tela. Nesta implementação, utilizamos o Callback devido ao uso do enqueue() que permite a execução uma thread paralela.

Ao utilizar callbacks o nosso código tende a aumentar a verbosidade, pois para cada requisição precisamos usar um boilerplate similar.

Coroutines como alternativa de callbacks

Como alternativa de implementação, podemos utilizar as coroutines no Android que permite o mesmo comportamento sem a necessidade de callback. Você pode adicionar as Coroutines com essa dependência

Um exemplo de código, é executando a Call diretamente dentro do escopo de uma Coroutine:

Esse código funciona, porém, no execute() o Android Studio apresenta a seguinte mensagem Inappropriate blocking method call, indicando que essa chamada não é apropriada, pois é um método que bloqueia a thread.

Entendendo o problema de bloquear a thread em Coroutine

O grande problema desse tipo de chamada em uma Coroutine, é que pode impactar a performance, pois, ao bloquear threads, corremos o risco de travar outras Coroutines e impedir o processo de suspensão.

É possível simular e visualizar esse comportamento criando várias coroutines e executando Thread.sleep() (chamada equivalente a uma instrução de bloqueio) em um CoroutineContext específico, nesse caso, o Dispatchers.IO. Vamos considerar o seguinte exemplo:

Ao testar e visualizar o logcat, notamos que a requisição HTTP, que deveria ser executada em paralelo, só é chamada após a finalização de algumas Coroutines. Isso demonstra o problema de executar instruções que podem bloquear threads dentro de Coroutines.

Quanto maior a quantidade de execução simultâneas, mais fácil é visualização do problema... Além da quantidade, o processador também influencia no resultado, quanto menos potente, mais fácil de simular o problema.

Suspend functions nos serviços do Retrofit

Por conta disso, a partir da versão 2.6 do Retrofit, temos o suporte ao uso de Coroutines, o que permite implementar os métodos dos serviços como uma função de suspensão (suspend function):

Além de evitar o problema de bloquear a thread, lidamos diretamente com a referência Response:

Dessa forma, temos o mesmo resultado, a diferença é que evitamos o risco de travar a Coroutine :)

LiveData com escopo de Coroutine no KTX

Inclusive, podemos simplificar mais ainda a nossa implementação, utilizando o KTX para o LiveData, que permite acessar um LiveDataScope, que herda de CoroutineScope e permite executar suspend functions. Você pode adicioná-lo a partir desta dependência

E então podemos implementar o mesmo código da seguinte maneira:

A diferença é que não precisamos mais criar um LiveData ou CoroutinesScope e utilizamos o método emit() para atualizar o valor do LiveData. Dessa forma, reduzimos bastante o código para executar uma requisição HTTP e atualizar a tela com o LiveData!

Por mais que a ideia seja simplificar, apenas essa implementação não é o suficiente para atender aos casos comuns de uma comunicação web.

Lidando com possíveis erros na comunicação HTTP

Além dos casos que temos o caminho feliz (tudo funcionando como esperado), nesse tipo de comunicação precisamos lidar com as situações excepcionais.

Uma das técnicas utilizadas para isso, é envolver a resposta da comunicação em uma outra classe capaz de identificar o resultado como um sucesso ou falha.

Uma implementação demonstrada até pela documentação do Android Developers é a classe Resultado:

Com esta classe, temos a possibilidade de atualizar o LiveData com sucesso ou erro. No nosso código podemos fazer o seguinte:

Então precisamos ajustar o retorno no ViewModel:

E quem consome o LiveData precisa implementar o comportamento de ambas as situações:

Com esse ajuste, somos capazes de apresentar o endereço quando a requisição é sucedida ou uma mensagem específica, quando apresenta um problema:

Evitando problemas de comunicação com try catch

Além dos casos que ocorrem a falha devido à resposta da API, também há casos em que o endereço da API está errado, ou ocorre um timeout ou qualquer problema de uma falha de comunicação. Nesses casos, precisamos envolver todo o código que chama o service em um try catch:

Fazendo a simulação de um endereço inválido (https://teste.com.br/ws/), temos a seguinte mensagem para o nosso usuário final:

Essa mensagem é identificada pela Exception java.net.ConnectionException, portanto, podemos identificá-la e apresentar uma mensagem mais específica:

E para evitar futuras mensagens do gênero, exceptions que ainda não identificamos, podemos apresentar uma mensagem genérica caso seja uma exception diferente:

Além de evitar uma mensagem muito estranha para o usuário final, temos a possibilidade de identificar por meio de um log.

O ideal nas exceptions é utilizar técnicas de log que permitam monitorar quando as exceções ocorrem nos dispositivos dos usuários.

Conclusão

Com a possibilidade de utilizar Coroutines, evitamos o uso excessivo de callbacks em chamadas assíncronas e conseguimos escrever um código de maneira objetiva para realizar operações assíncronas

Código fonte

Você pode consultar o código fonte do artigo a partir deste repositório do GitHub.