अलमारियों पर स्विफ्टयूआई

हर बार एक प्रोग्रामिंग भाषा में एक नया ढांचा दिखाई देता है, जितनी जल्दी या बाद में, लोग दिखाई देते हैं जो इससे भाषा सीखते हैं। स्विफ्ट की उपस्थिति के समय आईओएस विकास में शायद यह मामला था: पहले इसे ऑब्जेक्टिव-सी के अतिरिक्त के रूप में माना जाता था - लेकिन मुझे यह पहले से नहीं मिला। अब, यदि आप खरोंच से शुरू करते हैं, तो भाषा का विकल्प अब इसके लायक नहीं है। स्विफ्ट प्रतिस्पर्धा से परे है।

एक ही बात है, लेकिन एक छोटे पैमाने पर, चौखटे के साथ हो रहा है। SwiftUI की उपस्थिति कोई अपवाद नहीं है। मैं शायद डेवलपर्स की पहली पीढ़ी का प्रतिनिधि हूं, जिसने यूआईएफटी को अनदेखा करते हुए, स्विफ्टयूआई को सीखना शुरू किया। इसकी एक कीमत है - अब तक बहुत कम प्रशिक्षण सामग्री और काम करने वाले कोड के उदाहरण हैं। हां, नेटवर्क में पहले से ही एक विशेष सुविधा, एक विशेष उपकरण के बारे में बताने वाले कई लेख हैं। एक ही www.hackingwithswift.com में पहले से ही स्पष्टीकरण के साथ कोड उदाहरण के बहुत सारे हैं। हालांकि, वे उन लोगों की मदद करने के लिए बहुत कम करते हैं जो मेरी तरह स्विफ्टयूआई सीखने का फैसला करते हैं। नेटवर्क पर अधिकांश सामग्री विशिष्ट, तैयार किए गए प्रश्नों के उत्तर हैं। एक अनुभवी डेवलपर आसानी से यह पता लगा सकता है कि सब कुछ कैसे काम करता है, ऐसा क्यों है, और इसे क्यों लागू किया जाना चाहिए। एक शुरुआत के लिए, पहले आपको यह समझने की ज़रूरत है कि किस प्रश्न को पूछना है, और उसके बाद ही वह इन लेखों को प्राप्त कर सकता है।



कट के तहत, मैं उस समय जो मैं सीखने में कामयाब रहा हूं, उसके माध्यम से व्यवस्थित और क्रमबद्ध करने की कोशिश करूंगा। लेख का प्रारूप लगभग एक मार्गदर्शक है, हालाँकि, मेरे द्वारा संकलित की गई एक चिट शीट, जिसमें मैं स्वयं अपनी यात्रा की शुरुआत में इसे पढ़ना चाहूंगा। अनुभवी डेवलपर्स के लिए जो अभी तक स्विफ्टयूआई में गहराई से नहीं गए हैं, कुछ दिलचस्प कोड उदाहरण भी हैं, और पाठ संबंधी व्याख्याओं को तिरछे तरीके से पढ़ा जा सकता है।

मुझे उम्मीद है कि यह लेख आपको कुछ समय बचाएगा जब आप भी थोड़ा जादू महसूस करना चाहते हैं।

शुरुआत के लिए, अपने बारे में थोड़ा

मेरे पास व्यावहारिक रूप से कोई मोबाइल विकास पृष्ठभूमि नहीं है, और महत्वपूर्ण अनुभव है
1s में यहाँ ज्यादा मदद नहीं कर सकता था। कैसे और क्यों मैंने स्विफ्टयूआई सीखने का फैसला किया, मैं आपको कुछ और समय बताऊंगा, अगर यह किसी के लिए दिलचस्प होगा, तो निश्चित रूप से।

ऐसा हुआ कि मोबाइल विकास में मेरे विसर्जन की शुरुआत आईओएस 13 और स्विफ्टयूआई की रिलीज के साथ हुई। यह एक संकेत है, मैंने सोचा, और UIKit की अनदेखी करते हुए, तुरंत इसके साथ शुरू करने का फैसला किया। मैंने इसे एक मनोरंजक संयोग पाया कि मैंने ऐसे समय में 1 सी के साथ काम करना शुरू किया: तब बस प्रबंधित रूप दिखाई दिए। 1 सी के मामले में, नई तकनीक के लोकप्रिय होने में लगभग पांच साल लग गए। हर बार एक डेवलपर को कुछ नई कार्यक्षमता को लागू करने का निर्देश दिया गया था, उसने एक विकल्प का सामना किया: इसे जल्दी और मज़बूती से करने के लिए, परिचित उपकरणों के साथ, या नए लोगों के साथ बहुत समय बिताने के लिए, और परिणामों की गारंटी के बिना। विकल्प आमतौर पर गति और गुणवत्ता के पक्ष में बनाया गया था, और नए उपकरणों में निवेश करने में बहुत लंबे समय के लिए देरी हुई थी।

अब, जाहिरा तौर पर, स्विफ्टयूआई के साथ स्थिति उसी के बारे में है। हर कोई दिलचस्पी रखता है, हर कोई समझता है कि यह भविष्य है, लेकिन अभी तक कुछ लोगों ने इसका अध्ययन करने के लिए समय लिया है। जब तक पालतू परियोजनाओं के लिए नहीं।

मेरे लिए यह बहुत मायने नहीं रखता था कि कौन सी रूपरेखा का अध्ययन करना है, और मैंने सामान्य राय के बावजूद मौका लेने का फैसला किया कि इसे एक या दो साल में उत्पादन में लॉन्च करना संभव होगा। और जब से ऐसा हुआ है कि मैं अग्रदूतों में से था, मैंने व्यावहारिक अनुभव साझा करने का फैसला किया। मैं कहना चाहता हूं कि मैं गुरु नहीं हूं, और सामान्य रूप से मोबाइल विकास में - एक केतली। फिर भी, मैं पहले से ही एक निश्चित तरीके से चला गया हूं, जिसके दौरान मैंने जानकारी की तलाश में सभी इंटरनेट को खोजा, और मैं आत्मविश्वास से कह सकता हूं कि यह पर्याप्त नहीं है और यह व्यावहारिक रूप से व्यवस्थित नहीं है। लेकिन रूसी में, ज़ाहिर है, यह व्यावहारिक रूप से कोई नहीं है। यदि ऐसा है, तो मैंने अपनी ताकत को इकट्ठा करने का फैसला किया, नपुंसक को दूर धकेल दिया, और उस समुदाय के साथ साझा किया जो मैंने खुद को पता लगाने में कामयाब रहा। मैं इस धारणा से आगे बढ़ूंगा कि पाठक पहले से ही कम से कम SwiftUI से परिचित है, और मैं VStack{…} , Text(…) , आदि जैसी चीजों को नहीं VStack{…} ।

मैं एक बार फिर इस बात पर जोर देता हूं कि मैं स्विफ्टयूआई से वांछित परिणाम प्राप्त करने के प्रयासों के अपने स्वयं के छापों का वर्णन करूंगा। मैं अच्छी तरह से कुछ समझ नहीं सका, और कुछ प्रयोगों से गलत या गलत निष्कर्ष निकालने के लिए, इसलिए किसी भी सुधार और स्पष्टीकरण का जोरदार स्वागत है।

