Two-Way Binding : qu'est-ce que c'est, liaison bidirectionnelle de données dans Android et iOS

Qu'est-ce que le Two-Way Binding ?

Two-Way Binding (liaison bidirectionnelle de données) — un mécanisme architectural où les changements dans le modèle de données sont automatiquement reflétés dans l'interface utilisateur, et les changements dans l'UI mettent immédiatement à jour le modèle. Contrairement à la liaison unidirectionnelle, où les données circulent uniquement du modèle vers la vue, la liaison bidirectionnelle crée une boucle de synchronisation fermée sans codage manuel de chaque mise à jour.

Selon Android Developers Blog (2023), la bibliothèque DataBinding, introduite en 2015, est utilisée dans 42 % des applications Android commerciales. Le mécanisme est particulièrement demandé dans les formulaires de saisie — champs de texte, interrupteurs, curseurs et cases à cocher — où la saisie utilisateur doit être instantanément reflétée dans le modèle et les changements programmatiques dans l'UI. Dans tous ces scénarios, le développeur écrit une liaison au lieu d'une paire « écouteur + setter ».

Chez IT Sectr, nous avons appliqué la liaison bidirectionnelle dans des projets depuis 2017 et recommandons de l'utiliser consciemment : pour les champs de saisie simples, mais pas pour les états complexes avec dépendances.

Comment fonctionne la liaison bidirectionnelle ?

Le mécanisme Two-Way Binding repose sur trois éléments clés : champ observable (observable), écouteur de changement et mécanisme de synchronisation inverse. Lorsqu'un utilisateur saisit du texte dans un champ EditText, le système intercepte l'événement TextWatcher, écrit la nouvelle valeur dans la variable liée et notifie l'UI pour se redessiner si la variable a changé depuis le code.

Sous le capot, la bibliothèque DataBinding d'Android génère une classe Binding à la compilation qui contient toute la logique de liaison. Pour chaque View avec l'attribut @={variable}, une paire setter + getter avec invalidation est créée. Dans SwiftUI, le propertyWrapper @Binding effectue un travail similaire, synchronisant la valeur via le mécanisme Combine. SwiftUI suit les changements via les propriétés @Published et redessine automatiquement la View à tout changement de la variable liée.

Selon la WWDC Session 10033 (2023), le mécanisme @Binding dans SwiftUI traite jusqu'à 60 images par seconde lors de la synchronisation des champs de saisie, ce qui le rend adapté aux formulaires interactifs sans latence. Dans les deux frameworks, Two-Way Binding est du sucre syntaxique sur le pattern Observer, automatisant l'abonnement et la notification.

Two-Way Binding sur Android : DataBinding et Jetpack Compose

Sur Android, la liaison bidirectionnelle est disponible en deux variantes : le DataBinding XML classique via l'attribut @={} et Jetpack Compose via des références d'état bidirectionnelles. Les deux approches résolvent le même problème — synchroniser l'UI et le modèle — mais diffèrent par la syntaxe et le domaine d'application.

DataBinding avec @BindingAdapter et @=

Dans le balisage XML, la liaison bidirectionnelle est indiquée par la syntaxe @={variable.property} — le signe égal à l'intérieur des accolades le distingue de l'unidirectionnel @{variable}. Pour les Views personnalisées, l'annotation @BindingAdapter avec un attribut inverse est requise.

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

L'exemple montre un formulaire simple avec email et case à cocher — les deux champs utilisent la liaison bidirectionnelle, ce qui évite d'écrire TextWatcher et OnCheckedChangeListener dans le code de l'Activity. Lorsque l'utilisateur modifie le texte, le champ viewModel.email se met à jour automatiquement.

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

Un BindingAdapter personnalisé pour RatingBar utilise une paire d'annotations — @BindingAdapter et @InverseBindingAdapter — pour que la bibliothèque DataBinding sache comment lire la valeur depuis la View (retour inverse) et comment écrire dans la View (liaison directe). Le troisième adaptateur avec le suffixe AttrChanged notifie le système des changements de valeur initiés par l'utilisateur.

Two-Way Binding dans Jetpack Compose

Jetpack Compose ne prend pas en charge la syntaxe @={} mais fournit un mécanisme similaire via mutableStateOf et le passage explicite de fonction setter. La liaison bidirectionnelle dans Compose est construite en passant State et une fonction de callback (value, onValueChange) aux composants enfants.

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

    OutlinedTextField(
        value = email,
        onValueChange = { email = it },
        label = { Text("E-mail") }
    )
}

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

