Two-Way Binding: ما هو الربط ثنائي الاتجاه للبيانات في Android و iOS

ما هو Two-Way Binding؟

Two-Way Binding (الربط ثنائي الاتجاه للبيانات) — آلية معمارية حيث تنعكس التغييرات في نموذج البيانات تلقائياً في واجهة المستخدم، وتقوم التغييرات في الواجهة بتحديث النموذج فوراً. على عكس الربط أحادي الاتجاه، حيث تتدفق البيانات فقط من النموذج إلى العرض، ينشئ الربط ثنائي الاتجاه حلقة مزامنة مغلقة دون ترميز يدوي لكل تحديث.

وفقاً لـ Android Developers Blog (2023)، مكتبة DataBinding، التي تم تقديمها في 2015، تُستخدم في 42% من تطبيقات Android التجارية. الآلية مطلوبة بشكل خاص في نماذج الإدخال — حقول النص، المفاتيح، أشرطة التمرير وخانات الاختيار — حيث يجب أن ينعكس إدخال المستخدم فوراً في النموذج والتغييرات البرمجية في الواجهة. في كل هذه السيناريوهات، يكتب المطور ربطاً واحداً بدلاً من زوج "مستمع + محدد".

في IT Sectr، طبقنا الربط ثنائي الاتجاه في المشاريع منذ 2017 ونوصي باستخدامه بوعي: لحقول الإدخال البسيطة، ولكن ليس للحالات المعقدة ذات التبعيات.

كيف يعمل الربط ثنائي الاتجاه؟

آلية Two-Way Binding مبنية على ثلاثة عناصر رئيسية: حقل قابل للمراقبة (observable)، مستمع التغييرات و آلية المزامنة العكسية. عندما يكتب المستخدم نصاً في حقل EditText، يعترض النظام حدث TextWatcher، يكتب القيمة الجديدة في المتغير المرتبط ويخطر الواجهة لإعادة الرسم إذا تغير المتغير من الكود.

تحت الغطاء، تقوم مكتبة DataBinding في Android بتوليد فئة Binding في وقت الترجمة تحتوي على كل منطق الربط. لكل View بسمة @={variable}، يتم إنشاء زوج setter + getter مع إبطال. في SwiftUI، يقوم propertyWrapper @Binding بعمل مماثل، بمزامنة القيمة عبر آلية Combine. يتتبع SwiftUI التغييرات عبر خصائص @Published ويعيد رسم الـ View تلقائياً عند أي تغيير في المتغير المرتبط.

وفقاً لـ WWDC Session 10033 (2023)، آلية @Binding في SwiftUI تعالج ما يصل إلى 60 إطاراً في الثانية عند مزامنة حقول الإدخال، مما يجعلها مناسبة للنماذج التفاعلية دون تأخير. في كلا الإطارين، Two-Way Binding هو سكر نحوي فوق نمط Observer، لأتمتة الاشتراك والإخطار.

Two-Way Binding في Android: DataBinding و Jetpack Compose

في Android، الربط ثنائي الاتجاه متاح بنوعين: DataBinding الكلاسيكي عبر XML بسمة @={} و Jetpack Compose عبر مراجع الحالة ثنائية الاتجاه. كلا النهجين يحلان نفس المشكلة — مزامنة الواجهة والنموذج — لكنهما يختلفان في بناء الجملة ونطاق التطبيق.

DataBinding مع @BindingAdapter و @=

في ترميز XML، يُشار إلى الربط ثنائي الاتجاه ببناء الجملة @={variable.property} — علامة التساوي داخل الأقواس المتعرجة تميزه عن الربط أحادي الاتجاه @{variable}. للـ Views المخصصة، يلزم التعليق التوضيحي @BindingAdapter مع سمة عكسية.

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

يظهر المثال نموذجاً بسيطاً بالبريد الإلكتروني وخانة اختيار — كلا الحقلين يستخدمان الربط ثنائي الاتجاه، مما يلغي الحاجة لكتابة TextWatcher و OnCheckedChangeListener في كود Activity. عندما يغير المستخدم النص، يتم تحديث حقل viewModel.email تلقائياً.

@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 مخصص لـ RatingBar يستخدم زوجاً من التعليقات التوضيحية — @BindingAdapter و @InverseBindingAdapter — لتعرف مكتبة DataBinding كيفية قراءة القيمة من الـ View (التغذية العكسية) وكيفية الكتابة في الـ View (الربط المباشر). المحول الثالث باللاحقة AttrChanged يخطر النظام بتغييرات القيمة التي بدأها المستخدم.

Two-Way Binding في Jetpack Compose

Jetpack Compose لا يدعم بناء جملة @={} ولكنه يوفر آلية مماثلة عبر mutableStateOf وتمرير دالة setter صريحة. الربط ثنائي الاتجاه في Compose مبني على تمرير State ودالة رد اتصال (value, onValueChange) إلى المكونات الفرعية.

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

    OutlinedTextField(
        value = email,
        onValueChange = { email = it },
        label = { Text("البريد الإلكتروني") }
    )
}

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

