व्यू से 'लिखें' सुविधा पर माइग्रेट करते समय, डेटा सिर्फ़ यूज़र इंटरफ़ेस (यूआई) से जुड़ा होता है. डेटा को सुरक्षित तरीके से और ज़्यादा से ज़्यादा बढ़ाने के लिए, इन बातों का ध्यान रखें. यह आपके लेखों को माइग्रेट करते समय कुछ बातों का ध्यान रखें, लिखने के लिए देखें-आधारित ऐप्लिकेशन.
अपने ऐप्लिकेशन की थीम को माइग्रेट करना
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) का इस्तेमाल करें वह ऐसा कर सकता है. दोनों व्यू के लिए, डेटा को दूसरी जगह भेजने से जुड़ी गाइड उपलब्ध है और लिखें:
- व्यू में मटीरियल 1 से कॉन्टेंट 2 तक
- व्यू में मटीरियल 2 से कॉन्टेंट 3 तक
- Compose में मौजूद मटीरियल 2 से कॉन्टेंट 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() } }
टेस्टिंग के बारे में ज़्यादा जानने के लिए, 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 } }
नेविगेशन ग्राफ़ में ViewModel
एलिमेंट का स्कोप भी किया जाता है. ऐसे कंपोज़ेबल जो
डेस्टिनेशन ग्राफ़ में ViewModel
का एक अलग इंस्टेंस है.
इस मामले में, ViewModel
को डेस्टिनेशन के लाइफ़साइकल के दायरे में रखा जाएगा और
डेस्टिनेशन को बैकस्टैक से हटाए जाने पर, यह मिट जाता है. इस
जब उपयोगकर्ता प्रोफ़ाइल स्क्रीन पर जाता है, तो
GreetingViewModel
का इंस्टेंस बनाया गया.
@Composable fun MyApp() { NavHost(rememberNavController(), startDestination = "profile/{userId}") { /* ... */ composable("profile/{userId}") { backStackEntry -> GreetingScreen(backStackEntry.arguments?.getString("userId") ?: "") } } }
राज्य की जानकारी का सोर्स
जब आप यूज़र इंटरफ़ेस (यूआई) के किसी एक हिस्से में 'लिखें' इस्तेमाल करते हैं, तो हो सकता है कि 'लिखें' और
डेटा शेयर करने के लिए व्यू सिस्टम कोड की ज़रूरत होती है. हमारा सुझाव है कि अगर संभव हो, तो
यूडीएफ़ के सबसे सही तरीकों का पालन करने वाली किसी अन्य क्लास में उस शेयर किए गए स्टेटस को एनकैप्सुलेट करना
दोनों प्लैटफ़ॉर्म पर इस्तेमाल होता है; उदाहरण के लिए, 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 }
ज़्यादा जानकारी के लिए, 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 } }
शेयर किया गया यूज़र इंटरफ़ेस (यूआई) माइग्रेट किया जा रहा है
अगर आपको धीरे-धीरे 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) } } }
ध्यान दें कि कंपोज़ेबल पैरामीटर, कस्टम डाइमेंशन में बदले जा सकने वाले वैरिएबल बन जाते हैं
व्यू. इससे कस्टम 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
पैरंट के बिना फिर से इस्तेमाल किया जा सके.
दोबारा इस्तेमाल किए जा सकने वाले कंपोज़ेबल में लिखने के दौरान, इस तरह की कोई समस्या नहीं होती. माता-पिता ये काम कर सकते हैं स्टेटस और कॉलबैक आसानी से तय करें, ताकि दोबारा इस्तेमाल किए जा सकने वाले कंपोज़ेबल में लिखा जा सके उन्हें इस्तेमाल करने की सटीक जगह की जानकारी नहीं होनी चाहिए.
@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
लेआउट बनाएं. हालांकि, क्वालिफ़ाइड रिसॉर्स का इस्तेमाल करना भी एक विकल्प है
ताकि आप स्क्रीन के स्तर पर लेआउट चुन सकें, 'लिखें' इसकी मदद से अपने लेआउट में बदलाव करना
पूरी तरह से लेआउट में, सामान्य कंडीशनल लॉजिक के साथ कोड में. ज़्यादा जानने के लिए, विंडो साइज़ की क्लास देखें.
इसके अलावा, अलग-अलग स्क्रीन साइज़ के साथ काम करने की सुविधा के बारे में जानें देखें.
व्यू के साथ नेस्ट की गई स्क्रोलिंग
नेस्ट किए गए स्क्रोलिंग इंटरऑप को चालू करने का तरीका जानें स्क्रोल किए जा सकने वाले व्यू एलिमेंट और स्क्रोल किए जा सकने वाले कंपोज़ेबल, जो दोनों दिशाओं में नेस्ट किए गए हों, रीड थ्रू नेस्ट किया गया स्क्रोलिंग इंटरऑप.
RecyclerView
में लिखें
RecyclerView
में कंपोज़ेबल, RecyclerView
वर्शन से परफ़ॉर्म कर रहे हैं
1.3.0-alpha02. पक्का करें कि आप इसके कम से कम वर्शन 1.3.0-alpha02 पर हों
RecyclerView
पर जाकर उन फ़ायदों को देखें.
WindowInsets
व्यू के साथ इंटरऑप
अगर आपकी स्क्रीन में व्यू और कोड को उसी क्रम में लिखें. इस मामले में, आपको साफ़ तौर पर किसे इनसेट का इस्तेमाल करना चाहिए और किसे अनदेखा करना चाहिए.
उदाहरण के लिए, अगर आपका सबसे बाहरी लेआउट एक Android View लेआउट है, तो आपको
व्यू सिस्टम में इनसेट का इस्तेमाल करेगा और कंपोज़ के लिए उन्हें अनदेखा कर देगा.
इसके अलावा, अगर आपका सबसे बाहरी लेआउट एक कंपोज़ेबल है, तो आपको
लिखें और AndroidView
कंपोज़ेबल को ज़रूरत के हिसाब से पैड करें.
डिफ़ॉल्ट रूप से, हर ComposeView
खपत का WindowInsetsCompat
लेवल. इस डिफ़ॉल्ट तरीके को बदलने के लिए, इसे सेट करें
ComposeView.consumeWindowInsets
false
तक.
ज़्यादा जानकारी के लिए, लिखें में WindowInsets
दस्तावेज़ पढ़ें.
आपके लिए सुझाव
- ध्यान दें: JavaScript बंद होने पर लिंक टेक्स्ट दिखता है
- डिसप्ले इमोजी
- Compose में मटीरियल डिज़ाइन 2
- Compose में विंडो इनसेट