Handler() est obsolète dans Android ? Que utiliser en 2025

Handler() obsolète : quoi maintenant ? Regard vers 2025

Si vous avez déjà programmé pour Android, vous avez sûrement utilisé Handler() pour basculer entre les threads, exécuter des tâches différées ou mettre à jour l'interface utilisateur. Cette bonne vieille classe nous a accompagnés depuis les premières versions d'Android. Mais en 2024-2025, Google a officiellement déclaré le constructeur Handler() deprecated (obsolète). Des milliers de développeurs sur Stack Overflow se demandent : « Que dois-je utiliser maintenant que Handler() est déprécié ? »

Dans cet article, nous allons comprendre pourquoi Handler() est obsolète, quelles alternatives Android propose en 2025, et surtout — comment écrire du code moderne et propre en Kotlin qui ne fera pas pleurer votre chef d'équipe. C'est parti !

Pourquoi Handler() est-il devenu déprécié ?

La classe Handler elle-même n'a pas disparu. C'est précisément le constructeur sans arguments (Handler()) et ses surcharges qui sont devenus obsolètes, car ils créaient implicitement un Looper à partir du thread actuel. Le problème est que ce comportement :

\n
• Implicite et dangereux — si vous appelez Handler() dans un thread d'arrière-plan qui n'a pas de Looper, vous obtenez une RuntimeException.
\n
• Complique les tests — Handler est étroitement lié au cycle de vie des threads, ce qui rend les tests unitaires problématiques.
\n
• Moralement obsolète — des outils plus modernes et déclaratifs sont apparus : les coroutines, HandlerThread (de manière explicite) et LiveData.
\n

Google recommande de passer explicitement un Looper au constructeur, ou d'utiliser des alternatives. Voyons ce qui a exactement pris le relais.

Alternative n°1 : Looper explicite (le correctif le plus simple)

Si vous ne voulez pas réécrire tout le code, le moyen le plus rapide de supprimer la dépréciation est de passer explicitement un Looper. Pour le thread principal (UI thread), utilisez Looper.getMainLooper().

// Ancien code (déprécié)\nval handler = Handler()\n\n// Nouveau code (2025)\nval handler = Handler(Looper.getMainLooper())\n\n// Ou pour un thread d'arrière-plan :\nval handler = Handler(Looper.myLooper()) // Attention : peut être null !\n

Cela ne résoudra pas tous les problèmes, mais supprimera l'avertissement du compilateur. Cependant, pour des projets sérieux, il est préférable de passer aux coroutines.

Alternative n°2 : Kotlin Coroutines (recommandée par Google)

Depuis 2021, Google recommande officiellement Kotlin Coroutines pour les opérations asynchrones. En 2025, c'est déjà un standard de l'industrie. Pourquoi les coroutines sont-elles meilleures que Handler ?

\n
• Légèreté — des milliers de coroutines ne bloquent pas les threads.
\n
• Concurrence structurée — annulation automatique à la fin du cycle de vie.
\n
• Lisibilité — le code ressemble à du code synchrone, sans callbacks.
\n
• Testabilité — runBlocking et TestCoroutineDispatcher pour les tests unitaires.
\n

Voici comment remplacer les tâches typiques de Handler par des coroutines :

Remplacement de postDelayed (tâche différée)

// Ancienne méthode avec Handler\nval handler = Handler(Looper.getMainLooper())\nhandler.postDelayed({\n    // exécuter après 2 secondes\n}, 2000)\n\n// Nouvelle méthode avec Coroutines\nlifecycleScope.launch {\n    delay(2000) // ne bloque pas le thread !\n    // exécuter après 2 secondes\n}\n

Remplacement de post (basculement vers le thread UI)

// Ancienne méthode\nhandler.post {\n    textView.text = "Bonjour depuis un thread d'arrière-plan"\n}\n\n// Nouvelle méthode\nlifecycleScope.launch(Dispatchers.Main) {\n    textView.text = "Bonjour depuis une coroutine"\n}\n

Remplacement de removeCallbacks (annulation de tâche)

// Ancienne méthode\nval runnable = Runnable { /*...*/ }\nhandler.postD