viewModelScope : ce que c'est, liaison avec ViewModel et fonctionnement sous Android

Qu'est-ce que viewModelScope sous Android ?

viewModelScope est une propriété d'extension sur l'interface ViewModel, ajoutée dans la bibliothèque lifecycle-viewmodel-ktx (à partir de la version 2.1.0). Elle fournit un CoroutineScope prêt à l'emploi lié au cycle de vie de ViewModel.

// Internal structure (simplified)
val ViewModel.viewModelScope: CoroutineScope
    get() {
        val scope = this.getTag(JOB_KEY)
        if (scope != null) return scope
        return CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
            .also { setTag(JOB_KEY, it) }
    }

Le scope est créé de manière paresseuse (lazy) au premier accès et mis en cache via setTag. Il utilise SupervisorJob, ce qui signifie qu'une exception dans une coroutine enfant n'annule pas les autres. Le dispatcher par défaut est Dispatchers.Main.immediate, qui exécute le code sur le thread principal sans répartition supplémentaire si déjà sur Main.

Comment viewModelScope reçoit la notification de nettoyage

Lorsque le ViewModel quitte le cycle de vie (l'Activity est terminée ou le Fragment est supprimé), le système appelle clear(), qui déclenche onCleared(). Dans ce callback, viewModelScope annule son Job, ce qui termine récursivement toutes les coroutines actives. Le mécanisme est implémenté via l'interface Closeable, où le Job du scope est enregistré comme ressource pour fermeture automatique.

Comment fonctionne viewModelScope : liaison avec le cycle de vie de ViewModel

Le mécanisme de liaison de viewModelScope au cycle de vie de ViewModel est basé sur le marquage (tagging) et le callback onCleared. Voyons-le étape par étape.

Étape 1 : Création du scope au premier accès

Lorsque le ViewModel exécute viewModelScope.launch { ... }, le getter vérifie si un scope est déjà stocké sous le tag JOB_KEY. Si aucun scope n'existe, une nouvelle instance de CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate) est créée. Le scope est stocké dans le ViewModel via une map interne de tags.

Étape 2 : Cycle de vie des coroutines

Toutes les coroutines lancées via viewModelScope.launch ou viewModelScope.async deviennent enfants du SupervisorJob du scope. Elles s'exécutent sur le thread principal (sauf si un autre dispatcher est spécifié via withContext). Tant que le ViewModel est vivant, les coroutines peuvent être actives, suspendues ou terminées.

Étape 3 : Annulation lors de onCleared

Lorsque le système détruit le ViewModel, ViewModel.clear() est appelé. À l'intérieur de clear(), ce qui suit se produit :

• onCleared() est appelé pour la logique de nettoyage personnalisée
• Toutes les ressources Closeable enregistrées via addCloseable sont fermées
• Le Job de viewModelScope passe à l'état Cancelled
• Toutes les coroutines enfants sont annulées récursivement
• Les références au scope sont libérées pour le ramasse-miettes

Résistance à la rotation

Lorsque l'écran est tourné, l'Activity est recréée, mais le ViewModel survit (grâce à ViewModelStoreOwner). Cela signifie que viewModelScope reste actif et que les coroutines continuent de s'exécuter sans interruption. Après la recréation de l'Activity, le même ViewModel (et le même scope) est réutilisé — le chargement des données ne repart pas de zéro.

viewModelScope dans l'architecture MVVM

MVVM (Model-View-ViewModel) est l'architecture recommandée par Google pour les applications Android. viewModelScope y occupe une place centrale en tant qu'exécuteur d'opérations asynchrones.

Le rôle de viewModelScope dans les couches de l'architecture

Le ViewModel lance des coroutines via viewModelScope, à l'intérieur desquelles il appelle des fonctions suspend du Repository. Le résultat est transformé en StateFlow, qui est observé par la couche UI. Cette conception garantit une séparation claire des responsabilités et la testabilité indépendante de chaque couche.

Pourquoi viewModelScope dans ViewModel et pas dans Fragment

Si les coroutines étaient lancées depuis un Fragment, elles seraient annulées lors de la rotation de l'écran avec la destruction du Fragment. Le ViewModel survit à la rotation, donc les coroutines lancées dans son scope continuent de s'exécuter. C'est l'avantage clé de viewModelScope par rapport à lifecycleScope lors du chargement de données.

Exemples d'utilisation de viewModelScope

Examinons trois scénarios pratiques d'utilisation de viewModelScope dans une application Android avec Kotlin.

Exemple 1 : Chargement de données à la création du ViewModel

class ProfileViewModel(
    private val repo: ProfileRepository
) : ViewModel() {

    private val _profile = MutableStateFlow<Profile?>(null)
    val profile: StateFlow<Profile?> = _profile

    init {
        loadProfile()
    }

    private fun loadProfile() {
        viewModelScope.launch {
            val result = repo.getProfile()
            _profile.value = result
        }
    }
}

Dans le bloc init, le chargement du profil commence immédiatement. La coroutine s'exécute sur le thread principal (par défaut). Le référentiel utilise withContext(Dispatchers.IO) pour la requête réseau à l'intérieur de sa fonction suspend, donc le ViewModel n'a pas à se soucier du changement de threads.

Exemple 2 : Gestion des erreurs avec sealed class

sealed class UiState {
    object Loading : UiState()
    data class Success(val data: List<Item>) : UiState()
    data class Error(val message: String) : UiState()
}

fun fetchItems() {
    _state.value = UiState.Loading
    viewModelScope.launch {
        try {
            val items = repo.getItems()
            _state.value = UiState.Success(items)
        } catch (e: Exception) {
            _state.value = UiState.Error(e.message ?: "Unknown error")
        }
    }
}

L'état de l'UI est décrit via une sealed class UiState. Le ViewModel met à jour l'état à chaque changement. Le Fragment s'abonne au StateFlow et réagit uniquement à l'état actuel, ignorant les appels obsolètes des rotations précédentes.

Exemple 3 : Annulation de la coroutine précédente lors d'une nouvelle requête

private var searchJob: Job? = null

fun search(query: String) {
    searchJob?.cancel()
    searchJob = viewModelScope.launch {
        delay(300)
        val results = repo.search(query)
        _searchResults.value = results
    }
}

À chaque nouvelle requête de recherche, la coroutine précédente est annulée. delay(300) implémente le debounce — la recherche n'est exécutée qu'après 300 ms d'inactivité. Cela réduit la charge du serveur et évite les résultats obsolètes.

viewModelScope vs lifecycleScope : quand choisir lequel

Les deux scopes sont fournis par la bibliothèque AndroidX Lifecycle, mais sont liés à des cycles de vie différents. Le choix dépend du type de tâche.

Comparaison des scopes

Recommandations Google

Google recommande d'utiliser viewModelScope pour toutes les tâches de chargement et de traitement de données. lifecycleScope doit être utilisé pour les opérations liées à un moment spécifique du cycle de vie de l'UI — par exemple, lancer une animation à la première apparition de l'écran ou s'abonner aux mises à jour de localisation qui doivent cesser en quittant l'écran.

Erreurs courantes lors de l'utilisation de viewModelScope

Même dans une API Android bien documentée, les développeurs commettent des erreurs typiques. Examinons quatre des problèmes les plus courants.

Erreur 1 : Mettre à jour l'UI après l'annulation du scope

L'erreur la plus insidieuse est de tenter de mettre à jour StateFlow ou LiveData après que le ViewModel a été nettoyé. Bien que viewModelScope soit annulé lors de onCleared(), une coroutine peut exécuter du code avant que l'annulation prenne effet. Utilisez isActive pour vérifier ou fiez-vous à la fin du bloc catch.

Erreur 2 : Lancer des coroutines sans considérer SupervisorJob

viewModelScope utilise SupervisorJob en interne, ce qui isole les erreurs entre les coroutines. Cependant, si vous lancez une coroutine avec son propre Job() dans viewModelScope.launch, cette coroutine devient un enfant de SupervisorJob mais ne sera pas protégée contre l'annulation causée par des erreurs dans d'autres coroutines.

Erreur 3 : Trop de coroutines dans un seul scope

Bien que viewModelScope n'ait pas de limite stricte, des milliers de coroutines actives peuvent ralentir le système. Pour les longues listes de données, utilisez Flow avec collectLatest au lieu de créer des coroutines séparées pour chaque élément.

Erreur 4 : Utiliser GlobalScope au lieu de viewModelScope

Si GlobalScope est importé accidentellement au lieu de viewModelScope, la coroutine ne sera pas annulée lors du nettoyage du ViewModel. Cela entraîne des fuites de mémoire et des plantages potentiels. Assurez-vous toujours que les coroutines sont lancées via viewModelScope, en particulier dans les sous-classes de Fragment.