Unity3D: iOS ऐप डेलिगेट को संशोधित करें

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

जो लोग अंतिम रास्ता चुनते हैं (हालांकि, मुझे लगता है, वे खुद जानते हैं), इस कठिन और कांटेदार रास्ते पर कई समस्याओं का सामना करेंगे:

• iOS एक बिल्कुल अपरिचित और अलग-थलग पारिस्थितिक तंत्र है, जो अपने तरीके से विकसित हो रहा है। कम से कम, आपको यह समझने में काफी समय देना होगा कि आप आवेदन कैसे प्राप्त कर सकते हैं, और जहां स्वचालित रूप से उत्पन्न Xcode परियोजना के आंत्र में यूनिटी 3 डी इंजन कोड के मूल घटक के साथ बातचीत करने के लिए कोड है।
• ऑब्जेक्टिव-सी एक काफी अलग और छोटी-सी प्रोग्रामिंग भाषा है। और जब यह यूनिटी 3 डी एप्लिकेशन के सी ++ कोड के साथ बातचीत करने की बात आती है, तो इस भाषा का "बोली", जिसे ऑब्जेक्टिव-सी ++ कहा जाता है, दृश्य में प्रवेश करता है। उसके बारे में बहुत कम जानकारी है, इसमें से अधिकांश प्राचीन और अभिलेखीय है।
• यूनिटी 3 डी और आईओएस एप्लीकेशन के बीच पारस्परिक क्रिया का प्रोटोकॉल खराब वर्णित है। आपको केवल नेटवर्क उत्साही लोगों के ट्यूटोरियल पर भरोसा करना चाहिए जो लिखते हैं कि सबसे सरल देशी प्लगइन कैसे विकसित किया जाए। उसी समय, कुछ लोग कुछ जटिल करने की आवश्यकता से उत्पन्न गहरे मुद्दों और समस्याओं को छूते हैं।

जो लोग बिल्ली के नीचे, एक iOS एप्लिकेशन के साथ यूनिटी 3 डी की बातचीत के तंत्र के बारे में सीखना चाहते हैं।

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

IOS और एप्लिकेशन के बीच सहभागिता

एक परिचय के रूप में, आइए देखें कि सिस्टम के साथ आवेदन की बातचीत को आईओएस में कैसे लागू किया जाता है और इसके विपरीत। योजनाबद्ध रूप से, iOS एप्लिकेशन का लॉन्च इस तरह दिखता है:



कोड के दृष्टिकोण से इस तंत्र का अध्ययन करने के लिए, "सिंगल व्यू ऐप" टेम्पलेट का उपयोग करके Xcode में बनाया गया एक नया एप्लिकेशन उपयुक्त है।



इस टेम्पलेट को चुनने से, आउटपुट आपको सरलतम iOS एप्लिकेशन देगा जो डिवाइस या एमुलेटर पर चल सकता है और एक सफेद स्क्रीन दिखा सकता है। Xcode सहायक रूप से एक प्रोजेक्ट बनाएगा जिसमें स्रोत कोड के साथ केवल 5 फाइलें होंगी (और उनमें से 2 में। Codec फ़ाइलें हैं।) और कई सहायक फाइलें हैं जो हमारे लिए दिलचस्प नहीं हैं (टाइपसेटिंग, कॉन्फ़िगर, आइकन)।



आइए देखें कि स्रोत कोड फाइलें किसके लिए जिम्मेदार हैं:

• ViewController.m / ViewController.h - हमारे लिए बहुत दिलचस्प स्रोत कोड नहीं है। चूंकि आपके आवेदन में एक दृश्य है (जिसे कोड द्वारा दर्शाया नहीं गया है, लेकिन स्टोरीबोर्ड का उपयोग करके), आपको नियंत्रक वर्ग की आवश्यकता होगी, जो इस दृश्य को नियंत्रित करेगा। सामान्य तौर पर, इस तरह से Xcode हमें MVC पैटर्न का उपयोग करने के लिए प्रोत्साहित करता है। Unity3D बनाने वाली परियोजना में ये स्रोत फ़ाइलें नहीं होंगी।
• AppDelegate.m / AppDelegate.h आपके आवेदन का प्रतिनिधि है। एप्लिकेशन में रुचि का बिंदु जहां कस्टम एप्लिकेशन कोड का काम शुरू होता है।
• main.m - आवेदन का प्रारंभिक बिंदु। किसी भी C / C ++ एप्लिकेशन के तरीके में, इसमें मुख्य फ़ंक्शन होता है, जिसके साथ कार्यक्रम शुरू होता है।

