Composition: جوہر، Compose میں UI ٹری کی تعمیر

Jetpack Compose میں Composition کیا ہے

Composition Composable فنکشنز پر عمل درآمد کا عمل ہے، جس کے نتیجے میں صارف انٹرفیس کی نوڈس کے درخت کے طور پر اندرونی نمائندگی ہوتی ہے۔ اس درخت کا ہر نوڈ یا تو بلٹ ان جزو (Text, Button, Image) سے یا صارف کے بیان کردہ Composable فنکشن کی کال سے مطابقت رکھتا ہے۔ Composition براہ راست Android View اشیاء نہیں بناتا — یہ ایک تجریدی وضاحت بناتا ہے جسے بعد میں Layout اور Drawing مراحل میں پروسیس کیا جاتا ہے۔

Composition کی اہم خصوصیت اس کی دوبارہ شروع ہونے کی صلاحیت ہے۔ کمپوزیشن کے اندر ہر Composable فنکشن کسی بھی وقت دوبارہ شروع کیا جا سکتا ہے اگر اس کے ان پٹ پیرامیٹرز یا اس کے پڑھے گئے حالت کی اشیاء تبدیل ہو گئی ہوں۔ نظام پورے درخت کو دوبارہ شروع نہیں کرتا — صرف وہ فنکشنز جو تبدیل شدہ ڈیٹا پر حقیقت میں منحصر ہیں۔

تکنیکی طور پر، Composition کو Composer کے ذریعے منظم کیا جاتا ہے — ایک اندرونی انجن جو Kotlin کمپائلر ہر Composable فنکشن میں شامل کرتا ہے۔ Composer سلاٹس (مقام گروپ) میں معلومات لکھتا ہے کہ کون سے فنکشنز کہلائے گئے، کن پیرامیٹرز کے ساتھ اور کس ترتیب میں۔ بعد میں کالوں پر، Composer نئے ڈیٹا کا ذخیرہ شدہ ڈیٹا سے موازنہ کرتا ہے اور دوبارہ شروع کرنے کا فیصلہ کرتا ہے۔

Composition کے دوران UI ٹری کیسے بنتا ہے

UI ٹری بنانے کا عمل Activity یا Fragment کے اندر setContent طریقہ کو کال کرنے سے شروع ہوتا ہے۔ یہ طریقہ ابتدائی Composition بناتا ہے اور جڑ Composable فنکشن کو عمل میں لانا شروع کرتا ہے۔ پھر ہر nested Composable فنکشن درخت میں اپنے نوڈ شامل کرتا ہے، ایک درجہ بندی بناتا ہے: Row میں Text اور Button ہوتے ہیں، Column میں Image اور Card ہوتے ہیں، وغیرہ۔

ہر درخت کا نوڈ سورس کوڈ میں اپنی پوزیشن کی بنیاد پر ایک منفرد مقام کلید حاصل کرتا ہے۔ یہ کلید بعد میں عمل درآمد کے دوران نوڈ کی شناخت کے لیے استعمال ہوتی ہے۔ مقام کلید وہ وجہ ہے کہ Composable فنکشنز کو کال کرنے کی ترتیب شرائط پر منحصر نہیں ہونی چاہیے: اگر ایک رن میں A -> B کہلائے، اور اگلے میں B -> A، تو Compose پرانے اور نئے نوڈس کو مماثل نہیں کر سکے گا۔

@Composable
fun AppScreen() {
    Column {                     // Column نوڈ (مقام 1)
        HeaderSection()            // HeaderSection نوڈ (مقام 2)
        ContentSection()           // ContentSection نوڈ (مقام 3)
        FooterSection()            // FooterSection نوڈ (مقام 4)
    }
}

@Composable
fun HeaderSection() {
    Row {                       // Row نوڈ (مقام 2.1)
        Text("عنوان")         // Text نوڈ (مقام 2.2)
        Icon(...)                // Icon نوڈ (مقام 2.3)
    }
}

