Two-Way Binding: کیا ہے، Android اور iOS میں دو طرفہ ڈیٹا بائنڈنگ

Two-Way Binding کیا ہے؟

Two-Way Binding (دو طرفہ ڈیٹا بائنڈنگ) — ایک آرکیٹیکچرل میکانزم جس میں ڈیٹا ماڈل میں تبدیلیاں خودکار طور پر صارف انٹرفیس میں ظاہر ہوتی ہیں، اور UI میں تبدیلیاں فوری طور پر ماڈل کو اپ ڈیٹ کرتی ہیں۔ یک طرفہ بائنڈنگ کے برعکس، جہاں ڈیٹا صرف ماڈل سے ویو کی طرف بہتا ہے، دو طرفہ بائنڈنگ ہر اپ ڈیٹ کو دستی کوڈنگ کے بغیر ایک بند ہم آہنگی لوپ بناتی ہے۔

Android Developers Blog (2023) کے مطابق، 2015 میں متعارف کرائی گئی DataBinding لائبریری، 42% تجارتی Android ایپلیکیشنز میں استعمال ہوتی ہے۔ یہ میکانزم خاص طور پر ان پٹ فارمز — ٹیکسٹ فیلڈز، سوئچز، سلائیڈرز اور چیک باکس — میں مانگ میں ہے جہاں صارف کا ان پٹ فوری طور پر ماڈل میں اور پروگراماتی تبدیلیاں UI میں ظاہر ہونی چاہئیں۔ ان تمام منظرناموں میں، ڈیولپر "سننے والا + سیٹر" کی جوڑی کے بجائے ایک بائنڈنگ لکھتا ہے۔

IT Sectr میں، ہم نے 2017 سے پروجیکٹس میں دو طرفہ بائنڈنگ کا اطلاق کیا ہے اور اسے شعوری طور پر استعمال کرنے کی سفارش کرتے ہیں: سادہ ان پٹ فیلڈز کے لیے، لیکن انحصار والی پیچیدہ حالتوں کے لیے نہیں۔

دو طرفہ بائنڈنگ کیسے کام کرتی ہے؟

Two-Way Binding میکانزم تین اہم عناصر پر بنایا گیا ہے: قابل مشاہدہ فیلڈ (observable)، تبدیلی سننے والا اور معکوس ہم آہنگی میکانزم۔ جب صارف EditText فیلڈ میں ٹیکسٹ ٹائپ کرتا ہے، سسٹم TextWatcher ایونٹ کو روکتا ہے، نئی قیمت کو باؤنڈڈ متغیر میں لکھتا ہے، اور UI کو دوبارہ ڈرائنگ کے لیے مطلع کرتا ہے اگر متغیر کوڈ سے تبدیل ہوا ہو۔

ہڈ کے نیچے، Android DataBinding لائبریری مرتب وقت پر ایک Binding کلاس تیار کرتی ہے جس میں تمام بائنڈنگ منطق ہوتی ہے۔ @={variable} وصف والے ہر View کے لیے، invalidiation کے ساتھ setter + getter جوڑا بنایا جاتا ہے۔ SwiftUI میں، @Binding propertyWrapper Combine میکانزم کے ذریعے قیمت کو ہم آہنگ کرتے ہوئے اسی طرح کا کام کرتا ہے۔ SwiftUI @Published خصوصیات کے ذریعے تبدیلیوں کو ٹریک کرتا ہے اور باؤنڈڈ متغیر میں کسی بھی تبدیلی پر خودکار طور پر View کو دوبارہ ڈرائنگ کرتا ہے۔

WWDC Session 10033 (2023) کے مطابق، SwiftUI میں @Binding میکانزم ان پٹ فیلڈز کو ہم آہنگ کرتے ہوئے فی سیکنڈ 60 فریموں تک پروسیس کرتا ہے، جو اسے بغیر تاخیر کے انٹرایکٹو فارمز کے لیے موزوں بناتا ہے۔ دونوں فریم ورکس میں، Two-Way Binding Observer پیٹرن پر نحوی شوگر ہے، جو سبسکرپشن اور اطلاع کو خودکار بناتا ہے۔