अनुभवी डेवलपर्स के लिए, यह लेख स्पष्ट चीजों के विवरणों से भरा लग सकता है, लेकिन सख्ती से न्याय नहीं करते हैं। स्विफ्टयूआई पर डमी के लिए ट्यूटोरियल अभी तक नहीं लिखे गए हैं।

यह स्विफ्टयूआई क्या है?

इसलिए, मैं शायद इसके बारे में सब कुछ शुरू करूंगा, यह आपकी स्विफ्टयूआई है। यहाँ फिर से, मेरा पहला अतीत सामने आता है। प्रबंधित रूपों के साथ सादृश्य तभी मजबूत हुआ जब मैंने स्टोरीबोर्ड में लेआउट इंटरफेस में कुछ वीडियो देखे (यानी जब UIKit के साथ काम करते हुए)। मैंने 1s में "बेकाबू" रूपों के अनुसार उदासीनता ली: फार्म पर तत्वों का मैनुअल प्लेसमेंट, और विशेष रूप से बाइंडिंग ... ओह, जब लगभग 20 मिनट के प्रशिक्षण वीडियो के लेखक ने विभिन्न तत्वों के एक दूसरे को और स्क्रीन के किनारों के बंधन की पेचीदगियों के बारे में बात की, तो मुझे एक मुस्कान 1C - के साथ याद आई। नियंत्रित रूपों से पहले सब कुछ समान था। ठीक है, लगभग ... थोड़ा बुरा, ज़ाहिर है, अच्छी तरह से, और तदनुसार - आसान। और स्विफ्टयूआई, एप्पल से मोटे तौर पर प्रबंधित रूप है। कोई बंधन नहीं। कोई स्टोरीबोर्ड और segways। आप बस कोड में अपने व्यू की संरचना का वर्णन करते हैं। और वह सब है। सभी मापदंडों, आकार, आदि को सीधे कोड में सेट किया जाता है - लेकिन काफी सरल। अधिक सटीक रूप से, आप कैनवस में मौजूदा वस्तुओं के मापदंडों को संपादित कर सकते हैं, लेकिन इसके लिए आपको पहले उन्हें कोड में जोड़ना होगा। ईमानदारी से, मुझे नहीं पता कि यह बड़ी विकास टीमों में कैसे काम करेगा, जहां यह डिज़ाइन के लेआउट और व्यू की सामग्री को अलग करने के लिए प्रथागत है, लेकिन एक इंडी डेवलपर के रूप में मुझे वास्तव में यह दृष्टिकोण पसंद है।

घोषणात्मक शैली

SwiftUI मानता है कि आपके दृश्य की संरचना का वर्णन पूरी तरह से कोड में है। इसके अलावा, Apple हमें इस कोड को लिखने की एक घोषणात्मक शैली प्रदान करता है। यह कुछ इस तरह है:

“यह एक दृश्य है। यह (किसी कारण से मैं "दृश्य" कहना चाहता हूं, और, तदनुसार, एक महिला शब्द के लिए लागू होने के लिए) दो पाठ फ़ील्ड और एक चित्र शामिल हैं। पाठ क्षेत्रों को एक के बाद एक क्षैतिज रूप से व्यवस्थित किया जाता है। छवि उनके नीचे है और इसके किनारों को एक चक्र के आकार में काट दिया गया है। "

असामान्य लगता है, है ना? आमतौर पर, कोड में हम इस प्रक्रिया का वर्णन करते हैं, हमारे सिर में जो परिणाम होता है उसे प्राप्त करने के लिए क्या करना होगा:

"एक ब्लॉक डालें, इस ब्लॉक में एक टेक्स्ट फ़ील्ड डालें, उसके बाद एक अन्य टेक्स्ट फ़ील्ड, और उसके बाद, एक तस्वीर लें, इसके किनारों को गोल करके फसल दें, और नीचे पेस्ट करें।"

यह Ikea से फर्नीचर के लिए एक निर्देश की तरह लगता है। और स्विफ्टयूआई में, हम तुरंत देखते हैं कि परिणाम क्या होना चाहिए। कैनवास या डिबगिंग के बिना भी, कोड की संरचना स्पष्ट रूप से व्यू की संरचना को दर्शाती है। यह स्पष्ट है कि क्या और किस क्रम में और किन प्रभावों के साथ प्रदर्शित किया जाएगा।

FunctionBuilder के बारे में एक उत्कृष्ट लेख, और यह आपको एक घोषणात्मक शैली में कोड लिखने की अनुमति कैसे देता है यह पहले से ही हैबे पर है ।

सिद्धांत रूप में, घोषणात्मक शैली और इसके लाभों के बारे में बहुत कुछ लिखा गया है, इसलिए मैं इसे बंद कर दूंगा। मैं अपने आप से जोड़ता हूं कि मुझे इसकी थोड़ी आदत हो गई है और वास्तव में यह महसूस किया है कि इंटरफेस के लिए कोड को इस शैली में लिखना कितना सुविधाजनक है। इस के साथ, Apple ने बुलसे को क्या कहा!

क्या देखें से मिलकर बनता है?

लेकिन चलो एक करीब देखो। Apple का सुझाव है कि घोषणात्मक शैली इस प्रकार है:

 struct ContentView: View { var text1 = "some text" var text2 = "some more text" var body: some View { VStack{ Text(text1) .padding() .frame(width: 100, height: 50) Text(text2) .background(Color.gray) .border(Color.green) } } } 

कृपया ध्यान दें, View कुछ मापदंडों के साथ एक संरचना है। संरचना View बनाने के लिए, हमें परिकलित पैरामीटर body सेट करना होगा, जो some View लौटाता है। हम इस बारे में बाद में बात करेंगे। body: some View { … } की सामग्री body: some View { … } बंद होने का वर्णन है कि स्क्रीन पर क्या प्रदर्शित किया जाएगा। वास्तव में, यह वह सब है जो हमारी संरचना के लिए व्यू प्रोटोकॉल की आवश्यकताओं को पूरा करने के लिए आवश्यक है। मैं मुख्य रूप से body पर ध्यान केंद्रित करने का सुझाव देता हूं।

और इसलिए, अलमारियों

कुल में, मैंने तीन प्रकार के तत्वों को गिना जिसमें से दृश्य का शरीर निर्मित है:

• अन्य दृश्य
  यानी प्रत्येक दृश्य में एक या अधिक अन्य View । वे, बदले में, दोनों पूर्वनिर्धारित प्रणाली को भी देख सकते हैं जैसे कि Text() , और कस्टम, डेवलपर द्वारा लिखित जटिल। यह एक प्रकार की घोंसले के शिकार गुड़िया को असीमित स्तर के घोंसले के शिकार के रूप में बदल देता है।
• संशोधक
  संशोधक की मदद से, सभी जादू होता है। उनके लिए धन्यवाद, हम संक्षेप में और स्पष्ट रूप से स्विफ्टयूआई को बताते हैं कि हम किस तरह का दृश्य देखना चाहते हैं। यह कैसे काम करता है, हम अभी भी इसका पता लगाएंगे, लेकिन मुख्य बात यह है कि संशोधक एक निश्चित View की सामग्री में आवश्यक टुकड़ा जोड़ते हैं।
