Este repositório abriga uma implementação iOS do iddog, um app que exibe uma lista de cachorros filtrados por quatro raças para usuários autenticados.

• Estrutura do projeto
• Arquitetura
• Dependencências de terceiros
• Trade-offs
  • UI
  • Testes
• Stack
• Referências

A estrutura do projeto se assemelha a uma divisão por módulos, com algumas ressalvas. Estruturas de projetos iOS modulares são mais comumente usadas em apps de grande porte, pois normalmente cada feature pode ser seu próprio módulo, além dos componentes usuais como networking, autenticação, core e eventuais bibliotecas desenvolvidas in-house.

Esta versão do iddog é um app bem pequeno, que por si só não justificaria uma estrutura modular completa. Apesar disso, esta versão quase não faz uso de dependências externas, optando pela implementação in-house de eventuais bibliotecas necessárias. Por conta disso, tem-se os seguintes módulos:

• Authentication: persistência do token no keychain e modelo de credenciais
• Networking: camada de "serviço", com definição do client da API de cachorros e dos modelos do schema JSON dos retornos dos endpoints
• Redux: componentes necessários para a implementação de um fluxo de dados unidirecional, reativo e com gerenciamento de efeitos colaterais
• Streams: estruturas e operadores inspirados em RxSwift que implementam algumas noções de programação funcional reativa
• Application: código da aplicação de fato, com view controllers, views, coordinators, view models e outros componentes que fazem parte da camada de apresentação
• Pods: dependências de terceiros gerenciadas por CocoaPods

O app utiliza uma arquitura unidirecional de dados. Todos os dados consumidos pelas features ficam em uma única árvore em memória, que atua como a fonte de verdade do app. Estes dados ficam armazenados e protegidos pela store, uma estrutura de dados que cumpre três requisitos:

1. Controla as mutações da árvore de estados através de reducers
2. Recebe assinaturas de subscribers
3. Publica todas as alterações na árvore de estados para todos os subscribers

Os reducers são funções puras que calculam novos valores para o estado com base no estado atual e em mensagens que são emitidas pelos clientes da store. Estas mensagens, que chamaremos de actions, são a representação das interações entre o app e o mundo exterior, e são a única maneira fornecida pela store para causar transformações no estudo. Desta forma, torna-se impossível modificar o estado sem passar pelos reducers, fazendo com que os dados consumidos por todo o app estejam sempre em dia, consistentes e previsíveis.

Esta estrutura exige um mecanismo de gerenciamento de efeitos colaterais para que o app possa se comunicar com o mundo exterior (como APIs, bancos de dados, filesystems etc.). Este gerenciamento foi implementado nesta versão utilizando a noção de efeitos. Efeitos são unidades de código que podem se comunicar livremente com o mundo exterior, mas que só podem devolver os resultados dessa comunicação para a store por meio de actions. A store é o único componente da arquitetura capaz de executar estes efeitos, que são retornados pelos reducers como parte do pipeline de transformação do estado. Como os reducers apenas definem os efeitos não os executam, eles permanecem puro e pode ser testados de forma unitária e previsível.

O "mundo exterior" é representado pelos environments, objetos encarregados da injeção de dependências. A store recebe um environment global e cada reducer (em outras palavras, cada feature) recebe um environment local que é um subconjunto do environment global. Estes objetos nada mais são que getters para objetos de serviço que se comunicam com o mundo exterior, como clients de API ou de banco de dados, location managers, loggers etc.

Esta versão do iddog tentou fazer o mínimo uso de dependências externas, apoiando-se na filosofia de que dependências externas são código que não conhecemos e que não temos controle, tornando-se assim um portal para complexidade possivelmente indesejada.

Seguindo as recomendações do enunciado do desafio, optamos por usar dependências externas para a camada de rede e para o download e cache das imagens, além de um terceiro caso de uso: geração de enumerações para assets e strings. Geradores de código que enumeram assets, strings e outros recursos estáticos consumidos pela aplicação são muito úteis pois diminuem a possibilidade de erros causados por referências a recursos inexistentes ou erros de nomenclatura, além de permitir a verificação dessas referências em tempo de compilação.

O app faz uso das seguintes dependências externas:

• Alamofire: comunicação com a internet
• Kingfisher: download e cache de imagens
• SwiftGen: geração de código

Todas elas são baixadas, instaladas e gerenciadas utilizando CocoaPods.

Apesar de implementar um app muito simples, esta versão do iddog buscou ser um showcase de noções de arquitura, de filosofias de desenvolvimento e de padrões de projeto. De fato, mais tempo foi gasto na estrutura e na arquitetura do que de fato na implementação das features − uma decisão totalmente consciente.

Por conta disso, alguns trade-offs precisaram ser assimilados.

A camada de apresentação buscou seguir boas práticas e consistência na definição dos layouts e na organização da hierarquia de componentes, mas usou noções mínimas de UI e UX. O foco foi muito mais forte na construção de uma interface funcional que uma interface bonita e usável.

A base de código inclui apenas testes unitários e nenhum teste integrado nem testes end-to-end. Esta foi uma decisão tomada conforme o prazo foi chegando ao fim, utilizando os seguintes raciocínios:

• O app é muito simples e nenhuma das camadas implementa regras de negócio complexas
• Faltou organização e atenção ao cronograma durante o desenvolvimento, e os testes mais robustos foram despriorizados pela razão entre o custo de implementação e o valor agregado para o projeto.

• macOS 10.14.6
• Xcode 11.3.1
• Swift 5.0
• Ruby 2.7.1
• CocoaPods 1.9.3

• The Composable Architecture https://github.com/pointfreeco/swift-composable-architecture
• pointfree.co − Composable Architecture https://www.pointfree.co/collections/composable-architecture
• Modular Architecture in iOS https://medium.com/flawless-app-stories/a-modular-architecture-in-swift-aafd9026aa99