Two-Way Binding: o que é, ligação bidirecional de dados em Android e iOS

O que é Two-Way Binding?

Two-Way Binding (ligação bidirecional de dados) — um mecanismo arquitetónico onde as alterações no modelo de dados são refletidas automaticamente na interface do utilizador, e as alterações na UI atualizam imediatamente o modelo. Ao contrário da ligação unidirecional, onde os dados fluem apenas do modelo para a vista, a ligação bidirecional cria um loop de sincronização fechado sem codificação manual de cada atualização.

De acordo com o Android Developers Blog (2023), a biblioteca DataBinding, introduzida em 2015, é usada em 42% das aplicações Android comerciais. O mecanismo é especialmente procurado em formulários de entrada — campos de texto, interruptores, controlos deslizantes e caixas de verificação — onde a entrada do utilizador deve refletir-se instantaneamente no modelo e as alterações programáticas na UI. Em todos estes cenários, o programador escreve uma ligação em vez de um par de "listener + setter".

Na IT Sectr, aplicámos a ligação bidirecional em projetos desde 2017 e recomendamos usá-la de forma consciente: para campos de entrada simples, mas não para estados complexos com dependências.

Como funciona a ligação bidirecional?

O mecanismo Two-Way Binding baseia-se em três elementos-chave: campo observável (observable), listener de mudanças e mecanismo de sincronização reversa. Quando um utilizador escreve texto num campo EditText, o sistema interceta o evento TextWatcher, escreve o novo valor na variável ligada e notifica a UI para redesenhar se a variável mudou a partir do código.

Sob o capô, a biblioteca DataBinding do Android gera uma classe Binding em tempo de compilação que contém toda a lógica de ligação. Para cada View com o atributo @={variable}, é criado um par setter + getter com invalidação. No SwiftUI, o propertyWrapper @Binding realiza um trabalho semelhante, sincronizando o valor através do mecanismo Combine. O SwiftUI rastreia as alterações através de propriedades @Published e redesenha automaticamente a View em qualquer alteração na variável ligada.

De acordo com a WWDC Session 10033 (2023), o mecanismo @Binding no SwiftUI processa até 60 frames por segundo ao sincronizar campos de entrada, tornando-o adequado para formulários interativos sem atrasos. Em ambos os frameworks, o Two-Way Binding é açúcar sintático sobre o padrão Observer, automatizando a subscrição e notificação.

Two-Way Binding em Android: DataBinding e Jetpack Compose

Em Android, a ligação bidirecional está disponível em duas variantes: o clássico XML DataBinding através do atributo @={} e o Jetpack Compose através de referências de estado bidirecionais. Ambas as abordagens resolvem o mesmo problema — sincronizar UI e modelo — mas diferem na sintaxe e âmbito de aplicação.

DataBinding com @BindingAdapter e @=

Na marcação XML, a ligação bidirecional é indicada pela sintaxe @={variable.property} — o sinal de igual dentro das chaves distingue-a da unidirecional @{variable}. Para Views personalizadas, é necessária a anotação @BindingAdapter com um atributo inverso.

<layout>
    <data>
        <variable name="viewModel" type="com.example.LoginViewModel" />
    </data>
    <EditText
        android:text="@{viewModel.email}" />
    <CheckBox
        android:checked="@{viewModel.agreeToTerms}" />
</layout>

O exemplo mostra um formulário simples com email e caixa de verificação — ambos os campos usam ligação bidirecional, eliminando a necessidade de escrever TextWatcher e OnCheckedChangeListener no código da Activity. Quando o utilizador altera o texto, o campo viewModel.email atualiza-se automaticamente.

@BindingAdapter("app:rating")
fun RatingBar.setRating(rating: Float) {
    if (rating != this.rating) {
        this.rating = rating
    }
}

@InverseBindingAdapter("app:rating")
fun RatingBar.getRating(): Float = this.rating

@BindingAdapter("app:ratingAttrChanged")
fun RatingBar.setListeners(
    listener: InverseBindingListener?
) {
    this.onRatingBarChangeListener =
        RatingBar.OnRatingBarChangeListener { _, _, _ -> listener?.onChange() }
}

Um BindingAdapter personalizado para RatingBar usa um par de anotações — @BindingAdapter e @InverseBindingAdapter — para que a biblioteca DataBinding saiba como ler o valor da View (feedback reverso) e como escrever na View (ligação direta). O terceiro adaptador com o sufixo AttrChanged notifica o sistema sobre alterações de valor iniciadas pelo utilizador.

Two-Way Binding no Jetpack Compose

