Two-Way Binding: ce este, legarea bidirecțională în Android și iOS

Ce este Two-Way Binding?

Two-Way Binding (legarea bidirecțională a datelor) — un mecanism arhitectural prin care modificările din modelul de date se reflectă automat în interfața utilizatorului, iar modificările din UI actualizează imediat modelul. Spre deosebire de legarea unidirecțională, unde fluxul de date merge doar de la model la prezentare, legarea bidirecțională creează un ciclu închis de sincronizare fără codificarea manuală a fiecărei actualizări.

Conform Android Developers Blog (2023), biblioteca DataBinding, introdusă în 2015, este utilizată în 42% din aplicațiile Android comerciale. Mecanismul este deosebit de solicitat în formularele de intrare — câmpuri text, comutatoare, glisante și căsuțe de bifat — unde intrarea utilizatorului trebuie să se reflecte instantaneu în model, iar modificările programatice — în UI. În toate aceste scenarii, dezvoltatorul scrie o singură legare în locul perechii „ascultător + setter”.

În IT Sectr am aplicat legarea bidirecțională în proiecte din 2017 și recomandăm să o folosiți conștient: pentru câmpuri simple de intrare, dar nu pentru stări complexe cu dependențe.

Cum funcționează legarea bidirecțională?

Mecanismul Two-Way Binding se bazează pe trei elemente cheie: câmp observabil (observable), ascultător de modificări (listener) și mecanism de sincronizare inversă. Când utilizatorul introduce text în câmpul EditText, sistemul interceptează evenimentul TextWatcher, scrie noua valoare în variabila legată și notifică UI despre necesitatea redesenării, dacă variabila s-a modificat din cod.

Sub capotă, biblioteca DataBinding din Android generează clasa Binding în faza de compilare, care conține întreaga logică de legare. Pentru fiecare View cu atributul @={variable} se creează o pereche setter + getter cu invalidare. În SwiftUI, o muncă similară o face propertyWrapper @Binding, care sincronizează valoarea prin mecanismul Combine. SwiftUI urmărește modificările prin proprietățile @Published și redesenează automat View la orice modificare a variabilei legate.

Conform WWDC Session 10033 (2023), mecanismul @Binding din SwiftUI procesează până la 60 de cadre pe secundă la sincronizarea câmpurilor de intrare, ceea ce îl face potrivit pentru formulare interactive fără întârzieri. În ambele frameworkuri, Two-Way Binding este zahăr sintactic peste modelul Observer, automatizând abonarea și notificarea.

Two-Way Binding în Android: DataBinding și Jetpack Compose

În Android, legarea bidirecțională este disponibilă în două variante: XML-DataBinding clasic prin atributul @={} și Jetpack Compose prin referințe de stare bidirecționale. Ambele abordări rezolvă aceeași sarcină — sincronizarea UI și a modelului — dar diferă prin sintaxă și domeniul de aplicare.

DataBinding cu @BindingAdapter și @=

În marcajul XML, legarea bidirecțională se notează prin sintaxa @={variable.property} — semnul egal din interiorul acoladelor o deosebește de @{variable} unidirecțională. Pentru View-uri personalizate este necesară adnotarea @BindingAdapter cu specificarea atributului inverse.

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

Exemplul arată un formular simplu cu email și căsuță de bifat — ambele câmpuri folosesc legarea bidirecțională, ceea ce elimină necesitatea de a scrie TextWatcher și OnCheckedChangeListener în codul Activity. La modificarea textului de către utilizator, câmpul viewModel.email se actualizează automat.

@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() }
}

BindingAdapter personalizat pentru RatingBar folosește o pereche de adnotări — @BindingAdapter și @InverseBindingAdapter — pentru ca biblioteca DataBinding să știe cum să citească valoarea din View (feedback invers) și cum să scrie în View (legare directă). Al treilea adapter cu sufixul AttrChanged notifică sistemul despre modificarea valorii de către utilizator.

Two-Way Binding în Jetpack Compose

Jetpack Compose nu acceptă sintaxa @={}, dar oferă un mecanism similar prin mutableStateOf și transmiterea explicită a funcției setter. Legarea bidirecțională în Compose se bazează pe transmiterea State și a funcției callback (value, onValueChange) către componentele copil.

@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
    )
}