اس مثال میں، ہر کال کوڈ میں ترتیب کی بنیاد پر ایک مقام ملتا ہے۔ Column (مقام 1) میں تین بچے نوڈ ہیں (مقام 2, 3, 4)۔ HeaderSection دو مزید بچے نوڈ شامل کرتا ہے (2.1, 2.2, 2.3)۔ اگر اگلی recomposition میں ContentSection کو HeaderSection سے پہلے کہا جائے، تو Composer نوڈس کو صحیح طریقے سے مماثل نہیں کر سکے گا — اس لیے اصول: Composable فنکشن کالز کی ترتیب مستحکم ہونی چاہیے۔

Composition میں حالت کا انتظام

Composition میں حالت State<T> قسم کی اشیاء کے ذریعے منظم کی جاتی ہے۔ جب کوئی Composable فنکشن کسی مندوب خاصیت (by) کے ذریعے State سے قدر پڑھتا ہے، تو یہ اس State پر انحصار رجسٹر کرتا ہے۔ جب قدر تبدیل ہوتی ہے، تو اس State کو پڑھنے والے تمام فنکشنز اگلے کمپوزیشن مرحلے میں دوبارہ شروع کرنے کے لیے نشان زد ہو جاتے ہیں۔

انحصار رجسٹریشن میکانزم کو snapshot نظام کہا جاتا ہے۔ جب بھی State تبدیل ہوتا ہے، ایک snapshot تمام تبدیلیاں ریکارڈ کرتا ہے اور Composer کو بتاتا ہے کہ کون سے فنکشنز اس State پر منحصر ہیں۔ یہ سمجھنا ضروری ہے: غیر Composable کوڈ (مثلاً، onClick میں) کے اندر State پڑھنا انحصار رجسٹر نہیں کرتا — صرف Composable فنکشن کے اندر یا کمپوزیشن تناظر میں عمل میں لائے گئے لیمبڈا میں پڑھنا انحصار رجسٹر کرتا ہے۔

Snapshot نظام لین دین کے انداز میں کام کرتا ہے: ایک ہی واقعہ کے اندر متعدد State تبدیلیاں ایک لین دین میں یکجا ہو جاتی ہیں، جو متعدد recompositions کو روکتی ہیں۔ یہ خاص طور پر اشاروں کو سنبھالتے وقت اہم ہے: ایک حرکت کئی State اشیاء کو تبدیل کرتی ہے، لیکن Compose صرف ایک recomposition انجام دیتا ہے۔

@Composable
fun StateExample() {
    var text by remember { mutableStateOf("Hello") }
    var isVisible by remember { mutableStateOf(true) }

    Column {
        Text(text)  // متن پر انحصار رجسٹر کرتا ہے

        if (isVisible) {  // isVisible پر انحصار رجسٹر کرتا ہے
            TextField(value = text, onValueChange = { text = it })
        }

        Button(onClick = { isVisible = !isVisible }) {
            Text(if (isVisible) "چھپائیں" else "دکھائیں")
        }
    }
}

متن تبدیل کرنے سے صرف Column, Text اور TextField کی recomposition شروع ہوتی ہے۔ Column, Button اور isVisible شرط تبدیل نہیں ہوتے۔ recomposition کی یہ تنہائی ان نظاموں کے مقابلے میں Compose کا ایک اہم فائدہ ہے جو پوری اسکرین کو دوبارہ بناتے ہیں۔ ہر Composable فنکشن صرف ان State اشیاء کو ٹریک کرتا ہے جنہیں وہ براہ راست پڑھتا ہے۔

Composition بمقابلہ Recomposition: کلیدی فرق

Composition اور Recomposition Composable فنکشنز پر عمل درآمد کے دو مختلف طریقے ہیں۔ Composition اسکرین بننے پر ایک بار ہوتا ہے: نظام تمام Composable فنکشنز کو ابتدائی اقدار کے ساتھ عمل میں لاتا ہے اور ابتدائی UI ٹری بناتا ہے۔ Recomposition ڈیٹا تبدیل ہونے پر کئی بار ہوتا ہے: نظام صرف ان فنکشنز کو دوبارہ شروع کرتا ہے جو تبدیل شدہ حالت پر منحصر ہیں۔

