Créer une application Android en 2025

Présentation de l’environnement de développement d’applications Android selon les standards actuels

• Build : gradle
• Configuration du build : convention plugin
• Gestion des dépendances : version catalog
• Adoption de build cache
• Analyse des performances du build : build-scan
• Organisation des modules : séparation par feature
• Réseau - retrofit
• Mapping JSON - kotlinx serialization
• Stockage persistant des données - jetpack datastore, room
• DI - koin
• Chargeur d’images - coil
• UI - compose
• Communication entre View et ViewModel - flow
• Gestion de la qualité du code - ktlint , konsist
• Tests unitaires - junit 4

[kipsong133]

Merci pour cet excellent article.

[ganadist]

En tant que personne qui s’est retrouvée un peu par hasard à se fixer comme ingénieur build d’applications Android, si je devais donner mon avis...

Build : gradle

Même si c’est extrêmement gros ou complexe, il faut utiliser gradle... (regard au loin)
Les projets ci-dessous sont en cours pour améliorer les performances de build de gradle sur des projets très volumineux ou complexes ; si vous utilisez gradle sur un gros projet, mieux vaut préparer la migration à l’avance.

• https://docs.gradle.org/current/userguide/configuration_cache.html
• https://docs.gradle.org/current/userguide/isolated_projects.html

Organisation des modules : séparation par feature

Personnellement, je ne pense pas qu’il soit nécessaire d’exposer les couches d’architecture au système de build.
Dans le cas de l’application que je gère, nous exposons au système de build les modules feature-api / feature-impl.

• feature-app :
  • modèle de données, ou interface liée à d’autres modules
• feature-impl:
  • implémentation réelle de la feature

Avec cette organisation, les changements de code dans feature-impl n’impactent pas les autres modules qui référencent feature-api (isolation des dépendances), ce qui aide beaucoup à améliorer les builds incrémentaux et le taux de hit du build cache.

Tests unitaires - junit 4

Je pense que la décision de Google y est pour beaucoup.

• https://issuetracker.google.com/issues/127100532
• Dans le cas de la plateforme Android, JUnit3 (qui ressemble à du JUnit4) est utilisé, et le framework de test des outils de build Android fonctionne sur une base JUnit4 ; Google a clairement indiqué qu’il n’avait pas l’intention de migrer vers JUnit5.
  Cela dit, le plugin de screenshot testing sorti récemment est basé sur JUnit5.

[ganadist]

Cela dit, quand on veut adopter les technologies les plus récentes (?), il arrive assez souvent que JUnit4 soit un frein, donc personnellement j’ai le petit espoir qu’on migre vers JUnit5.
https://docs.gradle.com/develocity/test-distribution/

On peut faire fonctionner des tests JUnit4 sur JUnit5 sans gros changements en utilisant junit-vintage-engine, mais le surcoût est assez important. (environ 20 % plus lent)

[kingori]

Quelle gloire pour la famille Huh !

[gera1d]

C'est Wilson !

[brainer]

Hum... soit dit en passant, ces dernières années, on observe un phénomène assez étrange : la plupart des startups choisissent Flutter, tandis que les grandes entreprises comme META et OpenAI s’orientent vers le natif...

[tsboard]

Justement, j’avais prévu de créer une app Android cette année, donc ça m’a été très utile comme guide. Haha.