EditText en Kotlin : 5 façons de définir un texte et laquelle choisir

Introduction : une ligne — un million de questions

Avez-vous déjà écrit dans votre code editText.text = "Bonjour" et obtenu une erreur de compilation ? Ou, au contraire, le code fonctionnait, mais l'IDE soulignait la ligne en jaune ? Félicitations : vous avez rencontré le « casse-tête » classique de tout développeur Android qui passe à Kotlin.

Le sujet Setting text in EditText Kotlin est l'une des requêtes les plus populaires sur Stack Overflow (des milliers de vues !). À première vue, la tâche est triviale : prendre et assigner une valeur. Mais en Kotlin, il y a des nuances qui transforment une simple opération en un terrain de débat. Dans cet article, nous allons analyser toutes les approches actuelles : de l'ancien findViewById au moderne view binding et DataBinding. Vous découvrirez quelle méthode choisir pour un nouveau projet et comment éviter les pièges liés aux types de données.

C'est parti ! 🚀

Pourquoi simplement « text = ... » ne fonctionne-t-il pas ?

Si vous essayez d'écrire :

val editText = findViewById<EditText>(R.id.my_edit_text)\neditText.text = "Nouveau texte"

Le compilateur affichera une erreur : Type mismatch. Required: Editable! Found: String.

Tout est dû au fait que la propriété text de EditText est de type Editable (et non String). En Java, nous étions habitués à setText(CharSequence), mais Kotlin « sous le capot » traduit cela en un setter de propriété qui attend un Editable. Il existe une solution — et pas qu'une seule.

Méthode n°1 : La classique — findViewById + setText

La méthode la plus directe, qui fonctionne depuis le SDK 1.0. Elle ne nécessite pas de bibliothèques supplémentaires et est compréhensible même pour un débutant.

val editText = findViewById<EditText>(R.id.my_edit_text)\neditText.setText("Bonjour le monde !")

Ici, nous appelons la méthode Java setText(CharSequence), qui accepte une chaîne de caractères. En Kotlin, cela ressemble à un appel de fonction ordinaire.

Avantages :

\n
• Minimum de code
\n
• Ne nécessite pas d'imports (sauf les imports de base)
\n
• Fonctionne dans tout fragment/activité
\n

Inconvénients :

\n
• Recherche manuelle de la vue — facile de se tromper dans l'id
\n
• Null safety non garantie : il faut vérifier la nullité
\n
• Plus lent que le binding (mais pour un seul champ, la différence est imperceptible)
\n

Quand l'utiliser : dans les projets legacy, dans le code pour un prototypage rapide ou dans les situations où vous savez avec certitude que la vue existe.

Méthode n°2 : Kotlin Android Extensions (synthétiques)

Auparavant, c'était la « solution miracle » pour les développeurs Kotlin. Vous écriviez simplement my_edit_text.text = "Texte" — et tout fonctionnait. La magie résidait dans la génération automatique de propriétés synthétiques.

// build.gradle (app) — il fallait auparavant ajouter :\n// apply plugin: 'kotlin-android-extensions'\n// Maintenant, le plugin est obsolète !\n\n// Dans le code :\nimport kotlinx.android.synthetic.main.activity_main.*\n\nmy_edit_text.setText("Texte via les synthétiques")

Avantages :

\n
• Très concis
\n
• Pas besoin d'écrire findViewById
\n
• Prenait en charge la null safety à l'origine
\n

Inconvénients :

\n
• Le plugin est déclaré obsolète (deprecated) depuis Kotlin 1.8. Google recommande de migrer vers View Binding
\n
• Ne fonctionne pas avec les fragments si le layout est réutilisé
\n
• Crée un contexte global — des fuites de mémoire possibles
\n

Important : Si vous commencez un nouveau projet en 2024–2025 — n'utilisez pas cette approche. Pour les anciens projets — planifiez la migration.

Méthode n°3 : View Binding — le standard moderne

Aujourd'hui, View Binding est la méthode officiellement recommandée pour travailler avec les vues dans Android. Il génère une classe Binding pour chaque fichier layout, donnant accès à chaque vue par son nom.

// 1. Activer dans build.gradle (app) :\nandroid {\n    ...\n    buildFeatures