Ne pas utiliser un ViewModel dans un Worker

💡 Sujet

Éviter d’appeler un ViewModel dans un Worker WorkManager.
Un Worker n’a pas de cycle de vie lié à l’UI, contrairement au ViewModel.

🚫 Mauvaise pratique

Un ViewModel est conçu pour vivre le temps du composant UI (Activity ou Fragment).
Un Worker, lui, peut s’exécuter :

• en arrière-plan,
• après la fermeture de l’app,
• ou même au redémarrage du téléphone.

👉 Utiliser un ViewModel à l’intérieur d’un Worker peut donc provoquer :

• des exceptions (IllegalStateException),
• des problèmes d’injection de dépendances,
• des fuites mémoire.

❌ Exemple de code à éviter

class SyncWorker(
    context: Context,
    params: WorkerParameters,
    private val myViewModel: MyViewModel
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        myViewModel.syncData()
        return Result.success()
    }
}

✅ Bonne pratique : passer par le Repository

Le Repository doit centraliser la logique métier et l’accès aux données.
Le ViewModel et le Worker s’y connectent indépendamment.

✅ Exemple correct

class SyncWorker(
    context: Context,
    params: WorkerParameters,
    private val repository: DataRepository
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        repository.syncData()
        return Result.success()
    }
}

Et côté ViewModel :

class MyViewModel(
    private val repository: DataRepository
) : ViewModel() {

    fun onUserAction() {
        viewModelScope.launch {
            repository.syncData()
        }
    }
}

🧩 Résumé

• ❌ Ne pas injecter de ViewModel dans un Worker.
• ✅ Utiliser un Repository partagé pour les opérations communes.
• 💡 Cela garantit un code découplé, testable et conforme à l’architecture Android.

🔗 Références

• WorkManager — Android Docs
• Guide Android Architecture
• ViewModel — Android Docs