भाग 1. अपना कोकोपोड बनाने के लिए विस्तृत निर्देश

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

परिचय

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

प्रोजेक्ट पेज पर, अपने स्वयं के "पॉड" के निर्माण के सामान्य सिद्धांत का महत्वहीन रूप से वर्णन किया गया है । "फली" के विकास के लिए लेखकों द्वारा सुझाई गई निर्देशिका संरचना इस प्रकार है:

. ├── Classes └── ios └── osx ├── Resources ├── Project └── Podfile ├── LICENSE ├── Readme.markdown └── NAME.podspec 

क्या है:

• कक्षाएं - आईओएस और / या ओएस एक्स के लिए उप-निर्देशिकाओं में एक निर्देशिका जो आपके "पॉड" के स्रोत हैं
• संसाधन - चित्र, वीडियो, अन्य बायनेरी, कोर डेटा मॉडल, आदि।
• प्रोजेक्ट - एक नियम के रूप में आपके "पॉड" का उपयोग करने वाली एक परियोजना - एक नियम के रूप में - एक परियोजना जो आपके "पॉड" के उपयोग के उदाहरणों को दिखाती है, और यह यूनिट परीक्षणों के साथ अत्यधिक वांछनीय है
• पॉडफाइल - इस फाइल में, जैसा कि यह पहले से ही पता होना चाहिए, विभिन्न "पॉड्स" पर प्रोजेक्ट की निर्भरताएं इस मामले में, हमारे मामले में इंगित की जाती हैं।
• ओमित फाइलें जो उनके नाम से खुद के लिए बोलती हैं
• NAME.podspec - निर्मित "पॉड" का विनिर्देश a

"पॉड" प्रोजेक्ट बनाएं

तो चलिए शुरू करते हैं। बस मामले में, नमूना परियोजना GitHub पर है ।
MyCustomPod जैसे नाम के साथ अपना GitHub रिपॉजिटरी बनाएं।
आइए अपनी "पॉड" परियोजना बनाएं, इसके लिए हम टर्मिनल में निम्नलिखित दर्ज करते हैं:

 $ mkdir ~/Documents/PodSample $ cd ~/Documents/PodSample $ git init $ git remote add origin https://github.com/username/MyCustomPod.git $ touch LICENSE $ git add LICENSE && git commit -m "License file" $ git push -u origin master $ mkdir Classes 

क्या हो रहा है, इसका संक्षिप्त विवरण।
हम एक स्थानीय गिट रिपॉजिटरी बनाते हैं, इसे GitHub में बाँधते हैं, एक फाइल बनाते हैं और बनाते हैं जहाँ प्रोजेक्ट के लिए लाइसेंसिंग स्कीम का वर्णन किया जाएगा, और GutHub में परिवर्तन भेजें। हम कक्षाएं निर्देशिका बनाते हैं जिसमें "पॉड" का स्रोत कोड स्वयं झूठ होगा। हम वर्ग / ios और वर्ग / osx की उपनिर्देशिकाएँ नहीं बनाएंगे, क्योंकि हम अभी तक केवल एक ही प्लेटफॉर्म - आईओएस पर ध्यान केंद्रित करते हैं।

एक "कल्पना" बनाएँ

और फिर से सिद्धांत पर। प्रत्येक "पॉड" के अपने विनिर्देश होते हैं - "युक्ति", जो इसके मेटाडेटा का वर्णन करता है: नाम, संस्करण, लाइसेंस, प्लेटफॉर्म संस्करण पर निर्भरता, प्रयुक्त फ्रेमवर्क, अन्य "पॉड्स", स्रोत भंडार, एआरसी का उपयोग, आदि। यह सब NAME.podspec फ़ाइल को लिखा गया है।
.Podspec फ़ाइल डेवलपर "पॉड" द्वारा बनाई गई है और "विशेष" एस के एक विशेष भंडार में रखी गई है। एक मुख्य रिपॉजिटरी है जहां सभी "पॉड्स" हैं जो डिफ़ॉल्ट रूप से "लाइव" द्वारा उपलब्ध हैं, जैसे कि, उदाहरण के लिए, कुख्यात AFNetworking । आपका उपयोगी "पॉड" भी वहां दिखाई दे सकता है। अपने स्वयं के "स्पेक्स" रिपॉजिटरी बनाने और उपयोग करने का अवसर भी है, जिस तक पहुंच आपके द्वारा व्यक्तिगत रूप से विनियमित की जाती है।
लेकिन शुरुआत में वापस। टर्मिनल में अपना .podspec बनाने के लिए, निम्न कमांड दर्ज करें:

 $ pod spec create MyLibrary 

