De projeto para projeto, percebemos que nosso código executa as mesmas funções e parece quase o mesmo. Isso nos faz pensar - não estamos fazendo o trabalho extra reescrevendo a mesma coisa? Começamos a copiar as aulas de projetos anteriores e ainda entendemos que estamos fazendo algo errado e certo - basta copiar as aulas de projeto para projeto, podemos facilmente perder / substituir / limpar alguma coisa, e se nossa equipe liderar mais algumas projetos simultaneamente, a detecção de erros nas classes emprestadas exigirá alterações manuais em todos os projetos. Cansados ​​de pisar neste rake, decidimos que precisamos de um código comum que será compartilhado em todos os nossos projetos e quaisquer alterações nele serão facilmente puxadas. Sim, estamos criando nossa biblioteca de componentes reutilizáveis! Você aprenderá sobre diferentes maneiras de organizar sua biblioteca, sobre todos os prós e contras das abordagens em cat :)

Existem várias maneiras de organizar nossa base de código comum:

1. Biblioteca Android (aar / jar)
2. Sub-módulo Git
3. Subárvore Git

Biblioteca Android (aar / jar)

Qualquer biblioteca para nosso aplicativo é composta por várias classes organizadas de uma certa maneira. Cada vez que conectamos algum Retrofit ou Dagger no build.gradle , carregamos a biblioteca como um arquivo aar / jar de uma das plataformas de publicação de bibliotecas. As plataformas de publicação de bibliotecas mais populares são o JCenter e o MavenCentral. Os desenvolvedores da biblioteca trabalham em seu repositório na nova versão e, quando a versão fica pronta para ser lançada no mundo, eles a publicam em uma das plataformas e dizem "Ei, lançamos uma nova versão da nossa principal biblioteca!". Tudo o que resta a ser feito para os desenvolvedores que usam essa biblioteca em seus projetos é alterar a versão no build.gradle e aproveitar os novos recursos. É conveniente? Palavra errada!

Mas quão conveniente é essa abordagem se nossa biblioteca estiver em desenvolvimento e atualizada todos os dias com novos recursos de diferentes desenvolvedores de diferentes projetos de nossa equipe? Vamos ver como fica na prática.

Criamos um repositório de nossa biblioteca, contribuímos com alguns recursos, depuramos e estamos prontos para compartilhá-lo com nossa equipe. Em seguida, aprenderemos sobre palavras como JCenter, MavenCentral, Bintray, Jitpack.io ... todas essas são plataformas para publicação de bibliotecas. Agora, a principal plataforma para projetos Android é o JCenter. Se você criar um projeto, verá que no build.gradle (nível do projeto) nos repositórios, o JCenter é especificado

repositories { google() jcenter() } 

Ou seja, se o desenvolvedor quiser conectar sua biblioteca, será suficiente para ele conectá-la ao nível do módulo build.gradle .

A maneira mais fácil de publicar a biblioteca para mim parece ser o Jitpack.io, algumas etapas e sua biblioteca está pronta para uso.

Como organizar o trabalho em equipe na biblioteca

Se criamos uma biblioteca e a carregamos no repositório, o restante da nossa equipe possui apenas o arquivo jar / aar recebido. Para que toda a equipe possa trabalhar em qualquer um - cada desenvolvedor deve esvaziar o repositório da biblioteca e fazer alterações nele.

Versionamento

Ao desenvolver e usar bibliotecas, é preciso lidar com um conceito como versionamento. Ou seja, o conjunto de alterações na biblioteca que queremos publicar deve ser corrigido pela versão. Isso ajudará ao atualizar a biblioteca para uma nova versão para entender como as alterações graves / graves foram feitas, graças ao esquema de versão adotado.

Verificando a biblioteca no projeto

Para verificar se as alterações efetuadas fazem o que pretendemos - é necessário verificar o comportamento do código escrito no projeto. Aumentamos a versão da biblioteca e ... aqui está um dos gargalos dessa abordagem. Nossa biblioteca e o projeto estão em repositórios diferentes, o que significa que não podemos simplesmente obter classes de biblioteca no projeto. Temos duas opções para verificar o novo código da biblioteca:

