- O App Pokedex é um explorador de pokemons para os entusiastas desse universo, ele conta com filtros e buscas para encontrar o seu pokemon favorito.
https://drive.google.com/file/d/10D9Em32LNbHE7Jod44365ZSFKfvOOlt5/view?usp=sharing
- Mecanismo de busca por nome ou id do pokemon
- Filtragem por tipo de pokemon
- Ordenação por ordem alfabética ou id(crescente)
- Modal com detalhes do pokemon
- Opção de abrir um pokemon relacionado dentro do modal de outro pokemon
Durante o desenvolvimento do projeto foi notado que a resposta da API de pokemons não permite passagem de parametro para filtro, então, para evitar o trabalho de realizar várias requisições que buscariam todos os pokemons todas as vezes que for solicitado, foi implementado um cache local que vai ser usado para salvar localmente os pokemons e pode ser útil no caso de não haver conexão com a internet, sendo possivel com um movimento de refresh fazer a busca dos dados na API.
Alguns dados dos pokemons exibidos no Modal dos detalhes estão sendo gerados randomicamente pois não estão presentes na resposta da API fornecida
Conectividade: Para que o app continue funcionando mesmo sem acesso a internet foi implementado o cache dos pokemons, é realizado uma validação de conexão para isso e o consumo em diante é feito dos pokemons salvos localmente, podendo ser atualizado com o gesture de refresh na tela principal.
Snack Bar e avisos: Foi adicionado alguns SnackBars para alertar o usuário falhas, respostas vazias e similares...
Retry Logic: Foi criado um interceptor que tenta refazer a requisição se ela entrar em alguns critérios de resposta
- Flutter: 3.32.0
- Dart: 3.8.0
- flutter_bloc: 9.1.1
- dio: ^5.9.0
- flutter_dotenv: ^6.0.0
- flutter_modular: ^6.4.1
- result_dart: ^2.1.1
- flutter_svg: ^2.2.2
- shared_preferences: ^2.5.3
- connectivity_plus: ^7.0.0
Para o desenvolvimento do presente projeto foi abordado o uso do Clean Architecture e gerencimento da camada de apresentação baseando-se em eventos, apesar de ser um projeto pequeno, a forma que o projeto está apresentado busca trazer uma alta flexibilidade para sua continuidade uma vez que a filosofia baseada vem de principios básicos como inversão de dependencia, separação de responsabilidades e outros.
A estrutura atual do app conta com 3 camadas, (Data, Domain e Presentation)
A camada da Data fica por conta das implementações relacionada aos dados, conta com Classes DataSources que são responsáveis por buscar o dado de X localidade. USO: Obtenção de dados remoto e local.
Intermediário(Data/Domain) Para que os dados saiam de um DataSource é utilizado uma Classe Repository para armazenar lógicas relacionadas a infra/localidade do dado. USO: Gerenciamento de onde viria os dados dos pokemons com ou sem internet.
A camada Domain fica responsável por definir regras de negócio usando UseCases e armazenar as DTOs(classes modelos -> pokemon.dart) USO: Não foi julgado necessário o uso de UC pois não houveram regras de negócios que requisitasse estar dentro de um UC, os repositories só possuem lógicas relacionadas aos dados/localidade/infra como dito
A camada de apresentação é responsável por gerenciar a UI, foi utilizado o BLoC para criar estados bem definidos da tela e captar eventos de interação do usuário. USO: Tela de listagem de pokemons e detalhes dos mesmos.
Foi Utilizado o BLoC como gerenciador de estado, além de estar entre os pacotes recomendados o padrão BLoC é muito bom em separar responsabilidades de lógica e UI, apesar de ser um pouco mais trabalhoso o seu desenvolvimento, ele facilita o processo de manutenibilidade das features já que sua estrutura permite separar bem as chamadas por eventos, além de tornar fácil a emissão de um novo estado para a tela de forma robusta.
- Flutter SDK >= 3.32.0
- Dart SDK >= 3.8.0
- Android Studio / Xcode
- Java 17
- Cocoapods last-version
- Clone o repositório
- Execute
flutter pub get - Execute
flutter run
flutter run
flutter test
Além de ser um pacote recomendado ele foi extremamente útil já que ele faz o gerenciamento das dependencias e rotas do app, além disso caso o projeto crescesse ele seria um ótimo gerenciador pois consegue segregar em módulos, separando contextos, facilitando trabalho de times maiores simultanemanete e injetando modulos somente quando necessário ajudando no desempenho. Mas poderia ter usado get_it e go_route no lugar.
Conforme dito no 3.4, o BLoC um pacote recomendado, separa muito bem a lógica da UI, responsabilidades e contextos bem definidas graças aos eventos.
Foi Escolhido o Dio como pacote para realizar as solicitações REST pois nos requisítos era necessário implementar Interceptors, o pacote é bem robusto para isso e é mais completo do que outros como o http.
Mesmo se tratando de uma API open source "eu quis trazer o pacote para armazenar a base url que o projeto consome pois acredito muito na proposta de segurança de esconder as URLs da aplicação", mas resolvi subi o arquivo no commit pela praticidade de quem for testar meu projeto.
Sou muito adepto em trazer esses auxiliadores de tratamento de resposta pois são muito úteis para entender o erro, facilita a implementação da camada de apresentação saber oque deve ser feito para o usuário, fora que os tests unitários também ficam bem organizados também.
O design possui alguns SVGs e esse pacote foi prático de apresenta-los.
Foi desenvolvido a capacidade de armazenar localmente os pokemons e o pacote é prático de configurar. Foi descartado usar pacotes de banco de dados relacional por se tratar de poucos tipos de dados, se fosse mais dados diferentes talvez usaria algum banco de dados local.
Para decidir qual datasource iria trazer os dados precisei usar um pacote que me informasse o status de conectividade e esse me serviu bem.
Esse pacote foi usado para gerar a slash screen do app de forma mais rápida.
Para os testes foi utilizado os pacotes mocktail e bloc_test.
Durante os testes foi pretendido testar todas as camadas ditas na arquitetura do projeto, a ideia organizacional foi espelhar as pastas do projeto para pastas e arquivos dos testes para facilitar a manutenção, além disso os testes por exemplo foram realizado para cobrir o Success e Failure pois foi usado o result_dart para melhorar o tratamento de dados de uma camada para a outra, no Failure foi checado principalmente a natureza do erro e a mensagem, já no Success houveram casos de sucesso na resposta mas não era o caso perfeito e com o caso que tudo estava correto, dados esperados nos fixtures(stubs), tipagem...
Para testar a camada de apresentação foi usado o bloc_test pois precisa de uma simulação de dispare de eventos e acredito que com outras bibliotecas seria bem mais dificil de fazer isso, por sua vez eu busquei testar a tipagem e estados, quais foram chamados e como ficou o estado final.
Foi implementado o analytics do firebase dos nativos e através de uma bridge(popular MethodChannel) é invocado em uma classe de serviço bem genérica para possíveis criações de eventos, sendo necessário somente um nome e um Map para passar os dados(essa parte eu não desenvolvi bem no painel do firebase). Foi criado dois eventos:
- Abrir tela principal
- Escolher pokemon
A ideia é rastrear o uso e os pokemons mais consultados.