IOS में UI लागू करना: बेहतर, तेज, और यह तराजू

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

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

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

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


नाइके एयर मैक्स '97 - एम्पायर स्टेट बिल्डिंग (न्यूयॉर्क सिटी)

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


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

समस्या का वर्णन

मैं समस्या को केवल एक वाक्य में परिभाषित करने का प्रयास करूँगा:

IOS टीम के पास UI की कोई स्पष्ट प्रक्रिया नहीं थी।

व्यवहार में इसका क्या मतलब था? इसका मतलब था कि iOS ऐप में यूजर इंटरफेस में बदलाव के साथ कोई भी नया फीचर विकसित करने से सभी तरह की समस्याएं हो सकती हैं। यहाँ सबसे आम मुद्दे हैं जो हम दैनिक आधार पर सामना कर रहे थे:

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

इन समस्याओं को हल करने के लिए कोई जादू की छड़ी नहीं होने वाली थी क्योंकि यह प्रक्रिया के बारे में है। जिस तरह से चीजें की जाती हैं उसे बदलने के लिए अलग-अलग टीमों के बीच तालमेल की जरूरत होती है और नए तरीके के काम करने के फायदों के बारे में प्रक्रिया से प्रभावित लोगों को समझाने की जरूरत होती है।

Isol फूट डालो और जीतो ’ यहां एक आसान दृष्टिकोण हो सकता है, छोटे मुद्दों से शुरू होकर, प्रत्येक समस्या को अलग करना, और फिर कदम से एक वैश्विक समाधान का निर्माण शुरू करना। इस लेख में मैं समझाता हूँ कि हमने इसे कैसे हासिल किया!

यूआई फ्रेमवर्क

हमने नींव से शुरू करके समस्या का सामना किया। पता करने के लिए पहला मुद्दा कोड दोहराव था, हमें अपने घटकों को एकजुट करने और उन सभी को एक ही स्थान पर प्राप्त करने की आवश्यकता थी।

हमारा समाधान कुछ चौखटों का निर्माण करना था, जिसका नाम हमने ब्यूटुइट रखा। विचार यह था कि यह सभी यूआई घटकों को धारण करेगा, जैसा कि Apple UIKit के साथ करता है। इसमें ऐसी कक्षाएं शामिल हैं जो एक विशिष्ट एप्लिकेशन के उपयोगकर्ता इंटरफ़ेस का प्रतिनिधित्व करती हैं (हमारी कंपनी में कुछ अन्य अनुप्रयोग हैं लेकिन इस विशिष्ट UIKit में केवल उपयोगकर्ता इंटरफ़ेस घटक शामिल हैं जो कि एप्लिकेशन के लिए विशिष्ट हैं)।

हर एप्लिकेशन का एक अलग रंग पैलेट, फोंट, मार्जिन आदि होता है ... इसलिए यह एप्लिकेशन के साथ-साथ फ्रेमवर्क के भीतर स्टाइलशीट जोड़ने के लिए ऐप-विशिष्ट फ्रेमवर्क बनाने में मदद करता है।



यूआई घटकों के साथ क्या होता है जिसे विभिन्न अनुप्रयोगों में साझा और पुन: उपयोग किया जा सकता है?

इसके लिए हमने Platform_UIKit नाम से एक और फ्रेमवर्क बनाया। इस ढांचे में सभी सामान्य यूआई घटक हैं जिनका उपयोग विभिन्न ऐप में किया जा सकता है।

क्या हमने सभी UI को सीधे नए ढांचे में स्थानांतरित कर दिया है?

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

बाद में, एक बार नींव बन जाने के बाद हमने अपने यूजर इंटरफेस के लिए यूआई फ्रेमवर्क में भी चैट की। हमने ऐसा कुछ समय बाद किया जब हमारे पास बुनियादी ढांचा था और इसने एक चिकनी प्रवासन प्रक्रिया में मदद की।

साइड नोट:
यदि आप उन घटकों में से एक बनाने की प्रक्रिया के बारे में उत्सुक हैं, तो कृपया मेरे सहयोगी Valerii Chehataev के इस महान लेख पर एक नज़र डालें

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

UI को अन्य निर्भरताओं से अलग करके हम घटकों को यथासंभव पुन: प्रयोज्य बनाते हैं:



अगर यह किसी अन्य कारण से नहीं है, तो Platform_UIKit से आयात करना ठीक है, लेकिन किसी अन्य सरल तरीके से, अगर Platform_UIKit BadooUIKit पर निर्भर करता है, तो यह अनुप्रयोग-अज्ञेयवादी नहीं होगा।



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

यहाँ UIKit का उपयोग करने के कुछ लाभ दिए गए हैं:

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

गैलरी अनुप्रयोग

BetUIKit ने हमारी कई समस्याओं को हल किया लेकिन हम जानते थे कि हम अभी भी आगे बढ़ सकते हैं, कुछ सुधार थे जो इस प्रक्रिया में किए जा सकते हैं।

अलगाव में सभी UI घटकों को कैसे देखें? क्या हम यूआई घटकों को खोजने का एक तरीका तैयार कर सकते हैं और देख सकते हैं कि वे विभिन्न कोड रंगों के साथ कैसे दिखेंगे? क्या हम उन्हें आसानी से परीक्षण योग्य बना सकते हैं? क्या कोई ऐसा तरीका था जिससे डिज़ाइनर उन सभी मौजूदा यूआई घटकों की एक सूची बना सकते थे जिन्हें हम पहले से ही iOS में लागू कर रहे थे?

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

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

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

• घटक खोजते हैं
  
• घटक नाम सॉर्ट
  
• पसंदीदा के रूप में चिह्नित करें
  
