EditText en Kotlin: 5 formas de establecer texto y cuál elegir

Introducción: una línea — un millón de preguntas

¿Alguna vez has escrito en código editText.text = "Hola" y recibiste un error de compilación? ¿O, por el contrario, el código funcionaba, pero el IDE subrayaba la línea en amarillo? Felicidades: te has topado con el clásico «dolor de cabeza» de todo desarrollador Android que migra a Kotlin.

El tema Setting text in EditText Kotlin es una de las consultas más populares en Stack Overflow (¡miles de visitas!). A primera vista, la tarea es trivial: tomar y asignar un valor. Pero en Kotlin hay matices que convierten una operación simple en un campo de debate. En este artículo, analizaremos todos los enfoques actuales: desde el antiguo findViewById hasta el moderno view binding y DataBinding. Aprenderás qué método elegir para un proyecto nuevo y cómo no pisar el rastrillo con los tipos de datos.

¡Allá vamos! 🚀

¿Por qué simplemente «text = ...» no funciona?

Si intentas escribir:

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

El compilador mostrará un error: Type mismatch. Required: Editable! Found: String.

El problema es que la propiedad text de EditText es de tipo Editable (no String). En Java estábamos acostumbrados a setText(CharSequence), pero Kotlin «bajo el capó» traduce esto a un setter de propiedad que espera Editable. Hay solución, y más de una.

Método n.º 1: Clásico — findViewById + setText

El método más directo, que funciona desde SDK 1.0. No requiere bibliotecas adicionales y es comprensible incluso para un principiante.

val editText = findViewById<EditText>(R.id.my_edit_text)\neditText.setText("¡Hola, mundo!")

Aquí llamamos al método Java setText(CharSequence), que acepta una cadena. En Kotlin, esto se ve como una llamada de función normal.

Ventajas:

\n
• Mínimo código
\n
• No requiere imports (excepto los básicos)
\n
• Funciona en cualquier fragmento/actividad
\n

Desventajas:

\n
• Búsqueda manual de view — fácil equivocarse en el id
\n
• Null safety no garantizado: hay que verificar si es null
\n
• Más lento que binding (pero para un solo campo la diferencia es imperceptible)
\n

Cuándo usarlo: en proyectos legacy, en código para prototipado rápido o en situaciones donde sabes con certeza que la view existe.

Método n.º 2: Kotlin Android Extensions (sintéticos)

Antes, esto era la «bala de plata» para los desarrolladores Kotlin. Simplemente escribías my_edit_text.text = "Texto" y todo funcionaba. La magia consistía en la generación automática de propiedades sintéticas.

// build.gradle (app) — antes había que agregar:\n// apply plugin: 'kotlin-android-extensions'\n// ¡Ahora el plugin está obsoleto!\n\n// En el código:\nimport kotlinx.android.synthetic.main.activity_main.*\n\nmy_edit_text.setText("Texto mediante sintéticos")

Ventajas:

\n
• Muy conciso
\n
• No es necesario escribir findViewById
\n
• Originalmente soportaba null safety
\n

Desventajas:

\n
• El plugin está declarado obsoleto (deprecated) desde Kotlin 1.8. Google recomienda migrar a View Binding
\n
• No funciona con fragmentos si el layout se reutiliza
\n
• Crea un contexto global — posibles fugas de memoria
\n

Importante: Si estás comenzando un nuevo proyecto en 2024–2025, no uses este enfoque. Para proyectos antiguos, planifica la migración.

Método n.º 3: View Binding — el estándar moderno

Hoy en día, View Binding es la forma recomendada oficialmente para trabajar con views en Android. Genera una clase Binding para cada archivo layout, dando acceso a cada view por su nombre.

// 1. Habilitar en build.gradle (app):\nandroid {\n    ...\n    buildFeatures