Android میں Two-Way Binding: DataBinding اور Jetpack Compose

Android میں، دو طرفہ بائنڈنگ دو شکلوں میں دستیاب ہے: @={} وصف کے ذریعے کلاسک XML DataBinding اور دو طرفہ اسٹیٹ ریفرنسز کے ذریعے Jetpack Compose۔ دونوں طریقے ایک ہی مسئلہ — UI اور ماڈل کو ہم آہنگ کرنا — حل کرتے ہیں لیکن نحو اور اطلاق کے دائرہ کار میں مختلف ہیں۔

@BindingAdapter اور @= کے ساتھ DataBinding

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>

مثال ای میل اور چیک باکس کے ساتھ ایک سادہ فارم دکھاتی ہے — دونوں فیلڈ دو طرفہ بائنڈنگ استعمال کرتے ہیں، جو Activity کوڈ میں TextWatcher اور OnCheckedChangeListener لکھنے کی ضرورت کو ختم کرتا ہے۔ جب صارف ٹیکسٹ تبدیل کرتا ہے، 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() }
}

RatingBar کے لیے ایک کسٹم BindingAdapter تشریحات کا ایک جوڑا — @BindingAdapter اور @InverseBindingAdapter — استعمال کرتا ہے تاکہ DataBinding لائبریری کو پتہ چلے کہ View سے قیمت کیسے پڑھنی ہے (معکوس فیڈ بیک) اور View میں کیسے لکھنی ہے (براہ راست بائنڈنگ)۔ AttrChanged لاحقہ والا تیسرا اڈاپٹر صارف کی طرف سے شروع کردہ قیمت کی تبدیلیوں کے بارے میں سسٹم کو مطلع کرتا ہے۔

Jetpack Compose میں Two-Way Binding

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 جوڑی کے ذریعے نقلی کی جاتی ہے — والدین موجودہ قیمت اور ایک اپ ڈیٹ فنکشن پاس کرتا ہے، چائلڈ جزو صارف کے تعامل پر کال بیک کو طلب کرتا ہے۔ یہ طریقہ ڈیٹا کے بہاؤ کی سمت واضح طور پر دکھاتا ہے، جو واضح DataBinding ہم آہنگی کے مقابلے میں ڈیبگنگ کو آسان بناتا ہے۔

iOS میں Two-Way Binding: SwiftUI میں @Binding

SwiftUI میں، دو طرفہ بائنڈنگ @Binding propertyWrapper کے ذریعے لاگو کی جاتی ہے، جو والدین 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 میں ٹیکسٹ تبدیلیوں کو Combine میکانزم کے ذریعے email خصوصیت کی اپ ڈیٹ سے جوڑتا ہے۔ والدین View اپنے @State کے لیے ایک Binding چائلڈ جزو کو پاس کرتا ہے، جو مندوبین یا کال بیک کے بغیر کسی بھی درجہ بندی کی سطح سے حالت میں ترمیم کی اجازت دیتا ہے۔

Apple WWDC 2023 کے مطابق، SwiftUI دوبارہ ڈرائنگ کو کم سے کم کرنے کے لیے diffing الگورتھم استعمال کرتا ہے: اگر @Binding قیمت تبدیل ہوتی ہے لیکن View اس قیمت پر منحصر نہیں ہے، تو کوئی دوبارہ ڈرائنگ نہیں ہوتی۔ یہ UIKit کے مقابلے کی کارکردگی فراہم کرتا ہے (ProMotion ڈسپلے پر 120 FPS تک)۔

Two-Way Binding بمقابلہ UDF: کب کیا انتخاب کریں

