Composable Function Jetpack Compose میں یوزر اینٹرفیس کی ایک بنیادی اکائی ہے جو اس بات کی وضاحت کرتی ہے کہ سکرین کا ایک حصہ کیسا دکھنا اور برتاو کرنا چاہیے۔ ایسا ہر فنکشن @Composable اینوٹیشن سے نشان شدہ ہوتا ہے اور ایک خاص سیاق میں چلایا جاتا ہے جو Compose کو انحصارات کو ٹریک کرنے اور ڈیٹا بدلنے پر خود برداست UI تعمیر کرنے کی اجازت دیتا ہے۔ Google Android Developers, 2026 کے مطابق، Composable فنکشن کی مناسب تعمیر ایپلیکیشن کی کارکردگی اور دوبارہ ترتیب کی موثریت کو سیدھے متاثر کرتا ہے۔
اہم نکات
Composable Function Kotlin زبان میں ایک فنکشن ہے، جو @Composable اینوٹیشن سے نشان شدہ ہوتا ہے، جو یوزر اینٹرفیس کے ایک حصہ کو اعلانی انداز میں بیان کرتا ہے۔ Java کوڈ یا XML مارک اپ کے ذریعے View ابجیکٹس بنانے اور ترتیب دینے کے بجائے، ڈیولپر صرف یہ لکھتا ہے کہ ڈیٹا کی ہر حالت کے لیے UI کیسا دکھنا چاہیے۔
Composable فنکشن اور روایتی Android View نظام کے درمیان بنیادی فرق اپ ڈیٹ ماڈل میں ہے۔ کلاسیکی طریقے میں، ڈیولپر دستی طور پر findViewById کو کال کرتا تھا، setText کے ذریعے متن بدلتا تھا اور setVisibility کے ذریعے مرئی کا انتظام کرتا تھا۔ Composable Function آپ کو اس روٹین سے آزاد کرتا ہے: جب ڈیٹا بدلتا ہے، نظام خود طور پر طے کرتا ہے کہ کن سے فنکشن کو دوبارہ ترتیب دینے کی ضرورت ہے اور صرف انہیں چلاتا ہے۔
Kotlin کامپائلر، @Composable اینوٹیشن پر کارروائی کرتے هوئے، اضافی کوڈ تیار کرتا ہے جو فنکشن کو ترتیب کے میکانزم میں ضم کرتا ہے۔ اس کوڈ میں سلوٹس میں پڑھنا اور لکھنا شامل ہے — خاص میمری سیلز جو موجودہ UI درخت میں ہر Composable فنکشن کی حالت اور پیرامیٹر محفوظ کرتے ہیں۔ اس انضمام کے شکریے، Compose جانتا ہے کہ کون سے فنکشن کس ڈیٹا پر منحصر ہیں۔
Composable فنکشن کا سین ٹیکس انتہائی مختصر ہے: fun کی ورڈ سے پہلے @Composable شامل کریں۔ فنکشن کسی بھی پیرامیٹر کو قبول کر سکتا ہے، اپنے بوڈی میں دوسرے Composable کالز شامل کر سکتا ہے اور شرطی UI رینڈرنگ کے لیے Kotlin کے تعمیرات — شرائط، لوپس، when ایکسپریشنز — استعمال کر سکتا ہے۔
@Composable
fun ProductItem(
product: Product,
modifier: Modifier = Modifier,
onAddToCart: () -> Unit
) {
Card(modifier = modifier.padding(8.dp)) {
Row(modifier = Modifier.fillMaxWidth().padding(12.dp),
verticalAlignment = Alignment.CenterVertically) {
Column(modifier = Modifier.weight(1f)) {
Text(text = product.name, style = MaterialTheme.typography.titleMedium)
Text(text = "${product.price}", color = MaterialTheme.colorScheme.primary)
}
Button(onClick = onAddToCart) {
Text("ٹوکری میں شامل کریں")
}
}
}
}
اس مثال میں، ProductItem Composable فنکشن ایک Product آبجیکٹ، ایک موڈیفائر اور ایک کول بیک قبول کرتا ہے۔ تینوں پیرامیٹر ناقابل تبدیل ہیں، جو دوبارہ ترتیب کے دوران متوقع سلوک کی ضمانت دیتا ہے۔ موڈیفائر ایک طبیعی قیمت کے ساتھ پیرامیٹر کے طور پر پیس کیا جاتا ہے — یہ ایک معیاری مشق ہے جو کال کرنے والے کو پیڈنگ اور حجوم کو کسٹمائز کرنے کی اجازت دیتا ہے۔
Composable فنکشن کے اندر، مضمونی Material Design اجزاء (Text, Button, Card, TextField) یا بنیادی پرائمٹو (Canvas, Layout) استعمال ہوتے ہیں۔ ہر اجزاء ظاہر اور رویے کو ترتیب دینے کے لیے پیرامیٹر اور modifier پیرامیٹر کے ذریعے ایک یا زائد موڈیفائر قبول کرتا ہے۔
موڈیفائر فنکشنوں کی ایک زنجیر ہے جو ایک اجزاء کے حجم، مقام، واقعے کی ھینڈلنگ اور ظاہر کو بدلتے ہیں۔ زنجیر میں موڈیفائر کی ترتیب اہم ہے: clickable.semantics، semantics.clickable سے مختلف کام کرتا ہے، اور padding.background پیڈنگ سمیت رقبے اور پس منظر کو رنگ دیتا ہے، جو ڈیزائن کی زبان اہم ہے۔
Composable فنکشن کے اندر، آپ UI کے حصون کے شرطی رینڈرنگ کے لیے if اور when شرائط، اور متغیر فہرستوں کے لیے for لوپس استعمال کر سکتے ہیں۔ یہ سارے تعمیرات قدرتی طور پر کام کرتے ہیں کیونکہ Kotlin ایک مکمل پروگرامنگ زبان ہے۔
@Composable
fun ProductList(
products: List<Product>,
modifier: Modifier = Modifier
) {
LazyColumn(modifier = modifier) {
items(products, key = { it.id }) { product ->
ProductItem(
product = product,
onAddToCart = { /* add to cart */ }
)
}
}
}
آئیں کئی Composable فنکشنز استعمال کرتے ہوئے مصنوعات کی تلاش کی ایک سکرین کی مثال پر غور کریں۔ یہاں معمولی نمونے دکھائے گئے ہیں: حالت کے ساتھ ایک انپٹ فیلڈ، فہرست کی فلٹرنگ، خالی نتائج کی ہینڈلنگ اور لوڈنگ۔
data class Product(
val id: String,
val name: String,
val price: Double,
val category: String
)
@Composable
fun SearchScreen() {
var query by remember { mutableStateOf("") }
val products = remember(query) { getFilteredProducts(query) }
Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {
OutlinedTextField(
value = query,
onValueChange = { query = it },
label = { Text("مصنوعات کی تلاش کریں") },
modifier = Modifier.fillMaxWidth()
)
Spacer(modifier = Modifier.height(16.dp))
when (products) {
is Loading -> CircularProgressIndicator()
is Empty -> Text("کئی نتائج نہیں ملے")
is Result -> LazyColumn {
items(products.items, key = { it.id }) { product ->
ProductItem(product = product, onAddToCart = {})
}
}
}
}
}
یہ مثال ایک ساتھ کئی اسالیب کو ظاہر کرتا ہے: تلاش کے سوال کی حالت کو محفوظ رکھنے کے لیے remember، کنجی سے فلٹر کرنے کے لیے remember(query)، تین UI حالتوں کے لیے when اور موثر فہرست رینڈرنگ کے لیے LazyColumn۔
Composable فنکشنز عام Kotlin فنکشنوں کی طرح پیرامیٹر قبول کرتے ہیں، لیکن ایک اہم فرق کے ساتھ: ایک پیرامیٹر @Composable اینوٹیشن کے ساتھ lambda کے ذریعے پیس کیا گیا ایک اور Composable فنکشن ہو سکتا ہے۔ اس میکانزم کو Slot API کہا جاتا ہے اور دوبارہ استعمال کے قابل کنٹینر بنانے کا مرکزی نمونہ ہے۔
Slot API اس مسئلے کو حل کرتا ہے جو روایتی View نظام میں ViewGroup اور پروگرامی طور پر چائلڈ ویوز کے اضافے سے حل کیا جاتا تھا۔ addView کے طریقوں کے بجائے، Compose content lambdas استعمال کرتا ہے — @Composable () -> Unit قسم کا آخری پیرامیٹر۔
Composable فنکشن کے پیرامیٹر میں طبیعی قیمتیں ہو سکتی ہیں، جو مختلف سیاق میں ان کا استعمال آسان بناتا ہے۔ سفارش کی جاتی ہے کہ صرف وہ پیرامیٹر لازمی بنائیں جن کے بغیر فنکشن اپنا کام نہیں کر سکتا، اور باقی کے لیے مناسب طبیعی قیمتیں فراہم کریں۔
| پیرامیٹر | قسم | مثال |
|---|---|---|
| لازمی | کوئی بھی قسم | name: String |
| اختیاری | طبیعی قیمت کے ساتھ | modifier: Modifier = Modifier |
| Content | @Composable () -> Unit | content: @Composable () -> Unit |
| Callback | @Composable کے بغیر Lambda | onClick: () -> Unit |
Compose کی برادری میں کئی قائم شدہ اسالیب سامنے آئے ہیں جو Composable فنکشنز کو زیادہ پڑھنے اور متوقع بناتے ہیں۔ پہلا State Hoisting ہے: حالت کو اوپر ایک سطح پر اٹھایا جاتا ہے اور Composable فنکشن اسے پیرامیٹروں کے ذریعے وصول کرتا ہے۔
دوسرا اسالیب Event-driven پیرامیٹر ہے۔ Composable فنکشن میں ViewModel یا useCase پیس کرنے کے بجائے، صرف مخصوص کول بیکز پیس کیے جاتے ہیں: onSave, onDelete, onNavigateToDetail۔
تیسرا اسالیب ترتیب کے درخت کے ذریعے مشترک ڈیٹا پیس کرنے کے لیے CompositionLocal ہے۔ تھیم، سکرین کی کثافت، موجودہ Route — یہ سب CompositionLocal کے ذریعے پیس کیا جاتا ہے۔
// State Hoisting: حالت والد فنکشن میں اٹھا دی گئی
@Composable
fun CounterDisplay(
count: Int,
onIncrement: () -> Unit
) {
Column(horizontalAlignment = Alignment.CenterHorizontally) {
Text(text = "کاؤنٹر: $count", style = MaterialTheme.typography.headlineLarge)
Button(onClick = onIncrement) {
Text("+1")
}
}
}
// State Hoisting کے ساتھ استعمال
@Composable
fun CounterScreen() {
var count by remember { mutableStateOf(0) }
CounterDisplay(
count = count,
onIncrement = { count++ }
)
}
اکثر پوچے جانے والے سوالات
ہاں، return کی اجازت ہے، لیکن احتیاط کے ساتھ۔ Compose انفرادی فنکشن کی سطح پر دوبارہ ترتیب کو بہتر بناتا ہے اور جلدی return اس بہتری کو توڑ سکتا ہے۔
Kotlin میں، Unit ایک سنگلٹن آبجیکٹ ہے، خالی قسم نہیں۔ Composable فنکشن Unit واپس کرتے ہیں، جس کا تکنیکی مطلب ہے کہ وہ خود Unit آبجیکٹ کو واپس کرتے ہیں۔
قابل تبدیل کلیکشنز کو پیس کرنا ممکن ہے، لیکن بری مشق ہے۔ اگر کلیکشن بدلتا ہے، Compose کو اس کا علم نہیں ہگا کیونکہ آبجیکٹ کا حوالہ وہی رہتا ہے۔
ڈیبگنگ کے لیے، Layout Inspector کے ساتھ Android Studio استعمال کریں۔ یہ موجودہ Composable فنکشن درخت، پیرامیٹر قیمتیں اور دوبارہ ترتیب کی وجوہات دکھاتا ہے۔
Composable فنکشن ہمیشہ Unit واپس کرتا ہے، لھذا واپسی قسم متعین نہیں کی جاتی۔ دوسری قسم واپس کرنے کی کوشش کرنا @Composable اینوٹیشن کے غیر Unit واپسی قسموں کے ساتھ نا مطابقت کے سبب ترتیب کی غلطی کا سبب بنے گا۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں