Refatoração e validação da solução Ąnal

Depois de ter analisado os requisitos de funcionamento offline na aplicação In- ventum, partiu-se para a etapa de desenvolvimento de fato, que consistiu em instalar a biblioteca OfflineManager, e aplicar o tratamento nas chamadas que a aplicação fazia ao back-end.

Começando pela instalação, o processo é bem simpliĄcado pois a mesma foi con- Ągurada de forma a ser utilizada com o Gradle5_{, que é o gerenciador de dependências da}

plataforma Android. Portanto, basta adicionar a dependência no Graddle da aplicação. Após sincronizar o projeto, a biblioteca OfflineManager já está disponível para utilização. Nesta etapa de desenvolvimento, o conhecimento sobre a aplicação adquirido na etapa anterior foi bastante útil para identiĄcar de forma mais rápida os pontos onde cha- madas HTTP eram executadas por meio do RetroĄt. Além disso, o projeto utiliza uma organização de pacotes bastante popular no cenário de desenvolvimento Android, sepa- rando as interfaces deĄnidas do RetroĄt em um pacote chamado service. Dessa forma, encontrar os métodos HTTP implementados com o RetroĄt para o back-end da aplica- ção é uma tarefa simples. A análise desses métodos implementados permite também a compreensão sobre os dados que são retornados por cada chamada.

5

Primeiramente, para o modo verboso foi sempre atribuído o valor verdadeiro, pois o estudo prévio da aplicação e suas funcionalidades mostrou, como relatado anteriormente, que a falta de feedbacks para o usuário é um problema para a aplicação em cenários de uso offline.

Sobre os modos de tratamento escolhidos, diversas telas do sistema executam ações de forma transparente ao usuário Ű por exemplo carregamento de dados nas telas, carrega- mento de mais resultados nas listagens, dentre outros. A Ąm de manter essa característica, para essas telas e funcionalidades, o tratamento escolhido foi o modo transparente para dispositivo offline.

Um exemplo de utilização desse modo foi na tela inicial: antes da aplicação da biblioteca OfflineManager, ao abrir o aplicativo sem conexão, a tela inicial era mostrada vazia, pois sem conexão nenhum Ąlme era mostrado e nenhum tratamento era aplicado. Além disso, quando a conexão era retomada, não existia meio de recarregar os dados da tela.

Depois de aplicar a biblioteca na tela inicial, utilizando o modo de tratamento transparente para dispositivo offline e para servidor indisponível, a funcionalidade conti- nua transparente ao usuário porém melhorada. Os dados continuam não sendo exibidos caso a conexão não esteja disponível, mas o tratamento da biblioteca garante que eles sejam atualizados assim que a conexão for retomada.

O modo transparente foi utilizado também nas listas de Ąlmes e séries de TV, acessíveis pelo menu lateral, pelos mesmos motivos da tela inicial. E ainda nessas listas de Ąlmes e de séries de TV, ele foi utilizado para a paginação e carregamento de mais resultados. Quando o usuário navega para o Ąm da lista de itens carregados, se não houver conexão, uma chamada transparente será armazenada, e os resultados estarão disponíveis assim que a conexão retornar. Aqui, o modo transparente é bastante interessante pois permite uma navegação mais Ćuída pela lista, e a retomada de navegação automaticamente quando a conexão é retomada, sem a necessidade de o usuário realizar um recarregamento da tela.

Para a tela de detalhes de um Ąlme, foi utilizado o modo Ćexível. Aqui, a tela oferece uma grande quantidade de informações referentes ao Ąlme selecionado, e a interação é mais pontual, por apresentar os detalhes de um Ąlme dentre os diversos disponíveis nas listagens. Por isso, uma conĄrmação do usuário antes de o tratamento ser aplicado pareceu ser mais adequada, justiĄcando a escolha do modo Ćexível.

Assim, ao entrar na tela de detalhes, sem conexão com a Internet, o aplicativo veriĄca se aquele Ąlme está armazenado em cache. Se sim, os detalhes serão exibidos de forma transparente ao usuário. Se não, uma requisição será necessária. Nesse ponto, o modo Ćexível interage com o usuário por meio de um pop-up para conĄrmar a intenção

em armazenar essa chamada e executá-la posteriormente. Pode ser que o usuário desista dessa ação, cancelando o tratamento, e prosseguindo para outras interações. Senão, pode ser que ele conĄrme o tratamento, pois se interessa pelo carregamento em segundo plano caso a conexão volte. Isso faz com que os dados estejam disponíveis em um segundo momento quando ele abrir o dispositivo móvel que foi deixado com a aplicação nesta tela. É importante mencionar que o reĄnamento dos modos utilizados para cada ponto de interação pode ser ajustado de acordo com testes de usabilidade e validação pelos clientes Ąnais da aplicação.

Ainda na tela de detalhes de Ąlme foi aplicada uma chamada no modo transpa- rente, para carregar a seção de vídeos, caso o aplicativo perca a conexão nesta tela, ou caso o usuário entre para ver os detalhes de um Ąlme já em cache, enquanto o dispositivo está desconectado. Esta seção de vídeos não é estritamente necessária, portanto seu carre- gamento é feito em segundo plano, de forma transparente, caso a conexão seja retomada enquanto o usuário consome os detalhes de um Ąlme selecionado.

As últimas duas funcionalidades onde a biblioteca tratou cenários de utilização offline foram a pesquisa rápida, e a tela de ŞDiscoverŤ. Na pesquisa rápida, uma pequena mudança no código da aplicação atribuiu ação ao botão de conĄrmar no teclado virtual, para realizar a chamada quando pressionado.

