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

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

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

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

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

  • AppCompat लाइब्रेरी का इस्तेमाल करने वाला मटीरियल डिज़ाइन 1 (यानी कि Theme.AppCompat.*)
  • MDC-Android लाइब्रेरी (जैसे, Theme.MaterialComponents.*) का इस्तेमाल करके, मटीरियल डिज़ाइन 2
  • MDC-Android लाइब्रेरी (जैसे, Theme.Material3.*) का इस्तेमाल करके, मटीरियल डिज़ाइन 3

Compose ऐप्लिकेशन के लिए, Material के दो वर्शन उपलब्ध हैं:

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

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

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

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

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

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

Compose और व्यू, दोनों का इस्तेमाल करके बनाए गए यूज़र इंटरफ़ेस (यूआई) की जांच करना

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

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

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()
    }
}

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

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

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

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

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

Compose का इस्तेमाल करते समय, अलग-अलग कंपोज़ेबल में एक ही 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
    }
}

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

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

सही और पूरी जानकारी का सोर्स

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

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

Compose को सही और पूरी जानकारी के सोर्स के तौर पर इस्तेमाल करना

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

उदाहरण के लिए, आपकी Analytics लाइब्रेरी आपको कस्टम मेटाडेटा (इस उदाहरण में उपयोगकर्ता प्रॉपर्टी) को बाद के सभी 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
}

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

सिस्टम को सोर्स ऑफ़ ट्रुथ के तौर पर देखना

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

यहां दिए गए उदाहरण में, 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
    }
}

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

अगर 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)
        }
    }
}

ध्यान दें कि कंपोज़ेबल पैरामीटर, कस्टम व्यू में म्यूटेबल वैरिएबल बन जाते हैं. इससे कस्टम 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 */ }
        }
    }
}

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

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

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

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

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

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

डिज़ाइन के हिसाब से, 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 }
        )
    }
}

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

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

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

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

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

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

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

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

व्यू के साथ नेस्टेड स्क्रोलिंग

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

RecyclerView में लिखें

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

WindowInsets व्यू के साथ इंटरऑपरेबिलिटी

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

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

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

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