Estudo da aplicação e requisito de funcionamento offline

Depois de selecionado o projeto para a implantação da biblioteca, foi feito um es- tudo sobre o aplicativo em questão para a compreensão de suas funcionalidades, e também uma análise sobre o código do projeto para o entendimento de sua implementação.

Em seguida, foi analisada a questão do funcionamento offline: o aplicativo trata a questão de conexão com a Internet em uma camada bastante superĄcial, na forma de veriĄcações de conectividade antes da realização de carregamentos das telas. Isso faz com que a maioria das funcionalidades do sistema não ofereça nenhum tipo de tratamento para funcionamento offline. O que acontece, caso o dispositivo perca a conexão, é que o aplicativo oferece um feedback para o usuário informando sobre a falta de conexão com a Internet, como mostrado na Figura 15.

Figura 15 Ű Tela do aplicativo Iventum em um cenário sem conexão com a Internet, mostrando uma mensagem de feedback, sem o tratamento da biblioteca OfflineManager

Outro tratamento parcial oferecido, no sentido de funcionamento em caso de falta de conexão, é o armazenamento em cache local dos dados de Ąlmes, séries de TV e atores. Sempre que o usuário acessa os detalhes de um desses três dados, é feita uma veriĄcação para saber se eles já estão em cache. Se sim, os dados retornados são os dados da cache, senão os dados retornados são buscados pela requisição ao servidor, que além de mostrar os dados buscados, atualiza as entradas na cache para o dado recém buscado.

Esse tratamento faz que, em caso de falta de conexão, ainda existam alguns dados disponíveis para o acesso, desde que o usuário já tenha navegado por aquela tela anteri- ormente. Portanto, é possível aĄrmar que o aplicativo quase não oferece funcionalidades para cenários de utilização em modo offline, uma vez que o único tratamento real oferecido é o de cache, mas depende da disponibilidade prévia daquele dado na cache, e esse trata- mento não considera nenhum outro aspecto de usabilidade ou interação. Pode-se aĄrmar, portanto, que esse tratamento tem como principal objetivo melhorar o desempenho.

É possível aĄrmar também que a aplicação não oferece nenhum tratamento para o caso de o servidor estar indisponível, pois não existe nenhum código que trata desse aspecto. O que aconteceria, nesse cenário, seriam retornos de mensagens de erro possi- velmente difíceis de serem compreendidas por um usuário comum, pois os erros causados por exceções de indisponibilidade do servidor não são tratados de maneira reĄnada, são apenas retornados ao usuário Ąnal.

Analisando também pelo fator de experiência de usuário quando a conexão com a Internet não está disponível, algumas observações podem ser feitas: algumas telas, como por exemplo a tela inicial da aplicação, apesar da mensagem de feedback informar a falta de conexão, apresentam uma interface bastante ruim, pois nada é carregado e a tela Ąca em branco, como mostrado na Figura15.

Outras telas, como a da funcionalidade de busca rápida, não apresentam feedback sobre ações realizadas em momentos de falta de conexão, o que gera comportamento in- consistente. Nessa busca, quando existe Internet disponível, o usuário digita os caracteres da busca e para cara carácter digitado, uma busca é realizada, fazendo com que os resul- tados mudem para cara carácter digitado conforme a palavra se forma. Se a Internet cair em algum momento nesse processo, os resultados param de serem trazidos, sem nenhuma mensagem de feedback.

Além disso, nessa tela, o botão contextual de submeter a busca pelo teclado virtual apenas esconde o teclado da tela. Não permite ao usuário a ação de buscar, depois que um texto foi digitado com conexão offline. Existe ainda a tela ŞDiscoverŤ, que apesar de não apresentar comportamento inconsistente, pode causar um pouco de frustração, à medida que o usuário gasta tempo preenchendo as opções e personalizando uma busca, e ao clicar para buscar, se não houver conexão, nada acontece e ele terá que realizar a mesma busca e digitar novamente suas opções em um segundo momento.

É claro que alguns desses problemas citados anteriormente na usabilidade em um cenário offline podem ser resolvidos puramente com refatorações de código sem a utiliza- ção da biblioteca OfflineManager. O simples fato de analisar a aplicação nesse contexto já permite que algumas alterações sejam feitas de maneira a melhorar a qualidade geral do aplicativo em um cenário de conexão intermitente com a Internet.

A principal delas, que inclusive foi identiĄcada no experimento de comparação (a ser apresentado mais adiante, na Seção 4.3) é a funcionalidade do ŞPull to refreshŤ (ou arraste para recarregar). É uma função que a maioria dos aplicativos atuais implementa, e opera de maneira que o usuário pode arrastar a tela da aplicação para baixo para forçar um recarregamento dos dados. Outras alterações possíveis seriam a melhoria de algumas mensagens de feedback, implantação de alguns processos de recarregamento dos dados baseado no estado da conexão, ou mudança de alguns Ćuxos de utilização para comportar possíveis casos de perda de conexão.

Observa-se porém, que as alterações sugeridas, que entende-se que seriam as pos- síveis alterações a Ąm de melhoria em um cenário offline, tendem a se aproximar de mudanças no código que não passam somente pela camada de comunicação e de dados, mas sim diretamente pelas camadas de interface e de usabilidade.

Tendem também a se aproximar cada vez mais de alterações mais complexas nos Ćuxos de funcionamento da aplicação, deixando para trás as pequenas alterações, que são poucas. Isso mostra que de fato existe um interesse em aplicar a biblioteca do Offline- Manager, a Ąm de agrupar essas alterações necessárias em uma biblioteca que resolva os diferentes cenários, nas diversas camadas da aplicação, de forma mais centralizada e direta.