कंपोज़िशन आपके ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) के बारे में बताती है और इसे कंपोज़ेबल. कंपोज़िशन ट्री-स्ट्रक्चर है, जिसमें ऐसे कंपोज़ेबल जो आपके यूज़र इंटरफ़ेस (यूआई) के बारे में बताते हैं.
कंपोज़िशन के बगल में एक पैरलल ट्री मौजूद है, जिसे सिमेंटिक्स ट्री. यह ट्री आपके यूज़र इंटरफ़ेस (यूआई) के बारे में अन्य तरीके से बताता है. यह जानकारी इन्हें सुलभता सेवाओं और टेस्टिंग के लिए समझा जा सकता है फ़्रेमवर्क शामिल है. सुलभता सेवाएं इस ट्री का इस्तेमाल करके, लोगों को ऐप्लिकेशन के बारे में जानकारी देती हैं किसी खास ज़रूरत के लिए. टेस्टिंग फ़्रेमवर्क आपके ऐप्लिकेशन के साथ इंटरैक्ट करने के लिए ट्री का इस्तेमाल करता है और इसके बारे में दावे करें. सिमैंटिक ट्री में कंपोज़ेबल ड्रॉ करने के बारे में जानकारी है, लेकिन इसमें आपके कंपोज़ेबल का सिमेंटिक मतलब.
![यूज़र इंटरफ़ेस (यूआई) की खास हैरारकी और उसका सिमेंटिक्स ट्री](https://developer.android.com/static/develop/ui/compose/images/semantics-ui-tree.png?authuser=0000&hl=hi)
अगर आपके ऐप्लिकेशन में, Compose के पुराने वर्शन के कंपोज़ेबल और मॉडिफ़ायर शामिल हैं और मटीरियल लाइब्रेरी के साथ, सिमैंटिक ट्री अपने-आप भर जाता है और आपके लिए. हालांकि, अगर आपको लो-लेवल के कस्टम कंपोज़ेबल को जोड़ना है, तो आपके पास मैन्युअल रूप से इसके सिमैंटिक देने के लिए. कुछ ऐसी स्थितियाँ भी हो सकती हैं जिनमें आपका ट्री सही तरीके से या पूरी तरह से, स्क्रीन, जैसे कि इस मामले में आप पेड़ के हिसाब से बदलाव कर सकते हैं.
उदाहरण के लिए, इस कस्टम कैलेंडर कंपोज़ेबल का इस्तेमाल करें:
![कैलेंडर बनाने के लिए, पसंद के मुताबिक बनाया जा सकने वाला एलिमेंट, जिसमें दिन के हिसाब से चुने जा सकने वाले एलिमेंट शामिल हैं](https://developer.android.com/static/develop/ui/compose/images/semantics-calendar.png?authuser=0000&hl=hi)
इस उदाहरण में, पूरे कैलेंडर को एक लोअर-लेवल के तौर पर लागू किया गया है
Layout
के कंपोज़ेबल का इस्तेमाल करके और सीधे Canvas
पर ड्रॉइंग करके, कंपोज़ेबल.
अगर कोई और कार्रवाई नहीं की जाती है, तो सुलभता सेवाओं को बेहतर जानकारी नहीं मिलेगी
कंपोज़ेबल में उपलब्ध कॉन्टेंट और उपयोगकर्ता के चुने गए कॉन्टेंट के बारे में जानकारी
कैलेंडर. उदाहरण के लिए, अगर कोई उपयोगकर्ता 17 वाले दिन पर क्लिक करता है,
सुलभता फ़्रेमवर्क को सिर्फ़ पूरी जानकारी के लिए ब्यौरे की जानकारी मिलती है
कैलेंडर नियंत्रण. इस मामले में, TalkBack की सुलभता सेवा को
"Calendar" लिखो या, सिर्फ़ थोड़ा बेहतर, "अप्रैल कैलेंडर" और उपयोगकर्ता को
बस यह सोचकर रह जाता है कि कौनसा दिन चुना गया. इस कंपोज़ेबल को ज़्यादा बेहतर बनाने के लिए
ऐक्सेस किया जा सकता है, तो आपको सिमैंटिक जानकारी मैन्युअल रूप से जोड़नी होगी.
सिमैंटिक प्रॉपर्टी
यूज़र इंटरफ़ेस (यूआई) ट्री में कुछ सिमैंटिक मतलब वाले सभी नोड में पैरलल नोड होता है
सिमैंटिक ट्री. सिमैंटिक ट्री के नोड में वे प्रॉपर्टी होती हैं जो
कंपोज़ेबल का मतलब बताया गया हो. उदाहरण के लिए, Text
कंपोज़ेबल में एक सिमैंटिक प्रॉपर्टी text
है, क्योंकि यह इसका मतलब है
जोड़ी जा सकती हैं. Icon
में एक contentDescription
प्रॉपर्टी होती है (अगर इसे
डेवलपर) से मिली होती है जो टेक्स्ट में यह बताती है कि Icon
का मतलब क्या है.
कंपोज़ेबल और मॉडिफ़ायर, जो Compose के फ़ाउंडेशन के सबसे ऊपर बने हैं
लाइब्रेरी से आपके लिए काम की प्रॉपर्टी पहले ही सेट कर दी गई हैं. वैकल्पिक रूप से, सेट करें
या semantics
से प्रॉपर्टी को खुद बदल दें और
clearAndSetSemantics
मॉडिफ़ायर. उदाहरण के लिए, custom जोड़
किसी नोड की सुलभता सुविधाओं के लिए कार्रवाइयां, तो कोई दूसरी स्टेटस उपलब्ध कराएं
ब्यौरा या किसी खास टेक्स्ट के बारे में बताना
कंपोज़ेबल को हेडर के तौर पर माना जाना चाहिए.
सिमैंटिक ट्री को विज़ुअलाइज़ करने के लिए, लेआउट इंस्पेक्टर टूल का इस्तेमाल करें या
टेस्ट के लिए printToLog()
तरीका. यह मौजूदा
लॉगकैट में सीमैंटिक ट्री.
class MyComposeTest { @get:Rule val composeTestRule = createComposeRule() @Test fun MyTest() { // Start the app composeTestRule.setContent { MyTheme { Text("Hello world!") } } // Log the full semantics tree composeTestRule.onRoot().printToLog("MY TAG") } }
इस जांच का आउटपुट यह होगा:
Printing with useUnmergedTree = 'false'
Node #1 at (l=0.0, t=63.0, r=221.0, b=120.0)px
|-Node #2 at (l=0.0, t=63.0, r=221.0, b=120.0)px
Text = '[Hello world!]'
Actions = [GetTextLayoutResult]
इस बात पर ध्यान दें कि सिमेंटिक्स प्रॉपर्टी, किसी कंपोज़ेबल का मतलब कैसे दिखाती हैं. इसके लिए,
Switch
. यह उपयोगकर्ता को ऐसा दिखता है:
![](https://developer.android.com/static/develop/ui/compose/images/semantics-switches.png?authuser=0000&hl=hi)
इस एलिमेंट का मतलब बताने के लिए, ऐसा कहा जा सकता है: "यह एक स्विच है, जो इसके 'चालू है' में टॉगल किया जा सकने वाला एलिमेंट है राज्य. क्लिक करने पर से इंटरैक्ट करना होता है."
ठीक इसी काम के लिए सिमेंटिक्स प्रॉपर्टी का इस्तेमाल किया जाता है. सिमेंटिक्स नोड इस स्विच एलिमेंट में ये प्रॉपर्टी शामिल हैं. इन्हें लेआउट इंस्पेक्टर:
![लेआउट इंस्पेक्टर, जिसमें स्विच कंपोज़ेबल के सिमैंटिक प्रॉपर्टी दिखाई गई हैं](https://developer.android.com/static/develop/ui/compose/images/semantics-layout-inspector-switch.png?authuser=0000&hl=hi)
Role
एलिमेंट का टाइप बताता है. StateDescription
में बताया गया है कि
"चालू है" राज्य का संदर्भ दिया जाना चाहिए. डिफ़ॉल्ट रूप से यह स्थानीय भाषा में इसका एक वर्शन है
"चालू है" शब्द का इस्तेमाल करते हैं, लेकिन इसे खास जानकारी के आधार पर और खास (उदाहरण के लिए, "चालू है") बनाया जा सकता है
के संदर्भ को समझने में मदद मिलती है. स्विच की मौजूदा स्थिति ToggleableState
है. कॉन्टेंट बनाने
OnClick
प्रॉपर्टी, इस एलिमेंट के साथ इस्तेमाल किए जाने वाले तरीके के बारे में बताती है. इसके लिए
सिमैंटिक प्रॉपर्टी की पूरी सूची देखें. इसके लिए, SemanticsProperties
ऑब्जेक्ट है. सुलभता से जुड़ी कार्रवाइयों की पूरी सूची देखने के लिए, यहां जाएं:
SemanticsActions
ऑब्जेक्ट.
अपने ऐप्लिकेशन में अनलॉक किए जाने वाले हर कंपोज़ेबल की सिमेंटिक्स प्रॉपर्टी पर नज़र रखें का इस्तेमाल करें. कुछ उदाहरण:
- TalkBack की सुविधा, स्क्रीन पर दिखाई गई जानकारी को तेज़ आवाज़ में सुनने के लिए, प्रॉपर्टी का इस्तेमाल करती है और उपयोगकर्ता को आसानी से इसके साथ इंटरैक्ट करने दें. स्विच कंपोज़ेबल के लिए, TalkBack की सुविधा बोलें: "चालू है; स्विच करें; टॉगल करने के लिए दो बार टैप करें". उपयोगकर्ता दो बार टैप कर सकता है स् क्रीन पर.
-
टेस्टिंग फ़्रेमवर्क, नोड ढूंढने, उनसे इंटरैक्ट करने के लिए प्रॉपर्टी का इस्तेमाल करता है
और दावे कर सकते हैं. Switch के लिए टेस्ट का तरीका:
val mySwitch = SemanticsMatcher.expectValue( SemanticsProperties.Role, Role.Switch ) composeTestRule.onNode(mySwitch) .performClick() .assertIsOff()
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
मर्ज और अनमर्ज किया गया सिमैंटिक ट्री
जैसा कि पहले बताया गया है, यूज़र इंटरफ़ेस (यूआई) ट्री में हर कंपोज़ेबल में शून्य या उससे ज़्यादा हो सकता है सिमैंटिक प्रॉपर्टी सेट. जब किसी कंपोज़ेबल में कोई सिमैंटिक प्रॉपर्टी सेट नहीं होती, तो यह को सीमैंटिक ट्री के हिस्से के रूप में शामिल नहीं किया जाता. इस तरह, सिमैंटिक ट्री में सिर्फ़ ऐसे नोड होते हैं जिनका असल में सिमैंटिक मतलब होता है. हालांकि, कभी-कभी स्क्रीन पर दिखाए गए कॉन्टेंट का सही मतलब बताया जाता है. नोड के कुछ सब-ट्री को मर्ज करना और उन्हें एक मानना भी उपयोगी है. इस तरफ़ से आप नोड के एक सेट के बारे में सोच-विचार कर सकते हैं, न कि हर एक नोड के साथ डिसेंडेंट नोड अलग-अलग. बुनियादी नियम के मुताबिक, इस ट्री में हर नोड सुलभता सेवाओं का इस्तेमाल करते समय, फ़ोकस करने लायक एलिमेंट दिखाता है.
इस तरह के कंपोज़ेबल का उदाहरण Button
है. बटन की मदद से,
एक एलिमेंट के रूप में हो, भले ही इसमें कई चाइल्ड नोड शामिल हों:
Button(onClick = { /*TODO*/ }) { Icon( imageVector = Icons.Filled.Favorite, contentDescription = null ) Spacer(Modifier.size(ButtonDefaults.IconSpacing)) Text("Like") }
सिमैंटिक ट्री में, बटन के डिसेंडेंट की प्रॉपर्टी मर्ज की जाती हैं, और बटन को ट्री में सिंगल लीफ़ नोड के रूप में दिखाया जाता है:
![मर्ज किया गया सिंगल लीफ़ सिमैंटिक्स](https://developer.android.com/static/develop/ui/compose/images/semantics-merged-single-leaf.png?authuser=0000&hl=hi)
कंपोज़ेबल और मॉडिफ़ायर से पता चलता है कि वे अपनी ऐसेट को मर्ज करना चाहते हैं
डिसेंडेंट' Modifier.semantics
(mergeDescendants = true) {}
को कॉल करके सिमैंटिक प्रॉपर्टी. इस प्रॉपर्टी को true
पर सेट करने से यह पता चलता है कि
सिमैंटिक प्रॉपर्टी मर्ज की जानी चाहिए. Button
उदाहरण में, Button
composable, अंदरूनी तौर पर clickable
मॉडिफ़ायर का इस्तेमाल करता है. इसमें यह शामिल होता है
semantics
मॉडिफ़ायर. इसलिए, बटन के डिसेंडेंट नोड मर्ज किए जाते हैं.
आपको कब बदलाव करना चाहिए, इस बारे में ज़्यादा जानने के लिए, सुलभता का दस्तावेज़ पढ़ें
आपके कंपोज़ेबल में मर्ज करने के व्यवहार को देख सकते हैं.
फ़ाउंडेशन और मटीरियल कंपोज़ में कई मॉडिफ़ायर और कंपोज़ेबल
लाइब्रेरी में यह प्रॉपर्टी सेट होती है. उदाहरण के लिए, clickable
और toggleable
मॉडिफ़ायर अपने डिसेंडेंट अपने-आप मर्ज कर देंगे. साथ ही, ListItem
composable, इसके डिसेंडेंट को मर्ज कर देगा.
पेड़ों की जांच करें
सिमेंटिक्स ट्री दरअसल दो अलग-अलग ट्री है. यहां मर्ज किए गए सिमैंटिक हैं
ट्री, जो mergeDescendants
के true
पर सेट होने पर डिसेंडेंट नोड को मर्ज करता है.
यहां अनमर्ज सिमैंटिक ट्री भी है, जो मर्जिंग को लागू नहीं करता, लेकिन
प्रत्येक नोड को वैसे ही बनाए रखता है. सुलभता सेवाएं, अनमर्ज किए गए ट्री का इस्तेमाल करती हैं और इन्हें लागू करती हैं
मर्ज करने के लिए अपने एल्गोरिदम, mergeDescendants
को ध्यान में रखते हुए
प्रॉपर्टी. टेस्टिंग फ़्रेमवर्क, डिफ़ॉल्ट रूप से मर्ज किए गए ट्री का इस्तेमाल करता है.
printToLog()
तरीके से दोनों ट्री की जांच की जा सकती है. डिफ़ॉल्ट रूप से, और जैसा कि
पहले के उदाहरणों में, मर्ज किए गए ट्री को लॉग किया गया है. अनमर्ज किए गए ट्री को प्रिंट करने के लिए
इसके बजाय, onRoot()
मैचर के useUnmergedTree
पैरामीटर को इस पर सेट करें
true
:
composeTestRule.onRoot(useUnmergedTree = true).printToLog("MY TAG")
लेआउट इंस्पेक्टर की मदद से, मर्ज किए गए और अनमर्ज किए गए सिमैंटिक, दोनों दिखाए जा सकते हैं ट्री के लिए, व्यू फ़िल्टर में पसंदीदा ट्री को चुनें:
![लेआउट इंस्पेक्टर व्यू के विकल्प, जिससे मर्ज किए गए और अनमर्ज किए गए सिमैंटिक ट्री, दोनों को दिखाया जा सकता है](https://developer.android.com/static/develop/ui/compose/images/semantics-layout-inspector-menu.png?authuser=0000&hl=hi)
आपके ट्री में हर नोड के लिए, लेआउट इंस्पेक्टर, मर्ज किए गए सिमैंटिक दोनों दिखाता है और प्रॉपर्टी पैनल में उस नोड पर सेट किए गए सिमैंटिक:
![सिमैंटिक प्रॉपर्टी मर्ज की गईं और सेट की गईं](https://developer.android.com/static/develop/ui/compose/images/semantics-merged-and-set.png?authuser=0000&hl=hi)
डिफ़ॉल्ट रूप से, टेस्टिंग फ़्रेमवर्क में मैच करने वाले उपयोगकर्ता, मर्ज किए गए सिमैंटिक ट्री का इस्तेमाल करते हैं.
इसलिए, आप इसमें दिखाए गए टेक्स्ट से मेल करके, Button
के साथ इंटरैक्ट कर सकते हैं
यह:
composeTestRule.onNodeWithText("Like").performClick()
पैरामीटर का useUnmergedTree
पैरामीटर सेट करके इस व्यवहार को बदलें
true
के साथ मैचर और onRoot
मैचर के साथ.
मर्ज व्यवहार
जब कोई कंपोज़ेबल बताता है कि उसके डिसेंडेंट को मर्ज किया जाना चाहिए, तो यह कैसे होता है विलय ठीक ही होता है?
हर सिमेंटिक्स प्रॉपर्टी की मर्ज करने की रणनीति तय होती है. उदाहरण के लिए,
ContentDescription
प्रॉपर्टी सभी डिसेंडेंट ContentDescription वैल्यू को
सूची. किसी सिमैंटिक प्रॉपर्टी की मर्ज करने की रणनीति पता करने के लिए
SemanticsProperties.kt
में mergePolicy
लागू किया गया. प्रॉपर्टी ये काम कर सकती हैं
पैरंट या चाइल्ड वैल्यू का इस्तेमाल करके, वैल्यू को सूची में मर्ज करें या
स्ट्रिंग डालें, मर्ज करने की बिलकुल भी अनुमति न दें और इसके बजाय अपवाद या कोई और शर्त लागू करें
मर्ज करने की कस्टम रणनीति.
ध्यान दें कि जिन डिसेंडेंट ने खुद mergeDescendants
= true
सेट किया है उन्हें मर्ज में शामिल नहीं किया जाता. एक उदाहरण देखें:
![इमेज, कुछ टेक्स्ट, और बुकमार्क आइकॉन वाला सूची आइटम](https://developer.android.com/static/develop/ui/compose/images/semantics-dagger.png?authuser=0000&hl=hi)
यहां क्लिक किया जा सकने वाला सूची आइटम दिया गया है. जब उपयोगकर्ता पंक्ति को दबाता है, तो ऐप्लिकेशन इस पर क्लिक करके उपयोगकर्ता लेख की ज़्यादा जानकारी वाले पेज पर जा सकता है. सूची में मौजूद आइटम के अंदर, लेख को बुकमार्क करने के लिए एक बटन होता है. यह बटन, ऐसा नेस्ट किया गया क्लिक किया जा सकने वाला एलिमेंट होता है, ताकि बटन आपकी साइट पर अलग-अलग दिखे मर्ज किए गए पेड़. पंक्ति का बाकी कॉन्टेंट मर्ज कर दिया गया है:
![मर्ज किए गए ट्री में पंक्ति नोड के अंदर किसी सूची में कई टेक्स्ट हैं. अनमर्ज किए गए ट्री में हर टेक्स्ट कंपोज़ेबल के लिए अलग-अलग नोड होते हैं.](https://developer.android.com/static/develop/ui/compose/images/semantics-merged-vs-unmerged.png?authuser=0000&hl=hi)
सिमैंटिक ट्री को अपनाएं
जैसा कि पहले बताया गया है, आपके पास कुछ सिमैंटिक प्रॉपर्टी को बदलने या हटाने का विकल्प होता है या ट्री के मर्ज होने के तरीके को बदलें. यह खास तौर पर तब ज़रूरी होता है, जब इसकी मदद से, कस्टम कॉम्पोनेंट बनाए जा सकते हैं. सही कीवर्ड सेट किए बिना प्रॉपर्टी और मर्ज के काम करने के तरीके के बारे में नहीं है, तो हो सकता है कि आपका ऐप्लिकेशन ऐक्सेस न किया जा सके. साथ ही, और वह आपकी उम्मीद से अलग तरह से काम करता है. इस्तेमाल के कुछ सामान्य उदाहरणों के बारे में ज़्यादा जानने के लिए यहां आपको सिमैंटिक ट्री को अपने हिसाब से इस्तेमाल करना चाहिए, और इसके लिए सुलभता से जुड़ी जानकारी को पढ़ना दस्तावेज़ में दिया गया है. अगर आपको टेस्टिंग के बारे में ज़्यादा जानना है, तो टेस्टिंग” पर जाएँ गाइड देखें.
अन्य संसाधन
- सुलभता: ज़रूरी कॉन्सेप्ट और ऐसी तकनीकें जो सभी Android ऐप्लिकेशन डेवलपमेंट में आम हैं
- सुलभता ऐप्लिकेशन बनाने का तरीका: मुख्य चरण तो अपने ऐप्लिकेशन को ज़्यादा से ज़्यादा लोगों तक पहुंचाने के लिए
- ऐप्लिकेशन को बेहतर बनाने के सिद्धांत सुलभता: इन मुख्य बातों का ध्यान रखें: अपने ऐप्लिकेशन को ज़्यादा से ज़्यादा लोगों तक पहुंचाने के लिए काम करते समय
- सुलभता के लिए टेस्टिंग: Android सुलभता के लिए नियमों और टूल की जांच करना
आपके लिए सुझाव
- ध्यान दें: JavaScript बंद होने पर लिंक टेक्स्ट दिखता है
- Compose में सुलभता
- Compose में मटीरियल डिज़ाइन 2
- Compose के लेआउट की जांच करना