Xcode: परियोजनाओं में हमारे अपने पुस्तकालयों की निर्भरता का प्रबंधन। कोकोपोड्स उन्नत

Cocoapods Xcode परियोजनाओं के लिए एक पुस्तकालय निर्भरता प्रबंधक है। मैं यह नहीं बताऊंगा कि किसी मौजूदा लाइब्रेरी को प्रोजेक्ट से जोड़ने के लिए इसका उपयोग कैसे किया जाए, हैबर पर इस लेख सहित पर्याप्त जानकारी है। मैं आपको बताऊंगा कि अगर आपको उस लाइब्रेरी की ज़रूरत नहीं है जो आपको सूची में चाहिए , या इससे भी बदतर, आप अपनी खुद की लाइब्रेरी बनाना चाहते हैं और, एक विकल्प के रूप में, इसे उपलब्ध न करें।

भाग I: पॉडफाइल के माध्यम से पुस्तकालयों को जोड़ना

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

1. लाइब्रेरी को समर्थित सूची से कनेक्ट करें:

   pod 'Reachability' pod 'AFNetworking/Reachability' pod 'JSONKit', '~> 1.4' 

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

    pod 'ZipKit', :podspec => 'ZipKit.podspec' 

   इसका उपयोग तब किया जा सकता है जब मौजूदा कोकोपॉड्स विनिर्देश आपको किसी भी तरह से सूट नहीं करते हैं (उदाहरण के लिए, लाइब्रेरी के लिए विनिर्देश में iOS 6.1 शामिल है, और आपके पास प्रोजेक्ट में 6.0 पर तैनाती लक्ष्य निर्धारित है)। हम अपने लिए विनिर्देश सहेजते हैं, इसे अपनी आवश्यकताओं के लिए संपादित करते हैं, इसे परियोजना की जड़ में सहेजते हैं - परिणामस्वरूप, सब कुछ आपके लिए काम करता है, और सार्वजनिक विनिर्देश में संभावित हानिकारक परिवर्तनों को जोड़ने की कोई आवश्यकता नहीं है।
   
   
3. लाइब्रेरी को स्थानीय पथ से कनेक्ट करें (विनिर्देश के साथ):

    pod 'SuperLibrary', :path => 'Submodules/SuperLibrary' 

   यह विकल्प पहले से ही अधिक दिलचस्प है, क्योंकि आप संयुक्त कोड (तोड़फोड़ बाहरी, गिट सबमॉड्यूल ...) के लिए पथ निर्दिष्ट कर सकते हैं। इस पद्धति के साथ, पुस्तकालय फाइलें इस पथ के लिंक के साथ परियोजना में शामिल हैं, जो हमें पुस्तकालय को संपादित करने और संस्करण नियंत्रण प्रणाली में परिवर्तन सहेजने की अनुमति देती है। हम बाद में इस पर और विस्तार से चर्चा करेंगे।
   
   
4. संस्करण नियंत्रण प्रणाली में स्थित पुस्तकालय (विनिर्देशन के साथ), या बस आर्काइव लिंक पर क्लिक करके कनेक्ट करें:

    pod 'SuperLibrary', :git => 'git@bitbucket.org:bestcompany/SuperLibrary.git', :branch => 'development' 

   पिछले पैराग्राफ से मुख्य अंतर यह है कि लाइब्रेरी के स्रोत कोड को संपादित करना अब संभव नहीं है (यह तकनीकी रूप से संभव है, हालांकि, निर्भरता स्थापित करते समय, फ़ाइलों की प्रतियां बस उस परियोजना में जोड़ दी जाएंगी जो मूल रूप से किसी भी तरह से संदर्भित नहीं होंगी और मूल फ़ाइलों पर कॉपी की जाएंगी जब निर्भरता बाद में अपडेट हो जाती है)

भाग II: हमारी अपनी लाइब्रेरी के लिए एक विनिर्देशन लिखना - "2 बाइट कैसे भेजें"

