Struttura del progetto Lightbuild

Sperimentale: Lightbuild è un'anteprima sperimentale. Il suo design è ancora in fase di evoluzione e non supporta ancora tutte le funzionalità di build di Android. Per le app di produzione, i progetti esistenti o le nuove app ambiziose, continua a utilizzare Kotlin DSL. L'anteprima di Lightbuild è più adatta per app di piccole dimensioni, prototipi e demo. Per maggiori dettagli su ciò che supporta, consulta il confronto con Kotlin DSL e le note di rilascio.

Un progetto Lightbuild separa l'assemblaggio dell'app dal codice dell'app: un modulo dell'app (o "shell dell'app") assembla l'app, mentre i moduli della libreria contengono le funzionalità, l'interfaccia utente e la logica di business dell'app. Questa pagina descrive il layout di un nuovo progetto Lightbuild e il ruolo di ogni modulo e file di build.

Layout del progetto

Il modello di progetto Lightbuild predefinito contiene i seguenti file e moduli di 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

Il progetto ha tre file di configurazione di compilazione: un file project.lightbuild.yaml nella directory root e un file lightbuild.yaml in ogni modulo. Ogni modulo ha anche un file resolved.deps. Per informazioni dettagliate sulle impostazioni di ogni file di configurazione, consulta il riferimento alla configurazione di Lightbuild.

Modulo dell'app

I progetti Lightbuild utilizzano un modulo dell'app come base per l'app. Viene anche chiamato "shell dell'app" perché gestisce l'assemblaggio del progetto senza contenere codice sorgente. Tutte le funzionalità e la logica rimangono in moduli di libreria separati e la shell dell'app si concentra sulla configurazione finale, ad esempio la firma e l'ottimizzazione.

Il file lightbuild.yaml del modulo dell'app imposta il type del modulo su application e specifica come viene assemblata l'app finale, tra cui:

• L'identità dell'app: ID applicazione, codice versione e nome versione
• I requisiti dell'SDK dell'app: le versioni compileSdk, minSdk e targetSdk
• I moduli da cui dipende l'app, in questo esempio app-core

Moduli della libreria

I moduli della libreria contengono il codice assemblato dal modulo dell'app, ad esempio le funzionalità, i componenti dell'interfaccia utente e la logica di business dell'app. Nel nuovo modello di progetto, il modulo della libreria app-core contiene il file MainActivity.kt con il codice di esempio.

Il file lightbuild.yaml di un modulo della libreria imposta il valore type del modulo su library. I moduli della libreria definiscono le versioni compileSdk e minSdk, ma non supportano l'impostazione targetSdk. Il file lightbuild.yaml di un modulo della libreria dichiara anche le dipendenze, i processori KSP e i test del modulo.

Nota: per aggiungere un modulo, crea una directory che contenga un file lightbuild.yaml e aggiungi il nome del modulo all'elenco modules in project.lightbuild.yaml.

Più moduli dell'app

Un progetto può avere più di un modulo dell'app. Lightbuild non supporta le versioni prodotto e i tipi di build personalizzati nel senso tradizionale. Devi invece creare un modulo dell'app separato per ogni versione dell'app, ad esempio le versioni dev e prod o le versioni free e paid.

Ogni modulo dell'app dipende dai moduli della libreria richiesti dalla sua versione. I moduli dell'app possono condividere moduli di libreria, dipendere da moduli di libreria diversi per codice e impostazioni specifici della versione (ad esempio moduli di dependency injection (DI) separati) e omettere moduli di libreria per funzionalità non incluse in una versione.

Ad esempio, un progetto con versioni senza costi e a pagamento di un'app potrebbe avere i seguenti moduli:

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

Il file app-paid/lightbuild.yaml della versione a pagamento dipende da tutti i moduli della versione a pagamento:

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

Il file app-free/lightbuild.yaml della versione senza costi dipende dal modulo core condiviso e dal proprio modulo DI, mentre esclude il modulo premium:

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

Ogni modulo dell'app ha le proprie impostazioni, ad esempio l'ID applicazione e la firma della release, in modo da poter creare, installare e pubblicare ogni versione separatamente. Per creare una versione specifica, specifica il modulo dell'app quando esegui il comando build. Ad esempio:

lightbuild build app-free

Dipendenze risolte

Ogni modulo di un progetto Lightbuild include un file resolved.deps, che registra tutte le dipendenze risolte del modulo, incluse quelle transitive. Lightbuild genera questo file automaticamente, in modo da non dover risolvere le dipendenze in modo dinamico ogni volta che apri o crei il progetto. Non modificare questo file manualmente.

Esegui il check-in dei file resolved.deps nel controllo della versione, insieme ai file lightbuild.yaml del progetto.

Per bloccare le dipendenze, ad esempio in una build CI, aggiungi il flag --locked-dependencies a lightbuild resolve o lightbuild test. Con questo flag, il comando non va a buon fine se un file resolved.deps non corrisponde alle dipendenze del modulo, anziché aggiornare il file:

lightbuild resolve --locked-dependencies