Jetpack — ce que c'est, composants d'architecture

Qu'est-ce qu'Android Jetpack ?

Android Jetpack est une collection de bibliothèques, d'outils et de directives architecturales de Google, présentée en 2018 lors de Google I/O. Jetpack a remplacé Support Library et Android Architecture Components, les fusionnant en un seul écosystème. Avant Jetpack, chaque bibliothèque Android était mise à jour indépendamment, créant des conflits de versions. Jetpack a synchronisé les versions sous un seul identifiant AndroidX et a introduit un modèle de versions majeures stables avec des correctifs mineurs.

Les bibliothèques Jetpack sont divisées en quatre catégories : Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Chaque catégorie traite les tâches d'une couche spécifique de l'application, de la gestion des données à l'interface utilisateur.

Philosophie de Jetpack

Google promeut trois principes Jetpack : accelerate development (moins de boilerplate, plus de logique métier), eliminate boilerplate (ViewModel élimine la sauvegarde manuelle d'état, Room élimine l'écriture de SQLiteOpenHelper) et build with confidence (chaque bibliothèque passe plus de 15 000 tests avant sa sortie). Selon Android Developers (2026), les applications utilisant Jetpack ont 30 % moins de crashes liés au cycle de vie.

AndroidX comme base

Toutes les bibliothèques Jetpack sont distribuées sous l'identifiant AndroidX (artefacts comme androidx.*). AndroidX a remplacé Support Library (artefacts comme com.android.support.*), divisant la bibliothèque monolithique en artefacts modulaires avec un versionnage indépendant. La migration vers AndroidX se fait via l'option android.useAndroidX=true dans gradle.properties — Android Studio convertit automatiquement les importations.

Composants d'architecture : ViewModel, Lifecycle, LiveData

ViewModel est le composant central de l'architecture Jetpack qui stocke les données de l'interface utilisateur. Contrairement à une Activity, qui est détruite lors de la rotation de l'écran, ViewModel reste en mémoire. L'utilisateur remplit un formulaire, tourne le téléphone — les données ne sont pas perdues. ViewModel est automatiquement nettoyé lorsque le LifecycleOwner (Activity ou Fragment) termine définitivement son cycle de vie (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Écran démarré")
    }
}

LiveData — un conteneur de données observable qui respecte le cycle de vie. Si l'écran n'est pas visible (onStop), LiveData n'envoie pas de mises à jour, ce qui évite les fuites mémoire et les crashs lors de la tentative de mise à jour d'une Activity inexistante. Lifecycle — une classe qui stocke l'état actuel (CREATED, STARTED, RESUMED) et permet à d'autres composants de s'abonner aux changements d'état. Ensemble, ViewModel, LiveData et Lifecycle constituent le fondement de l'architecture réactive d'Android.

ViewModelScope et coroutines

viewModelScope — un CoroutineScope intégré lié au cycle de vie de ViewModel. Toutes les coroutines lancées dans ce scope sont automatiquement annulées lors du nettoyage de ViewModel. Cela élimine la gestion manuelle de Disposable et CompositeDisposable dans chaque ViewModel. Pour travailler avec viewModelScope, la dépendance androidx.lifecycle:lifecycle-viewmodel-ktx est requise.

Room : travailler avec une base de données sur Android