1. Crie um módulo no projeto de biblioteca de amostra no qual o código será gravado que verifica a funcionalidade da biblioteca. A opção é simples, mas existem 2 desvantagens: 1. Escrevemos código adicional; 2. O ambiente do módulo de teste é diferente do projeto real no qual usaremos a biblioteca e, se cometermos erros, ele aparecerá quando recebermos uma nova versão do projeto.
2. Publique as alterações no repositório mavenLocal local. Graças a essa abordagem, você pode obter um novo código no projeto, mas ele não será publicado para toda a equipe (mas você precisará mexer um pouco na configuração).

Sub-módulo Git

Na abordagem anterior, enfrentamos a dificuldade de obter novo código no estágio de desenvolvimento / depuração do projeto, pois a biblioteca e o código do projeto estão em diferentes repositórios e projetos de estúdio. A abordagem do Sub-módulo Git também envolve o uso de repositórios separados, mas permite que o projeto principal obtenha a biblioteca como um módulo usando o Git. Isso significa que o código da biblioteca estará disponível no projeto e todas as alterações imediatamente disponíveis no projeto!

Como isso funciona

Os submódulos permitem que você contenha um repositório Git como um subdiretório de outro repositório Git. Isso torna possível clonar outro repositório dentro do projeto, armazenando as confirmações para esse repositório separadamente.

Simplificando, temos 2 repositórios: um projeto e uma biblioteca. O repositório do projeto armazena o código da biblioteca e um link para o status do repositório da biblioteca. Portanto, o Git entende qual o estado (versão) da biblioteca que o projeto precisa.

Leia mais sobre como o Submodule do Git funciona aqui.

Como organizar o trabalho em equipe

Na abordagem do Git Submodule, o trabalho em equipe na biblioteca é organizado da seguinte maneira:

1. Ao criar um novo projeto ou conectar uma biblioteca a um projeto existente, uma nova ramificação Git do master é criada com o nome do projeto.
2. Quando chega a hora de reabastecer a biblioteca com alguma funcionalidade, uma ramificação para a tarefa (da ramificação do projeto) é criada e as alterações são feitas lá.
3. Uma revisão está sendo conduzida, os pools estão sendo despejados na filial do projeto. Quando alterações suficientes são digitadas para liberar a versão, um pool é criado na mesclagem da ramificação do projeto na ramificação principal da biblioteca.
4. Depois que o pool passa na revisão pela equipe responsável pela biblioteca e é derramado na ramificação principal, as equipes restantes do projeto serão notificadas da atualização da biblioteca que apareceu e decidirão sobre a atualização.

Versionamento

Quando o pool foi derramado no mestre e as equipes são notificadas da atualização da biblioteca, elas não estão cientes de quão globais são as alterações na nova versão. Afinal, a abordagem com o Git Submodule não requer nenhum esquema de versão. Mas esse problema é facilmente resolvido com a introdução de um esquema de versão. Tudo o que é necessário é escrever uma versão e descrição do que foi alterado e incluído na descrição da solicitação de pool na ramificação principal . Em seguida, os desenvolvedores entenderão o quanto eles podem realmente atualizar para a nova versão da biblioteca. Parece ótimo, mas a pergunta é:

Sim, o estúdio não sabe se comprometer separadamente com a lib conectada pelo submódulo. Eu uso o SourceTree para resolver esse problema. Esta aplicação é para Windows e Mac, e para Linux existe o GitKraken.

Subárvore Git

Git Subtree é uma versão aprimorada do Git Submodule. No Git Subtree, eles tentaram resolver os problemas que os desenvolvedores encontraram ao trabalhar com o Git Submodule, há um bom artigo no hub que descreve as diferenças entre as ferramentas. Embora eles funcionem de maneira diferente, eles resolvem um problema.

Conclusão

As ferramentas Git Submodule / Subtree são ótimas para resolver o problema de criar uma base de código comum para uma equipe envolvida em vários projetos. Uma das vantagens importantes é a verificação instantânea do novo código no projeto após fazer alterações na biblioteca. Nesse sentido, a abordagem padrão de publicação de uma biblioteca no JCenter ou no MavenCentral é inferior. Se você decidir levar o Submodule / Subárvore Git para sua equipe, pense com antecedência sobre o esquema de versão e crie regras / plugins para controlar a versão.

Grande reutilização para todos!