Outra mudança foi que, para o caso de o dispositivo estar sem conexão, a busca não ser executada a cada caractere inserido, mas somente quando o botão para buscar for pressionado. Isso para evitar que diversas chamadas sejam feitas e encadeadas durante o tratamento, sendo que o resultado da pesquisa a ser mostrado vai ser somente o da última chamada realizada, quando a conexão for retomada.

Dessa forma, o funcionamento da aplicação Ącou da seguinte forma: com o dispo- sitivo conectado, a busca ocorre a cada caractere pressionado, e os resultados vão sendo exibidos de acordo com a palavra que se forma. Caso não haja conexão, o usuário digita toda a frase que deseja pesquisar, e ao pressionar o botão de pesquisa, a biblioteca trata de forma Ćexível, informando ao usuário que a conexão não está disponível e perguntando se ele deseja que essa pesquisa seja executada em segundo plano com a retomada de conexão. As telas para esses dois casos são apresentadas na Figura 16:

Essas duas mudanças se mostraram necessárias para o bom funcionamento do tratamento em modo offline, inserido pela biblioteca OfflineManager. Principalmente, a mudança que evita o encadeamento das chamadas caso o dispositivo esteja sem conexão, evitando o armazenamento desnecessário de diversas chamadas intermediárias, antes da última, que teria seus resultados exibidos.

Além disso, essa última evidenciou o que pode ser um trabalho futuro para a biblio- teca OfflineManager. Quando existir um cenário onde diversas chamadas são encadeadas,

(a) Conectado à Internet (b) Sem conexão com a Internet

Figura 16 Ű Telas do aplicativo Inventum que mostram a busca rápida com conexão disponível, e sem conexão disponível, tratadas pela biblioteca OfflineManager

e somente uma delas deve ser válida, a biblioteca poderia oferecer um tratamento para esse caso, de forma a descartar automaticamente as outras chamadas encadeadas. Poderia ser possível a conĄguração de um valor de intervalo máximo de tempo para que esse descarte ocorra, e também um modo de tratar qual a chamada seria a válida: a primeira, a última, ou alguma intermediária baseada em algum valor de retorno obtido pela chamada. Esse novo tratamento evitaria a necessidade de alteração no código da aplicação, como ocorreu neste trabalho.

Já na tela de ŞDiscoverŤ o tratamento foi bastante semelhante aos outros trata- mentos aplicados. O modo de tratamento para dispositivo offline foi o Ćexível, com o modo verboso ativado para que haja tanto interação com o usuário, como feedbacks sobre a completude das ações. Portanto, se o usuário realizar uma pesquisa elaborada enquanto o dispositivo estiver sem conexão, ele pode interagir conĄrmando o armazenamento para que essa pesquisa seja executada e os resultados populados conforme o dispositivo retoma a conexão.

Nessa funcionalidade, é bastante interessante a aplicação da biblioteca e o trata- mento da chamada pois esse é um Ćuxo que pode ser passível de frustração para o usuário. Pode ser que ele gaste um tempo pensando e elaborando os campos para a realização de uma pesquisa reĄnada, e ao submeter, a falta de conexão barra a continuidade do Ćuxo. Além disso, ele teria que Ącar manualmente tentando novamente executar a pesquisa, até que ela seja possibilitada com a retomada de conexão.

salvar essa requisição, ela livra o usuário de ter que tentar novamente por si, e também evita a frustração de ter que preencher os campos da pesquisa novamente. Os resultados estarão prontamente disponíveis uma vez que a conexão seja retomada.

Este cenário, então, pode ser expandido para uma análise mais ampla: aumenta o valor da utilização da biblioteca, em cenários onde o usuário interage elaborando pes- quisas ou preenchendo formulários. Isso não somente em chamadas HTTP do tipo GET, que apenas requisitam dados do servidor, mas principalmente para chamadas HTTP do tipo POST, que enviam dados. Qualquer tipo de envio de formulários ou dados ao ser- vidor, depois que o usuário utilizou e gastou tempo preenchendo e elaborando, pode ser encapsulado para que seja executado em um segundo momento, mesmo que a conexão não esteja disponível no momento do envio.

Junto a isso, mensagens de feedback informam ao usuário sobre os processos que estão acontecendo, para que ele sempre saiba o que está acontecendo na aplicação com os seus dados, com suas interações.

Por Ąm, mas não menos importante, todas as chamadas foram também tratadas para o caso do servidor não estar disponível, pois é um mecanismo que também está presente nos chamadas realizadas por meio da biblioteca, como foi explicado no capítulo3. Para esses casos, porém, no contexto desse aplicativo, a escolha dos modos de tratamento caso o servidor encontre-se indisponível foi bastante direta. Para todas as chamadas, fez sentido a utilização do modo Ćexível.

Como nesta aplicação a indisponibilidade do servidor é um cenário bastante raro6_,

é interessante haver interação do usuário para decidir se prossegue com tratamento offline ou não, caso isso aconteça.

O usuário será sempre informado também com feedbacks sobre ações realizadas devido ao modo verboso ativado. Apenas nas chamadas de carregamento de Ąlmes, nas listas com paginação, que se utilizou o tratamento Sem Ação, pois entende-se que o cenário de servidor indisponível ou instável poderia atrapalhar o Ćuxo do carregamento das mensagens paginadas, portanto ali foi aplicado o tratamento que na verdade demanda disponibilidade do servidor, caso contrario o usuário será informado do problema e o carregamento será interrompido.