दूसरी ज़रूरी बातें

व्यू से Compose पर माइग्रेट करना, पूरी तरह से यूज़र इंटरफ़ेस (यूआई) से जुड़ा है. हालांकि, सुरक्षित और इंक्रीमेंटल माइग्रेशन करने के लिए, कई बातों का ध्यान रखना ज़रूरी है. आपके व्यू-आधारित ऐप्लिकेशन को Compose में माइग्रेट करते समय, इस पेज पर दी गई कुछ बातों का ध्यान रखा जाता है.

अपने ऐप्लिकेशन की थीम को माइग्रेट करना

Android ऐप्लिकेशन को थीम देने के लिए, मटीरियल डिज़ाइन का इस्तेमाल करने का सुझाव दिया जाता है.

व्यू पर आधारित ऐप्लिकेशन के लिए, Material के तीन वर्शन उपलब्ध हैं:

• AppCompat लाइब्रेरी (यानी Theme.AppCompat.*) का इस्तेमाल करके, Material Design 1
• MDC-Android लाइब्रेरी (Theme.MaterialComponents.*) का इस्तेमाल करके, Material Design 2
• MDC-Android लाइब्रेरी (Theme.Material3.*) का इस्तेमाल करके, Material Design 3

Compose के ऐप्लिकेशन में मटीरियल के दो वर्शन उपलब्ध हैं:

• Compose मटीरियल लाइब्रेरी का इस्तेमाल करके मटीरियल डिज़ाइन 2 (यानी androidx.compose.material.MaterialTheme)
• Compose Material 3 लाइब्रेरी का इस्तेमाल करके मटीरियल डिज़ाइन 3 (यानी androidx.compose.material3.MaterialTheme)

हमारा सुझाव है कि अगर आपके ऐप्लिकेशन का डिज़ाइन सिस्टम, नए वर्शन (Material 3) का इस्तेमाल करने की ज़रूरी शर्तें पूरी करता है, तो नए वर्शन का इस्तेमाल करें. डेटा को दूसरी जगह भेजने से जुड़ी गाइड, व्यू और Compose, दोनों के लिए उपलब्ध हैं:

• व्यू में मटीरियल 1 से मटीरियल 2
• व्यू में मटीरियल 2 से कॉन्टेंट 3 तक
• Compose में, दूसरे मटीरियल से तीसरे मटीरियल पर जाना

Compose में नई स्क्रीन बनाते समय, यह पक्का करें कि आप Compose Material लाइब्रेरी से यूज़र इंटरफ़ेस (यूआई) उत्सर्जित करने वाले किसी भी कंपोज़ेबल से पहले MaterialTheme लागू करें. भले ही, मटीरियल डिज़ाइन का कोई भी वर्शन इस्तेमाल किया जा रहा हो. Material के कॉम्पोनेंट (Button, Text वगैरह), MaterialTheme के मौजूद होने पर ही काम करते हैं. इसके बिना, इनका व्यवहार तय नहीं होता.

सभी Jetpack Compose सैंपल, MaterialTheme के आधार पर बनाई गई कस्टम Compose थीम का इस्तेमाल करते हैं.

ज़्यादा जानने के लिए, Compose में सिस्टम डिज़ाइन करना और एक्सएमएल थीम को कंपोज़ में माइग्रेट करना देखें.

नेविगेशन

अगर आपने अपने ऐप्लिकेशन में नेविगेशन कॉम्पोनेंट का इस्तेमाल किया है, तो ज़्यादा जानकारी के लिए Compose का इस्तेमाल करके नेविगेट करना - इंटरऑपरेबिलिटी और Jetpack नेविगेशन को Compose नेविगेशन पर माइग्रेट करना लेख पढ़ें.

Compose/व्यू के यूज़र इंटरफ़ेस (यूआई) को टेस्ट करना

अपने ऐप्लिकेशन के कुछ हिस्सों को Compose में माइग्रेट करने के बाद, यह जांच करना ज़रूरी है कि आपने कुछ भी गलत तो नहीं किया है.

