Structure d'un projet Lightbuild

Un projet Lightbuild sépare l'assemblage de l'application du code de l'application : un module d'application (ou "shell d'application") assemble votre application, et les modules de bibliothèque contiennent les fonctionnalités, l'UI et la logique métier de votre application. Cette page décrit la mise en page d'un nouveau projet Lightbuild, ainsi que le rôle de chaque module et fichier de compilation.

Mise en page du projet

Le modèle de projet Lightbuild par défaut comporte les fichiers et modules de compilation suivants :

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

Le projet comporte trois fichiers de configuration de compilation : un fichier project.lightbuild.yaml dans le répertoire racine et un fichier lightbuild.yaml dans chaque module. Chaque module comporte également un fichier resolved.deps. Pour en savoir plus sur les paramètres de chaque fichier de configuration, consultez la documentation de référence sur la configuration Lightbuild.

Module d'application

Les projets Lightbuild utilisent un module d'application comme base pour votre application. On l'appelle également "shell d'application", car il gère l'assemblage du projet sans contenir de code source. Toutes vos fonctionnalités et votre logique restent dans des modules de bibliothèque distincts, et le shell d'application se concentre sur la configuration finale, comme la signature et l'optimisation.

Le fichier lightbuild.yaml du module d'application définit le type du module sur application et spécifie la manière dont l'application finale est assemblée, y compris les éléments suivants :

  • L'identité de l'application : son ID d'application, son code de version et son nom de version
  • Les exigences du SDK de l'application : ses versions compileSdk, minSdk et targetSdk
  • Les modules dont dépend l'application, dans cet exemple app-core

Modules de bibliothèque

Les modules de bibliothèque contiennent le code que le module d'application assemble, comme les fonctionnalités de votre application, les composants d'interface utilisateur et la logique métier. Dans le nouveau modèle de projet, le module de bibliothèque app-core contient le fichier MainActivity.kt avec un exemple de code.

Le fichier lightbuild.yaml d'un module de bibliothèque définit la valeur type du module sur library. Les modules de bibliothèque définissent leurs versions compileSdk et minSdk, mais ils ne sont pas compatibles avec le paramètre targetSdk. Le fichier lightbuild.yaml d'un module de bibliothèque déclare également les dépendances, les processeurs KSP et les tests du module.

Plusieurs modules d'application

Un projet peut comporter plusieurs modules d'application. Lightbuild n'est pas compatible avec les types de produits et les types de compilation personnalisés au sens traditionnel. À la place, vous créez un module d'application distinct pour chaque version de votre application, par exemple les versions dev et prod, ou les versions free et paid.

Chaque module d'application dépend des modules de bibliothèque dont sa version a besoin. Les modules d'application peuvent partager des modules de bibliothèque, dépendre de différents modules de bibliothèque pour le code et les paramètres spécifiques à une version (comme des modules d'injection de dépendances distincts) et exclure les modules de bibliothèque pour les fonctionnalités qu'une version n'inclut pas.

Par exemple, un projet comportant des versions sans frais et payantes d'une application peut inclure les modules suivants :

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

Le fichier app-paid/lightbuild.yaml de la version payante dépend de tous les modules de la version payante :

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

Le fichier app-free/lightbuild.yaml de la version sans frais dépend du module core partagé et de son propre module d'ID, et omet le module premium :

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

Chaque module d'application possède ses propres paramètres, tels que son ID d'application et sa signature de version, ce qui vous permet de compiler, d'installer et de publier chaque version séparément. Pour créer une version spécifique, spécifiez son module d'application lors de l'exécution de la commande build. Exemple :

lightbuild build app-free

Dépendances résolues

Chaque module d'un projet Lightbuild inclut un fichier resolved.deps, qui enregistre toutes les dépendances résolues du module, y compris les dépendances transitives. Lightbuild génère automatiquement ce fichier, de sorte qu'il n'a pas besoin de résoudre les dépendances de manière dynamique chaque fois que vous ouvrez ou compilez votre projet. Vous ne devez pas modifier ce fichier manuellement.

Enregistrez vos fichiers resolved.deps dans le contrôle des versions, ainsi que les fichiers lightbuild.yaml de votre projet.

Pour verrouiller vos dépendances, par exemple dans un build d'intégration continue, ajoutez l'option --locked-dependencies à lightbuild resolve ou lightbuild test. Avec cette option, la commande échoue si un fichier resolved.deps ne correspond pas aux dépendances du module, au lieu de mettre à jour le fichier :

lightbuild resolve --locked-dependencies