गुणवत्ता iOS अनुप्रयोग बनाने के लिए 9 सिद्धांत

सिद्धांत ह्योकू की प्रसिद्ध कार्यप्रणाली पर आधारित हैं, अय्योस डेवलपमेंट (कंटेनरों की कमी जो कि तैनाती को पूरा करने और धीमा करने में कई दिन लगते हैं , की वास्तविकताओं के अनुकूल है, Xcode केवल एक खसखस ​​पर काम करता है)।

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

टीएल, डॉ

• निर्भरताएँ : स्पष्ट रूप से और विशेष रूप से निर्दिष्ट (Xcode का संस्करण, CocoaPods, podfile में निर्भरता का संस्करण) होना चाहिए। इससे नए डेवलपर के लिए किसी भी मैक पर बिल्ड खेलना संभव हो जाता है। 6 महीने पहले उपयोग किए गए असेंबली को भी दोहराएं।
• कॉन्फ़िगरेशन : कोड में कोई कॉन्फ़िगरेशन, एप्लिकेशन और हवा द्वारा अपडेट करने की क्षमता के साथ आता है
• अनुप्रयोग विकास / कार्य समता : जितना संभव हो सके विकास, मंचन और उत्पादन वातावरण को बनाए रखें
• तैनाती : तैनाती को स्वचालित करें ताकि आप इसे किसी भी मशीन से जारी कर सकें।
• स्थानीय बनाम बेक : अपने iOS ऐप को सार्वभौमिक रखें ताकि आप जब भी संभव हो बिना बैकएंड के काम कर सकें
• पिछड़े संगत एपीआई : प्रत्येक उपयोगकर्ता को नवीनतम संस्करण में अपग्रेड करने के लिए मत सोचो
• अनुप्रयोग संस्करण : स्वचालित संस्करण और उन्नयन का निर्माण
• रोलबैक : रोलबैक विधानसभा जो समस्याओं का कारण बनती है
• डेटा स्टोरेज : डेटा स्टोरेज के लिए एप्पल की सिफारिशों का पालन करें

पर निर्भर करता है

आवेदन निर्भरता घोषणा प्रकट का उपयोग करके पूरी तरह से और सही ढंग से अपनी सभी निर्भरता की घोषणा करता है।
इसमें स्विफ्ट, Xcode, CocoaPods, Carthgae और Fastlane का एक विशिष्ट संस्करण शामिल है। इसके अलावा, पॉडफाइल और कार्टिफाइल में सभी निर्भरताएं एक विशिष्ट संस्करण को निर्दिष्ट करना चाहिए।

स्पष्ट रूप से निर्भरता की घोषणा करने के फायदों में से एक यह है कि यह नए डेवलपर्स के लिए अनुप्रयोगों को कॉन्फ़िगर करना आसान बनाता है।

विशिष्ट निर्भरताओं को निर्दिष्ट करने की सहायता से, आप 6 महीने पहले उपयोग किए गए निर्माण को पुन: उत्पन्न कर सकते हैं, यह जानते हुए कि इसका निर्माण किया जाएगा क्योंकि बिल्ड Xcode, CocoaPods और Swift के एक ही संस्करण का उपयोग करेगा।

सीमा - चूंकि iOS के विकास को एक कंटेनर में समाहित नहीं किया जा सकता है, क्योंकि यह पहले से ही वेब विकास के लिए उपयोग किया जाता है, हम इस आवश्यकता को पूरा करने के लिए तृतीय-पक्ष टूल तक सीमित हैं जब तक कि Apple एक आधिकारिक समाधान प्रदान नहीं करता है। एक तृतीय-पक्ष वाणिज्यिक (बंद) समाधान है जिसे वीर्टु कहा जाता है जो आपको ऐप्पल हार्डवेयर पर वर्चुअल मैकओएस वातावरण बनाने की अनुमति देता है।

विन्यास

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

बिल्ड समय में कॉन्फ़िगरेशन मान दर्ज करने के कई तरीके हैं।

• कॉन्फ़िगरेशन फ़ाइलें (JSON या YAML फ़ाइलें)
• cocoapods- कुंजियों को छिपाने के लिए और निर्माण के दौरान उन्हें अपने iOS एप्लिकेशन पर लागू करें
• अनुकूलित समाधान (उदा। बिल्ड चरण का उपयोग करके)

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

OTA कॉन्फ़िगरेशन अपडेट आपको तुरंत अनुमति देते हैं:

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

ओटीए अपडेट लागू करते समय कुछ संभावित दृष्टिकोण:

• अपने स्वयं के निर्णय को लागू करें
• टर्नकी समाधान जैसे फायरबेस रिमोट कॉन्फिग
• FeatureFlags की तरह एक खुला स्रोत सेवा

अनुप्रयोग विकास / कार्य समता

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

• समय का अंतर
• स्टाफ का अंतर
• टूल गैप:

समाधान:

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

तैनाती

जैसा कि डिपेंडेंसी सिद्धांत में वर्णित है, कोड रिपॉजिटरी में आईओएस एप्लिकेशन को बनाने, परीक्षण करने और तैनात करने के लिए आवश्यक सभी निर्भरताएं शामिल होनी चाहिए।

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