जब किसी गतिविधि या फ़्रैगमेंट में लिखें की सुविधा का इस्तेमाल किया जाता है, तो आपको ActivityScenarioRule के बजाय createAndroidComposeRule का इस्तेमाल करना होगा. createAndroidComposeRule, ActivityScenarioRule को ComposeTestRule के साथ इंटिग्रेट करता है. इससे, एक ही समय में कोड लिखने और देखने की सुविधा की जांच की जा सकती है.

class MyActivityTest {
    @Rule
    @JvmField
    val composeTestRule = createAndroidComposeRule<MyActivity>()

    @Test
    fun testGreeting() {
        val greeting = InstrumentationRegistry.getInstrumentation()
            .targetContext.resources.getString(R.string.greeting)

        composeTestRule.onNodeWithText(greeting).assertIsDisplayed()
    }
}
AddingComposeToYourAppSnippets.kt

टेस्टिंग के बारे में ज़्यादा जानने के लिए, Compose लेआउट की जांच करना लेख पढ़ें. यूज़र इंटरफ़ेस (यूआई) टेस्टिंग फ़्रेमवर्क के साथ काम करने के लिए, Espresso के साथ काम करने की सुविधा और UiAutomator के साथ काम करने की सुविधा देखें.

Compose को अपने मौजूदा ऐप्लिकेशन आर्किटेक्चर के साथ इंटिग्रेट करना

एकतरफ़ा डेटा फ़्लो (यूडीएफ़) आर्किटेक्चर के पैटर्न, Compose के साथ आसानी से काम करते हैं. अगर ऐप्लिकेशन, मॉडल व्यू प्रेज़ेंटर (एमवीपी) जैसे अन्य आर्किटेक्चर पैटर्न का इस्तेमाल करता है, तो हमारा सुझाव है कि आप Compose का इस्तेमाल करने से पहले या उसके दौरान, यूज़र इंटरफ़ेस (यूआई) के उस हिस्से को यूडीएफ़ में माइग्रेट करें.

Compose में ViewModel का इस्तेमाल करना

अगर स्ट्रक्चर कॉम्पोनेंट ViewModel लाइब्रेरी का इस्तेमाल किया जाता है, तो viewModel() फ़ंक्शन को कॉल करके किसी भी कंपोज़ेबल से ViewModel को ऐक्सेस किया जा सकता है, जैसा कि Compose और अन्य लाइब्रेरी में बताया गया है.

ध्यान दें: लाइफ़साइकल और स्कोप की वजह से, आपको स्क्रीन-लेवल पर ViewModel इंस्टेंस को ऐक्सेस और कॉल करना चाहिए कॉम्पोज़ेबल. इसका मतलब है कि आपको नेविगेशन ग्राफ़ की किसी ऐक्टिविटी, फ़्रैगमेंट या डेस्टिनेशन से कॉल किए गए रूट कॉम्पोज़ेबल के आस-पास होना चाहिए. आपको कभी भी ViewModel इंस्टेंस को दूसरे कॉम्पोज़ेबल में पास नहीं करना चाहिए. इसके बजाय, सिर्फ़ वह डेटा और फ़ंक्शन पास करें जो पैरामीटर के तौर पर ज़रूरी लॉजिक को पूरा करते हैं.

Compose का इस्तेमाल करते समय, अलग-अलग कंपोज़ेबल में एक ही ViewModel टाइप का इस्तेमाल करते समय सावधानी बरतें. इसकी वजह यह है कि ViewModel एलिमेंट, व्यू-लाइफ़साइकल के स्कोप का पालन करता है. अगर नेविगेशन लाइब्रेरी का इस्तेमाल किया जाता है, तो स्कोप होस्ट ऐक्टिविटी, फ़्रैगमेंट या नेविगेशन ग्राफ़ होगा.

ध्यान दें: सभी कॉम्पोज़ेबल में ViewModel टाइप के एक ही इंस्टेंस का इस्तेमाल किया जाता है, बशर्ते कॉम्पोज़ेबल, नेविगेशन ग्राफ़ या अलग-अलग ऐक्टिविटी या फ़्रैगमेंट इंस्टेंस का डेस्टिनेशन न हो.

उदाहरण के लिए, अगर कॉम्पोज़ेबल किसी गतिविधि में होस्ट किए जाते हैं, तो viewModel() हमेशा वही इंस्टेंस दिखाता है जो गतिविधि खत्म होने पर ही हटाया जाता है. यहां दिए गए उदाहरण में, एक ही उपयोगकर्ता ("user1") का दो बार स्वागत किया गया है. ऐसा इसलिए है, क्योंकि होस्ट गतिविधि के तहत सभी कंपोज़ेबल में एक ही GreetingViewModel इंस्टेंस का फिर से इस्तेमाल किया गया है. बनाए गए पहले ViewModel इंस्टेंस का इस्तेमाल, अन्य कॉम्पोज़ेबल में फिर से किया जाता है.

class GreetingActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MaterialTheme {
                Column {
                    GreetingScreen("user1")
                    GreetingScreen("user2")
                }
            }
        }
    }
}

@Composable
fun GreetingScreen(
    userId: String,
    viewModel: GreetingViewModel = viewModel(  
        factory = GreetingViewModelFactory(userId)  
    )
) {
    val messageUser by viewModel.message.observeAsState("")
    Text(messageUser)
}

class GreetingViewModel(private val userId: String) : ViewModel() {
    private val _message = MutableLiveData("Hi $userId")
    val message: LiveData<String> = _message
}

class GreetingViewModelFactory(private val userId: String) : ViewModelProvider.Factory {
    @Suppress("UNCHECKED_CAST")
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        return GreetingViewModel(userId) as T
    }
}
ComposeExistingArchSnippets.kt

नेविगेशन ग्राफ़ में ViewModel एलिमेंट भी शामिल होते हैं. इसलिए, नेविगेशन ग्राफ़ में डेस्टिनेशन के तौर पर इस्तेमाल किए जाने वाले कॉम्पोज़ेबल में ViewModel का एक अलग इंस्टेंस होता है. इस मामले में, ViewModel का दायरा डेस्टिनेशन के लाइफ़साइकल तक सीमित होता है. साथ ही, डेस्टिनेशन को बैकस्टैक से हटाने पर, इसे मिटा दिया जाता है. यहां दिए गए उदाहरण में, जब उपयोगकर्ता प्रोफ़ाइल स्क्रीन पर जाता है, तो GreetingViewModel का एक नया इंस्टेंस बन जाता है.

@Composable
fun MyApp() {
    NavHost(rememberNavController(), startDestination = "profile/{userId}") {
        /* ... */
        composable("profile/{userId}") { backStackEntry ->
            GreetingScreen(backStackEntry.arguments?.getString("userId") ?: "")
        }
    }
}
ComposeExistingArchSnippets.kt

सटीक जानकारी का सोर्स

जब आप यूज़र इंटरफ़ेस (यूआई) के किसी एक हिस्से में 'लिखें' इस्तेमाल करते हैं, तो हो सकता है कि 'लिखें' और 'व्यू सिस्टम कोड' को डेटा शेयर करने की ज़रूरत पड़े. हमारा सुझाव है कि जब भी हो सके, आप शेयर किए गए उस स्टेटस को किसी ऐसी क्लास में एन्क्रिप्ट (सुरक्षित) करें जो दोनों प्लैटफ़ॉर्म में इस्तेमाल किए जाने वाले यूडीएफ़ के सबसे सही तरीकों का पालन करता हो. उदाहरण के लिए, ऐसे ViewModel में जो डेटा अपडेट करने के लिए, शेयर किए गए डेटा की एक स्ट्रीम दिखाता है.

हालांकि, अगर शेयर किया जाने वाला डेटा बदला जा सकता है या किसी यूज़र इंटरफ़ेस (यूआई) एलिमेंट से ज़्यादा जुड़ा है, तो ऐसा हमेशा नहीं किया जा सकता. ऐसे में, एक सिस्टम को सटीक डेटा का सोर्स होना चाहिए. साथ ही, उस सिस्टम को दूसरे सिस्टम के साथ डेटा अपडेट शेयर करने होंगे. आम तौर पर, सटीक जानकारी देने वाले सोर्स का मालिकाना हक, यूज़र इंटरफ़ेस (यूआई) के क्रम में सबसे ऊपर मौजूद एलिमेंट के पास होना चाहिए.

