IOS एप्लिकेशन विकसित करने के लिए सर्वोत्तम अभ्यास और उपकरण

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

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

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

Cocoapods

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

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

Swiftlint

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

R.swift

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

• पूरी तरह से टाइप किया गया - कम जातियों और मान्यताओं के बारे में जो विधि वापस आ जाएगी
• संकलित समय की जाँच - अब कोई अमान्य लाइनें नहीं हैं जो एप्लिकेशन को कोड निष्पादन के दौरान चलने से रोकती हैं
• स्वतः पूर्ण - कोई नाम छवि / nib / स्टोरीबोर्ड फिर से अनुमान लगाने की आवश्यकता नहीं है

आधिकारिक स्ट्रिंग API का उपयोग करके निम्नलिखित कोड पर विचार करें:

let icon = UIImage(named: “custom-icon”) 

यदि आपने छवि के नाम पर कोई गलती की है, तो आपको शून्य मिलेगा। यदि आपकी टीम का कोई सदस्य छवि संसाधन का नाम बदलता है, तो यह कोड शून्य वापस आ जाएगा या यदि आप छवि को विस्तारित करने के लिए मजबूर करते हैं तो इसका निष्पादन रोक दिया जाएगा। R.swift का उपयोग करते समय, यह इस तरह दिखता है:

 let icon = R.image.customIcon() 

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

R.swift Cocoapods का उपयोग करके स्थापित किया गया है और संकलन चरण में टेम्पलेट में एकीकृत करता है और प्रत्येक संकलन के लिए स्विफ्ट शेल कक्षाएं उत्पन्न करेगा। इसका मतलब है कि यदि आप एक फ़ाइल / छवि / स्थानीयकरण / फ़ॉन्ट / रंग / पेन आदि जोड़ते हैं, तो यह सब परियोजना को संकलित करने के बाद R.swift के माध्यम से उपलब्ध होगा।

परीक्षणों के लिए अलग AppDelegate फ़ाइल

बहुत बार वे परीक्षण चलाते समय एक अलग TestAppDelegate वर्ग का उपयोग करने के अच्छे अभ्यास के बारे में भूल जाते हैं। यह एक अच्छा विचार क्यों है? आमतौर पर, एप्लिकेशन शुरू होने पर AppDelegate वर्ग बहुत काम करता है। इसमें विंडो कॉन्फ़िगरेशन तर्क हो सकता है, एप्लिकेशन उपयोगकर्ता इंटरफ़ेस के मूल प्रदर्शन को कॉन्फ़िगर कर सकता है, सूचनाएं प्राप्त करने के लिए पंजीकरण तर्क निष्पादित कर सकता है, डेटाबेस कनेक्शन सेटअप कोड हो सकता है और यहां तक ​​कि कभी-कभी सर्वर एपीआई कॉल भी कर सकता है। यूनिट परीक्षणों के दुष्प्रभाव नहीं होने चाहिए। आप वास्तव में रैंडम एपीआई कॉल नहीं करना चाहते हैं और केवल यूनिट टेस्ट चलाने के लिए अपने एप्लिकेशन की संपूर्ण यूजर इंटरफेस संरचना को अनुकूलित कर सकते हैं?

TestAppDelegate भी कोड पाने के लिए एक उपयुक्त विकल्प है जिसे आप टेस्ट सूट के निष्पादन के दौरान केवल एक बार चलाना चाहते हैं। इसमें वह कोड हो सकता है जो नकली वस्तुएं, नेटवर्क अनुरोध स्टब्स आदि उत्पन्न करता है।

टेम्पलेट में main.swift फ़ाइल है, जो अनुप्रयोग के लिए मुख्य प्रविष्टि बिंदु है। इस फ़ाइल में ऐसे तरीके हैं जो एप्लिकेशन के वातावरण का परीक्षण करते हैं, और यदि यह एक परीक्षण वातावरण है, तो वे TestAppDelegate कहते हैं।

संकलक प्रदर्शन रूपरेखा झंडे

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

तब एकमात्र समाधान परियोजना के संकलन समय को प्रोफाइल करने और अपने कोड को बदलने की कोशिश करना था ताकि कंपाइलर तेजी से काम करे। ऐसी समस्याओं को हल करने में मदद करने के लिए, Apple कुछ अनौपचारिक संकलक झंडे पेश करता है जो डेवलपर को चेतावनी देते हैं कि विधि निकाय को संकलित करने या अभिव्यक्ति के प्रकार को निर्धारित करने में बहुत लंबा समय लगता है। मैंने आपके आवेदन के लंबे संकलन समय के बारे में चेतावनी देने के लिए इन झंडों को टेम्पलेट प्रोजेक्ट में जोड़ा।

आजकल, संकलन समय में काफी कमी आई है, और डेवलपर्स को शायद ही कभी संकलन समय को कम करने के लिए अपने कोड का अनुकूलन करना पड़ता है। लेकिन फिर भी इस समस्या को हल करने की कोशिश करने से पहले ही सब कुछ जानना बेहतर होता है जब परियोजना बहुत बड़ी हो जाती है।

देव / मंचन / उत्पादन विन्यास

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

एक iOS प्रोजेक्ट में कई वातावरणों का समर्थन करने का एक तरीका प्रोजेक्ट स्तर पर कॉन्फ़िगरेशन जोड़ना है।


परियोजना स्तर विन्यास

कॉन्फ़िगरेशन परिभाषित करने के बाद, आप प्रत्येक वातावरण के लिए चर युक्त एक कॉन्फ़िगरेशन .plist फ़ाइल बना सकते हैं।


Configuration.plist

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



फिर आपको Info.plist प्रोजेक्ट फ़ाइल में एक और संपत्ति जोड़ने की आवश्यकता है। इस संपत्ति के मूल्य को वर्तमान कॉन्फ़िगरेशन के नाम पर रनटाइम पर गतिशील रूप से प्रतिस्थापित किया जाएगा।


यह सब टेम्पलेट में पूर्व-कॉन्फ़िगर किया गया है।

यह केवल एक वर्ग लिखने के लिए बना हुआ है जो विधानसभा योजना में चयनित कॉन्फ़िगरेशन के आधार पर इन चरों को चला सकता है। टेम्प्लेट में कॉन्फ़िगरेशन प्रबंधक वर्ग होता है, जो वर्तमान वातावरण के लिए चर को पुनः प्राप्त कर सकता है। आप यह देखने के लिए भी काम कर सकते हैं कि यह कैसे काम करता है।

रीडमी

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

Gitignore

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

बाहरी लिंक और सूचनाओं को संभालने के लिए आधार कक्षाएं

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

निष्कर्ष

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