अब, कोड को main.m फाइल से शुरू करते हुए देखते हैं:

int main(int argc, char * argv[]) { //1 @autoreleasepool { //2 return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); // 3 } } 

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

चलो लाइन 3 पर चलते हैं । इसे UIApplicationMain फ़ंक्शन कहते हैं। कार्यक्रम स्टार्टअप मापदंडों (argc, argv) को इसे पास किया जाता है। फिर, इस फ़ंक्शन में, यह इंगित किया जाता है कि आवेदन के मुख्य वर्ग के रूप में किस वर्ग का उपयोग करना है, इसका उदाहरण बनाया गया है। और, अंत में, यह इंगित किया जाता है कि आवेदन प्रतिनिधि के रूप में किस वर्ग का उपयोग करना है, इसका उदाहरण बनाया गया है, आवेदन वर्ग उदाहरण और उसके प्रतिनिधि के बीच कनेक्शन कॉन्फ़िगर किए गए हैं।

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

एप्लिकेशन डेलिगेट बनाएं

फ़ंक्शन डेलिगेट में एप्लिकेशन प्रतिनिधि के रूप में उपयोग करने के लिए किस वर्ग का एक संकेत है

 NSStringFromClass([AppDelegate class]) 

आइए इस कॉल का विश्लेषण भागों में करते हैं।

 [AppDelegate class] 

यह निर्माण AppDelegate वर्ग (जो AppDelegate.h / .m में घोषित किया गया है) की एक वस्तु देता है, और NSStringFromClass फ़ंक्शन एक स्ट्रिंग के रूप में वर्ग का नाम देता है। हम केवल UIApplicationMain फ़ंक्शन के प्रतिनिधि के रूप में बनाए जाने और उपयोग किए जाने वाले वर्ग के स्ट्रिंग नाम को पास करते हैं। एक बेहतर समझ के लिए, main.m फ़ाइल में लाइन 3 को निम्नलिखित द्वारा प्रतिस्थापित किया जा सकता है:

 return UIApplicationMain(argc, argv, nil, @"AppDelegate"); 

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

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

आवेदन प्रतिनिधि

IOS के साथ एप्लिकेशन का सभी इंटरैक्शन UIApplication वर्ग में होता है। यह वर्ग बहुत सारी जिम्मेदारियां लेता है - घटनाओं की उत्पत्ति, अनुप्रयोग की स्थिति और बहुत कुछ के बारे में सूचित करता है। अधिकांश भाग के लिए, उनकी भूमिका सूचित कर रही है। लेकिन जब सिस्टम में कुछ होता है, तो हमें किसी तरह से इस परिवर्तन का जवाब देने में सक्षम होना चाहिए, ताकि कुछ प्रकार की कस्टम कार्यक्षमता हो सके। यदि UIApplication वर्ग का एक उदाहरण ऐसा करता है, तो यह अभ्यास ईश्वरीय वस्तु नामक एक दृष्टिकोण से मेल खाने लगेगा। इसलिए, इस वर्ग को अपनी जिम्मेदारियों से मुक्त करने के बारे में सोचने लायक है।

यह इन उद्देश्यों के लिए है कि आईओएस पारिस्थितिकी तंत्र एक आवेदन प्रतिनिधि के रूप में इस तरह की चीज का उपयोग करता है। नाम से ही, हम यह निष्कर्ष निकाल सकते हैं कि हम डेलिगेशन जैसे डिजाइन पैटर्न के साथ काम कर रहे हैं। संक्षेप में, हम केवल आवेदन प्रतिनिधि के लिए आवेदन की कुछ घटनाओं की प्रतिक्रिया को संसाधित करने के लिए जिम्मेदारी हस्तांतरण करते हैं। इस प्रयोजन के लिए, हमारे उदाहरण में, AppDelegate वर्ग बनाया गया था जिसमें हम कस्टम कार्यक्षमता लिख ​​सकते हैं, जबकि UIApplication वर्ग को ब्लैक बॉक्स मोड में काम करने के लिए छोड़ देते हैं। आर्किटेक्चर डिज़ाइन की सुंदरता के मामले में यह दृष्टिकोण किसी के लिए विवादास्पद लग सकता है, लेकिन आईओएस लेखक खुद हमें इस दृष्टिकोण और डेवलपर्स के विशाल बहुमत (यदि सभी नहीं) का उपयोग करने के लिए जोर दे रहे हैं।

आवेदन प्रतिनिधि के कार्य के दौरान यह देखने के लिए कि आवेदन प्रतिनिधि को एक विशेष संदेश प्राप्त होता है, आरेख पर एक नज़र डालें:



पीले रंग की आयतें आवेदन के जीवन की कुछ घटनाओं (एप्लिकेशन जीवनचक्र) के जवाब में एक या किसी अन्य प्रतिनिधि विधि के कॉल का संकेत देती हैं। यह आरेख केवल आवेदन की स्थिति में परिवर्तन से संबंधित घटनाओं को दिखाता है और प्रतिनिधि की जिम्मेदारी के कई अन्य पहलुओं को प्रतिबिंबित नहीं करता है, जैसे कि सूचनाओं को स्वीकार करना या फ्रेमवर्क के साथ बातचीत करना।

यहां कुछ उदाहरण दिए गए हैं, जहां हमें Unity3D से एक आवेदन प्रतिनिधि तक पहुंचने की आवश्यकता हो सकती है:

1. धक्का और स्थानीय सूचनाओं को संभालना
2. एनालिटिक्स में लॉगिंग एप्लिकेशन लॉन्च इवेंट
3. अनुप्रयोग को कैसे लॉन्च किया जाए, इसका निर्धारण - "साफ" या बाहर निकलने की पृष्ठभूमि
4. एप्लिकेशन को कैसे लॉन्च किया गया था - अधिसूचना के लिए tach द्वारा, होम स्क्रीन क्विक एक्ट्स का उपयोग करके या सिर्फ अनचाहे पर tach द्वारा
5. वॉचकीट या हेल्थकेट के साथ बातचीत
6. दूसरे एप्लिकेशन से URL खोलना और संसाधित करना। यदि यह URL आपके एप्लिकेशन पर लागू होता है, तो आप सिस्टम को ब्राउज़र में उस URL को खोलने देने के बजाय इसे अपने एप्लिकेशन में संसाधित कर सकते हैं

यह परिदृश्यों की पूरी सूची नहीं है। इसके अलावा, यह ध्यान देने योग्य है कि प्रतिनिधि अपने मूल प्लगइन्स में कई विश्लेषिकी और विज्ञापन प्रणालियों को संशोधित करते हैं।

यूनिटी 3 डी एक एप्लिकेशन प्रतिनिधि को कैसे लागू करता है

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

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

 - (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions 

UnityAppController क्लास के कोड में। इस पद्धति को एप्लिकेशन इनिशियलाइज़ेशन के समय कहा जाता है, जब आप अपने कस्टम कोड पर नियंत्रण स्थानांतरित कर सकते हैं। इस विधि के अंदर, उदाहरण के लिए, आप निम्न पंक्तियाँ पा सकते हैं:

 UnityInitApplicationNoGraphics([[[NSBundle mainBundle] bundlePath] UTF8String]); [self selectRenderingAPI]; [UnityRenderingView InitializeForAPI: self.renderingAPI]; _window = [[UIWindow alloc] initWithFrame: [UIScreen mainScreen].bounds]; _unityView = [self createUnityView]; [DisplayManager Initialize]; _mainDisplay = [DisplayManager Instance].mainDisplay; [_mainDisplay createWithWindow: _window andView: _unityView]; [self createUI]; [self preStartUnity]; 

यहां तक ​​कि इन चुनौतियों के बारे में विवरण में जाने के बिना, आप अनुमान लगा सकते हैं कि वे काम के लिए यूनिटी 3 डी तैयार करने से संबंधित हैं। यह निम्नलिखित परिदृश्य को दर्शाता है:

1. मुख्य कार्य main.mm से कहा जाता है
2. आवेदन और उसके प्रतिनिधि के उदाहरण वर्ग बनाए जाते हैं।
3. एप्लिकेशन प्रतिनिधि तैयार करता है और यूनिटी 3 डी इंजन लॉन्च करता है
4. आपका कस्टम कोड काम करना शुरू कर देता है। यदि आप il2cpp का उपयोग करते हैं, तो आपका कोड C # से IL में और फिर C ++ कोड से अनुवादित किया जाता है, जो सीधे Xcode प्रोजेक्ट में मिलता है।

यह स्क्रिप्ट बहुत सरल और तार्किक लगती है, लेकिन यह अपने साथ एक संभावित समस्या लेकर आती है: यदि हम यूनीटी 3 डी में काम करते समय सोर्स कोड तक पहुंच नहीं रखते हैं, तो हम एप्लिकेशन प्रतिनिधि को कैसे संशोधित कर सकते हैं?

अनुप्रयोग प्रतिनिधि को संशोधित करने के लिए प्रभावित यूनिटी 3 डी

हम AppDelegateListener.mm/.h फाइलों पर एक नज़र डाल सकते हैं। उनमें मैक्रोज़ होते हैं जो आपको एप्लिकेशन प्रतिनिधि के लिए इवेंट श्रोता के रूप में किसी भी वर्ग को पंजीकृत करने की अनुमति देते हैं। यह एक अच्छा दृष्टिकोण है, हमें मौजूदा कोड को संशोधित करने की आवश्यकता नहीं है, लेकिन बस एक नया जोड़ें। लेकिन इसमें एक महत्वपूर्ण कमी है: सभी एप्लिकेशन इवेंट समर्थित नहीं हैं और एप्लिकेशन लॉन्च के बारे में जानकारी प्राप्त करने का कोई तरीका नहीं है।

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

UnityAppController.h फ़ाइल, चर और विधियों की घोषणा करने के अलावा, एक मैक्रो परिभाषा भी शामिल है:

 #define IMPL_APP_CONTROLLER_SUBCLASS(ClassName) ... 

यह मैक्रो सिर्फ आवेदन प्रतिनिधि को ओवरराइड करना संभव बनाता है। ऐसा करने के लिए, आपको कुछ सरल कदम उठाने होंगे:

1. ऑब्जेक्टिव-सी में अपना खुद का एप्लीकेशन प्रतिनिधि लिखें
2. स्रोत कोड के अंदर कहीं निम्नलिखित पंक्ति जोड़ें

    IMPL_APP_CONTROLLER_SUBCLASS(___) 

3. इस स्रोत को अपने यूनिटी 3 डी प्रोजेक्ट के प्लगइन्स / आईओएस फ़ोल्डर के अंदर रखें

अब आपको एक परियोजना प्राप्त होगी जिसमें मानक यूनिटी 3 डी एप्लिकेशन प्रतिनिधि को आपके कस्टम एक के साथ बदल दिया जाएगा।

प्रतिनिधि प्रतिस्थापन मैक्रो कैसे काम करता है

आइए मैक्रो के पूर्ण स्रोत कोड को देखें:

 #define IMPL_APP_CONTROLLER_SUBCLASS(ClassName) ... @interface ClassName(OverrideAppDelegate) \ { \ } \ +(void)load; \ @end \ @implementation ClassName(OverrideAppDelegate) \ +(void)load \ { \ extern const char* AppControllerClassName; \ AppControllerClassName = #ClassName; \ } \ @end 

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

आधिकारिक दस्तावेज का कहना है कि लोड एक विशेष विधि है जिसे एप्लिकेशन लॉन्च के बहुत प्रारंभिक चरण में प्रत्येक वर्ग (विशेष रूप से वर्ग, इसके उदाहरणों) के लिए एक बार बुलाया जाता है, इससे पहले कि मुख्य फ़ंक्शन को भी कहा जाता है। एप्लिकेशन स्टार्टअप पर ऑब्जेक्टिव-सी (रनटाइम) रनटाइम वातावरण उन सभी वर्गों को पंजीकृत करेगा, जिनका उपयोग एप्लिकेशन ऑपरेशन के दौरान किया जाएगा और इसे लागू करने पर लोड विधि को कॉल करेगा। यह पता चला है कि हमारे आवेदन में किसी भी कोड की शुरुआत से पहले, चर AppControllerClassName आपकी कक्षा में जोड़ा जाएगा।

तब आप सोच सकते हैं: "और इस चर के होने का क्या मतलब है अगर इसे विधि के अंदर घोषित किया जाता है और इस विधि से बाहर निकलने पर मेमोरी से हटा दिया जाएगा?"। इस सवाल का जवाब ऑब्जेक्टिव-सी की सीमा से थोड़ा परे है।

और C ++ कहाँ है?

आइए इस चर की घोषणा पर एक और नज़र डालें

 extern const char* AppControllerClassName; 

इस घोषणा में केवल एक चीज जो समझ से बाहर हो सकती है, वह है बाहरी संशोधक। यदि आप इस संशोधक को शुद्ध उद्देश्य-सी में उपयोग करने का प्रयास करते हैं, तो Xcode एक त्रुटि देगा। तथ्य यह है कि यह संशोधक ऑब्जेक्टिव-सी का हिस्सा नहीं है, यह C ++ में लागू किया गया है। वस्तुनिष्ठ-सी को यह कहकर स्पष्ट रूप से वर्णित किया जा सकता है कि यह "वर्गों के साथ सी भाषा" है। यह सी भाषा का एक विस्तार है और उद्देश्य-सी कोड के साथ प्रतिच्छेदित सी कोड के असीमित उपयोग की अनुमति देता है।

हालांकि, बाहरी और अन्य सी ++ सुविधाओं का उपयोग करने के लिए, आपको कुछ चाल करने की आवश्यकता है - उद्देश्य-सी ++ का उपयोग करें। इस भाषा के बारे में व्यावहारिक रूप से कोई जानकारी नहीं है, इस तथ्य के कारण कि यह सिर्फ ऑब्जेक्टिव-सी कोड है जो C ++ कोड को डालने की अनुमति देता है। संकलक के लिए यह विचार करने के लिए कि कुछ स्रोत फ़ाइल को उद्देश्य-सी ++ के रूप में संकलित किया जाना चाहिए, और उद्देश्य-सी नहीं, आपको बस इस फ़ाइल के विस्तार को .m से .mm में बदलने की आवश्यकता है।

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

वापस मुख्य करने के लिए

हम याद करते हैं कि पहले क्या कहा गया था - वर्ग के नाम को निर्दिष्ट करके आवेदन प्रतिनिधि बनाया गया है। यदि प्रतिनिधि को नियमित Xcode प्रोजेक्ट टेम्पलेट में निरंतर मान [myClass वर्ग] का उपयोग करके बनाया गया था, तो, जाहिर है, यूनिटी के लोगों ने फैसला किया कि इस मूल्य को एक चर में लपेटा जाना चाहिए। वैज्ञानिक प्रहार विधि का उपयोग करते हुए, हम यूनिटी 3 डी द्वारा उत्पन्न एक्सकोड परियोजना को लेते हैं और मुख्य.एमएम फ़ाइल पर जाते हैं।

इसमें हम पहले की तुलना में अधिक जटिल कोड देखते हैं, इस कोड का हिस्सा अनावश्यक रूप से गायब है:

 // WARNING: this MUST be c decl (NSString ctor will be called after +load, so we cant really change its value) const char* AppControllerClassName = "UnityAppController"; int main(int argc, char* argv[]) { ... UIApplicationMain(argc, argv, nil, [NSString stringWithUTF8String: AppControllerClassName]); } return 0; } 

यहां हम इस बहुत ही चर की घोषणा, और इसकी मदद से एप्लिकेशन प्रतिनिधि के निर्माण को देखते हैं।
यदि हमने एक कस्टम प्रतिनिधि बनाया है, तो आवश्यक चर मौजूद है और पहले से ही मायने रखता है - हमारी कक्षा का नाम। मुख्य फ़ंक्शन से पहले वेरिएबल को घोषित करना और शुरू करना यह सुनिश्चित करता है कि इसका डिफ़ॉल्ट मान है - UnityAppController।

अब इस निर्णय के साथ सब कुछ बहुत स्पष्ट होना चाहिए।

मैक्रो की समस्या

बेशक, अधिकांश स्थितियों के लिए, इस मैक्रो का उपयोग करना एक महान समाधान है। लेकिन यह ध्यान देने योग्य है कि इसमें एक बड़ा नुकसान है: आपके पास एक से अधिक कस्टम प्रतिनिधि नहीं हो सकते। ऐसा इसलिए होता है क्योंकि यदि 2 या अधिक वर्ग IMPL_APP_CONTROLLER_SUBCLASS मैक्रो (ClassName) का उपयोग करते हैं, तो उनमें से पहले के लिए हमें जिस चर की आवश्यकता होगी उसका मान असाइन किया जाएगा, और आगे के असाइनमेंट को अनदेखा किया जाएगा। और यह चर एक स्ट्रिंग है, अर्थात, इसे एक से अधिक मान नहीं सौंपा जा सकता है।

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

और बात यह हो सकती है कि विज्ञापन या एनालिटिक्स प्लग इन में से कोई एक ही मैक्रो का उपयोग करता है। उदाहरण के लिए, AppsFlyer से प्लगइन में इस मैक्रो का उपयोग किया जाता है।

कई घोषणाओं के मामले में बाहरी चर का मूल्य क्या है?

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

आवेदन का सार सरल है। 2 वर्ग ए और बी हैं, दोनों वर्गों में बाहरी चर AexternVar घोषित किया गया है, इसे एक विशिष्ट मूल्य सौंपा गया है। कक्षाओं में चर के मान अलग-अलग सेट किए जाते हैं। मुख्य फ़ंक्शन में, इस चर का मान लॉग होता है। यह प्रायोगिक रूप से पाया गया कि चर का मूल्य उस क्रम पर निर्भर करता है जिसमें परियोजना में स्रोत जोड़े जाते हैं। अनुप्रयोग निष्पादन के दौरान ऑब्जेक्टिव-सी रनटाइम कक्षाओं को पंजीकृत करने का क्रम इस पर निर्भर करता है। यदि आप प्रयोग दोहराना चाहते हैं, तो परियोजना खोलें और प्रोजेक्ट सेटिंग्स में बिल्ड चरणों का चयन करें। चूंकि परियोजना परीक्षण और छोटी है, इसलिए इसमें केवल 8 स्रोत कोड हैं। वे सभी कंपाइल सोर्स लिस्ट में बिल्ड चरणों टैब पर मौजूद हैं।



यदि इस सूची में वर्ग A का स्रोत वर्ग B के स्रोत से अधिक है, तो चर वर्ग B से मान लेगा। अन्यथा, चर वर्ग A से एक मान लेगा।

बस कल्पना करें कि यह सैद्धांतिक रूप से कितनी समस्याएं पैदा कर सकता है एक छोटी सी बारीकियों। विशेष रूप से यदि परियोजना बड़ी है, तो स्वचालित रूप से उत्पन्न होती है और आप यह नहीं जानते हैं कि इस तरह के चर को किन वर्गों में घोषित किया जाता है।

समस्या हल करना

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

समस्या का एक और समाधान

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

बात छोटी है, यह यह निर्धारित करने के लिए बनी हुई है कि यह कैसे बनाया जा सकता है यूनिटी 3 डी का उपयोग करते हुए, एक निर्माण मशीन का उपयोग करके एक परियोजना के निर्माण की क्षमता को छोड़कर। समाधान एल्गोरिथ्म इस प्रकार है:

1. हम कस्टम प्रतिनिधियों को आवश्यक मात्रा में लिखते हैं, प्लगइन्स के तर्क को विभिन्न वर्गों में विभाजित करते हैं, एसओएलआईडी के सिद्धांतों का अवलोकन करते हैं और परिष्कार का सहारा नहीं लेते हैं।
2. UnityAppController XCode . UnityAppController .
3. UnityAppController Unity .
4. XCode UnityAppController ,

इस सूची में सबसे कठिन वस्तु निस्संदेह अंतिम है। हालाँकि, इस सुविधा को यूनिटी 3 डी में पोस्ट-प्रोसेस बिल्ड स्क्रिप्ट का उपयोग करके लागू किया जा सकता है। इस तरह की स्क्रिप्ट को एक सुंदर रात लिखा गया था, आप इसे गीथहब पर देख सकते हैं ।

यह पोस्ट-प्रोसेस उपयोग करने में काफी आसान है, इसे एकता परियोजना में चुनें। इंस्पेक्टर विंडो में देखें और वहां एक फ़ील्ड देखें जिसे न्यूडेलेगेट फ़ील कहा जाता है। अपने संशोधित UnityAppController को इस क्षेत्र में खींचें और छोड़ें और सहेजें।



आईओएस परियोजना का निर्माण करते समय, मानक प्रतिनिधि को एक संशोधित एक से बदल दिया जाएगा, और कोई मैनुअल हस्तक्षेप की आवश्यकता नहीं है। अब, जब परियोजना में नए कस्टम प्रतिनिधियों को जोड़ते हैं, तो आपको केवल अपने यूनिटी प्रोजेक्ट में आस-पास पड़े हुए UnityAppController विकल्प को संशोधित करने की आवश्यकता होती है।

पुनश्च

अंत तक जो भी मिला, उसके लिए धन्यवाद, लेख वास्तव में बहुत लंबा निकला। मुझे उम्मीद है कि चित्रित जानकारी सहायक है।