सटीक जानकारी के तौर पर कॉम्पोज़ करना

'लिखें' स्टेट को नॉन-लिखें कोड में पब्लिश करने के लिए, SideEffect कंपोज़ेबल का इस्तेमाल करें. इस मामले में, सटीक जानकारी को कॉम्पोज़ेबल में रखा जाता है, जो स्टेटस के अपडेट भेजता है.

उदाहरण के लिए, आपकी Analytics लाइब्रेरी आपको अपने सभी बाद के Analytics इवेंट में कस्टम मेटाडेटा (इस उदाहरण में उपयोगकर्ता प्रॉपर्टी) अटैच करके, उपयोगकर्ताओं की संख्या को सेगमेंट में बांटने की अनुमति दे सकती है. अपनी ऐनलिटिक्स लाइब्रेरी में मौजूद मौजूदा उपयोगकर्ता के टाइप की जानकारी देने के लिए, SideEffect का इस्तेमाल करके उसकी वैल्यू अपडेट करें.

@Composable
fun rememberFirebaseAnalytics(user: User): FirebaseAnalytics {
    val analytics: FirebaseAnalytics = remember {
        FirebaseAnalytics()
    }

    // On every successful composition, update FirebaseAnalytics with
    // the userType from the current User, ensuring that future analytics
    // events have this metadata attached
    SideEffect {
        analytics.setUserProperty("userType", user.userType)
    }
    return analytics
}
MigrationOtherConsiderationsSnippets.kt

ज़्यादा जानकारी के लिए, Compose में साइड-इफ़ेक्ट लेख पढ़ें.

सिस्टम को सच्चाई के स्रोत के रूप में देखें

अगर व्यू सिस्टम के पास किसी राज्य का मालिकाना हक है और वह उसे Compose के साथ शेयर करता है, तो हमारा सुझाव है कि आप स्टेटस को mutableStateOf ऑब्जेक्ट में रैप करें, ताकि वह कंपोज़ के लिए थ्रेड के ज़रिए सुरक्षित रहे. इस तरीके का इस्तेमाल करने पर, कॉम्पोज़ेबल फ़ंक्शन आसान हो जाते हैं, क्योंकि अब उनके पास सटीक जानकारी का सोर्स नहीं होता. हालांकि, व्यू सिस्टम को बदलाव की अनुमति वाली स्थिति और उस स्थिति का इस्तेमाल करने वाले व्यू को अपडेट करना पड़ता है.

यहां दिए गए उदाहरण में, CustomViewGroup में TextView और ComposeView शामिल है. साथ ही, इसमें TextField कॉम्पोज़ेबल भी है. TextView में, TextField में उपयोगकर्ता के टाइप किए गए कॉन्टेंट को दिखाना ज़रूरी है.

class CustomViewGroup @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyle: Int = 0
) : LinearLayout(context, attrs, defStyle) {

    // Source of truth in the View system as mutableStateOf
    // to make it thread-safe for Compose
    private var text by mutableStateOf("")

    private val textView: TextView

    init {
        orientation = VERTICAL

        textView = TextView(context)
        val composeView = ComposeView(context).apply {
            setContent {
                MaterialTheme {
                    TextField(value = text, onValueChange = { updateState(it) })
                }
            }
        }

        addView(textView)
        addView(composeView)
    }

    // Update both the source of truth and the TextView
    private fun updateState(newValue: String) {
        text = newValue
        textView.text = newValue
    }
}
ComposeExistingArchSnippets.kt

शेयर किया गया यूज़र इंटरफ़ेस (यूआई) माइग्रेट किया जा रहा है

अगर धीरे-धीरे Compose पर माइग्रेट किया जा रहा है, तो आपको Compose और व्यू सिस्टम, दोनों में शेयर किए गए यूज़र इंटरफ़ेस (यूआई) एलिमेंट का इस्तेमाल करना पड़ सकता है. उदाहरण के लिए, अगर आपके ऐप्लिकेशन में कोई कस्टम CallToActionButton कॉम्पोनेंट है, तो आपको उसे Compose और व्यू-आधारित, दोनों स्क्रीन में इस्तेमाल करना पड़ सकता है.