नतीजतन, वर्तमान निर्देशिका में हमें MyLibrary.podspec फ़ाइल के रूप में "युक्ति" टेम्पलेट मिलता है, जो यह बताता है कि प्रत्येक पैरामीटर के लिए क्या आवश्यक है। फ़ाइल प्रारूप का अधिक विस्तृत विवरण प्रोजेक्ट विकी पृष्ठ पर इंगित किया गया है ।

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

 Pod::Spec.new do |s| s.name = "MyLibrary" s.version = "0.0.1" s.summary = "Example of creating own pod." s.homepage = "https://github.com/username/MyCustomPod" s.license = { :type => 'MIT', :file => 'LICENSE' } s.author = { "Username" => "username@mail.domain" } s.platform = :ios, '7.0' s.source = { :git => "https://github.com/username/MyCustomPod.git", :tag => s.version.to_s } s.source_files = 'Classes/*.{h,m}' s.public_header_files = 'Classes/*.h' s.framework = 'Foundation' s.requires_arc = true end 

आइए उन रेखाओं पर चलते हैं, जिनके बारे में सटीक समझ की आवश्यकता होती है:

• संस्करण - हमारे "पॉड" का वर्तमान संस्करण
• लाइसेंस - एक ऐसी दुनिया में जहां कॉपीराइटर आधी सदी से काम कर रहे हैं, यह आपके काम के लाइसेंस के प्रकार को इंगित करने के लिए अत्यधिक उचित है
• लेखक - इस काम के लेखक के रूप में भी
• मंच - यहाँ हम संकेत देते हैं कि हमारा "पॉड" केवल न्यूनतम संस्करण 7.0 के iOS प्लेटफ़ॉर्म के लिए बनाया गया था, वैकल्पिक रूप से आप परिनियोजन_टार्ग पैरामीटर का उपयोग कर सकते हैं:

    s.ios.deployment_target = '7.0' 

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

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

  s.source_files = 'Classes/**/*.{h,m}' s.public_header_files = 'Classes/**/*.h' 

प्लेटफ़ॉर्म पैरामीटर के साथ लाइन हटाएं और निम्नलिखित पैरामीटर जोड़ें:

  s.ios.deployment_target = '7.0' s.osx.deployment_target = '10.8' 

एक प्रकार का वृक्ष "कल्पना"

लिंकिंग प्रक्रिया में .podspec फ़ाइल के सिंटैक्स की जांच करना, आवश्यक मापदंडों की उपस्थिति, पैरामीटर मानों की प्रासंगिकता और हमारे "पॉड" को संकलित करने का प्रयास करना शामिल है। एक तथाकथित "तेज" लिंक है, जहां .podspec फ़ाइल का सिंटैक्स और आवश्यक मापदंडों की उपस्थिति को बस चेक किया जाता है, जबकि "पॉड" रिपॉजिटरी और इसे संकलित करने के प्रयास डाउनलोड नहीं होते हैं।
हम परिणामी MyLibrary.specpod लिखते हैं और पहले --quick स्विच का उपयोग करके एक "क्विक" लिंक करते हैं:

 $ pod spec lint ~/Documents/PodSample/MyLibrary.podspec --quick 

आदर्श रूप में, कुछ इस तरह:

 $ pod spec lint ~/Documents/PodSample/MyLibrary.podspec --quick -> MyLibrary (0.0.1) Analyzed 1 podspec. MyLibrary.podspec passed validation. 

त्रुटियों की स्थिति में, प्रत्येक त्रुटि को काफी स्पष्ट रूप से टिप्पणी की जाती है और सुधार में समस्याएं नहीं होती हैं।

अगला, हमारे परिवर्तन के लिए प्रतिबद्ध करें:

 $ git add MyLibrary.podspec && git commit -m "Completed podspec file" 

सफल होने के लिए पूर्ण लिंकिंग के लिए, हम कुछ खाली फ़ाइलों का निर्माण करेंगे (अन्यथा हम एक त्रुटि देखेंगे - " ERROR | [iOS] The` source_files 'पैटर्न किसी भी फ़ाइल से मेल नहीं खाता था। "):

 $ touch Classes/AKClass.m $ touch Classes/AKClass.h $ git add Classes/AKClass.* && git commit -m "Empty files for successful lint" 

वर्तमान संस्करण संख्या के साथ टैग को नीचे रखें और GitHub पर हमारे "पॉड" को प्रकाशित करें:

 $ git tag "0.0.1" && git push origin master --tags 

Lintuem:

 $ pod spec lint ~/Documents/PodSample/MyLibrary.podspec 

यदि सब कुछ सही ढंग से एक समान चित्र देखा जाता है:

 $ pod spec lint ~/Documents/PodSample/MyLibrary.podspec -> MyLibrary (0.0.1) Analyzed 1 podspec. MyLibrary.podspec passed validation. 

हुर्रे! हमारा "पॉड" प्रोजेक्ट कॉन्फ़िगर किया गया है और इसमें त्रुटियां नहीं हैं।
जारी रखा जाए।

की योजना बनाई:
भाग 2. हम अपने "पॉड" को मॉड्यूल में विभाजित करते हैं। हम अपने स्वयं के विकास के लिए विदेशी "पॉड" का उपयोग करते हैं।
भाग 3. उसका "पॉड" प्रकाशन। साझा भंडार और व्यक्तिगत।