Escolha da aplicação

O primeiro requisito e o mais importante para a escolha do projeto foi que ele deveria ser de código aberto, para que se pudesse ter acesso a todo o código da aplicação, a Ąm de realizar quaisquer mudanças necessárias.

O segundo critério, de caráter exclusivo, foi a necessidade de o projeto utilizar a biblioteca do RetroĄt. É importante mencionar que o aplicativo a ser estudado já deveria fazer uso da biblioteca RetroĄt antes da avaliação, pois como foi explicado no Capítulo

3, RetroĄt é um pré-requisito para a utilização da biblioteca OfflineManager. Portanto, as observações aqui feitas dizem respeito exclusivamente às vantagens e desvantagens da biblioteca OfflineManager, e não ao uso do RetroĄt.

Outros critérios foram importantes também para a seleção do projeto, dentre eles a atualidade do projeto, com a Ąnalidade de selecionar um projeto que não fosse tão antigo ou depreciado do ponto de vista de tecnologias ou arquiteturas utilizadas, consi- derando que diversas versões da plataforma Android foram lançadas nos últimos anos. Além disso, a biblioteca OfflineManager suporta apenas versão 5 do Android ou superior, como apresentado no Capítulo3.

Outra característica considerada foi o tamanho do projeto, que pode ser metriĄcado pela quantidade de classes, no ponto de vista técnico, e pela quantidade de funcionalidades que oferece, do ponto de vista de utilização e requisitos. Essa característica é importante pois aproxima o processo aqui realizado de um cenário real de utilização da biblioteca. Por Ąm, o último critério, apesar de mais subjetivo, é também igualmente importante, é o grau em que o requisito de funcionamento offline se aplica ao projeto em questão, ou seja, o quanto é interessante para a aplicação escolhida oferecer tratamento para utilização em cenários offline.

Dados os critérios e características consideradas, fez-se uma busca no GitHub, por ser uma popular plataforma de compartilhamento e disponibilização de projetos em código livre. A busca foi realizada percorrendo extensivamente os projetos disponíveis, utilizando as palavras chave Android e Retrofit, dado o pré-requisito da aplicação ser em Android e utilizar a biblioteca RetroĄt. O maior desaĄo dessa busca deu-se pelo fato de que grande parte dos projetos disponibilizados em Android são bibliotecas, diĄcultando a seleção de projetos de aplicações completas.

Dos projetos de aplicativos completos que foram encontrados, parte não se utilizava da biblioteca RetroĄt, e parte eram projetos pequenos ou apenas aplicativos construídos na forma de tutorial, ou seja, aplicativos construídas com a Ąnalidade de detalhar ou explicar algum conceito ou tecnologia sobre a plataforma Android. Por esses motivos, poucos candidatos foram encontrados.

Dentre três aplicações candidatas, a que mais se adequou nos critérios e caracterís- ticas consideradas foi a aplicação chamada Inventum2

. Trata-se de um aplicativo Android que utiliza arquitetura REST, em conjunto com o RetroĄt, e faz requisições no back-end do TMDb Ű uma plataforma que, em conjunto com um banco de dados sobre Ąlmes, séries de TV e atores, disponibiliza esses dados por meio de uma API aberta3_.

Do ponto de vista de funcionalidades, esse aplicativo não requer que o usuário faça cadastro ou login, e apresenta na tela inicial listas de Ąlmes e séries de TV que estão em alta

2

https://github.com/qqq3/inventum

3

no momento. Pelo menu lateral, o usuário consegue navegar para seções de Ąlmes, onde Ąlmes podem ser listados de acordo com quatro características: mais populares, mais bem avaliados, Şestão por virŤ e Şpassando atualmenteŤ. Também no menu é possível navegar para uma tela semelhante, porém para séries de TV, que ordena a listagem de acordo com as características: Şpassando hojeŤ, séries atuais, populares, e mais bem avaliadas. A Figura 14 mostra a tela inicial do aplicativo, as opções disponíveis no menu lateral e as duas listagens mencionadas: de Ąlmes e de séries de TV.

(a) Tela inicial (b) Menu lateral

(c) Listagem de Ąlmes (d) Listagem de séries de TV

Figura 14 Ű Telas do aplicativo Inventum que mostram a tela inicial, as opções do menu lateral, e as telas de listagem de Ąlme e de séries de TV

mostradas na Figura 14, o usuário pode pressionar o ícone no canto superior direito para realizar uma busca rápida, onde ao digitar qualquer texto, os resultados vão sendo populados abaixo. No menu lateral, por Ąm, o usuário consegue ir para uma tela chamada ŞDiscoveryŤ, que nada mais é do que uma busca avançada: é possível preencher alguns dados e realizar uma busca por resultados Ąltrados de acordo com esses dados.

As últimas três opções listadas no menu lateral do aplicativo: Settings (conĄgura- ções), Feedback (Feedback sobre o aplicativo) e Donate Bitcoin (Doar bitcoins), mostrada na tela apresentada na Figura 14, não foram consideradas na refatoração apresentada nesta seção. A funcionalidade Settings não interage com a internet, e as funcionalidades Feedback e Donate Bitcoin abrem outra aplicação do dispositivo (se houver) para serem executadas.

O aplicativo Inventum também é um projeto atual: última atualização, indicada em sua página no GitHub, foi em 28 de janeiro de 2017. Além disso, é um projeto que pode ser considerado de médio porte, pois oferece uma quantidade razoável de funcionali- dades: desde funcionalidades grandes como as listas de Ąlmes e séries, detalhes dos Ąlmes ou séries, pesquisa e busca avançada; até requisitos não-funcionais como por exemplo ar- mazenamento em cache. Além disso, é composto por 57 classes e 5 interfaces e possui 23 arquivos de layout (arquivos que deĄnem as interfaces das telas da aplicação). Dessas classes:

• 13 são activities (atividades),

• 6 são fragments Ű fragmentos: semelhante a uma atividade, porém deĄne compor- tamento de apenas uma parte da tela ou de algum componente em especíĄco, • 5 são adapters Ű classes que deĄnem o comportamento de listas e seus itens,

• 15 são classes de modelo e representam entidades utilizadas na aplicação, como por exemplo a entidade Movie (Filme), ou a entidade Person (Pessoa).

O projeto conta, na época de sua utilização para esta dissertação, com 36 commits na plataforma de versionamento do GitHub, e com 3 contribuidores, desde a sua criação em 8 de Janeiro de 2017, deĄnida pelo commit inicial do projeto4_.

Por Ąm, devido ao seu funcionamento, é um projeto passível de aplicação de fun- cionalidades offline, uma vez que o tratamento em cache é feito apenas para a tela de detalhes de Ąlmes e não cobre nenhum tipo de tratamento para o caso de o servidor estar offline; e as demais telas do sistema não podem ser tratadas com cache por questões de requisito ou de funcionamento, ou seja, caso o dispositivo perca a conexão com a Internet, a maioria das funcionalidades e telas Ącarão indisponíveis. Do ponto de vista de usuário, o

4

requisito de funcionamento offline é interessante pois mesmo sem conexão, algumas ações ainda poderiam ser realizadas, feedbacks poderiam ser melhorados, e no geral a usabili- dade poderia continuar boa, mesmo com o dispositivo sem conexão, ou com o servidor indisponível.