Compose में, शेयर किए गए यूज़र इंटरफ़ेस (यूआई) एलिमेंट, कॉम्पोज़ेबल बन जाते हैं. इनका इस्तेमाल पूरे ऐप्लिकेशन में फिर से किया जा सकता है. भले ही, एलिमेंट को एक्सएमएल का इस्तेमाल करके स्टाइल किया गया हो या वह कस्टम व्यू हो. उदाहरण के लिए, आपको अपने कस्टम कॉल-टू-ऐक्शन Button कॉम्पोनेंट के लिए, CallToActionButton कॉम्पोज़ेबल बनाना होगा.

व्यू पर आधारित स्क्रीन में कॉम्पोज़ेबल का इस्तेमाल करने के लिए, AbstractComposeView से बड़ा कस्टम व्यू रैपर बनाएं. ओवरराइड किए गए Content कंपोज़ेबल में, अपनी Compose थीम में रैप किया गया कंपोज़ेबल डालें. जैसा कि यहां दिए गए उदाहरण में दिखाया गया है:

@Composable
fun CallToActionButton(
    text: String,
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
) {
    Button(
        colors = ButtonDefaults.buttonColors(
            containerColor = MaterialTheme.colorScheme.secondary
        ),
        onClick = onClick,
        modifier = modifier,
    ) {
        Text(text)
    }
}

class CallToActionViewButton @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyle: Int = 0
) : AbstractComposeView(context, attrs, defStyle) {

    var text by mutableStateOf("")
    var onClick by mutableStateOf({})

    @Composable
    override fun Content() {
        YourAppTheme {
            CallToActionButton(text, onClick)
        }
    }
}
ComposeExistingUISnippets.kt

ध्यान दें कि कंपोज किए जा सकने वाले पैरामीटर, कस्टम व्यू में बदलाव किए जा सकने वाले वैरिएबल बन जाते हैं. इससे कस्टम CallToActionViewButton व्यू को बड़े किए जा सकते हैं और उनका इस्तेमाल किया जा सकता है, जैसे कि किसी सामान्य व्यू का किया जाता है. व्यू बाइंडिंग के साथ इसका उदाहरण यहां देखें:

class ViewBindingActivity : ComponentActivity() {

    private lateinit var binding: ActivityExampleBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityExampleBinding.inflate(layoutInflater)
        setContentView(binding.root)

        binding.callToAction.apply {
            text = getString(R.string.greeting)
            onClick = { /* Do something */ }
        }
    }
}
ComposeExistingUISnippets.kt

अगर कस्टम कॉम्पोनेंट में बदलाव की सुविधा वाली स्थिति है, तो सही स्थिति का सोर्स देखें.

प्रज़ेंटेशन से स्प्लिट करने की स्थिति को प्राथमिकता देना

आम तौर पर, View स्टेटफ़ुल होता है. View, उन फ़ील्ड को मैनेज करता है जिनमें यह बताया जाता है कि क्या दिखाना है और कैसे दिखाना है. किसी View को Compose में बदलने पर, रेंडर किए जा रहे डेटा को अलग करें, ताकि एकतरफ़ा डेटा फ़्लो हासिल किया जा सके. इस बारे में ज़्यादा जानकारी स्टेटस होस्टिंग में दी गई है.

उदाहरण के लिए, View में visibility प्रॉपर्टी होती है, जिससे यह पता चलता है कि प्रॉपर्टी दिख रही है, नहीं दिख रही है या मौजूद नहीं है. यह View की एक खास प्रॉपर्टी है. कोड के अन्य हिस्सों से View के दिखने की सेटिंग में बदलाव हो सकता है. हालांकि, View को दिखने की मौजूदा सेटिंग के बारे में सिर्फ़ View को पता होता है. View के दिखने की सेटिंग में गड़बड़ी हो सकती है. यह सेटिंग अक्सर View से जुड़ी होती है.

इसके उलट, Compose में Kotlin के कंडीशनल लॉजिक का इस्तेमाल करके, पूरी तरह से अलग-अलग कॉम्पोज़ेबल दिखाना आसान है:

