Capítulo 3. Desenvolvimento 42
Figura 16 – Utilização do Postman para teste da rota de login
Fonte: Elaborado pelo autor (2019)
Figura 17 – Tela de cardápio apresentada para o coordenador
Fonte: Elaborado pelo autor (2019)
Figura 18 – Tela de cardápio apresentada para o cliente
Fonte: Elaborado pelo autor (2019)
Capítulo 3. Desenvolvimento 44
Os demais designs de tela do aplicativo se encontram no Apêndice B. As subse- ções subsequentes apresentam as particularidades na aplicação de cada padrão em suas respectivas versões do aplicativo e por fim os testes.
3.5.1 Passive Model-View-Controller (MVC)
O desenvolvimento do aplicativo no padrão Passive MVC foi inteiramente baseado no exemplo de Login apresentado porSokolova, Lemercier e Garcia (2013) disponibilizado no GitHub8 de um dos autores. A título de exemplificação, a modelagem de tal aplicação é exibida na Figura 19.
Figura 19 – Exemplo de login desenvolvido com o Passive MVC
Fonte:Sokolova, Lemercier e Garcia (2013, p. 10)
Do mesmo modo como o modelo apresentado, para cada activity ou fragment na aplicação existe uma classe Java view e controller correspondente. A classe view herda um componentes do layout correlato, assim sendo, adquirindo o contexto necessário para execução de sua responsabilidade na lógica de apresentação da aplicação. Por sua vez, o controller tem responsabilidade na lógica de negócio da aplicação e a classe activity ou fragment conecta os componentes decontroller com view na processo de iniciação.
Diferentemente dos componentes anteriores, não necessariamente há um model para cada activity ou fragment. Nessa respectiva camada, foi adotado, como no exemplo, ummodel para cada assunto. Dessa forma, por exemplo,activities que possuem em comum o assunto de notícias, compartilham o mesmo model. O model na presente aplicação tem responsabilidade de comunicação com back-end representada na camada de dados.
8 Disponível em:<https://bit.ly/2O0k4Vg>
Por fim, temos os listeners. Estes são implementados nas activities ou fragments e nos controllers respectivos. O listener na activity ou fragment permite que o controller comunique quando é necessário a execução de uma chamada nativa do Android, só executado na activity oufragment. O listener nocontroller permite que omodel retorne informações após a finalização de uma transação com o web service.
3.5.2 Model-View-Presenter (MVP)
O desenvolvimento do aplicativo no padrão Model-View-Presenter (MVP) foi baseado no exemplo apresentado porMainkar(2017). SegundoMainkar(2017), as camadas e respectivas responsabilidades do padrão MVP em Android podem ser descritas como:
• Model: responsável pela manipulação dos dados, seja repositórios locais ou distantes.
• View: renderiza informações para os usuários. É composta por componentes de interface do usuário, tais como arquivos .xml, activity, fragments e dialogs.
• Presenter: atua como mediador entre a view e omodel. Manipula os dados domodel e os exibe na view.
Seguindo o exemplo do primeiro padrão implementado, foi elaborado um diagrama similar ao apresentado anteriormente. AFigura 20exibe a modelagem dologin da aplicação desenvolvida no padrão MVP.
Figura 20 – Modelagem dologin da aplicação desenvolvida com o MVP
Fonte: Elaborado pelo autor (2019) adaptado deSokolova, Lemercier e Garcia (2013)
Para cada componente view na aplicação, existe um presenter e um model. Cada componente implementa uma interface correspondente à sua respectiva camada. Opresenter comunica com a view pertencente através da interface implementada pelaview. Do mesmo
Capítulo 3. Desenvolvimento 46
modo, omodel comunica com opresenter através da interface implementada pelo presenter, similar ao padrão Passive MVC. Dessa maneira, é possível que model retorne informações após a finalização de uma transação com o web service.
3.5.3 Model-View-ViewModel (MVVM)
O padrão Model-View-ViewModel (MVVM) é um dos componentes de arquitetura fornecidos no Android Jetpack. Assim sendo, o desenvolvimento da aplicação nesse padrão foi baseado nasGoogle Samples disponibilizadas noGitHub9. Como no exemplo, a aplicação desenvolvida aplica o padrãoMVVMcombinado a outros componentes de mesma categoria, sendo estes, o Data Binding que permite vincular de forma declarativa dados observáveis a elementos da User Interface (UI) eLiveData que possibilita a notificação das visualizações quando os dados subjacentes forem alterados.
O padrão Model-View-ViewModel (MVVM) aplicado em Android tem os seguintes componentes:
• Model: responsável pela manipulação dos dados, seja repositórios locais ou distantes, assim como nos padrões anteriores.
• View: renderiza informações para os usuários. É composta por componentes de interface do usuário, tais como arquivos .xml, activity, fragments e dialogs, como no padrão Model-View-Presenter (MVP).
• ViewModel: ajuda a manter o estado daview e realiza mudanças ou requisições no model a partir da interação do usuário na view.
Assim como para os demais padrões, foi elaborado um digrama que modela a estrutura da aplicação do padrão MVVM na funcionalidade de login, apresentado na Figura 21.
9 Disponível em:<https://bit.ly/2xQlMO6>
Figura 21 – Modelagem do login da aplicação desenvolvida com o MVVM
Fonte: Elaborado pelo autor (2019) adaptado deSokolova, Lemercier e Garcia (2013)
Em resumo, para cada componenteview na aplicação, existe um ViewModel cor- respondente. Por sua vez, assim como na aplicação do Passive MVC existe um model para cada assunto. O view está sincronizado com oViewModel por meio de observers e o ViewModel realiza chamadas diretas para os models e, também implementa listeners que
são usados por models para retorno dos dados após finalização das requisições.
3.5.4 Testes
Todas as versões das aplicações foram testadas utilizando dois tipos de testes: testes de unidade e testes de User Interface (UI). O JUnit10 foi utilizado para a realização dos testes de unidade, que foram construídos para testar principalmente pontos de validação dos dados de entrada da aplicação, tais como validação de senha, e-mails e formulários em geral. Só para exemplificar, a Figura 22 apresenta alguns dos testes construídos.
10 Disponível em:<https://bit.ly/2TTq3bW>
Capítulo 3. Desenvolvimento 48
Figura 22 – Exemplo de teste unitário construído
Fonte: Elaborado pelo autor (2019)
No que se refere aos testes de User Interface (UI), foi utilizado o framework Espresso11. Com o componente do Espresso, o Espresso Recorder é possível a criação de testes automatizados de User Interface (UI), a partir da gravação da interação com a interface do usuário. Como apresentado, todas as versões do aplicativo compartilham a mesma User Interface (UI). Em virtude disso, foi possível reutilizar os testes construídos com o Espresso Recorder em todas as versões das aplicações. A título de exemplo, a Figura 23 apresenta um dos testes construídos no contexto de login.
11 Disponível em:<https://bit.ly/2XIOnEp>
Figura 23 – Exemplo de teste de User Interface (UI) construído no contexto de login com framework Espresso
Fonte: Elaborado pelo autor (2019)