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

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

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

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

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

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

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

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

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

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

सभी Jetpack Compose के सैंपल MaterialTheme पर पसंद के मुताबिक बनाई गई ऐसी थीम इस्तेमाल करें जिसे लिखने के लिए डिज़ाइन किया गया है.

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

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

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

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

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

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 में ViewModel का इस्तेमाल करना

अगर स्ट्रक्चर के कॉम्पोनेंट का इस्तेमाल किया जाता है ViewModel लाइब्रेरी, जिसे आप ऐक्सेस कर सकते हैं इसके अलावा, अन्य कंपोज़ेबल में से 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

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

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

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

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

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

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

@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 पैरंट के बिना फिर से इस्तेमाल किया जा सके.

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

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

इसके अलावा, अलग-अलग स्क्रीन साइज़ के साथ काम करने की सुविधा के बारे में जानें देखें.

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

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

RecyclerView में लिखें

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

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

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

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

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

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