@Composable
fun MyComposable(showCautionIcon: Boolean) {
    if (showCautionIcon) {
        CautionIcon(/* ... */)
    }
}
MigrationOtherConsiderationsSnippets.kt

डिज़ाइन के हिसाब से, CautionIcon को यह जानने या परवाह होने की ज़रूरत नहीं है कि वह क्यों दिखाया जा रहा है. साथ ही, visibility का कोई कॉन्सेप्ट नहीं है: वह कंपोज़िशन में है या नहीं है.

स्टेटस मैनेजमेंट और प्रज़ेंटेशन लॉजिक को अलग-अलग करके, यूज़र इंटरफ़ेस (यूआई) में स्टेटस के कन्वर्ज़न के तौर पर कॉन्टेंट को दिखाने के तरीके को ज़्यादा आसानी से बदला जा सकता है. ज़रूरत पड़ने पर स्टेट को होस्ट करने की सुविधा होने से, कॉम्पोज़ेबल को बार-बार इस्तेमाल किया जा सकता है. ऐसा इसलिए होता है, क्योंकि स्टेट के मालिकाना हक को आसानी से मैनेज किया जा सकता है.

ऐसे कॉम्पोनेंट का प्रमोशन करें जो एनकैप्सुलेट किए गए हों और जिनका फिर से इस्तेमाल किया जा सकता हो

View एलिमेंट को अक्सर यह पता होता है कि वे कहां मौजूद हैं: Activity, Dialog, Fragment या किसी अन्य View हैरारकी में. अक्सर, इन्हें स्टैटिक लेआउट फ़ाइलों से फ़्लोरेट किया जाता है. इसलिए, View का पूरा स्ट्रक्चर बहुत सख्त होता है. इससे, कूपलिंग ज़्यादा टाइट हो जाती है और View को बदलना या फिर से इस्तेमाल करना मुश्किल हो जाता है.

उदाहरण के लिए, कोई कस्टम View यह मान सकता है कि उसके पास किसी खास आईडी वाला चाइल्ड व्यू है. साथ ही, किसी कार्रवाई के जवाब में सीधे तौर पर उसकी प्रॉपर्टी बदल सकता है. इससे उन View एलिमेंट को एक-दूसरे से कसकर जोड़ा जाता है: अगर चाइल्ड एलिमेंट नहीं मिलता है, तो कस्टम View क्रैश हो सकता है या काम नहीं कर सकता. साथ ही, कस्टम View पैरंट के बिना, चाइल्ड एलिमेंट का फिर से इस्तेमाल नहीं किया जा सकता.

Compose में, फिर से इस्तेमाल किए जा सकने वाले कॉम्पोज़ेबल का इस्तेमाल करने पर, यह समस्या कम होती है. माता-पिता आसानी से स्थिति और कॉलबैक की जानकारी दे सकते हैं, ताकि फिर से इस्तेमाल किए जा सकने वाले कंपोज़ेबल को लिखा जा सके. इसके लिए, उन्हें यह पता नहीं होना चाहिए कि उनका इस्तेमाल कहां किया जाएगा.

@Composable
fun AScreen() {
    var isEnabled by rememberSaveable { mutableStateOf(false) }

    Column {
        ImageWithEnabledOverlay(isEnabled)
        ControlPanelWithToggle(
            isEnabled = isEnabled,
            onEnabledChanged = { isEnabled = it }
        )
    }
}
MigrationOtherConsiderationsSnippets.kt

ऊपर के उदाहरण में, तीनों हिस्से ज़्यादा एनकैप्सुलेट और कम जोड़े गए हैं:

• ImageWithEnabledOverlay को सिर्फ़ यह जानना ज़रूरी है कि isEnabled की मौजूदा स्थिति क्या है. उसे यह जानने की ज़रूरत नहीं है कि ControlPanelWithToggle मौजूद है या नहीं या उसे कैसे कंट्रोल किया जा सकता है.