• कंटेनर
  पहला कंटेनर जो मानक "हैलो, दुनिया" से शुरू होता है, वह हैं HStack और VStack । थोड़ी देर बाद, Group , Section और अन्य दिखाई देते हैं। वास्तव में, कंटेनर समान दृश्य हैं, लेकिन उनके पास एक विशेषता है। आप उन्हें कुछ ऐसी सामग्री देते हैं, जिसे आप प्रदर्शित करना चाहते हैं। कंटेनर की पूरी विशेषता यह है कि उसे किसी तरह समूह बनाना चाहिए और इस सामग्री के तत्वों को प्रदर्शित करना चाहिए। इस अर्थ में, कंटेनर संशोधक के समान हैं, एकमात्र अंतर यह है कि संशोधक एक तैयार किए गए दृश्य को बदलने का इरादा रखते हैं, और कंटेनर एक निश्चित क्रम में इन दृश्य (सामग्री तत्वों, या घोषणात्मक वाक्यविन्यास ब्लॉकों) को व्यवस्थित करते हैं, उदाहरण के लिए, लंबवत या क्षैतिज रूप से ( VStack{...} HStack{...} )। विशिष्ट कंटेनर भी हैं, जैसे कि ForEach या GeometryReader , हम उनके बारे में थोड़ी देर बाद बात करेंगे।
  
  सामान्य तौर पर, मैं कंटेनरों को किसी भी दृश्य के रूप में मानता हूं, जिसमें सामग्री को एक पैरामीटर के रूप में पारित किया जा सकता है।

और वह सब है। Purebred SwiftUI के सभी तत्वों को इनमें से किसी एक प्रकार के लिए जिम्मेदार ठहराया जा सकता है। हां, यह आपके व्यू को कार्यक्षमता से भरने के लिए पर्याप्त नहीं है, लेकिन यह सब आपको स्क्रीन पर अपनी कार्यक्षमता दिखाने की आवश्यकता है।

.modifiers () - वे कैसे व्यवस्थित हैं?

सबसे सरल से शुरू करते हैं। एक संशोधक वास्तव में एक बहुत ही साधारण बात है। वह बस कुछ View लेता है, उसमें कुछ बदलाव करता है (या करता है?) , और उसे वापस लौटा देता है। यानी संशोधक View ही एक फंक्शन है, जो self लौटता है, जिसमें पहले कुछ संशोधन किए गए हैं।

नीचे कोड का एक उदाहरण है जिसके साथ मैं अपने स्वयं के संशोधक की घोषणा करता हूं। अधिक सटीक रूप से, मैं मौजूदा संशोधक frame(width:height:) अधिभारित करता हूं, जिसके साथ आप किसी विशेष दृश्य के विशिष्ट आयामों को ठीक कर सकते हैं। बॉक्स से, आपको इसके लिए चौड़ाई और ऊंचाई निर्दिष्ट करने की आवश्यकता है, और मुझे एक तर्क के साथ एक CGSize ऑब्जेक्ट को पास करने की आवश्यकता है, जो कि केवल लंबाई और चौड़ाई का विवरण है। मुझे इसकी आवश्यकता क्यों थी, मैं थोड़ी देर बाद बताऊंगा।

 struct FrameFromSize: ViewModifier{ let size: CGSize func body(content: Content) -> some View { content .frame(width: size.width, height: size.height) } } 

इस कोड के साथ, हमने एक संरचना बनाई है जो ViewModifier प्रोटोकॉल का अनुपालन करती है। इस प्रोटोकॉल के लिए आवश्यक है कि body() फ़ंक्शन को इस संरचना में लागू किया जाए, जिसके इनपुट में कुछ Content होगी, और आउटपुट में some View : हमारे View के body पैरामीटर के समान प्रकार (हम नीचे कुछ व्यू के बारे में बात करेंगे) । यह किस प्रकार की Content ?

कंटेंट + व्यूब्युल्ट = देखें

उसके बारे में अंतर्निहित प्रलेखन में ऐसा कहता है:

`कंटेंट` उस दृश्य के लिए एक प्रॉक्सी है, जिसमें` सेल्फ` द्वारा दर्शाया गया संशोधक होगा।

यह एक प्रॉक्सी प्रकार है, जो एक व्यू प्रीफ़ैब है जिसमें संशोधक लागू किए जा सकते हैं। एक प्रकार का अर्ध-तैयार उत्पाद। दरअसल, Content एक डिक्लेक्टिव स्टाइल क्लोजर है जो View स्ट्रक्चर का वर्णन करता है। इस प्रकार, यदि हम कुछ दृश्य के लिए इस संशोधक को कॉल करते हैं, तो वह सब करता है body से क्लोजर प्राप्त करता है और इसे हमारे body फंक्शन में पास करता है, जिसमें हम इस क्लोजर में अपने पांच सेंट जोड़ते हैं।

एक बार फिर, View मुख्य रूप से एक संरचना है जो स्क्रीन पर एक छवि बनाने के लिए आवश्यक सभी मापदंडों को संग्रहीत करती है। जिसमें विधानसभा निर्देश शामिल हैं, जिसमें से Content । इस प्रकार, ViewBuilder का उपयोग करके संसाधित एक घोषित शैली ( Content ) में एक बंद ViewBuilder हमें एक दृश्य देता है।

आइए अपने संशोधक पर वापस जाएं। सिद्धांत रूप में, FrameFromSize संरचना की घोषणा इसे लागू करने के लिए पहले FrameFromSize ही पर्याप्त है। body अंदर body हम इस तरह लिख सकते हैं:

 RoundedRectangle(cornerRadius: 4).modifier(FrameFromSize(size: size)) 

modifier एक दृश्य प्रोटोकॉल विधि है जो संशोधित किए View से सामग्री को निकालती है, इसे संशोधक संरचना के बॉडी फ़ंक्शन को पास करती है, और परिणाम को आगे ViewBuilder प्रसंस्करण, या अगले संशोधन के लिए पास करती है, अगर हमारे पास संशोधनों की एक श्रृंखला है।

लेकिन आप अपने स्वयं के संशोधक को एक फ़ंक्शन के रूप में घोषित करके इसे और अधिक संक्षिप्त बना सकते हैं, जिससे व्यू प्रोटोकॉल की क्षमताओं का विस्तार हो सकता है।

 extension View{ func frame(_ size: CGSize) -> some View { self.modifier(FrameFromSize(size: size)) } } 

इस मामले में, मैंने मौजूदा मॉडिफायर को .frame(width: height:) । .frame(width: height:) मापदंडों के एक और प्रकार के .frame(width: height:) । अब, हम किसी भी View लिए frame(size:) संशोधक को कॉल करने के विकल्प का उपयोग कर सकते हैं। जैसा कि यह निकला, कुछ भी जटिल नहीं है।


उसी तरह, आप कोई भी कस्टम संशोधक बना सकते हैं, और उन्हें उसी तरह से उपयोग कर सकते हैं जैसे कि अंतर्निहित स्विफ्टयूआई:

 RoundedRectangle(cornerRadius: 4).frame(size) 

स्पष्ट रूप से, स्पष्ट रूप से, स्पष्ट रूप से।

मैं एक धागे में पिरोए गए मोतियों की श्रृंखला की कल्पना करता हूं - हमारा दृश्य। यह सादृश्य इस अर्थ में भी सही है कि जिस क्रम में संशोधनों को मामले कहा जाता है।

फिर भी देखें

