Composable Function — ay ang pangunahing yunit ng user interface sa Jetpack Compose, na tumutukoy kung paano dapat magmukha at kumilos ang isang bahagi ng screen. Ang bawat naturang function ay minarkahan ng @Composable annotation at isinasagawa sa isang espesyal na konteksto, na nagpapahintulot sa Compose na subaybayan ang mga dependency at awtomatikong muling buuin ang UI kapag nagbago ang data. Ayon sa Google Android Developers, 2026, ang tamang pagbuo ng Composable function ay direktang nakakaapekto sa performance ng application at kahusayan ng recomposition.
Mga Pangunahing Punto
Composable Function — ay isang function sa wikang Kotlin na minarkahan ng @Composable annotation, na naglalarawan ng bahagi ng user interface sa isang deklaratibong paraan. Sa halip na lumikha at mag-configure ng mga View object sa pamamagitan ng Java code o XML markup, ang developer ay sumulat lamang kung paano dapat magmukha ang UI sa bawat estado ng data.
Ang pangunahing pagkakaiba sa pagitan ng Composable function at ng tradisyonal na View system ng Android ay nasa modelo ng pag-update. Sa klasikong approach, manu-manong tinatawag ng developer ang findViewById, binabago ang text sa pamamagitan ng setText, pinamamahalaan ang visibility sa pamamagitan ng setVisibility. Composable Function ay nagpapalaya mula sa routine na ito: kapag nagbago ang data, ang sistema mismo ang nagtatakda kung aling mga function ang kailangang i-restart at isinasagawa lamang ang mga ito.
Ang Kotlin compiler, habang pinoproseso ang @Composable annotation, ay bumubuo ng karagdagang code na nag-i-integrate ng function sa mekanismo ng komposisyon. Ang code na ito ay kinabibilangan ng pagbasa at pagsulat sa mga slot — mga espesyal na memory cell na nag-iimbak ng estado at mga parameter ng bawat Composable function sa kasalukuyang UI tree. Dahil sa integrasyong ito, alam ng Compose kung aling mga function ang umaasa sa aling data.
Ang syntax ng Composable function ay napakaikli: sapat na magdagdag ng @Composable bago ang keyword na fun. Ang function ay maaaring tumanggap ng anumang mga parameter, magsama ng iba pang Composable na tawag sa katawan nito, at gumamit ng mga konstruksyon ng Kotlin — mga kondisyon, loop, when expression — para sa kondisyonal na pagpapakita ng UI.
@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("Idagdag sa cart")
}
}
}
}
Sa halimbawang ito, ang Composable function na ProductItem ay tumatanggap ng Product object, modifier, at callback. Lahat ng tatlong parameter ay hindi nababago, na ginagarantiyaha ang predictable na pag-uugali sa recomposition. Ang modifier ay ipinasa bilang parameter na may default na halaga — ito ay isang karaniwang kasanayan na nagpapahintulot sa tumatawag na partido na i-customize ang mga margin at sukat.
Sa loob ng Composable function, ginagamit ang mga built-in na komponent ng Material Design (Text, Button, Card, TextField) o mga pangunahing primitibo (Canvas, Layout). Bawat komponent ay tumatanggap ng mga parameter para i-configure ang hitsura at pag-uugali, pati na rin isa o higit pang mga modifier sa pamamagitan ng parameter na modifier.
Ang mga modifier — ay isang chain ng mga function na nagbabago sa laki, posisyon, paghawak ng kaganapan, at hitsura ng komponent. Ang pagkakasunod-sunod ng mga modifier sa chain ay mahalaga: ang clickable.semantics ay gumagana nang iba sa semantics.clickable, at ang padding.background ay nagkukulay ng background ng lugar kasama ang padding, na kritikal sa pagdidisenyo.
Sa loob ng Composable function, maaaring gamitin ang mga kondisyong if at when para sa kondisyonal na pagpapakita ng mga bahagi ng UI, pati na rin ang mga loop na for para sa mga dinamikong listahan. Lahat ng mga konstruksyong ito ay gumagana nang natural, dahil ang Kotlin ay isang ganap na programming language. Gayunpaman, mahalagang tandaan: kung ang kondisyon o loop ay naglalaman ng mga tawag sa Composable function, sila rin ay lumalahok sa recomposition.
@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 */ }
)
}
}
}
Isaalang-alang natin ang isang halimbawa ng screen ng paghahanap ng produkto gamit ang ilang Composable function. Ipinapakita dito ang mga tipikal na pattern: input field na may estado, pagsasala ng listahan, paghawak ng walang resulta, at pag-load.
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("Maghanap ng mga produkto") },
modifier = Modifier.fillMaxWidth()
)
Spacer(modifier = Modifier.height(16.dp))
when (products) {
is Loading -> CircularProgressIndicator()
is Empty -> Text("Walang nakitang resulta")
is Result -> LazyColumn {
items(products.items, key = { it.id }) { product ->
ProductItem(product = product, onAddToCart = {})
}
}
}
}
}
Ang halimbawang ito ay nagpapakita ng ilang idiom nang sabay-sabay: remember para sa pag-save ng estado ng query sa paghahanap, remember(query) para sa pagsasala gamit ang susi, when para sa tatlong estado ng UI, at LazyColumn para sa mahusay na pagpapakita ng listahan. Bawat isa sa mga idiom na ito ay resulta ng praktikal na karanasan sa pag-develop ng mga Compose application.
Mga Composable function ay tumatanggap ng mga parameter tulad ng mga ordinaryong Kotlin function, ngunit may isang mahalagang pagkakaiba: ang parameter ay maaaring isa pang Composable function na ipinasa sa pamamagitan ng lambda na may @Composable annotation. Ang mekanismong ito ay tinatawag na Slot API at ito ang pangunahing pattern para sa paglikha ng mga magagamit muli na container.
Ang Slot API ay lumulutas ng problema na sa tradisyonal na View system ay nilulutas sa pamamagitan ng ViewGroup at programmatic na pagdaragdag ng child View. Sa halip na mga addView method, gumagamit ang Compose ng content lambda — ang huling parameter na may uri na @Composable () -> Unit. Ang tumatawag na partido ay nagpapasa ng anumang UI sa lambda na ito, at ang container mismo ay tumutukoy lamang sa pagkakalagay nito.
Ang mga parameter ng Composable function ay maaaring magkaroon ng mga default na halaga, na nagpapasimple sa kanilang paggamit sa iba't ibang konteksto. Inirerekomenda na gawing mandatory lamang ang mga parameter kung wala ang function ay hindi magagawa ang gawain nito, at ang iba ay bigyan ng makatwirang default na halaga.
| Parameter | Uri | Halimbawa |
|---|---|---|
| Mandatory | Anumang uri | name: String |
| Opsyonal | May default na halaga | modifier: Modifier = Modifier |
| Content | @Composable () -> Unit | content: @Composable () -> Unit |
| Callback | Lambda na walang @Composable | onClick: () -> Unit |
Sa komunidad ng Compose, nabuo ang ilang itinatag na idiom na ginagawang mas nababasa at predictable ang mga Composable function. Una — State Hoisting: ang estado ay itinaas sa mas mataas na antas, at ang Composable function ay tumatanggap nito sa pamamagitan ng mga parameter. Ginagawa nitong dalisay ang function at magagamit muli sa iba't ibang konteksto.
Ikalawang idiom — mga parameter na Event-driven. Sa halip na ipasa ang ViewModel o useCase sa Composable function, tiyak na mga callback lamang ang ipinapasa: onSave, onDelete, onNavigateToDetail. Binabawasan nito ang coupling at pinapasimple ang pag-test — para sa pag-test ng ProductItem ay hindi kailangan ng ViewModel, lambda-stub lamang.
Ikatlong idiom — CompositionLocal para sa pagpapasa ng karaniwang data sa pamamagitan ng puno ng komposisyon. Tema, density ng screen, kasalukuyang ruta — lahat ito ay ipinapasa sa pamamagitan ng CompositionLocal, iniiwasan ang mga chain ng parameter sa pamamagitan ng dose-dosenang Composable function. Gayunpaman, hindi dapat abusuhin ang CompositionLocal: ang mga tahasang parameter ay palaging mas gusto kaysa sa mga implicit na dependency.
// State Hoisting: estado itinaas sa parent function
@Composable
fun CounterDisplay(
count: Int,
onIncrement: () -> Unit
) {
Column(horizontalAlignment = Alignment.CenterHorizontally) {
Text(text = "Tagabilang: $count", style = MaterialTheme.typography.headlineLarge)
Button(onClick = onIncrement) {
Text("+1")
}
}
}
// Paggamit sa State Hoisting
@Composable
fun CounterScreen() {
var count by remember { mutableStateOf(0) }
CounterDisplay(
count = count,
onIncrement = { count++ }
)
}
Mga Madalas Itanong
Oo, pinapayagan ang return, ngunit nang may pag-iingat. Ino-optimize ng Compose ang recomposition sa antas ng indibidwal na function, at ang maagang return ay maaaring makagambala sa optimization na ito. Mas mainam na gumamit ng mga kondisyonal na operator na if o when sa loob ng katawan ng function.
Sa Kotlin, ang Unit ay isang singleton object, hindi isang walang laman na uri. Ang mga Composable function ay nagbabalik ng Unit, na teknikal na nangangahulugang ibinabalik nila ang Unit object mismo. Gayunpaman, sa praktika ay hindi ito mahalaga — ang ibinalik na halaga ay hindi pinapansin ng sistema ng komposisyon.
Ang pagpapasa ng mga nababagong koleksyon ay posible, ngunit ito ay masamang kasanayan. Kung magbago ang koleksyon, hindi malalaman ito ng Compose dahil ang reference sa object ay nananatiling pareho. Gumamit ng immutable list o mutableStateListOf para sa masusubaybayang pagbabago.
Para sa debugging, gamitin ang Android Studio na may Layout Inspector, na nagpapakita ng kasalukuyang puno ng Composable function, mga halaga ng parameter, at mga dahilan ng recomposition. Gumagana rin ang ordinaryong Kotlin debugger — ang mga breakpoint sa loob ng Composable function ay tama na na-t-trigger sa bawat recomposition.
Ang Composable function ay laging nagbabalik ng Unit, kaya hindi tinutukoy ang return type. Ang pagtatangkang magbalik ng ibang uri ay magdudulot ng error sa compilation, dahil ang @Composable annotation ay hindi tugma sa mga return type na hindi Unit.
Buod
Gagawa kami ng mobile application na turnkey
Gumagawa ang IT Sectr ng mga iOS at Android application para sa mga startup at negosyo mula noong 2017. Magpapayo kami sa iyo at magmumungkahi ng pinakamahusay na solusyon.
Basahin din