• ControlPanelWithToggle को पता नहीं है कि ImageWithEnabledOverlay मौजूद है. isEnabled को दिखाने के लिए, शून्य, एक या उससे ज़्यादा तरीके हो सकते हैं. साथ ही, ControlPanelWithToggle में कोई बदलाव नहीं करना पड़ेगा.

• पैरंट के लिए, इससे कोई फ़र्क़ नहीं पड़ता कि ImageWithEnabledOverlay या ControlPanelWithToggle कितनी गहराई तक नेस्ट किए गए हैं. ये बच्चे, बदलावों को ऐनिमेशन के तौर पर दिखा सकते हैं, कॉन्टेंट को बदल सकते हैं या कॉन्टेंट को दूसरे बच्चों को भेज सकते हैं.

इस पैटर्न को कंट्रोल में बदलाव के तौर पर जाना जाता है. इसके बारे में ज़्यादा जानने के लिए, CompositionLocal दस्तावेज़ पढ़ें.

स्क्रीन के साइज़ में होने वाले बदलावों को मैनेज करना

अलग-अलग विंडो साइज़ के लिए अलग-अलग संसाधन होने से, रिस्पॉन्सिव View लेआउट बनाने का एक मुख्य तरीका है. स्क्रीन-लेवल के लेआउट के फ़ैसलों के लिए, अब भी ज़रूरी रिसॉर्स का विकल्प उपलब्ध है. हालांकि, Compose की मदद से, सामान्य शर्तों वाले लॉजिक के साथ कोड में लेआउट को पूरी तरह से बदलना बहुत आसान हो जाता है. ज़्यादा जानने के लिए, विंडो साइज़ क्लास का इस्तेमाल करना लेख पढ़ें.

इसके अलावा, अडैप्टिव यूज़र इंटरफ़ेस (यूआई) बनाने के लिए, Compose की तकनीक की सुविधा के बारे में जानने के लिए, अलग-अलग साइज़ की स्क्रीन के हिसाब से जानकारी देना लेख पढ़ें.

व्यू की मदद से नेस्ट किया गया स्क्रोलिंग

नेस्ट किए गए व्यू एलिमेंट और नेस्ट किए गए कॉम्पोज़ेबल के बीच नेस्ट की गई स्क्रोलिंग इंटरऑपरेबिलिटी को चालू करने के तरीके के बारे में ज़्यादा जानने के लिए, नेस्ट की गई स्क्रोलिंग इंटरऑपरेबिलिटी लेख पढ़ें.

RecyclerView में ईमेल लिखना

RecyclerView के 1.3.0-alpha02 वर्शन से, RecyclerView में कॉम्पोज़ेबल बेहतर परफ़ॉर्म कर रहे हैं. ये फ़ायदे देखने के लिए, पक्का करें कि आपके पास RecyclerView का कम से कम 1.3.0-alpha02 वर्शन हो.

WindowInsets व्यू के साथ इंटरऑपरेट करना

अगर आपकी स्क्रीन पर व्यू और कंपोज़ कोड, दोनों एक ही क्रम में हैं, तो आपको डिफ़ॉल्ट इनसेट को बदलना पड़ सकता है. इस मामले में, आपको साफ़ तौर पर यह बताना होगा कि इनसेट का इस्तेमाल किसमें किया जाना चाहिए और किसमें नहीं.

उदाहरण के लिए, अगर आपका सबसे बाहरी लेआउट Android View लेआउट है, तो आपको View सिस्टम में इनसेट का इस्तेमाल करना चाहिए और Compose के लिए उन्हें अनदेखा करना चाहिए. इसके अलावा, अगर आपका बाहरी लेआउट एक कंपोज़ेबल है, तो आपको Compose में इनसेट का इस्तेमाल करना चाहिए और उसके हिसाब से AndroidView कंपोज़ेबल को पैड करना चाहिए.

डिफ़ॉल्ट रूप से, हर ComposeView खपत के WindowInsetsCompat लेवल पर सभी इनसेट का इस्तेमाल करता है. इस डिफ़ॉल्ट व्यवहार को बदलने के लिए, ComposeView.consumeWindowInsets को false पर सेट करें.

ज़्यादा जानकारी के लिए, लिखें में WindowInsets दस्तावेज़ पढ़ें.