पहले हमने इस बारे में बात की थी कि body में क्या है, View का निकाय या उसके विधानसभा निर्देश क्या हैं। आइए View स्वयं पर वापस जाएं। सबसे पहले, यह एक संरचना है जिसमें कुछ पैरामीटर घोषित किए जा सकते हैं, और body उनमें से केवल एक है। जैसा कि हमने पहले ही कहा, यह पता लगाना कि Content क्या Content , body वांछित दृश्य को इकट्ठा करने के तरीके पर एक निर्देश है, जो एक घोषणात्मक शैली में एक बंद है। लेकिन हमारे बंद को वापस क्या करना चाहिए?

कुछ दृश्य - सुविधा

और हम आसानी से एक सवाल पर आते हैं कि लंबे समय तक मैं इसका पता नहीं लगा सका, हालांकि इसने मुझे वर्किंग कोड लिखने से नहीं रोका। यह some View क्या है? प्रलेखन का कहना है कि यह विवरण एक "अपारदर्शी परिणाम प्रकार" है - लेकिन यह बहुत मायने नहीं रखता है।

some कीवर्ड एक "जेनेरिक" संस्करण है जो एक क्लोजर द्वारा लौटाए गए एक प्रकार के विवरण का है जो कोड के अलावा किसी अन्य चीज पर निर्भर नहीं करता है। यानी हमारे दृश्य के मुख्य भाग की गणना की गई संपत्ति तक पहुँचने का परिणाम कुछ संरचना होना चाहिए जो दृश्य प्रोटोकॉल को संतुष्ट करता है। उनमें से कई हो सकते हैं - पाठ, छवि, या शायद आपके द्वारा घोषित कुछ संरचना। कुछ कीवर्ड की पूरी चिप "जेनेरिक" घोषित करना है जो व्यू प्रोटोकॉल के अनुरूप है। यह आपके दृश्य के शरीर के अंदर कार्यान्वित कोड द्वारा सांख्यिकीय रूप से निर्धारित किया जाता है, और Xcode इस कोड को पार्स करने में सक्षम है, और वापसी मूल्य के विशिष्ट हस्ताक्षर (अच्छी तरह से, लगभग हमेशा) की गणना करता है। और कुछ सिर्फ अनावश्यक समारोहों के साथ डेवलपर को बोझ नहीं करने का प्रयास है। डेवलपर के पास यह कहने के लिए पर्याप्त है: "कुछ प्रकार का दृश्य होगा", और कौन सा - इसे अपने आप से बाहर निकालें। यहां कुंजी यह है कि ठोस प्रकार इनपुट मापदंडों द्वारा निर्धारित नहीं किया जाता है, जैसा कि सामान्य सामान्य प्रकार के साथ, लेकिन सीधे कोड द्वारा। इसलिए, ऊपर, सामान्य मैंने उद्धृत किया।

Xcode एक विशिष्ट प्रकार को इंगित करने में सक्षम होना चाहिए बिना यह जाने कि आप इस संरचना में कौन से मूल्यों को पास करते हैं। यह समझना महत्वपूर्ण है - संकलन के बाद, कुछ दृश्य को आपके View के विशिष्ट प्रकार से बदल दिया जाता है। यह प्रकार काफी नियतात्मक है, और उदाहरण के लिए, काफी जटिल हो सकता है, जैसे: Group<TupleView<(Text, ForEach<[SomeClass], SomeClass.ID, Text>)>> ।

नमूना कोड इस प्रकार से बहाल किया जा सकता है:

 Group{ Text(…) ForEach(…){(value: SomeClass) in Text(…) } } 

ForEach , जैसा कि हस्ताक्षर से देखा जा सकता है, रनटाइम लूप नहीं है। यह केवल एक View जो कुछ SomeClass ऑब्जेक्ट्स की एक सरणी के आधार पर बनाया गया है। संग्रह तत्व से जुड़े किसी विशेष subView के पहचानकर्ता के रूप में, तत्व आईडी को इंगित किया गया है, और प्रत्येक तत्व subView टाइप Text का एक subView । Text और ForEach संयोजित किया TupleView , और यह सब Group में रखा गया है। हम ForEach बारे ForEach अधिक विस्तार से बात करेंगे।

कल्पना कीजिए कि अगर हम पैरामीटर body तरह एक सटीक हस्ताक्षर का वर्णन करने के लिए मजबूर हुए तो कितना लेखन होगा? इससे बचने के लिए, some कीवर्ड बनाया गया था।

कुछ दृश्य - और परिणाम

शरीर के अंदर की अभिव्यक्ति के स्थैतिक प्रकार की गणना करने का दृष्टिकोण, मेरी राय में, दो महत्वपूर्ण बिंदुओं को जन्म देता है:

• जब संकलित किया जाता है, तो Xcode विशिष्ट रिटर्न प्रकार की गणना करने के लिए शरीर की सामग्री को पार्स करता है। जटिल निकायों में, इसमें कुछ समय लग सकता है। कुछ विशेष रूप से जटिल निकायों में, वह समझदारी के साथ समय का सामना करने में सक्षम नहीं हो सकता है, और वह सीधे ऐसा कहेगा।
  
  सामान्य तौर पर, व्यू को यथासंभव सरल रखा जाना चाहिए। कॉम्प्लेक्स संरचनाओं को सबसे अलग व्यू में रखा गया है। इस प्रकार, वास्तविक प्रकार की पूरी श्रृंखलाओं को एक प्रकार से बदल दिया जाता है - आपका कस्टम व्यू, जो कंपाइलर को इस सारी गड़बड़ से पागल नहीं होने देता है।
  वैसे, कैनवस में परिणाम देखने, प्राप्त करने और देखने के लिए, बड़े व्यू के एक छोटे टुकड़े को डिबग करना वास्तव में बहुत सुविधाजनक है।
• हम सीधे प्रवाह को नियंत्रित नहीं कर सकते। If - if SwiftUI फिर भी इसे टाइप करके "Schrödinger View" टाइप कर सकता है <_ConditionalContent <Text, TextField >> तो ट्रिनियर कंडीशन ऑपरेटर का उपयोग केवल एक विशिष्ट पैरामीटर मान का चयन करने के लिए किया जा सकता है, लेकिन एक प्रकार का नहीं, या यहां तक ​​कि संशोधक के अनुक्रम का चयन करने के लिए भी।
  
  लेकिन यह संशोधक के एक ही क्रम को बहाल करने के लायक है, और इस तरह के रिकॉर्ड से समस्या पैदा होती है।

शरीर को छोड़कर

हालांकि, संरचना में अन्य पैरामीटर हो सकते हैं जिनके साथ आप काम कर सकते हैं। पैरामीटर के रूप में हम निम्नलिखित बातों की घोषणा कर सकते हैं।

बाहरी मापदंडों

ये सरल संरचना पैरामीटर हैं जिन्हें हमें किसी तरह प्रस्तुत करने के लिए दृश्य के लिए आरंभीकरण के दौरान बाहर से पास होना चाहिए:

 struct TextView: View { let textValue: String var body: some View { Text(textValue) } } 

इस उदाहरण में, textValue संरचना के लिए textValue एक पैरामीटर है जिसे बाहरी रूप से पॉप्युलेट किया जाना चाहिए क्योंकि इसमें डिफ़ॉल्ट मान नहीं है। यह देखते हुए कि संरचनाएँ इनिशियलाइज़र की स्वचालित पीढ़ी का समर्थन करती हैं, हम इस दृश्य का उपयोग बस कर सकते हैं:

  TextView(textValue: "some text") 

