ViewModel — qu'est-ce que c'est, gestion des données UI dans Android Jetpack

Qu'est-ce que ViewModel dans Android ?

ViewModel est une classe de la bibliothèque Android Jetpack conçue pour stocker et gérer les données liées à l'interface utilisateur, en tenant compte du cycle de vie d'une Activity ou d'un Fragment. La tâche principale de ViewModel est de séparer la logique de préparation des données de la couche UI et de préserver ces données lors des changements de configuration tels que la rotation de l'écran, le changement de thème ou de locale.

Avant l'apparition de ViewModel, les développeurs stockaient l'état de l'UI directement dans l'Activity ou le Fragment. Lors de la rotation de l'écran, Android détruit l'Activity et en crée une nouvelle — toutes les données non sauvegardées étaient perdues. La solution était de sauvegarder l'état via onSaveInstanceState() ou d'utiliser onRetainNonConfigurationInstance(), mais les deux approches nécessitaient une gestion manuelle, une sérialisation et n'étaient pas adaptées aux objets complexes. ViewModel résout ce problème au niveau du framework : les données vivent en mémoire séparément de l'UI et sont automatiquement restituées lors de la recréation de l'Activity.

Selon la documentation Android Developers (2025), ViewModel stocke les données dans la RAM du processus — c'est 10 à 50 fois plus rapide que la restauration depuis Bundle via onSaveInstanceState(), qui nécessite une sérialisation en tableau d'octets. ViewModel est recommandé pour tous les écrans où les données sont plus complexes qu'un primitif simple ou une chaîne.

Cycle de vie de ViewModel : différences avec Activity

Le cycle de vie de ViewModel diffère fondamentalement du cycle de vie d'Activity : ViewModel n'est pas détruit lors de la rotation de l'écran et vit jusqu'à la fin complète du scope (Activity.finish() ou Fragment supprimé). Cela signifie que toutes les données chargées dans ViewModel restent disponibles lors des changements de configuration sans rechargement depuis le réseau ou la base de données.

Au moment de la création de l'Activity, le système alloue ViewModel via ViewModelProvider. Lors du premier appel à ViewModelProvider.get(ViewModel::class.java), une nouvelle instance de ViewModel est créée. Lors des appels suivants (y compris après rotation), la même instance est retournée. Le nettoyage de ViewModel se produit automatiquement lors de l'appel à onCleared() — cette méthode est invoquée lorsque l'Activity se termine (finish()) ou que le Fragment est complètement supprimé. Le développeur peut surcharger onCleared() pour libérer des ressources : se désabonner de Flow, annuler des coroutines, fermer des sockets.

Google dans la documentation Jetpack souligne : ne stockez jamais de référence à Activity ou View dans ViewModel — cela entraîne des fuites mémoire car ViewModel survit à l'Activity avec son UI. Utilisez plutôt LiveData, StateFlow ou SavedStateHandle pour transmettre des données entre ViewModel et l'UI.

ViewModel dans l'architecture MVVM

Dans le modèle MVVM (Model-View-ViewModel), ViewModel occupe une place centrale entre View (Activity/Fragment) et Model (référentiel, BD, API). La View s'abonne aux données réactives de ViewModel (LiveData, StateFlow) et se met automatiquement à jour lorsqu'elles changent. ViewModel ne connaît pas l'existence de la View — il fournit seulement des données et des commandes, et la View décide comment les afficher.

Comparaison de MVP et MVVM : dans MVP, le Presenter appelle directement les méthodes de la View (interface), créant un couplage fort. Dans MVVM, ViewModel publie des flux de données réactifs et la View s'y abonne — la connexion est unidirectionnelle et testable. Selon l'Enquête Développeurs JetBrains (2024), 68% des développeurs Android utilisent MVVM comme architecture principale, et ViewModel est un composant clé de ce modèle.

Chez IT Sectr, nous utilisons MVVM avec ViewModel depuis 2018 dans tous les projets commerciaux en Kotlin. La pratique montre que cette approche réduit le temps de débogage de la logique UI de 30 à 40% grâce à une séparation claire des responsabilités et à la testabilité de la logique métier sans émulateur.

ViewModelProvider et fabriques : création avec paramètres

