Android: Modularização de Android

Você já deve ter ouvido falar em modularidade de Android; em algum momento do desenvolvimento do Android, certo? Se não, não há problema. Essa série também é para você que quer aprender do zero.

A maior motivação para escrever esta série de artigos; é para que mais desenvolvedores possam acompanhar essa “nova” abordagem que é amplamente utilizada no desenvolvimento Android.

Domain Module:

Vamos falar primeiro do domínio, que é responsável pela comunicação com o módulo de apresentação; e também é um módulo kotlin/java puro, ou seja, não há dependência do Android.

Conteúdo do domínio:

Entity: é nossa entidade, apenas os dados que queremos enviar para o ViewModel/Presenter; ou seja, os dados mapeados do backend.
Caso de Uso; É aqui que faremos as regras de negócios com base nos dados solicitados do repositório. Supondo que seja mascarado; as alterações feitas aqui não devem afetar outros módulos do projeto; assim como as alterações em outros módulos não devem ser refletidas no UseCase.
Repositório: É uma interface de comunicação que solicita dados do backend ou cache.

Fluxograma de domínio do módulo.

A apresentação pede alguns dados ao UseCase, o UseCase pede ao repositório; e este vai até onde está implementado. Os dados chegam ao UseCase, que pode aplicar algumas regras de negócio; e retornar os dados para a representação.

Agora vamos começar a desenvolver esse modulo passo a passo:

Começar um projeto novo
Selecionar Empty Acitivity
Colocar o nome que você quiser no projeto(usei MyModuleExample)
Usar Android X
E coloque o minSdk = 20

Criamos nosso projeto, agora vamos criar nosso domínio:

A primeira coisa que fazemos pode não ser específica do domínio, mas precisa ser feita no início do desenvolvimento do projeto.

Vamos criar um arquivo de dependências onde centralizaremos as dependências do gradle do nosso projeto como bibliotecas, suas versões e outras coisas. Ao longo do projeto, melhoraremos os arquivos conforme necessário. Primeiro, vamos criar o arquivo, usá-lo para configurar o build.gradle do projeto e configurar as dependências do nosso domínio. comece a trabalhar:

Crie um arquivo no diretório raiz do projeto e nomeie-o como dependencies.gradle.
Nesse arquivo, coloque a versão da biblioteca e uma lista de dependências e suas versões nomeadas anteriormente.

Agora ja podemos utilizar no nosso projeto.

Primeiro, configuramos no build.gradle do projeto:

Configuração: Aplicar de “dependencies.gladle” no buildScript
Definindo a versão: Curiosamente, quando queremos usar essa abordagem, temos que usar aspas duplas nas dependências, portanto, use $kotlinVersion para definir a versão.
// Arquivo de construção de nível superior onde você pode adicionar opções de configuração comuns a todos os subprojetos/módulos.




Agora podemos configurar as dependências da nossa domain(FINALMENTE!!)

Vamos ao build.greadle da domain e vamos criar uma variável dependencies que capta todas as dependências do arquivo que criamos anteriormente e, com isso, podemos utilizar as que queremos implementar como no gist abaixo.

Mas qual o motivo de criar isso tudo para um projeto simples?

Simples ou não, o projeto mantém todas as dependências em um só lugar, ou seja, se outros módulos utilizam RxJava, por exemplo, com essa abordagem garantimos que todos os módulos tenham a mesma versão da lib. Com isso, evitamos que um módulo tenha uma versão diferente dos demais; e quando queremos atualizar para uma nova versão, todos os módulos são atualizados. Portanto, não importa se o projeto é simples ou não, sempre queremos pensar em evitar retrabalhos no futuro e tentar construir a estrutura mais limpa possível.

AGORA VAMOS PARA DENTRO DA DOMAIN!

Obs: nosso projeto mostrara uma lista de jobs Android e vamos utilizar a seguinte api; http://demo8470178.mockable.io/android-jobs

Vamos ter 4 pacotes na domain:

Entities: é onde vamos criar nossas data classes. E a primeira que vamos criar será AndroidJob:

Repository:

Aqui ficam nossas interfaces de comunicação com o module data(próximo artigo); e segue nosso primeiro repository, que vai retornar uma lista observável de AndroidJobs:



Podemos verificar no construtor que temos duas dependências necessárias para usar o UseCase;  o repositório do qual solicitaremos uma lista de dados e um agendador; para informar a thread onde assinaremos nossas chamadas. Essas duas dependências serão passadas pelo framework koin usando injeção de dependência.

Di: apenas um pacote para centralizar as dependências desse module de Android:


Criamos uma variável chamada useCaseModule que receberá um modulekoin, neste módulo as dependências que iremos fornecer são. Eu uso uma fábrica porque quero que ela crie uma nova instância toda vez que essa dependência for necessária. Temos repositório = get(), onde get significa que essa dependência foi criada em algum lugar do projeto. Vamos apenas disponibilizá-la no UseCase, para scheduler = Schedulers.io(); passamos o que queremos que o Scheduler use, neste caso é IO, mas pode ser computação etc.


Nosso projeto ainda não fez nada, mas estamos construindo de forma incremental. Por isso, nossa recompensa por enquanto é nos contentarmos apenas em criar domínios.

O ideal é que os testes sejam aplicados nesta fase mas primeiro vamos entender; o conceito de modularidade e quando terminarmos vamos começar a implementar os testes.