Pourquoi Room se plaint du thread principal ? Analyse de l'erreur et 3 façons de la résoudre

Introduction : pourquoi un « simple SELECT » devient un casse-tête

Vous écrivez votre première application Android avec Room et Kotlin. Tout se passe bien jusqu'à ce que vous deviez lire des données depuis la base. Vous écrivez quelque chose comme :

val user = userDao.getUserById(42)\ntextView.text = user.name

Vous lancez l'application — et elle plante avec l'exception :

java.lang.IllegalStateException: Cannot access database on the main thread\nsince it may potentially lock the UI for a long period of time.

Ça vous dit quelque chose ? Cette question sur Stack Overflow a recueilli des milliers de vues et des centaines de commentaires. L'erreur effraie les débutants, mais en réalité ce n'est pas un bug — c'est une protection contre les erreurs. Room (comme toute ORM bien conçue) vous empêche de bloquer accidentellement l'interface utilisateur.

Dans cet article, nous analyserons pourquoi cela se produit et comment exécuter correctement des requêtes SELECT dans Android Room avec Kotlin. Vous découvrirez trois approches éprouvées : LiveData, Coroutines et RxJava. C'est parti !

L'essentiel en bref : pourquoi Room bloque le thread principal ?

Android est un système monothread par défaut. Toute l'interface utilisateur fonctionne sur le main thread (thread principal). Si vous commencez à lire la base de données sur ce thread, l'interface se figera jusqu'à la fin de la requête. Avec de gros volumes de données, cela peut prendre plusieurs secondes — l'utilisateur verra une application « bloquée ».

Room joue la sécurité : il interdit toute opération longue (lecture, écriture) sur le thread principal. Exception faite si vous l'autorisez explicitement via .allowMainThreadQueries() lors de la construction de la base. Mais il ne faut pas le faire — c'est un anti-patron.

Voici à quoi ressemble le problème typique :

// DAO\n@Dao\ninterface UserDao {\n    @Query("SELECT * FROM users WHERE id = :userId")\n    suspend fun getUserById(userId: Int): User  // suspend — déjà un indice !\n}\n\n// Activity\nclass MainActivity : AppCompatActivity() {\n    override fun onCreate(savedInstanceState: Bundle?) {\n        super.onCreate(savedInstanceState)\n        // ❌ Erreur !\n        val user = database.userDao().getUserById(42)\n    }\n}

Même si vous avez rendu la fonction suspend, mais que vous l'appelez sans coroutine — Room lèvera quand même l'exception. On corrige ça !

Approche 1 : LiveData — simple et réactif

La façon la plus simple est de retourner LiveData depuis le DAO. Room gère lui-même le thread : la requête s'exécute en arrière-plan et le résultat arrive dans l'interface utilisateur.

Étape 1. Modifier le DAO

@Dao\ninterface UserDao {\n    @Query("SELECT * FROM users WHERE id = :userId")\n    fun getUserById(userId: Int): LiveData<User>\n}

Étape 2. S'abonner dans l'Activity/Fragment

class MainActivity : AppCompatActivity() {\n    override fun onCreate(savedInstanceState: Bundle?) {\n        super.onCreate(savedInstanceState)\n\n        database.userDao().getUserById(42).observe(this) { user ->\n            textView.text = user.name\n        }\n    }\n}

Avantages : code minimal, désabonnement automatique à la destruction de l'Activity, réactivité — les données se mettent à jour automatiquement lors des modifications de la table.

Inconvénients : LiveData est liée au cycle de vie, difficile à combiner avec d'autres sources de données (réseau, SharedPreferences).

Approche 2 : Coroutines — la méthode Kotlin moderne

Si vous utilisez Kotlin Coroutines (et vous devriez), c'est la façon la plus élégante. La fonction est marquée comme suspend, et l'appel est encapsulé dans une coroutine avec le bon Dispatchers.IO.

Étape 1. DAO avec suspend

@Dao\ninterface UserDao {\n    @Query("SELECT * FROM users WHERE id = :userId")\n    suspend fun getUserById(userId: Int): User\n}

Étape 2. Appel depuis le ViewModel (recommandé)

class MainVi