The Social Project: Configurando o Tema e Identificando suas Builds

Padrão

Se você ainda não conhece as motivações deste projeto, leia o primeiro artigo aqui.

Olá pessoal! No último post configuramos o Firebase no projeto, ao mesmo tempo em que mantivemos os JSONs de configuração seguros no nosso CI. Hoje vamos começar a preparar nosso app para soltar as primeiras releases.

Trazendo para o projeto algumas experiẽncias que tive em projetos que participei, posso dizer que a diferenciação entre o app em tempo de desenvolvimento e as releases é um problema bastante menosprezado quando estamos trabalhando em um projeto. É muito comum chegarmos ao ponto de não saber ao certo qual é a versão que estamos utilizando, e a inconsistência de comportamento acaba por nos colocar em situações complicadas (como testar o app errado, inconsistência de dados, dentre vários outros).

O primeiro passo, a viabilidade de que tanto as builds de release quanto as de debug possam conviver harmônicamente no mesmo device já foi resolvido no post anterior, através do applicationIdSuffix para o build type de debug.

O que faremos agora é criar uma identidade visual diferente para cada um dos build types.

Aqui vai um aviso: como ainda não temos um design definitivo, ou uma identidade visual para o nosso aplicativo, vai ser algo meio grotesco mesmo, mais como um placeholder do que algo definitivo, ou apropriado para um produto final 🙂

Como ícone do aplicativo, utilizei um dos ícones do banco de ícones do Material Design. São ícones para os mais diversos propósitos, divididos em várias categorias, otimizados tanto para mobile quanto para web.

Sim. Esse é o ícone do nosso app! 😂

Para prosseguirmos, também utilizei a ferramenta de cores do site do Material Design, que me ajudou a encontrar uma combinação de cores com bom contraste e gerar as suas variações mais clara e mais escura. Assim, os nosso ícones ficaram:

Sendo o ícone da esquerda a versão do aplicativo de release e a versão da direita a versão do app de debug.

Aqui, basicamente a ideia foi inverter as cores primary e accent para cada um dos build types. Dessa forma, o aplicativo final terá o verde como primary e o laranja como accent, enquanto a versão de debug terá o laranja como primary e o verde como accent. (vamos ver como isso vai ficar ao longo do projeto – designers, me salvem aqui! 😂)

Para que essa façanha funcione no aplicativo, precisamos fazer uso das diferentes pastas de source. Como pode ser visto no repositório, basicamente eu dupliquei os resources relacionados ao tema e ao ícone, separando suas respectivas versões em src/debug/ressrc/release/res. É importante salientar que os resources devem sempre ter o mesmo nome e os mesmos atributos nos XMLs para as duas pastas, caso contrário teremos problemas ao compilar o aplicativo.

O Android Gradle Plugin (AGP) tem esse mecanismo bacana. Com o mecanismo de build types (e flavors), conseguimos criar variações de um mesmo app facilmente. Da forma como fizemos, o aplicativo de debug será criado mesclando o conteúdo de src/mainsrc/debug, enquanto o de release será criado com o conteúdo de src/mainsrc/release.

Bom, aproveitando, também atualizei algumas coisas no repositório, como o Kotlin para a versão 1.2.31, e o Google Play Services (e Firebase) para a versão 12.0.1. Também atualizei o AGP para a versão 3.1.0, dando suporte ao Android Studio 3.1.

Com isso, tanto nosso app em debug e em release podem conviver em harmonia dentro do mesmo dispositivo.

E é isso! Lembrando que o código já foi mergeado e está disponível na branch develop do projeto.

Até a próxima!