अभी, iOS डेवलपर्स द्वारा उपयोग किया जा सकने वाला सबसे अच्छा तरीका है:

• Xcode- स्थापित के साथ Xcode इंस्टॉलेशन को स्वचालित करें
• Xcode की सटीक रिलीज़ को निर्दिष्ट करने के लिए .xcode- संस्करण फ़ाइल का उपयोग करें
• कॉन्फ़िगरेशन फ़ाइलों में सभी निर्भरताएँ परिभाषित करें (निर्भरता कारक देखें)
• फास्टलेन का उपयोग करके पूरी तैनाती प्रक्रिया को स्वचालित करें
• स्वचालित आवेदन हस्ताक्षर (codeigning.guide)
• रिलीज़ अक्सर, आदर्श रूप से साप्ताहिक शेड्यूल पर

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

स्थानीय बनाम बेक

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

एक एप्लिकेशन को कई कारणों से यथासंभव डिवाइस पर व्यावसायिक तर्क और कंप्यूटिंग करना चाहिए:

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

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

पिछड़े संगत एपीआई

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

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

https://your-api.com/1.0/drivers.json https://your-api.com/1.1/drivers.json 

अनुप्रयोग संस्करण

एप्लिकेशन में एक विशिष्ट एप्लिकेशन की पहचान करने के लिए संस्करण और बिल्ड नंबर का एक साथ उपयोग किया जाता है।

• संस्करण संख्या (CFBundleShortVersionString) - Xcode में संस्करण के रूप में (CFBundleShortVersionString)
• बिल्ड नंबर (CFBundleVersion) - (CFBundleVersion) इन बिल्ड (CFBundleVersion)

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

Xcode में एग्रावटूल नामक एक अंतर्निहित टूल होता है ।

रिश्वत

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

माइलस्टोन रिलीज - मील के पत्थर के रिलीज का उपयोग करके, आप धीरे-धीरे विधानसभा को रोल कर सकते हैं, कम संख्या में सक्रिय उपयोगकर्ताओं के साथ शुरू होता है

हालांकि, चरणबद्ध रिलीज़ के मामले में भी, विधानसभा को पूरी तरह से याद रखना असंभव है: उपयोगकर्ता के डिवाइस पर असेंबली स्थापित होने के बाद, इस असेंबली को बदलने का एकमात्र तरीका एक अद्यतन संस्करण / बिल्ड नंबर के साथ एक नया संस्करण वितरित करना है।

चरणबद्ध रिलीज़ के साथ, App Store और TestFlight विधानसभाओं को केवल इन चरणों का पालन करके अपडेट किया जा सकता है:

1. जिस राज्य में आप वापस जाना चाहते हैं, अपने संस्करण नियंत्रण प्रणाली पर वापस लौटें
2. संस्करण और / या अपनी परियोजना की संख्या बढ़ाएँ
3. अपना एप्लिकेशन बनाएं और साइन करें
4. अपने एप्लिकेशन को बीटा सेवा या ऐप स्टोर के माध्यम से वितरित करें
5. उपयोगकर्ता को अपने फोन पर एप्लिकेशन को अपडेट करना होगा।

उपरोक्त चरणों को मैन्युअल रूप से किया जा सकता है, हालांकि यह अनुशंसा की जाती है कि प्रक्रिया पूरी तरह से स्वचालित हो ताकि जल्दी से प्रतिक्रिया करने में सक्षम हो।

वैकल्पिक: पुराने बिल्ड पर फिर से हस्ताक्षर करें

1. प्रतिगमन पेश किए जाने से पहले पुरानी विधानसभा (.ipa फ़ाइल) तक पहुंचें
2. Info.plist फ़ाइल में संस्करण / बिल्ड नंबर अपडेट करें
3. "फिर से साइन इन करें" पुराने बिल्ड
4. इसे एक नए निर्माण के रूप में वितरित करें

हालांकि, "साइन इन" iOS ऐप अक्सर अधिक समस्याएं पैदा करता है, खासकर क्योंकि Xcode कमांड लाइन टूल ऐसा करने का एक अच्छा तरीका प्रदान नहीं करते हैं।

डेटा भंडारण

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

आधिकारिक Apple iOS डेटा संग्रहण दिशानिर्देशों का पालन करना सुनिश्चित करें:

• Documents : कस्टम सामग्री के लिए इस निर्देशिका का उपयोग करें, इसे संग्रहीत किया जाएगा
• Caches : पुनर्प्राप्त किए जा सकने वाले डेटा के लिए इस निर्देशिका का उपयोग करें।
• tmp : अस्थायी फ़ाइलों के लिए इस निर्देशिका का उपयोग करें
• फ़ाइलों के लिए संपत्ति का उपयोग do not back up करें

इन निर्देशिकाओं में उपयोगकर्ता की गोपनीय जानकारी (जैसे पासवर्ड या सत्र) को कभी संग्रहीत न करें। इसकी जगह किचेन एपीआई का इस्तेमाल करें।