În Compose, legătura bidirecțională este simulată prin perechea state + callback — părintele transmite valoarea curentă și funcția de actualizare a acesteia, componenta copil apelează callback la interacțiunea utilizatorului. Această abordare arată explicit direcția fluxului de date, ceea ce simplifică depanarea comparativ cu sincronizarea implicită a DataBinding.

Two-Way Binding în iOS: @Binding în SwiftUI

În SwiftUI, legarea bidirecțională se realizează prin propertyWrapper @Binding, care creează o referință read-write la sursa de date aparținând View-ului părinte. @Binding nu stochează valoarea independent — citește și scrie prin @State sau @StateObject al părintelui.

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

    var body: some View {
        Form {
            TextField("Email", text: $email)
            Toggle("Sunt de acord cu termenii", isOn: $agreeToTerms)
            ChildRatingView(rating: $rating)
        }
    }
}

struct ChildRatingView: View {
    @Binding var rating: Double

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

Simbolul $ înaintea numelui variabilei creează o referință Binding: $email are tipul Binding<String>, nu String. SwiftUI leagă automat modificarea textului din TextField cu actualizarea proprietății email prin mecanismul Combine. View-ul părinte transmite componentei copil un Binding la @State-ul său, ceea ce permite modificarea stării din orice nivel al ierarhiei fără delegați sau callback-uri.

Conform Apple WWDC 2023, SwiftUI folosește un algoritm de diffing pentru a minimiza redesenările: dacă valoarea @Binding s-a modificat, dar View nu depinde de această valoare, redesenarea nu are loc. Aceasta asigură o performanță comparabilă cu UIKit (până la 120 FPS pe display-urile ProMotion).

Two-Way Binding versus UDF: când să alegeți ce

Alegerea între legarea bidirecțională și fluxul de date unidirecțional (UDF) — una dintre deciziile arhitecturale cheie în dezvoltarea mobilă. Two-Way Binding este optim pentru stările locale ale formularului, unde fiecare pas al utilizatorului trebuie să se reflecte imediat în model fără cod suplimentar. UDF este preferat pentru starea globală a aplicației, unde predictibilitatea modificărilor este mai importantă decât viteza de dezvoltare.

Recomandare: folosiți Two-Way Binding pentru câmpuri simple de intrare (text, căsuțe de bifat, comutatoare) în formulare cu 3–5 câmpuri fără validare complexă. Pentru ecrane cu stare globală, cereri de rețea și câmpuri dependente, aplicați UDF cu flux unidirecțional și procesare explicită a evenimentelor. În IT Sectr combinăm ambele abordări: Two-Way Binding în interiorul formularului, UDF pentru navigare și logică de business.

Greșeli tipice la legarea bidirecțională

Bucla infinită de actualizare — cea mai frecventă problemă la utilizarea Two-Way Binding. Bucla apare când modificarea modelului provoacă actualizarea UI, care la rândul său modifică din nou modelul. În DataBinding, acest lucru se întâmplă dacă getter-ul din @InverseBindingAdapter returnează o valoare nouă imediat după apelul setter. Soluția — verificați dacă valoarea s-a modificat înainte de scrierea inversă (condiția guard).

A doua greșeală frecventă — legarea câmpurilor calculate. Dacă un câmp depinde de alt câmp (de exemplu, costul total = preț × cantitate), legarea bidirecțională poate duce la o stare inconsistentă. De exemplu, utilizatorul modifică cantitatea, se declanșează recalcularea costului, care modifică din nou cantitatea. Pentru câmpuri calculate, folosiți legarea unidirecțională cu Flow sau Combine.

A treia greșeală — legarea câmpurilor Observable fără LifecycleOwner. În Android DataBinding, trebuie transmis LifecycleOwner în binding, altfel observatorii nu vor fi curățați la distrugerea Activity, ceea ce duce la scurgeri de memorie. Transmiteți întotdeauna viewLifecycleOwner în fragmente și this în Activity.

Conform Google Issue Tracker (2024), aproximativ 15% din rapoartele de bug legate de DataBinding sunt asociate cu actualizări ciclice. Pentru diagnosticare, utilizați Android Studio Layout Inspector — acesta arată valorile curente ale tuturor binding-urilor pe ecran, ceea ce simplifică găsirea sursei buclei infinite.