बाहर से, आप उन क्लोजर को भी स्थानांतरित कर सकते हैं जो किसी ईवेंट के होने पर किए जाने की आवश्यकता होती है। उदाहरण के लिए, Button(lable:action:) करता है कि: एक बटन पर क्लिक किए जाने पर पारित कार्रवाई को बंद कर देता है।

राज्य - मापदंडों

SwiftUI बहुत ही सक्रिय रूप से नई स्विफ्ट 5.1 सुविधा - संपत्ति आवरण का उपयोग कर रहा है ।

सबसे पहले, ये राज्य चर हैं - हमारी संरचना के संग्रहीत पैरामीटर, जिनमें से परिवर्तन को स्क्रीन पर प्रतिबिंबित किया जाना चाहिए।वे विशेष आवरणों में लिपटे हैं @State- आदिम प्रकारों के लिए, और @ObservedObject- कक्षाओं के लिए। एक वर्ग को प्रोटोकॉल को पूरा करना होगा ObservableObject- इसका अर्थ है कि यह वर्ग ग्राहकों को सूचित करने में सक्षम होना चाहिए (देखें, जो इस मान का उपयोग एक आवरण के साथ करते हैं @ObservedObject) अपने गुणों में परिवर्तन के बारे में। ऐसा करने के लिए, बस आवश्यक गुणों को लपेटें @Published।

यदि आप आसान तरीकों की तलाश नहीं कर रहे हैं, या आपको अतिरिक्त कार्यक्षमता की आवश्यकता है, तो इस आवरण के बजाय, आप इन मापदंडों ObservableObjectPublisherकी घटनाओं का उपयोग करते हुए मैन्युअल रूप से सूचनाओं का उपयोग और भेज सकते हैं willSet(), जैसा कि उदाहरण के लिए, यहां ।

याद है, मैंने कहा थाbodyक्या यह सिर्फ एक कम्प्यूटेशनल संपत्ति है? सबसे पहले, मैंने तुरंत स्टेट वेरिएबल्स के बारे में पूरी बात नहीं समझी, और मैंने bodyबिना किसी रैपर के अंदर कुछ स्टेट वैरिएबल घोषित करने की कोशिश की । समस्या bodyयह है कि जैसा कि मैंने कहा, यह एक सांविधिक निर्देश है। इस निर्देश के अनुसार दृश्य उत्पन्न किया गया था, और शरीर के अंदर घोषित संपूर्ण संदर्भ लैंडफिल में चला गया। अगला, केवल संग्रहीत संरचना पैरामीटर रहते हैं। राज्य-मापदंडों को बदलते समय, हमारे सभी Viewअपडेट किए जाते हैं। निर्देश फिर से लिया जाता है, सभी संरचना मापदंडों के वर्तमान मूल्यों को इसमें प्रतिस्थापित किया जाता है, स्क्रीन पर छवि एकत्र की जाती है, निर्देश को अगली बार फिर से बाहर फेंक दिया जाता है। bodyइसके साथ - साथ अंदर घोषित चर । अनुभवी डेवलपर्स के लिए, यह स्पष्ट हो सकता है, लेकिन सबसे पहले, मुझे इस प्रक्रिया के सार को न समझते हुए, इसके साथ सताया गया था।


क्लासिक राज्य उदाहरण :

 struct ContentView: View { @State var tapCount = 0 var body: some View { VStack { Button(action: {self.tapCount += 1}, label: { Text("Tap count \(tapCount)") }) } } } 

बाइंडिंग पैरामीटर

खैर, देखें सेवा में कुछ बदलावों को प्रतिबिंबित करने के लिए @State @ObservedObject। लेकिन इन परिवर्तनों को कैसे पारित किया जाता है View? ऐसा करने के लिए, SwiftUI के पास एक और प्रॉपर्टीवॉपर है - @Binding। क्लिकों की गिनती के लिए एक बटन के साथ हमारे उदाहरण को जटिल करते हैं। मान लीजिए कि हमारे पास एक अभिभावक है View, जो अन्य बातों के अलावा, एक क्लिक काउंटर और Viewएक बटन वाले बच्चे को दर्शाता है । मूल दृश्य में, काउंटर को इस रूप में घोषित किया जाता है @State- यह समझ में आता है, लेकिन हम चाहते हैं कि स्क्रीन पर काउंटर अपडेट किया जाए। लेकिन सहायक में, काउंटर के रूप में घोषित किया जाना चाहिए @Binding। यह एक और प्रॉपर्टी रैपर है, जिसकी मदद से हम संरचना के मापदंडों की घोषणा करते हैं जो न केवल बदलेगा, बल्कि माता-पिता के पास भी लौटेगा View। यह एक तरह का inoutमार्कर हैView। जब कोई मूल्य बच्चे के दृश्य में बदलता है, तो यह परिवर्तन मूल रूप से उस पैरेंट व्यू में अनुवादित किया जाता है, जहां यह मूल रूप से आया था। और जैसा कि inout, हमें $,यह दिखाने के लिए एक विशेष प्रतीक के साथ संचरित मूल्यों को चिह्नित करने की आवश्यकता है कि हम दूसरे मान के अंदर परिवर्तन के लिए संचरित मूल्य की प्रतीक्षा कर रहे हैं। क्रिया में प्रतिक्रिया।

 struct ContentView: View { @State var tapCount = 0 var body: some View { VStack{ SomeView(count: $tapCount) Text("you tap \(tapCount) times") } } } 

यह डेटा प्रकारों में भी परिलक्षित होता है। @Binding var tapCount: Intउदाहरण के लिए, यह अब केवल एक Intप्रकार नहीं है , यह है

 Binding<Int> 

