Olá!!! Esse é meu segundo artigo sobre como integrar SwiftUI às arquiteturas mais comuns. No artigo anterior, eu falei como integrar SwiftUI com MVC e agora vou falar sobre MVP.
Se você leu meu último artigo, fico feliz em falar com você de novo. Se não, fico feliz em falar com você agora, e sugiro que leia o artigo de MVC.
Eu vou continuar de onde parei e fazer algumas comparações, mas ainda será possível entender esse artigo separadamente.
Então, vamos começar.
- • •
MVP
A arquitetura MVP consiste em três componentes:
- Model: Serviços, provedores de dados, gerenciadores, e entidades que representam os dados da aplicação. Os elementos dessa camada são responsáveis por coisas como requisição de rede, persistência, parser de informações e assim por diante.
- View: Responsável por renderizar a tela, receber ações do usuário e informar o presenter sobre elas.
- Presenter: Recebe ações a partir da view, faz as requisições necessárias para a camada de modelo para lidar com as ações apropriadamente, e formata os dados para serem apresentados na view.
Se você não está familiarizado com MVP, possivelmente está dizendo:
Espera um minuto, isso é só MVC substituindo ViewController por Presenter. Isso está certo?
E, bem, realmente parece isso, mas tem algumas diferenças. No MVP com UIKit, o UIViewController é considerado como parte da view e a responsabilidade do Controller do MVC passa para o presenter.
Mas por quê? Como isso muda as coisas?
Lembre-se que UIViewControllers também lidam com o ciclo de vida da view, com métodos como viewDidLoad, viewWillAppear e viewDidAppear. Consequentemente, eles se tornam muito difíceis de testar, porque esses comportamentos não são fáceis de mockar.
A ideia com MVP é mover a lógica para fora do ViewController, e colocá-la no presenter, assim podemos testá-la sem nos preocuparmos com o ciclo de vida da view.
Na verdade, o presenter é totalmente independente da view e não deve nem saber se está sendo utilizado UIKit, SwiftUI ou qualquer outra coisa. O que também torna mais fácil alterar o framework de UI utilizado, como faremos nesse tutorial.
- • •
MVP com UIKit
Primeiro, eu vou mostrar uma aplicação com MVP e UIKit, e depois vou mudar ela para SwiftUI. O app de exemplo basicamente apresenta uma lista de usuários e tem a opção de ordená-los por nome ou idade.
Primeiro, precisamos definir um serviço para carregar os dados e os modelos usados pela view. No caso, User e UserViewModel. O primeiro é o modelo retornado pelo backend e deve ser utilizado apenas por componentes com lógica de negócios (camada de model e presenter).
E o segundo é criado pelo presenter a partir do primeiro para ser usado especificamente pela view para renderizar as informações. Essa é uma boa prática porque torna a view independente das respostas do servidor.
Em seguida, nós criamos o presenter, exibimos seus métodos através do UserPresenterProtocol, e delegamos alguns métodos de renderização para a view, usando o protocolo UserPresenterDelegate. Dessa forma, o presenter depende da interface, em vez de depender da implementação concreta da view (princípio da inversão de dependências), tornando mais fácil substituir a view e criar componentes mocks que implementam esses protocolos, para testar o presenter.
Note também que o presenter lida com como os objetos são apresentados, ordenando eles, criando o campo nome, e transformando a data de nascimento em uma string com a idade do usuário. E ele não possui nenhum elemento do UIKit, IBOutlets ou IBActions.
E, finalmente, nós fazemos o UsersViewController implementar o protocol PresenterDelegate.
Mas agora, a pergunta principal:
- • •
Como usar isso com SwiftUI?
Bom, nós seguiremos uma abordagem muito similar a que foi utilizada no tutorial de MVC. Iremos substituir o UIViewController por uma Store, e fazer a Store implementar o PresenterDelegate:
Então, nós criamos a view usando SwiftUI e a fazemos ter uma referência para a store e para o presenter. Desse jeito, ela pode renderizar o estado de acordo com a informação da store, e chamar o presenter para lidar com ações do usuário e carregar dados.
Basicamente, a view envia eventos para a store, que envia para o presenter, que então lida com elas da mesma forma que faria no MVC. Depois, chama a store utilizando os métodos do delegate para atualizar seu estado.
Uma vez que a store atualiza sua propriedade local que controla o estado, a mudança é publicada utilizando o framework Combine, informando a view para se recarregar, pois ela tem a store como um observed object (objeto observado).
Note também que no exemplo foi utilizada a mesma prática do artigo anterior, decompondo a view em várias views menores.
Então temos uma view para cada estado: LoadingView, ErrorView, EmptyStateView e UsersDisplayView. E uma outra view (UsersView) para controlar o estado a ser apresentado e se comunicar com o presenter.
Note também como cada componente é pequeno e tem uma responsabilidade bem clara, e como foi fácil substituir o UIKit por SwiftUI quando utilizamos MVP. O presenter e o model não tiveram nenhuma alteração.
. No próximo artigo eu vou falar sobre VIPER e Clean Swift, que são arquiteturas mais complexas e frequentemente utilizadas. Fique ligado(a)!