Dans Compose, la communication bidirectionnelle est émulée via une paire state + callback — le parent passe la valeur actuelle et une fonction de mise à jour, le composant enfant invoque le callback lors de l'interaction utilisateur. Cette approche montre explicitement la direction du flux de données, simplifiant le débogage par rapport à la synchronisation implicite de DataBinding.

Two-Way Binding sur iOS : @Binding dans SwiftUI

Dans SwiftUI, la liaison bidirectionnelle est implémentée via le propertyWrapper @Binding, qui crée une référence lecture-écriture vers une source de données appartenant à la View parente. @Binding ne stocke pas la valeur lui-même — il lit et écrit via le @State ou @StateObject du parent.

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

    var body: some View {
        Form {
            TextField("Email", text: $email)
            Toggle("J'accepte les conditions", isOn: $agreeToTerms)
            ChildRatingView(rating: $rating)
        }
    }
}

struct ChildRatingView: View {
    @Binding var rating: Double

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

Le symbole $ devant un nom de variable crée une référence Binding : $email a le type Binding, pas String. SwiftUI lie automatiquement les changements de texte dans TextField à la mise à jour de la propriété email via le mécanisme Combine. La View parente passe un Binding à son @State au composant enfant, permettant la modification de l'état depuis n'importe quel niveau de hiérarchie sans délégués ni callbacks.

Selon Apple WWDC 2023, SwiftUI utilise un algorithme de diffing pour minimiser les redessins : si la valeur @Binding change mais que la View ne dépend pas de cette valeur, aucun redessin n'a lieu. Cela offre des performances comparables à UIKit (jusqu'à 120 FPS sur les écrans ProMotion).

Two-Way Binding vs UDF : quand choisir quoi

Le choix entre la liaison bidirectionnelle et le flux de données unidirectionnel (UDF) est l'une des décisions architecturales clés dans le développement mobile. Le Two-Way Binding est optimal pour les états locaux de formulaire où chaque étape de l'utilisateur doit être immédiatement reflétée dans le modèle sans code supplémentaire. L'UDF est préférable pour l'état global de l'application où la prédictibilité des changements est plus importante que la vitesse de développement.

Recommandation : utilisez Two-Way Binding pour les champs de saisie simples (texte, cases à cocher, interrupteurs) dans les formulaires de 3 à 5 champs sans validation complexe. Pour les écrans avec état global, requêtes réseau et champs dépendants, utilisez UDF avec flux unidirectionnel et gestion explicite des événements. Chez IT Sectr, nous combinons les deux approches : Two-Way Binding dans les formulaires, UDF pour la navigation et la logique métier.

Erreurs courantes dans la liaison bidirectionnelle

Boucle infinie de mise à jour — le problème le plus courant lors de l'utilisation de Two-Way Binding. La boucle se produit lorsqu'un changement de modèle déclenche une mise à jour de l'UI, qui à son tour modifie à nouveau le modèle. Dans DataBinding, cela se produit si le getter dans @InverseBindingAdapter renvoie une nouvelle valeur immédiatement après un appel setter. La solution est de vérifier si la valeur a changé avant de réécrire (condition de garde).

La deuxième erreur courante est la liaison de champs calculés. Si un champ dépend d'un autre champ (par exemple, coût total = prix × quantité), la liaison bidirectionnelle peut conduire à un état incohérent. Par exemple, l'utilisateur modifie la quantité, déclenchant un recalcul du coût, qui modifie à nouveau la quantité. Pour les champs calculés, utilisez la liaison unidirectionnelle avec Flow ou Combine.

La troisième erreur est la liaison de champs Observable sans LifecycleOwner. Dans Android DataBinding, un LifecycleOwner doit être passé à la liaison, sinon les observateurs ne seront pas nettoyés lors de la destruction de l'Activity, entraînant des fuites mémoire. Passez toujours viewLifecycleOwner dans les fragments et this dans l'Activity.

Selon Google Issue Tracker (2024), environ 15 % des rapports de bugs DataBinding sont liés à des mises à jour cycliques. Pour le diagnostic, utilisez Android Studio Layout Inspector — il affiche les valeurs actuelles de toutes les liaisons à l'écran, simplifiant la recherche de la source de la boucle infinie.