Estrutura do projeto do Lightbuild

Um projeto do Lightbuild separa a montagem do app do código dele: um módulo de app (ou "shell do app") monta o app, e os módulos de biblioteca contêm os recursos, a interface e a lógica de negócios do app. Nesta página, descrevemos o layout de um novo projeto do Lightbuild e o papel de cada módulo e arquivo de build.

Layout do projeto

O modelo de projeto padrão do Lightbuild tem os seguintes arquivos e módulos de build:

MyApp/
├── project.lightbuild.yaml  # Project-wide settings
├── app/                     # App module
│   ├── lightbuild.yaml
│   └── resolved.deps
└── app-core/                # Library module
    ├── lightbuild.yaml
    ├── resolved.deps
    └── src/                 # The app's source code

O projeto tem três arquivos de configuração de build: um arquivo project.lightbuild.yaml no diretório raiz e um arquivo lightbuild.yaml em cada módulo. Cada módulo também tem um arquivo resolved.deps. Para detalhes sobre as configurações em cada arquivo de configuração, consulte a referência de configuração do Lightbuild.

Módulo do app

Os projetos do Lightbuild usam um módulo de app como base para o app. Ele também é chamado de "shell do app" porque processa a montagem do projeto sem conter nenhum código-fonte. Todos os recursos e a lógica permanecem em módulos de biblioteca separados, e o shell do app se concentra na configuração final, como assinatura e otimização.

O arquivo lightbuild.yaml do módulo do app define o type do módulo como application e especifica como o app final é montado, incluindo o seguinte:

• A identidade do app: o ID do aplicativo, o código da versão e o nome da versão.
• Os requisitos de SDK do app: as versões compileSdk, minSdk e targetSdk
• Os módulos de que o app depende, neste exemplo, app-core.

Módulos de biblioteca

Os módulos de biblioteca contêm o código que o módulo do app monta, como os recursos, os componentes de interface e a lógica de negócios do app. No novo modelo de projeto, o módulo de biblioteca app-core contém o arquivo MainActivity.kt com um exemplo de código.

O arquivo lightbuild.yaml de um módulo de biblioteca define o valor type do módulo como library. Os módulos de biblioteca definem as versões compileSdk e minSdk, mas não são compatíveis com a configuração targetSdk. O arquivo lightbuild.yaml de um módulo de biblioteca também declara as dependências, os processadores KSP e os testes do módulo.

Vários módulos de app

Um projeto pode ter mais de um módulo de app. O Lightbuild não é compatível com variações de produtos e tipos de build personalizados no sentido tradicional. Em vez disso, crie um módulo de app separado para cada versão do seu app, como as versões dev e prod ou as versões free e paid.

Cada módulo de app depende dos módulos de biblioteca necessários para a versão dele. Os módulos de app podem compartilhar módulos de biblioteca, depender de diferentes módulos de biblioteca para códigos e configurações específicos da versão (como módulos de injeção de dependência (DI) separados) e deixar de fora módulos de biblioteca para recursos que uma versão não inclui.

Por exemplo, um projeto com versões sem custos financeiros e pagas de um app pode ter os seguintes módulos:

MyApp/
├── project.lightbuild.yaml
├── app-free/   # App module for the free version
├── app-paid/   # App module for the paid version
├── core/       # Library module that both versions use
├── di-free/    # DI module for the free version
├── di-paid/    # DI module for the paid version
└── premium/    # Library module for paid-only features

O arquivo app-paid/lightbuild.yaml da versão paga depende de todos os módulos da versão paga:

android:
  applicationId: com.example.myapp.paid
  dependencies:
    module:
      - //core
      - //di-paid
      - //premium

O arquivo app-free/lightbuild.yaml da versão sem custo financeiro depende do módulo compartilhado core e do próprio módulo de DI, deixando de fora o módulo premium:

android:
  applicationId: com.example.myapp.free
  dependencies:
    module:
      - //core
      - //di-free

Cada módulo de app tem as próprias configurações, como o ID do aplicativo e a assinatura da versão, para que você possa criar, instalar e publicar cada versão separadamente. Para criar uma versão específica, especifique o módulo do app ao executar o comando build. Exemplo:

lightbuild build app-free

Dependências resolvidas

Cada módulo em um projeto do Lightbuild inclui um arquivo resolved.deps, que registra todas as dependências resolvidas do módulo, incluindo as transitivas. O Lightbuild gera esse arquivo automaticamente para que não precise resolver dependências de forma dinâmica sempre que você abrir ou criar seu projeto. Não edite esse arquivo manualmente.

Verifique os arquivos resolved.deps no controle de versões, junto com os arquivos lightbuild.yaml do projeto.

Para bloquear as dependências, por exemplo, em um build de CI, adicione a flag --locked-dependencies a lightbuild resolve ou lightbuild test. Com essa flag, o comando falhará se um arquivo resolved.deps não corresponder às dependências do módulo, em vez de atualizar o arquivo:

lightbuild resolve --locked-dependencies