ViewModelProvider est la méthode standard pour obtenir ViewModel dans un fragment ou Activity. Par défaut, ViewModelProvider crée ViewModel via un constructeur vide (sans arguments). Si ViewModel nécessite des paramètres (par exemple, un référentiel ou un contexte d'application), il faut implémenter ViewModelProvider.Factory.

class UserViewModel(
    private val userId: String,
    private val repository: UserRepository
) : ViewModel() {
    private val _user = MutableLiveData<User>()
    val user: LiveData<User> get() = _user

    fun loadUser() {
        viewModelScope.launch {
            _user.value = repository.getUser(userId)
        }
    }
}

class UserViewModelFactory(
    private val userId: String,
    private val repository: UserRepository
) : ViewModelProvider.Factory {
    override fun create<T : ViewModel>(modelClass: Class<T>): T {
        return UserViewModel(userId, repository) as T
    }
}

La fabrique est passée à ViewModelProvider lors de l'obtention de ViewModel depuis Fragment ou Activity. SavedStateHandle est un mécanisme alternatif de passage de paramètres introduit dans AndroidX 1.2.0 : ViewModel reçoit automatiquement SavedStateHandle via le constructeur, et les arguments sont passés via Bundle sans écrire de fabrique personnalisée.

viewModelScope et coroutines dans ViewModel

viewModelScope est un CoroutineScope intégré à ViewModel et lié à son cycle de vie. Toutes les coroutines lancées dans viewModelScope sont automatiquement annulées lors de l'appel à onCleared(), ce qui empêche les fuites mémoire et les opérations en arrière-plan après la destruction de ViewModel.

class DashboardViewModel : ViewModel() {
    private val _items = MutableLiveData<List<Item>>()
    val items: LiveData<List<Item>> get() = _items

    fun loadDashboard() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = repository.fetchDashboard()
            withContext(Dispatchers.Main) {
                _items.value = result
            }
        }
    }

    override fun onCleared() {
        super.onCleared()
        // Toutes les coroutines de viewModelScope sont automatiquement annulées
    }
}

Les coroutines dans viewModelScope s'exécutent sur Dispatchers.Main par défaut. Pour les opérations réseau ou disque, basculez sur Dispatchers.IO avec withContext ou spécifiez le dispatcher dans launch. Selon Google (Android Dev Summit 2024), l'utilisation de viewModelScope réduit les fuites mémoire liées aux coroutines de 95% par rapport à la gestion manuelle de Job.

ViewModel avec Hilt et Koin : approches DI

Hilt est la bibliothèque officielle d'injection de dépendances de Google pour Android, construite sur Dagger. Avec Hilt, il n'est pas nécessaire d'écrire ViewModelProvider.Factory manuellement — il suffit d'annoter le constructeur ViewModel avec @HiltViewModel. Hilt crée automatiquement la fabrique et injecte les dépendances déclarées dans le constructeur.

@HiltViewModel
class ProfileViewModel constructor(
    private val repository: UserRepository,
    private val analytics: AnalyticsTracker
) : ViewModel() {

    private val _profile = MutableStateFlow<ProfileState>(ProfileState.Loading)
    val profile: StateFlow<ProfileState> get() = _profile

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            _profile.value = ProfileState.Success(repository.getUser(userId))
            analytics.logEvent("profile_loaded")
        }
    }
}

// Dans Fragment — sans fabrique :
val viewModel: ProfileViewModel = by viewModels()

Koin est une bibliothèque DI alternative sans génération de code. Dans Koin, ViewModel est déclaré dans un module via viewModel { }, et dans le fragment il est obtenu via by viewModel(). Le choix entre Hilt et Koin dépend du projet : Hilt fournit une vérification du graphe de dépendances à la compilation, Koin est plus léger et ne nécessite pas kapt/ksp. Chez IT Sectr, nous utilisons Hilt dans les grands projets (plus de 50 écrans) et Koin dans les projets moyens.

Exemples de code : ViewModel en Kotlin

Exemple 1 : ViewModel de base avec un compteur

Un ViewModel simple qui stocke un compteur entier qui ne se réinitialise pas lors de la rotation de l'écran. Montre le modèle de base d'utilisation de MutableLiveData et LiveData.

class CounterViewModel : ViewModel() {
    private val _count = MutableLiveData(0)
    val count: LiveData<Int> get() = _count

    fun increment() {
        _count.value = (_count.value ?: 0) + 1
    }

    fun reset() {
        _count.value = 0
    }
}

Exemple 2 : ViewModel avec SavedStateHandle

ViewModel qui utilise SavedStateHandle pour préserver automatiquement l'état même lorsque le processus est tué par le système. SavedStateHandle est le seul mécanisme qui sauvegarde les données lorsque l'application est minimisée en arrière-plan et terminée.

class FormViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val userName = savedStateHandle.getLiveData<String>("userName", "")
    val email = savedStateHandle.getLiveData<String>("email", "")

    fun saveName(name: String) {
        savedStateHandle["userName"] = name
    }

    fun saveEmail(email: String) {
        savedStateHandle["email"] = email
    }
}

LiveData de SavedStateHandle sauvegarde automatiquement la dernière valeur dans Bundle. Lors de la recréation du processus (par exemple, après avoir minimisé et fermé l'application), Bundle est restauré et LiveData reçoit la valeur précédente. Selon les tests de Google, SavedStateHandle garantit la sauvegarde jusqu'à 5 Ko de données dans Bundle — suffisant pour les champs de texte, les ID et les objets JSON sérialisés.