Arquitetura iOS: usando MVC num App absurdo
Olá, desenvolvedores!
Somos Mirella Almeida e Ana Melo (estudantes de Design e Engenharia Biomédica, respectivamente) e fazemos parte do projeto Apple Developer Academy — UFPE. Recentemente, nós fomos desafiadas: tivemos duas semanas para desenvolver um “aplicativo absurdo” aliando preferências pessoais, uma tecnologia e uma API de uma lista de tópicos aleatórios.
Ao final do desafio, deveríamos relatar sobre nosso maior aprendizado durante o processo. Acabamos optando por algo que não estava previsto pelo desafio em si, mas que contribuirá e muito para nossa formação como desenvolvedoras daqui em diante: o padrão Model-View-Controller (MVC) de arquitetura iOS.
Conceitos Básicos
A arquitetura de software dita como será o esboço, a base de todo o fluxo de uma solução. Ela compreende desde estrutura e sincronização de dados, até protocolos de comunicação e análise estratégica de componentes operacionais.
Os padrões de arquitetura, como o próprio nome sugere, são modelos onde esse "esboço" será montado durante o desenvolvimento. São de suma importância no gerenciamento do projeto uma vez que podem ajudar a tornar o processo mais dinâmico, principalmente quando se trata de trabalhos em equipe.
Sua premissa é agrupar arquivos que se utilizam de uma estrutura parecida e respondem, também, de forma similar. Esses arquivos, geralmente, dividem-se em Models, Views e Controllers, que explicaremos individualmente mais abaixo. Na imagem abaixo vemos como organizamos nosso projeto no Xcode:
A saber, nossos interesses pessoais escolhidos para o desafio foram moda sustentável e decoração DIY, buscávamos explorar as animações nativas de UIKit e uma API aleatória sobre Animes e Mangás. Juntando tudo, fizemos o QuizFeed, um app absurdo parodizando os testes do BuzzFeed, no qual pedimos: “Escolha itens de moda e decoração low cost e te daremos um título de anime aleatório”! O teste consiste em três perguntas e ao final é gerado um número aleatório entre 1 e 10000 para localizar um ID de anime qualquer do MyAnimeList que a API contenha. Veja agora como organizamos o código do QuizFeed dentro do MVC:
Model
Onde os arquétipos, a estrutura dos dados é definida, além da lógica de manipulação de algumas variáveis presentes no projeto.
Colocamos aqui o struct da API que escolhemos e também os structs e inicializadores das imagens que ilustram as alternativas, presentes nas CollectionViews utilizadas.
View
É a parte responsável pelo visual, o que é mostrado ao usuário e onde ele pode interagir: exibe os dados, de acordo com o Model, mas não é responsável pelo armazenamento dos mesmos. Por conta disso, precisa constantemente ter conhecimento de alterações que possam ocorrer no Model.
As três primeiras telas do QuizFeed era basicamente feitas de uma UILabel com a perguta e uma UIColletionView com as alternativas correspondentes. Então, nossos arquivos eram voltados para disposição visual e aparência de UICollectionsViewCell.
Controller
O Controller atua como intermediário na troca de informações entre o que é recebido na View (interação do usuário) e na Model (os arquétipos e dados), ele confirma se a View tem acesso toda a estrutura que é elaborada e garantir que as devidas alterações sejam feitas.
Os arquivos .swift aqui contidos dizem respeito ao controle das “telas” do app propriamente ditas: uma para cada pergunta e uma para o resultado. Aqui são colocadas também as funções referentes às Collection Views de modo geral, inclusive definição de Sections e Groups e relaciona as informações sobre elas presentes nas demais divisões.
Services(*)
Usamos a pasta Services que, como dissemos anteriormente, é opcional. É indicada quando se precisa armazenar dados ou outras funções que não cabem necessariamente nas demais divisões. Por esse motivo, achamos melhor separar a montagem de arrays e o armazenamento de respostas do quiz para um arquivo DataServices.swift; também usamos o arquivo para armazenar a função de gerar um número randômico para a API.
Dito isso, vale ressaltar que usar MVC no seu projeto não é uma regra, ele é apenas um dos padrões que existem, assim como o Model-View-Presenter (MVP) e o Model-View-ViewModel (MVVM). Da mesma forma que adequamos nossas divisões às necessidades do nosso projeto, nenhum deles é a “resposta certa”, conhecê-los e testá-los pode te ajudar a saber qual se adequa mais ao seu estilo, seu projeto ou equipe. Desde que não fique com arquivos muito extensos nem seu código fique confuso/difícil de explicar para outros (ou até o seu “eu do futuro”), você está fazendo um ótimo trabalho!
É importante destacar, também, que nossa intenção era colocar uma explicação mais prática e simplificada, baseada na nossa (ainda) pequena experiência em código e em como exploramos o MVC no nosso projeto especificamente. Quer saber ainda mais? Então indicamos as seguintes leituras:
- A Documentação da Apple Developer sobre o MVC (em inglês) — que pode dar uma base mais teórica sobre o assunto, mas para a prática indicamos os textos seguintes
- MVC em iOS — Uma Abordagem Moderna (em inglês) — Esse é bemmmm explicadinho, e prevê um âmbito mais geral, considerando diferentes alternativas de uso.
- Entendendo os Padrões de Modelagem MVC, MVP e MVVM (em português) — como o próprio nome já diz, compara e explica um pouco sobre esse e outros métodos de arquitetura iOS
- Padrão de Design Idiomático MVC em Swift (em inglês) — Um passo a passo mais técnico e com modelos de códigos para montar em conjunto.
Pode até parecer contraditório usar uma ferramenta de organização, uma estrutura mais consolidada para fazer um app sem lógica. Mas a função do app absurdo era justamente essa: utilizar-se de métodos ainda não dominados, mesmo que não façam sentido juntos naquele momento, para construir conhecimento!
Esperamos que nossa construção tenha sido útil e até a próxima!😄