Room est une bibliothèque ORM Jetpack qui fournit une couche d'abstraction sur SQLite. Au lieu d'écrire des requêtes SQL brutes et de convertir manuellement Cursor en objets, le développeur déclare une Entity (table), DAO (Data Access Object) et Database (point d'entrée). Room vérifie les requêtes SQL à la compilation via l'annotation @Query — si les tables ou colonnes n'existent pas, la compilation échoue avec une erreur claire.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

L'Entity User décrit une table avec trois colonnes. Le DAO déclare des fonctions suspend pour travailler avec les coroutines — la requête s'exécute automatiquement sur un thread d'arrière-plan. Room prend en charge les migrations via l'annotation @Migration : le développeur décrit le script SQL de transition entre les versions, et Room l'exécute sans perte de données. En l'absence de migration, Room lance IllegalStateException, protégeant ainsi les projets contre une perte accidentelle de données lors de la mise à jour du schéma.

TypeConverters et relations

Room ne stocke que les types primitifs et leurs wrappers. Pour stocker des listes, Date ou des objets personnalisés, on utilise @TypeConverter — une méthode statique qui convertit un type en String (JSON) ou Long (timestamp). Les relations entre tables sont modélisées via des objets imbriqués avec l'annotation @Relation et des classes POJO auxiliaires avec @Transaction pour des requêtes join efficaces.

Navigation Component : graphes et arguments

Navigation Component — une bibliothèque Jetpack pour gérer les transitions entre les écrans. Au lieu d'appeler manuellement FragmentTransaction, le développeur crée un graphe de navigation (fichier XML avec des nœuds de destination), et le système génère une classe Directions avec des méthodes de transition type-safe. Navigation Component garantit le bon fonctionnement de la pile de retour, des deep links et du passage d'arguments entre les écrans.

// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// Dans le code du fragment :
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

Les arguments userId sont passés dans le graphe de navigation avec une spécification de type (integer) et une valeur par défaut. La classe ProfileFragmentArgs est générée automatiquement par le plugin Navigation Safe Args — elle contient tous les arguments avec les types Kotlin corrects. Les deep links sont configurés dans le graphe : app:deepLink="app://profile/{userId}". Navigation Component analyse lui-même l'URL et crée la pile de retour comme si l'utilisateur avait navigué dans l'interface.

Bottom Navigation et navigation conditionnelle

Navigation Component s'intègre avec BottomNavigationView via NavController : chaque élément de menu est lié à une destination dans le graphe. Le changement d'onglets ne recrée pas le fragment — Navigation Component préserve l'état via NavBackStackEntry. Pour la navigation conditionnelle (afficher la connexion si non authentifié), on utilise navController.navigate(condition) avec une vérification dans onCreate.

AndroidX : la Support Library nouvelle génération

AndroidX est une architecture repensée de Support Library dans laquelle chaque bibliothèque a reçu son propre artefact avec une version indépendante. Au lieu d'un unique com.android.support:appcompat-v7:28.0.0, AndroidX propose androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 et ainsi de suite. Cela a éliminé le problème où différentes dépendances tiraient des versions différentes de Support Library, provoquant des conflits.

La migration vers AndroidX s'effectue automatiquement dans Android Studio 3.2+ via le menu Refactor → Migrate to AndroidX. Studio remplace toutes les importations dans les fichiers Java/Kotlin, les manifestes et les ressources. La rétrocompatibilité est le principal avantage d'AndroidX : les bibliothèques fonctionnent sur Android 5.0 (API 21) et plus, couvrant 97 % des appareils actifs selon Google Play Console (2025).

Principaux artefacts AndroidX

Les artefacts les plus utilisés : appcompat (thème sombre, Material Design sur les anciennes API), recyclerview (listes adaptatives avec ViewHolder), constraintlayout (conteneur flexible avec hiérarchie plate), cardview (cartes Material Design), preference (écran de paramètres avec style Material). Chaque artefact est versionné indépendamment, accélérant la livraison des correctifs sans mettre à jour l'ensemble du paquet.

Autres bibliothèques importantes de Jetpack

En plus d'Architecture et d'AndroidX, Jetpack inclut de nombreuses bibliothèques spécialisées pour les tâches typiques de développement mobile. WorkManager — pour les tâches d'arrière-plan avec exécution garantie (synchronisation, téléchargement de logs), prend en charge les tâches périodiques et différées, ainsi que les contraintes de réseau et de batterie. DataStore — un remplacement de SharedPreferences basé sur les coroutines, prenant en charge les propriétés typées (Preferences DataStore) et Protocol Buffers (Proto DataStore).

• Hilt — un framework DI basé sur Dagger qui simplifie l'injection de dépendances via les annotations @HiltViewModel, @Inject, @Module. Intégration native avec ViewModel et Navigation.
• Paging 3 — une bibliothèque pour le chargement paginé de données depuis le réseau/BD avec prise en charge de RemoteMediator (réseau + cache), StateFlow et Compose.
• CameraX — une API pour travailler avec l'appareil photo, abstrayant les différences entre fabricants (Samsung, Xiaomi, Honor) via une interface unifiée CameraController.
• Security Crypto — chiffrement des données via EncryptedSharedPreferences et EncryptedFile basé sur AES-256 avec une clé maîtresse dans Android Keystore.

Chaque bibliothèque a son propre SDK minimal et artefact. Google publie des versions majeures une fois par an (coïncidant avec la sortie d'Android) et des correctifs de sécurité trimestriellement. Recommandation — n'inclure que les bibliothèques nécessaires pour ne pas augmenter la taille de l'APK. La collection complète de Jetpack (tous les artefacts) pèse plus de 20 Mo, mais une application typique utilise 5 à 7 bibliothèques, ajoutant 3 à 5 Mo à l'APK.