12 de Abril de 2019
Desenvolvimento Mobile iOS

2 benefícios mais comuns entre as arquiteturas iOS

O desenvolvimento de aplicativos iOS está cada vez mais popular. Os aplicativos estão mais robustos, as interações mais complexas, as funcionalidades mais desafiadoras e os times cada vez maiores. É fundamental que um novo membro de um time seja capaz de compreender e alterar a base de código de um app de forma fácil e rápida. Para garantir a sincronia desses times e a manutenibilidade do projeto, assuntos como arquitetura foram introduzidos nas empresas e têm sido altamente fomentados na comunidade desenvolvedora. Essas arquiteturas possuem algumas características que podem beneficiar muito os times de desenvolvimento e os projetos como um todo.

A arquitetura de software define a estrutura de um sistema, a comunicação entre os componentes que o compõe e visa garantir a integridade dos requisitos técnicos e operacionais. A arquitetura adotada pela Apple para o desenvolvimento de aplicativos iOS é o MVC (ModelViewController), representada no diagrama abaixo:

Onde:

  • View é responsável pelos componentes visuais e por receber ações do usuário
  • Model representa os objetos de uma aplicação
  • Controller é responsável pela interação entre Views e Models

 Na prática View e Controller são representados em uma única classe, chamada UIViewController, que possui outlets para os componentes visuais, recebe as ações do usuário, além de prover dados e garantir a atualização dos modelos. Visto que o objetivo da empresa é apenas expor suas APIs e exemplificar seus usos, esse arranjo cumpre com seu dever.

No entanto, os aplicativos tomaram novas proporções e muitas vezes são altamente complexos, gerando a necessidade de uma nova maneira de organizar o código, para garantir a reusabilidade e manutenibilidade do mesmo. Nesse âmbito, o MVC foi apelidado de Massive View Controller, já que todas as lógicas ficam nessa única classe, e novas propostas surgiram para tentar resolver esse problema.

Algumas das propostas mais conhecidas são MVP, MVVM, MVVM-C, VIPER e VIP (também conhecida como CleanSwift). Apesar de suas particularidades e por algumas abrangerem também a forma de lidar com a manipulação de dados e fluxo de navegação, todas as arquiteturas têm como objetivo principal garantir alguns benefícios. São eles: single responsibility e testabilidade.

 Single responsibility

É muito pertinente que ao desenvolver uma aplicação exista a garantia da single responsibility, isso é, cada classe deve ser responsável por apenas uma atividade, logo View não será responsável por chamadas HTTP e Model não saberá da interação do usuário com a aplicação, por exemplo.

Algumas arquiteturas, como VIPER e CleanSwift possuem camadas específicas para lidar com as requisições à APIs ou gerenciamento de banco de dados. Essas camadas podem ser encontradas pelos nomes middleware, interactor, service, entre outros. A ideia é que essas classes possam ser reutilizadas por diferentes fluxos ao invés de haver a repetição de código em múltiplas partes do código.

A maioria das aplicações são contidas de diferentes telas e fluxos de navegação, por isso as novas arquiteturas procuram maneiras mais eficientes de realizar a orquestração dessas telas. É daí que surgiram termos como coordinator e router, classes que sabem a ordenação das telas e fluxos e quais os dados necessários para a inicialização de cada um deles.

 Testabilidade

A popularidade dos testes vêm aumentando e os desenvolvedores estão cada vez mais preocupados com a garantia da qualidade de seus códigos. Através da separação de responsabilidades e isolamento de side effects, que devem ser garantidos pelas arquiteturas, é possível testar cada unidade de código e cada um dos módulos. Isso dá liberdade para que o desenvolvedor possa realizar alterações sem que bugs sejam introduzidos na aplicação.

Existem diferentes tipos de testes. Teste unitário, teste de integração e teste de interface. O primeiro visa garantir que uma unidade de código funciona em isolamento. O segundo, como seu próprio nome diz, visa garantir a integração entre módulos e que essa integração não crie side effects na aplicação. Já o teste de interface costuma ser mais manual e, apesar de sua popularidade no mundo de desenvolvimento, deve ser usado com certa cautela, pois são voláteis e bastante custosos.

Independente da quantidade e quais tipos de testes são aplicados a um projeto, a arquitetura escolhida deve sempre visar o aumento da cobertura de testes do código, possibilitando que alterações sejam feitas sem a necessidade de regressões e garantindo ao desenvolvedor a segurança de que o app continua operando com sucesso.

Não necessariamente o seu projeto vai se encaixar em uma dessas opções. Você pode criar a sua própria arquitetura ou adaptar uma existente para atender as características do seu projeto. Toda essa sopa de letrinhas deve servir como inspiração e o fundamental é manter a clareza, organização e separação do código de forma que a responsabilidade única de cada classe e sua testabilidade sejam garantidas.


Yasmin Benatti do Grupo Movile

Comentários