EditText em Kotlin: 5 maneiras de definir texto e qual escolher

Introdução: uma linha — um milhão de perguntas

Você já escreveu no código editText.text = "Olá" e recebeu um erro de compilação? Ou, ao contrário, o código funcionava, mas a IDE sublinhava a linha em amarelo? Parabéns: você encontrou a clássica "dor de cabeça" de todo desenvolvedor Android que está migrando para Kotlin.

O tópico Setting text in EditText Kotlin é uma das consultas mais populares no Stack Overflow (milhares de visualizações!). À primeira vista, a tarefa é trivial: pegar e atribuir um valor. Mas em Kotlin existem nuances que transformam uma operação simples em um campo para discussões. Neste artigo, vamos analisar todas as abordagens atuais: desde o antigo findViewById até o moderno view binding e DataBinding. Você descobrirá qual método escolher para um novo projeto e como não cair em armadilhas com tipos de dados.

Vamos lá! 🚀

Por que simplesmente "text = ..." não funciona?

Se você tentar escrever:

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

O compilador emitirá um erro: Type mismatch. Required: Editable! Found: String.

Isso acontece porque a propriedade text do EditText tem o tipo Editable (e não String). Em Java, estávamos acostumados com setText(CharSequence), mas o Kotlin "por baixo dos panos" traduz isso para um setter de propriedade que espera Editable. A solução existe — e não é apenas uma.

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

O método mais direto, que funciona desde o SDK 1.0. Ele não requer bibliotecas adicionais e é compreensível até para iniciantes.

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

Aqui, chamamos o método Java setText(CharSequence), que aceita uma string. Em Kotlin, isso parece uma chamada de função comum.

Vantagens:

\n
• Mínimo de código
\n
• Não requer imports (além dos básicos)
\n
• Funciona em qualquer fragment/activity
\n

Desvantagens:

\n
• Busca manual da view — fácil errar no id
\n
• Null safety não é garantido: é necessário verificar se é nulo
\n
• Mais lento que binding (mas para um único campo, a diferença é imperceptível)
\n

Quando usar: em projetos legados, em código para prototipagem rápida ou em situações em que você tem certeza de que a view existe.

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

Antigamente, isso era a "bala de prata" para desenvolvedores Kotlin. Você simplesmente escrevia my_edit_text.text = "Texto" — e tudo funcionava. A mágica estava na geração automática de propriedades sintéticas.

// build.gradle (app) — antes era necessário adicionar:\n// apply plugin: 'kotlin-android-extensions'\n// Agora o plugin está obsoleto!\n\n// No código:\nimport kotlinx.android.synthetic.main.activity_main.*\n\nmy_edit_text.setText("Texto via sintéticos")

Vantagens:

\n
• Muito conciso
\n
• Não precisa escrever findViewById
\n
• Originalmente suportava null safety

Desvantagens:

• O plugin foi declarado obsoleto (deprecated) desde o Kotlin 1.8. O Google recomenda migrar para View Binding
• Não funciona com fragments se o layout for reutilizado
• Cria um contexto global — possíveis vazamentos de memória

Importante: Se você está iniciando um novo projeto em 2024–2025 — não use esta abordagem. Para projetos antigos — planeje a migração.

Método nº3: View Binding — o padrão moderno

Atualmente, o View Binding é a forma oficialmente recomendada para trabalhar com views no Android. Ele gera uma classe Binding para cada arquivo de layout, dando acesso a cada view pelo nome.

// 1. Ative no build.gradle (app):\nandroid {\n    ...\n    buildFeatures