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

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

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

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

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

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

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

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

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

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

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

ज़्यादा जानने के लिए, 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 और अन्य लाइब्रेरी में बताया गया है.

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

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

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

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

उदाहरण के लिए, आपकी 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 सिस्टम के पास स्टेट का मालिकाना हक है और वह इसे Compose के साथ शेयर करता है, तो हमारा सुझाव है कि आप mutableStateOf ऑब्जेक्ट में स्टेट को रैप करें, ताकि इसे Compose के लिए थ्रेड-सेफ़ बनाया जा सके. इस तरीके का इस्तेमाल करने पर, कॉम्पोज़ेबल फ़ंक्शन आसान हो जाते हैं, क्योंकि अब उनके पास सटीक जानकारी का सोर्स नहीं होता. हालांकि, व्यू सिस्टम को बदलाव की सुविधा वाले स्टेटस और उस स्टेटस का इस्तेमाल करने वाले व्यू को अपडेट करना होता है.

यहां दिए गए उदाहरण में, CustomViewGroup में TextView और ComposeView शामिल है. साथ ही, 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 Views के साथ इंटरऑपरेट करना

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

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

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

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