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

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

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

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

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

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

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

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

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

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

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

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

Compose/Views के मिले-जुले यूज़र इंटरफ़ेस (यूआई) की जांच करना

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

जब कोई गतिविधि या फ़्रैगमेंट, Compose का इस्तेमाल करता है, तो आपको createAndroidComposeRule के बजाय ActivityScenarioRule का इस्तेमाल करना होगा. 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()
    }
}
AddingComposeToYourAppSnippets.kt

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

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

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

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

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

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

स्टेट सोर्स ऑफ़ ट्रुथ

यूज़र इंटरफ़ेस (यूआई) के किसी हिस्से में Compose को अपनाने पर, ऐसा हो सकता है कि Compose और View सिस्टम कोड को डेटा शेयर करने की ज़रूरत पड़े. हमारा सुझाव है कि शेयर किए गए उस स्टेट को किसी दूसरी क्लास में एनकैप्सुलेट करें. यह क्लास, दोनों प्लैटफ़ॉर्म पर इस्तेमाल की जाने वाली यूडीएफ़ की सबसे सही तरीकों को फ़ॉलो करती है. उदाहरण के लिए, 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
}
MigrationOtherConsiderationsSnippets.kt

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

View सिस्टम को सोर्स ऑफ़ ट्रुथ के तौर पर इस्तेमाल करना

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

यहां दिए गए उदाहरण में, 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 और View सिस्टम, दोनों में शेयर किए गए यूज़र इंटरफ़ेस (यूआई) एलिमेंट का इस्तेमाल करना पड़ सकता है. उदाहरण के लिए, अगर आपके ऐप्लिकेशन में कस्टम 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 से जुड़ा होता है.

इसके उलट, 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 की ओर से ऑफ़र की जाने वाली तकनीकों के बारे में जानने के लिए, अलग-अलग डिसप्ले साइज़ के साथ काम करना लेख पढ़ें.

Views के साथ नेस्टेड स्क्रोलिंग

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

RecyclerView में Compose

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

Views के साथ WindowInsets इंटरऑप

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

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

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

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