विनिर्देशन बनाना सरल है:

 pod spec create SuperLibrary 

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

 s.subspec 'Data' do |ds| ds.source_files = 'Data/*.{h,m}', 'Data/Categories/*.{h,m}', 'Data/Objects/*.{h,m}' ds.resources = 'Data/SuperLibrary.xcdatamodeld' ds.dependency 'MagicalRecord' ds.dependency 'SuperLibrary/Resources' end 

मॉड्यूल तक पहुंच MasterSpec / Subspec के माध्यम से है, अंदर कुछ मॉड्यूल एक ही विनिर्देश के अंदर दूसरों पर निर्भर हो सकते हैं, बहु-स्तरीय घोंसले के शिकार की अनुमति है। यह मॉड्यूल को निर्दिष्ट करने के लिए बना हुआ है जो डिफ़ॉल्ट रूप से जुड़ा होगा, उदाहरण के लिए

 s.default_subspec = 'Controllers' 

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

भाग III: आपकी विशिष्टता रिपोजिटरी "शतरंज और कवियों के साथ"

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

1. हम विनिर्देशों के लिए एक नया भंडार बना रहे हैं, जो आपकी टीम के लिए उपलब्ध होगा। बुरी खबर यह है कि विनिर्देशन भंडार के लिए केवल गिट समर्थित है। (अच्छी खबर यह है कि जीआईटी पर केवल एक कल्पना भंडार होना चाहिए, पुस्तकालय स्वयं भी अभी भी जीआईटी / एसवीएन या यहां तक ​​कि एक नियमित संग्रह लिंक के माध्यम से उपलब्ध होंगे)। कंसोल से एक साधारण कमांड के साथ इसे कोकोपोड्स में जोड़ें:

    pod repo add Private-Cocoapods git@bitbucket.org:bestcompany/cocoapods-specs.git 

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

भाग IV: हम सब कुछ एक साथ जोड़ते हैं, या हम विकास प्रक्रिया का निर्माण कैसे कर सकते हैं

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

 Pod::Spec.new do |s| s.name = "SuperLibrary" s.version = "1.0.5-dev" s.source = { :git => "ssh://git@bitbucket.org:bestcompany/my-super-library.git"} 

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

 Pod::Spec.new do |s| s.name = "SuperLibrary" s.version = "1.1.0" s.source = { :git => "ssh://git@bitbucket.org:bestcompany/my-super-library.git", :tag => "SuperLibrary_v1.1.0" } 

लाइब्रेरी रिपॉजिटरी में जो कुछ भी रहता है वह है कि अब संस्करण को देव पोस्टफिक्स (हमारे मामले में 1.1.1-देव) को हटाकर रिपॉजिटरी में सभी बदलाव भेजने के लिए सेट किया जाए।
विकास, एक नियम के रूप में, एक अंतहीन प्रक्रिया है, और पुस्तकालयों को संपादित करने की आवश्यकता बहुत बार उठती है। ऐसे मामलों के लिए, आप हमेशा लाइब्रेरी के वर्तमान संस्करण के लिंक को Git में सबमॉड्यूल (सब-वर्जन में बाहरी) के माध्यम से संग्रहित कर सकते हैं। उसी समय, एक स्थिर संस्करण को हमेशा किसी विशेष उत्पाद के पॉडफाइल में इंगित किया जाता है (पॉडस्पेक हमारे विनिर्देशों भंडार पर संग्रहीत किया जाता है), लेकिन वर्तमान संस्करण के बगल में एक टिप्पणी लाइन है:

  #pod 'SuperLibrary', :path => 'Submodules/SuperLibrary' pod 'SuperLibrary' 

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

PS कोकोपोड्स को लगातार अपडेट किया जाता है, बग्स को ठीक किया जाता है, नई सुविधाएँ (और नए बग) जोड़े जाते हैं। यदि कुछ ने आपके लिए काम करना बंद कर दिया है (और ऐसा होता है), तो आलसी मत बनो, कृपया कारण खोजें, और अगर यह कोकोपोड्स है, तो डेवलपर्स को बताएं ।