यह जानना उपयोगी है, उदाहरण के लिए, यदि आप अपना खुद का इनिशलाइज़र लिखना चाहते हैं View।

 struct SomeView: View{ @Binding var tapCount: Int init(count: Binding<Int>){ self._tapCount = count //    -    } var body: some View{ Button(action: {self.tapCount += 1}, label: { Text("Tap me") }) } } 

कृपया ध्यान दें कि initकुछ मापदंडों में लिपटे मापदंडों को संदर्भित करने के लिए आपको @PropertyWrapperएक अंडरस्कोर का उपयोग करना चाहिए self._- यह शुरुआती में काम करता है, जब selfअभी भी निर्माण की प्रक्रिया में है। अधिक सटीक रूप से, इसकी मदद से self._हम इसके आवरण के साथ पैरामीटर को संदर्भित करते हैं। रैपर के अंदर मूल्य पर सीधे लागू करना बिना अंडरलाइन किए किया जाता है।

बदले में, यदि आपके पास किसी प्रकार के इनपुट में लिपटा हुआ एक चर है PropertyWrapper, तो हमें इस मामले में एक आवरण प्रकार मिलता है

 Binding<Int> 

आप के Intमाध्यम से सीधे प्रकार के मूल्य का उपयोग कर सकते हैं .wrappedValue।

EnvironmentObject

संक्षेप में, EnvironmentObjectपैरामीटर समान हैं Binding, केवल Viewपदानुक्रम में सभी के लिए तुरंत , उन्हें स्पष्ट रूप से पारित करने की आवश्यकता के बिना।

 ContentView().environmentObject(session) 

आमतौर पर, एप्लिकेशन की वर्तमान स्थिति, या इसका कुछ हिस्सा, जिसे एक बार में कई व्यू की आवश्यकता होती है, प्रसारित होता है। उदाहरण के लिए, किसी उपयोगकर्ता, सत्र, या कुछ समान के बारे में डेटा, इसे एक बार पर्यावरण दृश्य में डालने के लिए समझ में आता है, मूल दृश्य में। प्रत्येक दृश्य में, जहां उनकी आवश्यकता होती है, उन्हें रैपर @EnvironmentObject के साथ एक चर घोषित करके पर्यावरण से निकाला जा सकता है, उदाहरण के लिए

  @EnvironmentObject var session: Session 

एक विशिष्ट मूल्य का पहचानकर्ता स्वयं प्रकार है। यदि आप EnvironmentObjectएक ही प्रकार के कई मान रखते हैं, तो क्रम मायने रखता है। 3rd पर जाने के लिए, उदाहरण के लिए, मान, आपको क्रम में सभी मान प्राप्त करने होंगे, भले ही आपको उनकी आवश्यकता न हो। इसलिए, EnvironmentObjectयह अनुप्रयोग की स्थिति को प्रतिबिंबित करने के लिए अच्छी तरह से अनुकूल है, लेकिन यह एक ही प्रकार के कई मूल्यों को पारित करने के लिए अच्छी तरह से अनुकूल नहीं है View। उन्हें मैन्युअल रूप से, के माध्यम से प्रेषित करना होगा Binding।

@ पर्यावरण लगभग एक जैसा है। अर्थ में, यह पर्यावरण की एक स्थिति है, अर्थात्। ओएस। इस आवरण के माध्यम से प्राप्त करना सुविधाजनक है, उदाहरण के लिए, स्क्रीन की स्थिति (ऊर्ध्वाधर या क्षैतिज), एक प्रकाश या अंधेरे विषय का उपयोग किया जाता है, आदि। इसके अलावा, इस आवरण के माध्यम से आप कोरडेटा का उपयोग करते समय डेटाबेस तक पहुँच सकते हैं:

 @Environment(\.managedObjectContext) var moc: NSManagedObjectContext 

वैसे, SwiftUI में CoreData के साथ काम करने के लिए काफी दिलचस्प चीजें की गई हैं। लेकिन इस बारे में, शायद, अगली बार। इसलिए लेख सभी अपेक्षाओं से परे हो गया है।

कस्टम @PropertyWrapper

बाई एंड लार्ज, PropertyWrapperयह सेटर और गेट्टर के लिए एक शॉर्टकट है, एक ही में लिपटे सभी मापदंडों के लिए समान है property wrapper। रैपर डिक्लेरेशन को हटाकर और गेट्टर {} सेटर {} पैरामीटर लिखकर आप इस कार्यक्षमता को पूरी तरह से बहाल कर सकते हैं, लेकिन Viewकोड को डुप्लिकेट करने के लिए आपको हर बार ऐसा करना होगा । उदाहरण के लिए, इसका उपयोग करना PropertyWrapperकाम को छिपाने के लिए बहुत सुविधाजनक है UserDefaults।

 @propertyWrapper struct UserDefault<T> { var key: String var initialValue: T var wrappedValue: T { set { UserDefaults.standard.set(newValue, forKey: key) } get { UserDefaults.standard.object(forKey: key) as? T ?? initialValue } } } 

इस प्रकार, हम भंडारण में आदिम डेटा प्रकारों को संग्रहीत कर सकते हैं UserDefaults। Apple इस भंडारण के लिए एक बहुत अच्छी गति का दावा करता है, इसलिए संरचना मापदंडों या चर के रूप में स्मृति में इस डेटा को कैश करना आवश्यक नहीं है, जब तक कि वे बड़े पैमाने पर छोरों और गति-मांग वाले कार्यों में उपयोग नहीं किए जाते हैं।

इसे देखते हुए, आप एक स्टब टाइप (इस मामले में, एक एन्यूमरेशन) बना सकते हैं जिसमें स्थिर वैरिएबल्स को UserDefaultsकेवल बनाए गए रैपर का उपयोग करके स्टोर किए गए विशिष्ट मानों तक पहुंचने की घोषणा करना है :

 enum UserPreferences { @UserDefault(key: "isCheatModeEnabled", initialValue: false) static var isCheatModeEnabled: Bool @UserDefault(key: "highestScore", initialValue: 10000) static var highestScore: Int @UserDefault(key: "nickname", initialValue: "cloudstrife97") static var nickname: String } 

परिणाम का उपयोग बहुत ही आसानी से किया जा सकता है, तर्क और दृश्य प्रदर्शन पर ध्यान केंद्रित करते हुए, और सभी काम हुड के तहत किया जाता है।

 UserPreferences.isCheatModeEnabled = true UserPreferences.highestScore = 25000 UserPreferences.nickname = "squallleonhart” 

एक उदाहरण मूल रूप से यहां वर्णित किया गया था ।

कंटेनर

खैर, मेरी सूची से चर्चा करने वाली आखिरी बात कंटेनर है। हम पहले ही इस बारे में बात कर चुके हैं body। वास्तव में, कंटेनर आम हैं View। एकमात्र अंतर यह है कि इस संरचना के मापदंडों में से एक के रूप में, हम सामग्री को प्रसारित करते हैं। उस सामग्री को याद करें जो एक क्लोजर है जिसमें एक या अधिक घोषणात्मक अभिव्यक्तियाँ हैं। यह क्लोजर, यदि इसकी मदद से संसाधित किया जाता है, तो @ViewBuilderएक नए तरीके से हमारे पास वापस आ जाएगा, एक निश्चित तरीके से संयोजन करके सभी दृश्य क्लोजर (सामग्री ब्लॉक) में सूचीबद्ध होंगे। इसी समय, विभिन्न कंटेनरों के लिए, ब्लॉकों के प्रसंस्करण तंत्र स्वयं अलग हैं। VStackसामग्री तत्वों को लंबवत, HStackक्षैतिज रूप से और इतने पर व्यवस्थित करता है । यह एक संशोधक की तरह है, लेकिन इस बार यह केवल एक विशिष्ट दृश्य नहीं है जिसे संशोधित किया जा रहा है, बल्कि संपूर्ण भी हैContentकंटेनर में स्थानांतरित किया जाता है और एक नया उत्पन्न होता है View। इसके अलावा, इस नए Viewएक नए प्रकार है। उदाहरण के लिए, HStack{Text(…)}इस प्रकार के लिए होगा TupleView<Text, Image>।

हालांकि, यह मत भूलो कि Viewकंटेनर सहित कोई भी एक संरचना है, जिसमें शरीर के अलावा अन्य पैरामीटर भी हो सकते हैं। उदाहरण के लिए, लंबे समय तक मैं यह पता नहीं लगा सका कि Text(«a») Text(«b»)अंदर के बीच के छोटे अंतर को कैसे हटाया जाए HStack। जब तक मैं गलती से घोषणा के पूर्ण सिंटैक्स पर ठोकर न खा गया, मैंने बहुत समय बिताया offset()और position()लाइनों की लंबाई के आधार पर ऑफसेट के निर्देशांक की गणना की HStack:

HStack (रिक्ति:, विस्मयादिबोधक: संदर्भ :)।

बस, पहले दो पैरामीटर वैकल्पिक हैं, और अधिकांश उदाहरणों में छोड़ दिए जाते हैं। नौसिखिया गलती - पूर्ण सिंटैक्स देखने के लिए नहीं।

foreach

अलग से, यह बात करने लायक है ForEach। यह एक कंटेनर है जो स्क्रीन पर हस्तांतरित संग्रह के सभी तत्वों को प्रतिबिंबित करने के लिए कार्य करता है। सबसे पहले, आपको यह समझने की आवश्यकता है कि यह कुछ संग्रह के लिए कॉल करने के समान नहीं है forEach(…)। जैसा कि हमने ऊपर कहा, यह ForEachएक अनोखा रिटर्न देता है View, जो हस्तांतरित संग्रह के तत्वों के आधार पर बनाया गया है। यानीयह सिर्फ एक और कंटेनर है जिसमें संग्रह स्थानांतरित किया गया है, और स्क्रीन पर संग्रह के तत्वों को प्रतिबिंबित करने के तरीके के बारे में निर्देश दिए गए हैं।
इसके अलावा, इसे ForEachकुछ अन्य कंटेनर के अंदर रखा जाना चाहिए जो पहले से ही निर्धारित करेगा कि इस एकाधिक इकाई को कैसे समूह में रखा जाए - इसे लंबवत, क्षैतिज रूप से, या, उदाहरण के लिए, एक सूची में रखकर ( List)।

ForEachतीन मापदंडों को स्वीकार करता है: संग्रह ( data: RandomAccesCollection), संग्रह तत्व पहचानकर्ता का पता ( id: Hashable), और सामग्री ( content: ()->Content)। तीसरा हम पहले ही चर्चा कर चुके हैं: किसी भी अन्य कंटेनर की तरह, यह ForEachस्वीकार करता है Content- अर्थात शॉर्ट सर्किट। लेकिन साधारण कंटेनरों के विपरीत, जहां contentइसमें पैरामीटर नहीं होते हैं, यह ForEachएक संग्रह तत्व को बंद करने के लिए गुजरता है जिसका उपयोग सामग्री का वर्णन करने के लिए किया जा सकता है।

संग्रह ForEachकिसी भी के लिए उपयुक्त नहीं है, लेकिन केवल RandomAccesCollection। विभिन्न अव्यवस्थित संग्रहों के लिए, यह उस पद्धति को कॉल करने के लिए पर्याप्त है sorted(by:)जिसके साथ आप प्राप्त कर सकते हैं RandomAccesCollection।

ForEach- यह subViewसंचरित सामग्री के आधार पर संग्रह के प्रत्येक तत्व के लिए उत्पन्न एक सेट है। यह ध्यान रखना महत्वपूर्ण है कि स्विफ्टयूआई को यह जानने की जरूरत है कि subViewसंग्रह के किस तत्व के साथ कौन सा जुड़ा है। इसके लिए, प्रत्येक के Viewपास एक पहचानकर्ता होना चाहिए। इसके लिए ठीक दूसरे पैरामीटर की जरूरत है। यदि संग्रह के तत्व Hashableस्ट्रिंग जैसे प्रकार हैं, तो आप बस लिख सकते हैं id: \.self। इसका मतलब यह होगा कि स्ट्रिंग ही पहचानकर्ता होगा। यदि संग्रह के तत्व कक्षाएं हैं और प्रोटोकॉल को संतुष्ट करते हैंIdentifiable- तब दूसरा तर्क याद किया जा सकता है। इस स्थिति में, संग्रह में प्रत्येक आइटम की पहचान एक पहचानकर्ता बन जाएगी subView। यदि आपकी वस्तु में किसी प्रकार का प्रॉप्स है जो अद्वितीयता सुनिश्चित करता है, और जो प्रोटोकॉल से मिलता है Hashable, तो आप इसे इस तरह निर्दिष्ट कर सकते हैं:

 ForEach(values, id: \.value){item in …} 

मेरे उदाहरण में, valuesवर्ग वस्तुओं की एक सरणी है SomeObjectजिसके लिए सहारा घोषित किए जाते हैं value: Int। किसी भी मामले में, आपको यह सुनिश्चित करना चाहिए कि Viewआपके संग्रह के एक तत्व से जुड़ा प्रत्येक पहचानकर्ता अद्वितीय है । उदाहरण के लिए, आपके संदर्भ में, आपकी वस्तु के कुछ पैरामीटर बदल सकते हैं। Viewइसे डेटा ऑब्जेक्ट (संग्रह तत्व) के साथ 1 से 1 से मेल खाना चाहिए, अन्यथा यह स्पष्ट नहीं होगा कि @Bindingपैरामीटर परिवर्तन कहां वापस करना है View।

वैसे, संग्रह तत्वों के एक क्रॉल का आयोजन करना जो पहचानने योग्य को संतुष्ट नहीं करते हैं, उन्हें भी अनुक्रमित का उपयोग करके किया जा सकता है। उदाहरण के लिए, इस तरह:

 ForEach(keys.indices){ind in SomeView(key: self.keys[ind]) } 

इस मामले में, आघात का निर्माण तत्वों द्वारा नहीं, बल्कि उनके सूचकांकों द्वारा किया जाएगा। छोटे संग्रह के लिए, यह पूरी तरह से स्वीकार्य है। बड़ी संख्या में तत्वों के साथ संग्रह पर, यह संभवतः प्रदर्शन को प्रभावित कर सकता है, खासकर जब संग्रह के तत्व संदर्भ प्रकार नहीं होते हैं, लेकिन, उदाहरण के लिए, वॉल्यूमिनस स्ट्रिंग्स या JSON डेटा। सामान्य तौर पर, सावधानी के साथ उपयोग करें। क्या संदर्भित है

इसके बारे में एक महत्वपूर्ण बिंदु । वह बहुत मूडी है, और एक से अधिक ब्लॉक (यानी, वह सामान्य रूप से एक पंक्ति से सामग्री को मानता है, लेकिन वह पहले से ही 2 या अधिक नहीं है) के साथ क्लोजर के साथ सामान्य रूप से काम करने से इनकार करता है। यह काफी सरल रूप से हल किया गया है, यह सभी सामग्रियों को सामान करने के लिए काफी सरल है - इस तरह की हैक एक समस्या बन जाती है।ContentForEachGroupe{}

बस इस बंद के दायरे में आंतरिक चर घोषित करें काम नहीं करेगा। ViewBuilder के लिए पारित किए गए किसी भी क्लोजर में चर घोषणाएं नहीं हो सकती हैं। याद रखें, लेख की शुरुआत में मैंने एक संशोधक बनाने का एक उदाहरण दिया था .frame(size:)? मैंने इसे इसी वजह से बनाया है। मैंने एक पंक्ति में इन बटनों की संख्या और पंक्तियों की संख्या के आधार पर बटन आकारों की गणना की (मैं स्वचालित स्ट्रेचिंग से खुश नहीं था, अलग-अलग बटन के अलग-अलग आकार होने चाहिए)। फ़ंक्शन CGSize लौटा, और नेस्टेड संरचनाओं के कई स्तर अंदर क्रॉल किए गए थे। यदि एक बार फ़ंक्शन को निष्पादित करना संभव था, तो इसका परिणाम एक चर आकार के रूप में लिखें, और फिर कॉल करें.ftame(width: size.width, height: size.height)"मैं ऐसा करूंगा।" लेकिन ऐसी कोई संभावना नहीं है, और मैं दो बार कार्य नहीं करना चाहता था - क्योंकि मैंने इस सीमा को दरकिनार कर दिया और कोड का हिस्सा संशोधक में डाल दिया।

कस्टम कंटेनर दृश्य

खैर, जैसा कि हुआ, मैं एक कस्टम कंटेनर बनाने का एक उदाहरण दूंगा। अक्सर, "1: N" प्रकार की कई वस्तुओं के संबंध को शब्दकोश के रूप में आसानी से दर्शाया जा सकता है। किसी क्वेरी को निष्पादित करना और उसके परिणाम को एक प्रकार के शब्दकोश में बदलना dict: [KeyObject: [SomeObject]]मुश्किल नहीं है।

इस मामले में, कक्षा की वस्तुएं शब्दकोश कुंजी के रूप में कार्य करती हैं KeyObject(इसके लिए, इसे प्रोटोकॉल का समर्थन करना चाहिए Hashable), और मान किसी अन्य वर्ग की वस्तुओं के सरणियाँ हैं - SomeObject।

 class SomeObject: Identifiable{ let value: Int public let id: UUID = UUID() init(value: Int){ self.value = value } } class KeyObject: Hashable, Comparable{ var name: String init(name: String){ self.name = name } static func < (lhs: KeyObject, rhs: KeyObject) -> Bool { lhs.name < rhs.name } static func == (lhs: KeyObject, rhs: KeyObject) -> Bool { return lhs.name == rhs.name } func hash(into hasher: inout Hasher) { hasher.combine(name) } } 

यदि आपका एप्लिकेशन किसी प्रकार के एनालिटिक्स को समूहीकरण के साथ बनाने की योजना बनाता है, तो ऐसे शब्दकोशों को प्रदर्शित करने के लिए एक अलग कंटेनर बनाने का अर्थ है ताकि प्रत्येक दृश्य में सभी कोड की नकल न करें। और इस तथ्य को देखते हुए कि समूह को उपयोगकर्ता द्वारा बदला जा सकता है, हमें जेनेरिक का उपयोग करना होगा। मैंने दृश्य डिजाइन को जोड़कर इसे जटिल नहीं बनाया, केवल हमारे कंटेनर की संरचना को छोड़कर:

 struct TreeView<K: Hashable, V: Identifiable, KeyContent, ValueContent>: View where K: Comparable, KeyContent: View, ValueContent: View{ let data: [K: [V]] let keyContent: (K)->KeyContent let valueContent: (V)->ValueContent var body: some View{ VStack(alignment: .leading, spacing: 0){ ForEach(data.keys.sorted(), id: \.self){(key: K) in VStack(alignment: .trailing, spacing: 0){ self.keyContent(key) ForEach(self.data[key]!){(value: V) in self.valueContent(value) } } } } } } 

जैसा कि आप देख सकते हैं, कंटेनर प्रकार का एक शब्दकोश स्वीकार करता है [K: [V]](जहां Kशब्द कुंजी ऑब्जेक्ट Vका प्रकार है , एक प्रकार का सरणी है जिसमें शब्दकोश मान शामिल हैं), और दो संदर्भ: शब्दकोश कुंजियों को प्रदर्शित करने के लिए, और दूसरा मान प्रदर्शित करने के लिए। दुर्भाग्य से, मुझे ViewBuilder-कस्टम कंटेनरों के लिए कस्टम बनाने के उदाहरण नहीं मिले (शायद यह विकल्प बस मौजूद नहीं है), इसलिए हमें मानक एक का उपयोग करना होगा ForEach। चूंकि यह केवल इनपुट पर स्वीकार करता है RandomAccessCollection, और dict.keysयह नहीं है, हमें छंटाई का उपयोग करना होगा। इसलिए प्रोटोकॉल का समर्थन करने की आवश्यकता Comparableके KeyObject।

मैंने दो नेस्टेड ForEachकंटेनरों का इस्तेमाल किया । पहले मामले में, मैंने संग्रह आइटम के हैश का उपयोग किया (\.self) प्रत्येक नेस्टेड के पहचानकर्ता के रूप में View। मैं ऐसा कर सकता था शब्दकोश कुंजी को वैसे भी प्रोटोकॉल का समर्थन करना चाहिए Hashable। दूसरे मामले में, मैंने कक्षा में SomeObjectप्रोटोकॉल समर्थन जोड़ाIdentifiable। इसने मुझे एक संचार कुंजी को निर्दिष्ट करने की अनुमति नहीं दी - आईडी स्वचालित रूप से उपयोग की जाती है। मेरे मामले में, आईडी कहीं भी संग्रहीत नहीं है। हर बार एक ऑब्जेक्ट बनाया जाता है - चाहे वह कोड में निर्माण हो, या डेटाबेस क्वेरी का उपयोग करके पुनर्प्राप्त किया जाए - एक नई आईडी उत्पन्न होती है। एक इंटरफ़ेस के लिए, यह आवश्यक नहीं है। यह वस्तु के जीवन भर में नहीं बदलेगा अर्थात् सत्र, और यह इस आईडी के तहत प्रदर्शित करने के लिए पर्याप्त है। और अगर अगली बार आप आवेदन खोलते हैं तो इसकी एक अलग आईडी होगी - कुछ भी बुरा नहीं होगा। यदि आपकी ऑब्जेक्ट में पहले से ही प्रमुख फ़ील्ड हैं, तो आप बस आईडी की गणना कर सकते हैं, और इस प्रोटोकॉल और शॉर्टहैंड सिंटैक्स के समर्थन का उपयोग कर सकते हैं ForEach।

हमारे कंटेनर का उपयोग करने का एक उदाहरण:

 struct ContentView: View { let dict: [KeyObject: [SomeObject]] = [ KeyObject(name: "1st group") : [SomeObject(value: 1), SomeObject(value: 2), SomeObject(value: 3)], KeyObject(name: "2nd group") : [SomeObject(value: 4), SomeObject(value: 5), SomeObject(value: 6)], KeyObject(name: "3rd group") : [SomeObject(value: 7), SomeObject(value: 8), SomeObject(value: 9)] ] var body: some View { TreeView(data: dict, keyContent: {keyObject in Text("the key is: \(keyObject.name)") } ){valueObject in Text("value: \(valueObject.value)") } } } 

और कैनवस में स्क्रीन पर परिणाम:

जारी रखा जाए

अभी के लिए बस इतना ही। मैं उन सभी रेक को भी उजागर करना चाहता था, जिन पर मैंने कदम रखा, CoreDataस्विफ्टयूआई के साथ मिलकर इसका उपयोग करने की कोशिश कर रहा था, लेकिन, स्पष्ट रूप से, मुझे उम्मीद नहीं थी कि केवल स्विफ्टयूआई की मूल बातें में इतना समय लगेगा और लेख बहुत ही चमकदार होगा। इसलिए, जैसा वे कहते हैं, जारी रखा जाना चाहिए।

यदि आपके पास कुछ जोड़ने या ठीक करने के लिए है - टिप्पणियों में आपका स्वागत है। मैं लेख में महत्वपूर्ण टिप्पणियों को प्रतिबिंबित करने का प्रयास करूंगा।