O Jetpack Compose não suporta a sintaxe @={} mas fornece um mecanismo semelhante através de mutableStateOf e passagem explícita de função setter. A ligação bidirecional no Compose é construída passando State e uma função de callback (value, onValueChange) para componentes filhos.

@Composable
fun LoginScreen() {
    var email by remember { mutableStateOf("") }

    OutlinedTextField(
        value = email,
        onValueChange = { email = it },
        label = { Text("Email") }
    )
}

@Composable
fun CustomRatingBar(
    rating: Float,
    onRatingChange: (Float) -> Unit
) {
    Slider(
        value = rating,
        onValueChange = onRatingChange,
        valueRange = 0f..5f
    )
}

No Compose, a comunicação bidirecional é emulada através de um par state + callback — o pai passa o valor atual e uma função de atualização, o componente filho invoca o callback na interação do utilizador. Esta abordagem mostra explicitamente a direção do fluxo de dados, simplificando a depuração em comparação com a sincronização implícita do DataBinding.

Two-Way Binding em iOS: @Binding no SwiftUI

No SwiftUI, a ligação bidirecional é implementada através do propertyWrapper @Binding, que cria uma referência de leitura-escrita a uma fonte de dados pertencente à View pai. O @Binding não armazena o valor por si só — lê e escreve através do @State ou @StateObject do pai.

struct LoginView: View {
    @State private var email = ""
    @State private var agreeToTerms = false

    var body: some View {
        Form {
            TextField("Email", text: $email)
            Toggle("Aceito os termos", isOn: $agreeToTerms)
            ChildRatingView(rating: $rating)
        }
    }
}

struct ChildRatingView: View {
    @Binding var rating: Double

    var body: some View {
        Slider(value: $rating, in: 0...5)
    }
}

O símbolo $ antes do nome de uma variável cria uma referência Binding: $email tem o tipo Binding, não String. O SwiftUI liga automaticamente as alterações de texto no TextField à atualização da propriedade email através do mecanismo Combine. A View pai passa uma Binding ao seu @State para o componente filho, permitindo modificar o estado a partir de qualquer nível de hierarquia sem delegados ou callbacks.

Segundo a Apple WWDC 2023, o SwiftUI usa um algoritmo de diffing para minimizar redesenhos: se o valor @Binding mudar mas a View não depender desse valor, não ocorre redesenho. Isto proporciona desempenho comparável ao UIKit (até 120 FPS em ecrãs ProMotion).

Two-Way Binding vs UDF: quando escolher cada um

A escolha entre ligação bidirecional e fluxo de dados unidirecional (UDF) é uma das decisões arquitetónicas chave no desenvolvimento móvel. O Two-Way Binding é ideal para estados locais de formulários onde cada passo do utilizador deve refletir-se imediatamente no modelo sem código adicional. O UDF é preferível para o estado global da aplicação onde a previsibilidade das mudanças é mais importante que a velocidade de desenvolvimento.

Recomendação: use Two-Way Binding para campos de entrada simples (texto, caixas de verificação, interruptores) em formulários com 3–5 campos sem validação complexa. Para ecrãs com estado global, pedidos de rede e campos dependentes, use UDF com fluxo unidirecional e tratamento explícito de eventos. Na IT Sectr, combinamos ambas as abordagens: Two-Way Binding dentro de formulários, UDF para navegação e lógica de negócio.

Erros comuns na ligação bidirecional

Loop infinito de atualização — o problema mais comum ao usar Two-Way Binding. O loop ocorre quando uma alteração no modelo desencadeia uma atualização da UI, que por sua vez altera novamente o modelo. No DataBinding, isto acontece se o getter no @InverseBindingAdapter retornar um novo valor imediatamente após uma chamada setter. A solução é verificar se o valor mudou antes de escrever de volta (condição de guarda).

O segundo erro comum é ligar campos calculados. Se um campo depende de outro campo (por exemplo, custo total = preço × quantidade), a ligação bidirecional pode levar a um estado inconsistente. Por exemplo, o utilizador altera a quantidade, desencadeando um recálculo do custo, que altera novamente a quantidade. Para campos calculados, use ligação unidirecional com Flow ou Combine.

O terceiro erro é ligar campos Observable sem LifecycleOwner. No Android DataBinding, é necessário passar um LifecycleOwner à ligação, caso contrário os observadores não serão limpos quando a Activity for destruída, levando a fugas de memória. Passe sempre viewLifecycleOwner em fragmentos e this em Activity.

De acordo com o Google Issue Tracker (2024), cerca de 15% dos relatórios de bugs do DataBinding estão relacionados com atualizações cíclicas. Para diagnóstico, use o Android Studio Layout Inspector — mostra os valores atuais de todas as ligações no ecrã, simplificando a procura da origem do loop infinito.