دو طرفہ بائنڈنگ اور یک طرفہ ڈیٹا فلو (UDF) کے درمیان انتخاب موبائل ڈیولپمنٹ میں کلیدی آرکیٹیکچرل فیصلوں میں سے ایک ہے۔ Two-Way Binding مقامی فارم کی حالتوں کے لیے بہترین ہے جہاں صارف کے ہر قدم کو اضافی کوڈ کے بغیر فوری طور پر ماڈل میں ظاہر ہونا چاہیے۔ UDF عالمی ایپلیکیشن حالت کے لیے ترجیحی ہے جہاں تبدیلیوں کی پیش گوئی کرنا ڈیولپمنٹ کی رفتار سے زیادہ اہم ہے۔

سفارش: پیچیدہ توثیق کے بغیر 3–5 فیلڈ والے فارمز میں سادہ ان پٹ فیلڈز (ٹیکسٹ، چیک باکس، سوئچ) کے لیے Two-Way Binding استعمال کریں۔ عالمی حالت، نیٹ ورک کی درخواستوں اور منحصر فیلڈز والی اسکرینوں کے لیے، واضح واقعہ ہینڈلنگ کے ساتھ یک طرفہ بہاؤ والا UDF استعمال کریں۔ IT Sectr میں، ہم دونوں طریقوں کو یکجا کرتے ہیں: فارمز کے اندر Two-Way Binding، نیویگیشن اور کاروباری منطق کے لیے UDF۔

دو طرفہ بائنڈنگ میں عام غلطیاں

لامتناہی اپ ڈیٹ لوپ — Two-Way Binding استعمال کرتے وقت سب سے عام مسئلہ۔ لوپ اس وقت ہوتا ہے جب ماڈل میں تبدیلی UI اپ ڈیٹ کو متحرک کرتی ہے، جو پھر ماڈل کو دوبارہ تبدیل کرتی ہے۔ DataBinding میں، یہ اس وقت ہوتا ہے جب @InverseBindingAdapter میں getter setter کال کے فوراً بعد ایک نئی قیمت لوٹاتا ہے۔ حل یہ ہے کہ واپس لکھنے سے پہلے چیک کریں کہ قیمت تبدیل ہوئی ہے یا نہیں (گارڈ شرط)۔

دوسری عام غلطی حساب شدہ فیلڈز کو بائنڈ کرنا ہے۔ اگر ایک فیلڈ دوسرے فیلڈ پر منحصر ہے (مثلاً، کل لاگت = قیمت × مقدار)، دو طرفہ بائنڈنگ متضاد حالت کا باعث بن سکتی ہے۔ مثال کے طور پر، صارف مقدار تبدیل کرتا ہے، لاگت کی دوبارہ گنتی شروع کرتا ہے، جو پھر مقدار کو دوبارہ تبدیل کرتا ہے۔ حساب شدہ فیلڈز کے لیے، Flow یا Combine کے ساتھ یک طرفہ بائنڈنگ استعمال کریں۔

تیسری غلطی LifecycleOwner کے بغیر Observable فیلڈز کو بائنڈ کرنا ہے۔ Android DataBinding میں، بائنڈنگ میں LifecycleOwner پاس کیا جانا چاہیے، ورنہ Activity تباہ ہونے پر مبصرین صاف نہیں ہوں گے، جس سے میموری کا اخراج ہوتا ہے۔ Fragment میں ہمیشہ viewLifecycleOwner اور Activity میں this پاس کریں۔

Google Issue Tracker (2024) کے مطابق، DataBinding کی بگ رپورٹس کا تقریباً 15% چکری اپ ڈیٹس سے متعلق ہے۔ تشخیص کے لیے، Android Studio Layout Inspector استعمال کریں — یہ اسکرین پر تمام بائنڈنگز کی موجودہ قیمتیں دکھاتا ہے، لامتناہی لوپ کے ماخذ کی تلاش کو آسان بناتا ہے۔