⚙️ In this PR a setup the dependecies to create a test for navigation compose like:

• Updating junit version
• Add test library for Dagger Hilt
• Setup the same version of the Dagger Hilt to libraries
• Created a Custom Test runner to instrumented tests and setup it up in the build.gradle file
• Created a Hilt Activity to inject test modules to the tests

🧑‍🔬 Tests: I created a Navigation test class. In this class I check if loaded the Search Screen and try to navigate to the Pokémon detail screen

🩰 Next Steps:

• Inject the test module into the unit tests

This PR creates a navigation graph using Jetpack Compose Navigation library and creates a navigation graph for the pokemon search.

Also adds coil library to fetch remote images and handle image caches.

Next steps: add navigation tests

Esse PR migra o uso da api do pokemon-graphql para a PokeAPI.

O que foi feito:

• Adicionando Retrofit
• Removendo uso do apollo-graphql
• Alterando o resultado dos datasources remotos para Result do Kotlin
• Criando CallAdapter para lidar com retorno com Result no Retrofit

Próximos passos:

• Tratar melhor estados de UI
• Criar uma Home para listar: Pokemons, Movimentos e Jogos

Esse PR adiciona a capacidade de testar repositórios ao projeto.

• Adição das bibliotecas para tetar coroutines
• Ajustes no uso do Flow
• DataSource expondo somente o objeto de dominio e não mais um objeto do Apollo

Próximos Passos

• Adicionar teste aos mappers usados no DataSource
• Alterar o uso de Resource para Result no DataSource

Descrição

Para isolar as classes de graphql na camada de datasource, o repositório vai ficar com a responsabilidade de transformar as classes de datasource em classes de dominio para dentro da aplicação.

Aqui futuramente seria interessante tratar melhor os erros do graphql

Solução

• Adicionado mappers na camada dos repositories para converter objetos do graphql em modelos do repositório

Próximos passos

• Adicionar testes nas viewmodels, repositories e use cases

Descrição

Esse PR converte a abstração de apollo response para a abstração de resource do projeto.

Lembrando que: A abstração de resouce serve para buscar dado dos datasources, tanto local quanto remoto, informando o estado da operação:

• Carregando
• Sucesso
• Erro

Esse é o primeiro passo para separar a dependencia do graphql somente na estrutura do datasource, removendo a dependência dele dentro da camada de domínio do projeto.

Solução

• Retornando um flow da camada de datasource contendo um resource
• Adicionado tratamento do estado do resource na activity iniciando o tratamento de erros na aplicação

Próximos passos

• Melhorar o tratamento de erro
• Separar talvez o resource de domain
• Transformar o objeto do GraphQl em um model do projeto

Descrição

Agrupa todas classes utilitárias para criação de um projeto android no pacote core (talvez no futuro possa virar um módulo ou até uma outra lib).

Dessa forma o projeto fica organizado da seguinte forma:

project
    | buildSrc // Configurações de dependencias gradle do projeto
    | app // configurações principais do projeto
        | features // features da aplicação
        | core // classes da arquitetura e utilitários do projeto
            | coroutines // classes utilitárias para trabalhar com coroutines
            | datasource // classes utilitárias para trabalhar com datasources remotos e locais do projeto
            | di // classes com para prover componentes para injeção de dependência da arquitetura do projeto
            | logs // classes para trabalhar com logs no projeto  
         

Solução:

Migrado para arquitetura descrita acima

Descrição

Melhora a divisão de responsabilidades da aplicação, deixando mais claro o que a camada de datasource e domain devem fazer.

Solução:

• Adicionado o uso do flow na cama da data source
• Divindo melhor a aplicação em datasource, domain e view
• Movendo a dependência do apollo somente para a camada de datasource
• Adicionado a abstração de Resource, para buscar informação do datasource

Próximos passos

• Remover a dependência das classes geradas do apollo da camada de domain, pra remover dependência da aplicação da api
• Adicionar testes nas viewmodels

Descrição

Biblioteca adicionada para que seja possível mockar objetos como o Apollo.

Solução

• Adicionada versão e biblioteca ao arquivo Dependencies.kt
• Adicionado biblioteca no build.gradle

Próximos passos

• Adicionar teste de viewmodel

Descrição

Esse PR adiciona um framework para trabalhar com courotines em viewmodels.

Solução

• Adicionada abstração para trabalhar com os coroutine dispatchers
• Adicionada abstração para contextualizar os dispatchers com a viewmodel
• Criada uma abstração(CoroutineViewModel)) de ViewModel para lidar com courotines.

Próximos passos

• Adicionar testes nas viewmodels
• Criar abstração de Viewmodel para trabalhar com requests e retries

Descrição

Ao ser feito commit para main, automaticamente é gerada uma tag e uma release com o código da versão.

Solução

• Foi adicionada um action para fazer release
• A versão é retirada do arquivo: BuildConfigVersions.kt, do módulo buildSrc

Próximos passos

• Tag ser gerada em cima do número da build e não do version name