• मल्टी-स्टाइल स्विचर - यह देखने के लिए कि हमारे घटक विभिन्न स्टाइलशीट के साथ कैसे दिखेंगे
  
• फ्लेक्स
  
• एक फ्रेम-प्रति-सेकंड दर्शक
  

प्रत्येक घटक में उपयोगकर्ता इनपुट के आधार पर या एप्लिकेशन के आंतरिक तर्क के आधार पर कई अलग-अलग राज्य हो सकते हैं। उदाहरण के लिए, एक साधारण UIButton कई राज्यों को परिभाषित करता है: डिफ़ॉल्ट, हाइलाइटेड, फ़ोकस, चयनित, और अक्षम।

जानना चाहते हैं? अधिक जानकारी के लिए यहां देखें।

हम अपनी गैलरी में सभी संयोजनों को प्रस्तुत करने की क्षमता भी चाहते थे। हम किसी भी घटक के लिए प्रत्येक विशिष्ट स्क्रीन के अंदर ऐसा करते हैं। बेशक, हमारे अपने संस्करणों के बटन में Apple के UIKit बटन से अलग राज्य हो सकते हैं।



यह मुख्य गैलरी के मुख्य लाभों का सारांश है:

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

परीक्षण के बारे में

लेख में सूचीबद्ध अधिकांश प्रारंभिक समस्याओं को उपकरणों के नए सेट को पेश करके हल किया गया है:



लेकिन अभी भी कुछ मुद्दे थे जिनमें सुधार किया जा सकता था, अन्य सवालों के जवाब देने की आवश्यकता थी: परिवर्तन करते समय, हम यह कैसे सुनिश्चित कर सकते हैं कि यूआई कुछ बदलावों के बाद उम्मीद के मुताबिक दिखेगा? "उप-घटक" संशोधित होने पर हम आवेदन के अन्य भागों या अन्य घटकों पर प्रतिकूल प्रभाव डालने से कैसे बच सकते हैं?

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

Badoo में हमने स्नैपशॉट परीक्षण के लिए इस समय सबसे लोकप्रिय "टूल" में से एक का उपयोग करके स्नैपशॉट परीक्षण जोड़ना शुरू करने का निर्णय लिया: iOSSnapshotTestCase (पहले इसे FBSnapshotTestCase रूप में जाना जाता था क्योंकि इसे शुरू में फेसबुक द्वारा खुला स्रोत के रूप में जारी किया गया था)।

स्नैपशॉट परीक्षण और निम्नलिखित लिंक पर इस विशिष्ट ढांचे के बारे में अधिक जानकारी प्राप्त करें:

• https://github.com/uber/ios-snapshot-test-case/
  
• https://www.objc.io/issues/15-testing/snapshot-testing/
  
• https://ashfurrow.com/blog/snapshot-testing-on-ios/
  

हमें उन घटकों का परीक्षण करने का एक तरीका खोजने की आवश्यकता है जो हमारे पास पहले से ही BetUIKit में थे ताकि बाकी एप्लिकेशन द्वारा उपयोग किए जा रहे घटकों को संशोधित करते समय संभावित प्रतिगमनों से बचा जा सके।

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

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

BetUIKit में लागू सभी UI घटक एक वर्ग (रिपॉजिटरी या स्टोर पैटर्न) में संग्रहीत किए जाते हैं जो सभी घटकों तक पहुंच प्रदान करता है। यह स्टोर गैलरी में घटकों की सूची प्रस्तुत करने के साथ-साथ स्नैपशॉट परीक्षण कक्षाओं से उन्हें एक्सेस करने के लिए दोनों को तत्काल किया जा सकता है। इसका मतलब यह है कि परीक्षण स्तर में हर घटक के विभिन्न राज्यों को तत्काल तैयार करने और तैयार करने के काम की नकल करना आवश्यक नहीं है क्योंकि घटक को गैलरी ऐप इंटरफ़ेस में पेश करते समय पहले ही ऐसा किया जा चुका है।

ये कुछ प्रश्न हैं जो स्नैपशॉट परीक्षण के संबंध में उत्पन्न हो सकते हैं। मुझे कुछ उत्तर प्रदान करने की अनुमति दें:

स्नैपशॉट चित्र कहाँ संग्रहीत हैं?

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

क्या सभी संभावित सिमुलेटरों में सभी संभावित संकल्पों का परीक्षण किया गया है?

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

क्या स्नैपशॉट परीक्षण सभी यूआई को कवर करने के लिए पर्याप्त हैं?

मुझे ऐसा नहीं लगता। बुश में, हमारे पास आवेदन के विभिन्न स्तरों पर विभिन्न प्रकार के परीक्षण भी हैं, उदाहरण के लिए कार्यात्मक परीक्षण (हम Calabash और KIF फ्रेमवर्क का उपयोग करते हैं) और कुछ एकीकरण परीक्षण। मेरे अनुभव में किसी भी एप्लिकेशन की आवश्यकताओं को पूरा करने के लिए परीक्षणों की तरह और परीक्षणों की मात्रा के बीच एक अच्छा संतुलन खोजना महत्वपूर्ण है।

सबक सीखा

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

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

आगे जा रहे हैं - ब्रह्मांड

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



क्रिस्टियानो रस्टेली ने कई दिलचस्प लेख लिखे हैं जहां वह विस्तार से बताते हैं कि कॉस्मॉस कैसे आया। उन्हें याद मत करो!

स्वीकृतियाँ

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

धन्यवाद की अद्भुत डिज़ाइन टीम के लिए जो कंपनी में डिज़ाइन प्रक्रियाओं को बेहतर बनाने के लिए हमेशा अतिरिक्त मील जाने के लिए तैयार रहती हैं।

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