طریقہ Composition تمام درخت کے نوڈس کو فعال کرتا ہے، ہر فنکشن کے لیے سلاٹ مختص کرتا ہے اور تمام ذیلیوں کو رجسٹر کرتا ہے۔ Recomposition انتخابی طور پر کام کرتا ہے: Compose ہر فنکشن کے نئے اور پرانے پیرامیٹر اقدار کا موازنہ کرتا ہے، اور اگر وہ تبدیل نہیں ہوئے — فنکشن عمل میں نہیں آتا (skipping)۔

Composition اور Recomposition لاگت میں مختلف ہیں۔ پہلا Composition زیادہ مہنگا ہے کیونکہ اسے مکمل درخت کی تعمیر اور سلاٹ مختص کرنے کی ضرورت ہوتی ہے۔ Recomposition سستا ہے، خاص طور پر اگر زیادہ تر فنکشنز مستحکم ہوں — ان کے پیرامیٹرز کا equals سے موازنہ کیا جاتا ہے، اور Compose ان کی کال چھوڑ دیتا ہے۔ زیادہ سے زیادہ کارکردگی کے لیے، آپ کو کوشش کرنی چاہیے کہ زیادہ تر recompositions کم سے کم فنکشنز کو متاثر کریں۔

CompositionLocal: درخت کے ذریعے ڈیٹا کی منتقلی

CompositionLocal کمپوزیشن درخت کے ذریعے واضح طور پر ڈیٹا منتقل کرنے کا ایک طریقہ کار ہے۔ یہ اس مسئلے کو حل کرتا ہے جب کسی پیرامیٹر کو درجنوں nested Composable فنکشنز کے ذریعے منتقل کرنے کی ضرورت ہوتی ہے جو اسے براہ راست استعمال نہیں کرتے۔ واضح پیرامیٹر چین کے بجائے، ڈیٹا سب سے اوپر کی سطح پر سیٹ کیا جاتا ہے اور CompositionLocal.current کے ذریعے کسی بھی nested فنکشن میں پڑھا جاتا ہے۔

MaterialTheme CompositionLocal کی سب سے مشہور مثال ہے۔ تمام Compose اجزاء MaterialTheme.colorScheme, MaterialTheme.typography, MaterialTheme.shapes کے ذریعے رنگ، نوع ٹائپ اور شکلیں پڑھتے ہیں، بغیر پیرامیٹرز کے ذریعے حاصل کیے۔ ڈویلپرز موجودہ صارف، لوکلائزیشن سیٹنگز یا اسکرین کنفیگریشن جیسے ڈیٹا کے لیے اپنا CompositionLocal بنا سکتے ہیں۔

ایک اہم حد: CompositionLocal کو بار بار تبدیل ہونے والے ڈیٹا (اسکرول پوزیشن، ان پٹ فیلڈ میں متن) کے لیے استعمال نہیں کیا جانا چاہیے۔ CompositionLocal پڑھنے والا جزو ہر بار قدر تبدیل ہونے پر دوبارہ شروع ہوتا ہے، لہذا متحرک ڈیٹا کے لیے واضح پیرامیٹرز یا State استعمال کرنا بہتر ہے۔ CompositionLocal کنفیگریشن ڈیٹا کے لیے بہترین ہے جو شاذ و نادر یا کبھی تبدیل نہیں ہوتا۔

val LocalUser = compositionLocalOf<User?> { null }

@Composable
fun AppRoot(user: User, content: @Composable () -> Unit) {
    CompositionLocalProvider(LocalUser.provides(user)) {
        content()
    }
}

@Composable
fun UserAvatar() {
    val user = LocalUser.current  // واضح پیرامیٹر کے بغیر پڑھنا
    AsyncImage(model = user?.avatarUrl, contentDescription = "Avatar")
}

CompositionLocalProvider ایک دائرہ کار بناتا ہے جس کے اندر LocalUser.current مخصوص قدر لوٹاتا ہے۔ UserAvatar صارف کو انٹرمیڈیٹ فنکشنز کے ذریعے واضح طور پر پیرامیٹر منتقل کیے بغیر پڑھتا ہے۔ یہ گہری درجہ بندیوں میں خاص طور پر قیمتی ہے جہاں ڈیٹا صرف چند پتوں والے نوڈس میں درکار ہوتا ہے۔