في Compose، يتم محاكاة الاتصال ثنائي الاتجاه عبر زوج state + callback — يمرر الأصل القيمة الحالية ودالة التحديث، ويستدعي المكون الفرعي callback عند تفاعل المستخدم. هذا النهج يظهر بوضوح اتجاه تدفق البيانات، مما يبسط التصحيح مقارنة بمزامنة DataBinding الضمنية.

Two-Way Binding في iOS: @Binding في SwiftUI

في SwiftUI، يتم تنفيذ الربط ثنائي الاتجاه عبر propertyWrapper @Binding، الذي ينشئ مرجع قراءة-كتابة لمصدر بيانات مملوك للـ View الأصلي. @Binding لا يخزن القيمة بنفسه — يقرأ ويكتب عبر @State أو @StateObject للأصل.

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

    var body: some View {
        Form {
            TextField("Email", text: $email)
            Toggle("أوافق على الشروط", isOn: $agreeToTerms)
            ChildRatingView(rating: $rating)
        }
    }
}

struct ChildRatingView: View {
    @Binding var rating: Double

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

الرمز $ قبل اسم المتغير ينشئ مرجع Binding: $email له نوع Binding وليس String. يربط SwiftUI تلقائياً تغييرات النص في TextField بتحديث خاصية email عبر آلية Combine. يمرر الـ View الأصلي Binding إلى @State الخاص به للمكون الفرعي، مما يسمح بتعديل الحالة من أي مستوى في التسلسل الهرمي دون وكلاء أو callbacks.

وفقاً لـ Apple WWDC 2023، يستخدم SwiftUI خوارزمية diffing لتقليل إعادة الرسم: إذا تغيرت قيمة @Binding لكن الـ View لا يعتمد على تلك القيمة، لا تحدث إعادة رسم. هذا يوفر أداءً مشابهاً لـ UIKit (حتى 120 إطاراً في الثانية على شاشات ProMotion).

Two-Way Binding مقابل UDF: متى تختار ماذا

الاختيار بين الربط ثنائي الاتجاه وتدفق البيانات أحادي الاتجاه (UDF) هو أحد القرارات المعمارية الرئيسية في تطوير الجوال. Two-Way Binding هو الأمثل للحالات المحلية للنموذج حيث يجب أن تنعكس كل خطوة من المستخدم فوراً في النموذج دون كود إضافي. UDF مفضل للحالة العامة للتطبيق حيث تكون قابلية توقع التغييرات أكثر أهمية من سرعة التطوير.

توصية: استخدم Two-Way Binding لحقول الإدخال البسيطة (نص، خانات اختيار، مفاتيح) في نماذج بـ 3–5 حقول بدون تحقق معقد. للشاشات ذات الحالة العامة وطلبات الشبكة والحقول التابعة، استخدم UDF مع تدفق أحادي الاتجاه ومعالجة أحداث صريحة. في IT Sectr، نجمع بين كلا النهجين: Two-Way Binding داخل النماذج، UDF للملاحة ومنطق الأعمال.

الأخطاء الشائعة في الربط ثنائي الاتجاه

حلقة التحديث اللانهائية — المشكلة الأكثر شيوعاً عند استخدام Two-Way Binding. تحدث الحلقة عندما يتسبب تغيير النموذج في تحديث الواجهة، والذي بدوره يغير النموذج مرة أخرى. في DataBinding، يحدث هذا إذا أعاد getter في @InverseBindingAdapter قيمة جديدة فوراً بعد استدعاء setter. الحل هو التحقق مما إذا كانت القيمة قد تغيرت قبل الكتابة مرة أخرى (شرط الحماية).

الخطأ الثاني الشائع هو ربط الحقول المحسوبة. إذا كان حقل يعتمد على حقل آخر (مثلاً، التكلفة الإجمالية = السعر × الكمية)، يمكن أن يؤدي الربط ثنائي الاتجاه إلى حالة غير متسقة. على سبيل المثال، يغير المستخدم الكمية، مما يؤدي إلى إعادة حساب التكلفة، والذي يغير الكمية مرة أخرى. للحقول المحسوبة، استخدم الربط أحادي الاتجاه مع Flow أو Combine.

الخطأ الثالث هو ربط حقول Observable بدون LifecycleOwner. في Android DataBinding، يجب تمرير LifecycleOwner إلى الربط، وإلا لن يتم تنظيف المراقبين عند تدمير Activity، مما يؤدي إلى تسرب الذاكرة. قم دائماً بتمرير viewLifecycleOwner في الأجزاء (fragments) و this في Activity.

وفقاً لـ Google Issue Tracker (2024)، حوالي 15% من تقارير الأخطاء في DataBinding مرتبطة بالتحديثات الدورية. للتشخيص، استخدم Android Studio Layout Inspector — يعرض القيم الحالية لجميع الارتباطات على الشاشة، مما يبسط البحث عن مصدر الحلقة اللانهائية.