Avaliação do processo e considerações Ąnais

Feito todo o processo de refatoração e implantação da biblioteca OfflineManager, tem-se o último passo da metodologia informalmente adotada, que é a avaliação sobre a aplicação Ąnal, considerando o requisito de funcionamento em modo offline. É claro que

6

Em nenhum momento, durante o período de um mês de utilização da aplicação para essa avaliação, o back-end do TMDb Ącou indisponível.

essa avaliação precisaria da validação de usuários reais, bem como validação do responsável pelo produto Ąnal a Ąm de, pelos processos de software, avaliar se o requisito foi alcançado de maneira satisfatória. No escopo desta pesquisa, uma avaliação inicial é feita do ponto de vista de desenvolvimento. Algumas considerações, por Ąm, são apresentadas sobre o processo de implantação da biblioteca.

Como foi discutido anteriormente, todas as chamadas que o aplicativo realizava foram tratadas com a biblioteca. A maioria delas utilizando o modo transparente para o cenário de dispositivo offline, e o modo Ćexível para o servidor offline.

Algumas chamadas, porém, como os detalhes de Ąlme, série de TV ou pessoa, a pesquisa e o ŞDiscoverŤ, utilizaram o modo Ćexível para o caso de dispositivo offline. Isso pois essas telas exigiam um comportamento mais reĄnado na questão de exibir mais informações, ou de possuir uma interação mais reĄnada, com preenchimento de dados para a posterior execução da chamada.

No geral, esses dois modos trataram bem o requisito de funcionamento offline quando o dispositivo perde conexão com a Internet. Por ser uma aplicação mais informal, de consulta de dados, no contexto de Ąlmes e séries de TV, pode-se assumir que sua utilização é bastante intermitente e dependente da vontade do usuário em buscar alguma informação. Essa dependência da vontade do usuário signiĄca que um típico usuário dessa aplicação a utiliza apenas quando sente vontade de interagir com ela, diferenciando-se de uma aplicação de cunho mais prático, que demanda uma utilização mais pragmática, como por exemplo aplicações bancárias. Devido a essa característica, os tratamentos para utilização em modo offline podem ser mais Ćexíveis e menos engessados, o mesmo acontece com o tratamento adotado para funcionamento em caso de servidor offline.

Em outras aplicações, porém, que necessitam de maior pontualidade na interação, ou até de maior segurança dos dados, é possível assumir que existiriam chamadas que utilizassem o modo Enforce (para dispositivo offline) ou NoAction (para servidor indis- ponível), cujas Ąnalidades são fazer com que a chamada seja possível apenas no caso do dispositivo possuir conexão, ou o servidor estar disponível.

Já do ponto de vista do desenvolvedor, o processo de implantação foi bastante direto. A instalação da biblioteca é feita com apenas uma linha de código. A utilização da biblioteca para encapsular uma chamada do RetroĄt também requer apenas algumas linhas de código para implementar.

Aproveita-se a criação da chamada com a interface do RetroĄt, passando os parâ- metros que serão os cabeçalhos da chamada, e utiliza-se o método fornecido pela biblioteca OfflineManager para a execução tratada desta chamada. No Inventum, pode-se aprovei- tar as mesmas lógicas implementadas nos métodos de callbacks, sendo necessário apenas a adição de um cast explícito pois o callback oferecido pela biblioteca é genérico, enquanto

o oferecido pelo RetroĄt já é tipado.

Outro fator bastante simples é a sobrescrita das mensagens de feedback. A docu- mentação da biblioteca OfflineManager oferece um guia bastante claro sobre quais strings devem ser sobrescritas para alterar o texto de cada mensagem mostrada pela biblioteca. Portanto, bastou uma leve ponderação sobre quais mensagens seriam alteradas, uma rá- pida procura na documentação para saber as chaves que identiĄcavam essas mensagens, e a sobrescrita no arquivo de strings da aplicação.

Por Ąm, como considerações Ąnais, é possível aĄrmar que, por métricas de código, o processo de implantação da biblioteca em um projeto real de aplicativo, é bastante direto e rápido:

• 5 atividades alteradas, sendo que para cada uma delas apenas uma inicialização da biblioteca OfflineManager é necessária;

• 5 fragmentos alterados, sendo que para cada um deles apenas uma inicialização da biblioteca OfflineManager é necessária;

• Dentro dessas atividades e fragmentos, um total de 13 chamadas do RetroĄt foram alteradas para serem tratadas com a biblioteca;

• Cada alteração representa uma chamada ao método treatedCall, e foi implemen- tada por uma média de 20 linhas de código. Isso sem considerar a lógica da aplicação implementada nos métodos de callback do RetroĄt, que foi reaproveitada para os callbacks do método treatedCall;

• 2 linhas necessárias para adicionar a biblioteca OfflineManager ao projeto, por meio do Graddle;

Porém, o grande desaĄo desse processo se encontra nas etapas de:

• IdentiĄcação e avaliação do requisito de funcionamento em modo offline da aplica- ção;

• Escolher os tratamentos a serem adotados em cada chamada, em caso de dispositivo sem conexão;

• Escolher os tratamentos a serem adotados em cada chamada, em caso de servidor indisponível;

• Decisão sobre a utilização do modo verboso, que depende da usabilidade desejada e do contexto da aplicação e da chamada em especíĄco;

• Refatorações necessárias em outros trechos de código, para que o Ćuxo da aplicação seja adaptado ao tratamento oferecido pela biblioteca.

Contudo, já se esperava que essas etapas se mostrassem desaĄadoras, uma vez que se relacionam com o projeto da aplicação. Assim, essas decisões dependem bastante do contexto em que o aplicativo será inserido, seu objetivo principal e seu público alvo. Para a aplicação no Inventum, pouca refatoração de código foi necessária para a adaptação aos Ćuxos fornecidos pela biblioteca OfflineManager, mas esse fator, em outras aplicações, vai depender de certa forma do projeto inicial da aplicação e do estágio em que o requisito de funcionamento offline vai ser inserido.