👰🏾 👏 👩🏼‍🤝‍👨🏿 हम सुविधाओं को तेजी से विभाजित करते हैं। Android के विकास में अनुभव 👩🏿‍🤝‍👨🏻 🤷🏻 👨🏿‍🎨

सभी को नमस्कार! मेरा नाम अनातोली वरिवोचिक है। मैं एक साल से अधिक के लिए काम कर रहा हूँ, और मेरा कुल Android विकास का अनुभव पाँच साल से अधिक है।

मेरे व्यवहार में, मेरे सहयोगियों और मुझे अक्सर विचारों का परीक्षण करने की आवश्यकता का सामना करना पड़ता है जितनी जल्दी हो सके। हम कार्यान्वयन पर बहुत प्रयास नहीं करना चाहते हैं, क्योंकि हम जानते हैं कि यदि प्रयोग असफल रहा, तो हम कोड को बाहर फेंक देंगे।

इस लेख में मैं वास्तविक उदाहरणों के साथ दिखाऊंगा कि हम ऐसी परिस्थितियों में कैसे कार्य करते हैं और कौन से सिद्धांत हमें समस्या के एक या दूसरे समाधान के पक्ष में चुनाव करने में मदद करते हैं। उदाहरणों के विश्लेषण से हमारी सोच के पैटर्न को समझने में मदद मिलेगी: आप कभी-कभी विकास को गति देते हुए कोनों को कैसे काट सकते हैं।

योजना यह है:

विकास के सिद्धांत
केस की पढ़ाई।
डिजाइन प्रणाली।
वर्णित सिद्धांतों को कब लागू करें।

यह लेख AppsConf पर मेरी रिपोर्ट का एक पाठ संस्करण है, वीडियो को यहां देखा जा सकता है ।

विकास दृष्टिकोण सिद्धांत

करोड़ों लोग बेग का उपयोग करते हैं, इसलिए यदि हम सुनिश्चित नहीं हैं कि उपयोगकर्ता इसे पसंद करेंगे और उपयोगी साबित होंगे, तो हम नई कार्यक्षमता नहीं ला सकते।

हमारा विकास दृष्टिकोण कई कारकों से प्रभावित है।

ए / बी टेस्ट का उपयोग करना

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

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

विकास लागत कम करें

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

अधिकांश उपयोगकर्ता नियम

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

हम विकास को कैसे गति दें

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

शुरू करने के लिए, मैं आपको सुझाव देता हूं कि आप इस मामले को कैसे हल करें। और फिर मैं प्रत्येक विकल्प पर एक स्पष्टीकरण के साथ विचार करूंगा कि यह क्यों आया / हमारे मामले में फिट नहीं हुआ।

उदाहरण 1. प्रगति संचय बटन

हमें उपयोगकर्ता को 0 से 1 तक गोल कोनों के साथ बैटरी की प्रगति के साथ ऋण जमा करने की प्रक्रिया को दिखाने की आवश्यकता है।

समाधान विकल्प क्या हैं?

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

विकल्प सी: बस कुछ आइकन लें, उन्हें क्लाइंट पर हार्डकोड करें और उनमें से एक दिखाएं।

हमारे मामले में, हम बी और सी के समाधान के लिए आए थे। हम और अधिक विस्तार से चर्चा करेंगे।

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

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

कोड में, यह कुछ इस तरह दिखता है:

data class GoalInProgress(val progress: Float) private val unchargedPaint = Paint().apply { xfermode = PorterDuffXfermode(PorterDuff.Mode.MULTIPLY) } private fun mixChargedAndUncharged(canvas: Canvas) { drawFullyCharged(canvas) drawUnchargedPart(canvas) }

मैंने अधिकांश कोड हटा दिए हैं। लेख में बिटमैप मास्क के बारे में अधिक पढ़ें: https://habr.com/ru/company/badoo/blog/310618/ आप यह भी सीखेंगे कि मुखौटे को कैसे मिलाया जाए, प्रदर्शन के संदर्भ में क्या प्रभाव पड़ता है और यह कैसे काम करता है।

यह समाधान 100% हमारी आवश्यकताओं को पूरा करता है, अर्थात, यह 0 से 1 तक प्रगति को दिखाना संभव बनाता है।

एकमात्र नकारात्मक: यदि आपने पहले कभी ऐसा नहीं किया है, तो आपको बिटमैप मास्क लगाने के लिए समय बिताना होगा। इसके अलावा, आपको अभी भी उनके साथ खेलना है, किनारे के मामले देखना है, और परीक्षण करना है। मुझे लगता है कि कुल मिलाकर लगभग चार घंटे लगेंगे।

विकल्प सी। हम कुछ निश्चित प्रकार के आइकन लेते हैं और प्रगति के आधार पर हम उनमें से एक दिखाते हैं। उदाहरण के लिए, यदि उपयोगकर्ता की प्रगति 0.5 से कम है, तो एक खाली आइकन प्रदर्शित किया जाएगा। जाहिर है, यह समाधान आवश्यकताओं के 100% को संतुष्ट नहीं करता है। लेकिन इसके कार्यान्वयन के लिए, आपको कोड की केवल पांच लाइनें लिखने और डिजाइनर से तीन आइकन प्राप्त करने की आवश्यकता है।

 fun getBackground(goal: GoalInProgress) = when (goal.progress) { in 0.0..0.5 -> R.drawable.ic_not_filled in 0.5..0.99 -> R.drawable.ic_half_filled else -> R.drawable.ic_full_filled }

इसके अलावा, यह समाधान समय की गंभीर कमी की स्थितियों में इष्टतम है (जैसा कि हमारे पास था जब हमने लाइवस्ट्रीम कार्यक्षमता जारी की थी)। इसमें ज्यादा समय नहीं लगता है - आप बस इसे रोल आउट करते हैं और इसे अगले रिलीज में सही सुंदर समाधान के साथ बदल देते हैं। वास्तव में, जैसा कि हमने अपने समय में किया था।

उदाहरण 2. फ़ोन नंबर दर्ज करने की एक पंक्ति

अगला उदाहरण फोन नंबर दर्ज करना है। विशिष्ट विशेषताएं:

देश उपसर्ग बाईं ओर है;
उपसर्ग को हटाया नहीं जा सकता;
एक इंडेंट है;
उपसर्ग गैर-क्लिक करने योग्य है।

आइए इस बारे में सोचें कि इसे कैसे लागू किया जा सकता है।

विकल्प ए: एक कस्टम टेक्स्टवचर लिखें जो वांछित तर्क को लागू करता है। यह इस उपसर्ग को धारण करेगा, एक स्थान रखेगा, कर्सर की स्थिति को नियंत्रित करेगा।

विकल्प बी: इस घटक को दो स्वतंत्र क्षेत्रों में विभाजित करें। यूआई के दृष्टिकोण से, यह एक ही घटक होगा।

विकल्प सी: हमारे लिए इसे आसान बनाने के लिए एक अलग डिज़ाइन के लिए पूछें।

हमने विकल्प बी को लागू करने का निर्णय लिया। अधिक विस्तार से विचार करें।

एक अलग डिजाइन (विकल्प सी) के लिए पूछना पहली चीज है जिसे हमने करने की कोशिश की है। हालांकि, उत्पादों ने प्रारंभिक विचार पर जोर दिया। और यदि व्यवसाय किसी प्रकार की कार्यक्षमता पर जोर देता है, तो हमारा कार्य इसे लागू करना है।

कस्टम टेक्स्टवॉकर (विकल्प ए) केवल पहली नज़र में एक सरल समाधान की तरह लगता है, लेकिन वास्तव में कई किनारे मामले हैं जिन्हें संभालने की आवश्यकता है। उदाहरण के लिए, आपको चाहिए:

किसी तरह उपसर्ग पर क्लिक को इंटरसेप्ट करता है, फिर कर्सर की स्थिति को बदलने के लिए;
इसके अलावा इंडेंट;
विलोपन को रोकें ताकि उपयोगकर्ता देश के स्थान या उपसर्ग को न हटा सके।

यह सब करने के लिए, बेशक, संभव है, लेकिन मुश्किल है। ऐसा लगता है कि एक आसान विकल्प है।

और वह वास्तव में पाया गया था:

 <merge xmlns:android="http://schemas.android.com/apk/res/android" tools:parentTag="android.widget.LinearLayout"> <TextView android:id="@+id/country_code" /> <EditText android:id="@+id/phone_number" /> </merge>

हमने बस इस घटक को दो भागों में विभाजित किया है: TextView और EditText। प्रोग्रामवेट पर, टेक्स्टव्यू पर, हम बैकग्राउंड को इस तरह से सेट करते हैं, जैसे कि उत्पादों से ठीक वैसा ही डिजाइन मिलता है जैसी कि उत्पाद की अपेक्षा है।

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

 phoneNumber.setOnFocusChangeListener { _, hasFocus -> countryCode.setBackgroundResource(background(hasFocus)) } private fun background(hasFocus: Boolean) = when (hasFocus) { true -> R.drawable.phone_input_active false -> R.drawable.phone_input_inactive }

इस समाधान के कई फायदे हैं:

उपसर्ग पर क्लिक को संभालने की कोई आवश्यकता नहीं है;
कर्सर स्थिति के साथ काम करने की कोई आवश्यकता नहीं है - यह हमेशा एक अलग क्षेत्र में होता है।
इस तरह के कार्यान्वयन से बहुत कम बढ़त के मामले और समस्याएं पैदा होती हैं।

उदाहरण 3. स्वत: पूर्ण के साथ समस्या

जैसा कि आप बाईं ओर के एनीमेशन में देख सकते हैं, स्वतः पूर्ण काम नहीं करता है जैसा हम चाहते हैं। हम सब कुछ सही पर एनीमेशन की तरह देखना चाहेंगे।

आइए इस बारे में सोचें कि हम इसके बारे में क्या कर सकते हैं।

विकल्प A: ऐसा लगता है कि यह एक दुर्लभ मामला है जिसे कोई ठीक नहीं करता है। हम ऐसा क्यों नहीं करते?

विकल्प बी: कस्टम टेक्स्टवॉकर बहुत बेहतर करेगा और हमारी सभी समस्याओं को हल करेगा।

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

विकल्प D: अंत से N अक्षर लें।

हम विकल्प डी पर बस गए।

विकल्प ए। मैंने कई बड़े अनुप्रयोगों में देखा। कोई भी इसे ठीक करने के लिए नहीं लगता है।

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

विकल्प बी। कस्टम टेक्स्टवॉकर को लागू करना वास्तव में आसान है, क्योंकि पिछले उदाहरण में कई धारियां नहीं हैं। आप सम्मिलित पाठ को आसानी से रोक सकते हैं। केवल एक छोटी सी समस्या है: कुछ देशों में स्थानीय उपनाम हैं। उदाहरण के लिए, +44 और 0 का मतलब एक ही है।

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

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

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

विकल्प डी। अंत से एन अक्षरों का उपयोग करना हमें एक उपयुक्त समाधान लगता था।

 class DigitsTrimStartFilter(private val max: Int) : InputFilter { override fun filter(...): CharSequence? { val s = source.subSequence(start, end).filter { it.isDigit() } val keep = max - (dest.length - (dend - dstart)) return when { keep <= 0 -> "" keep >= s.length -> null // keep original else -> s.subSequence(s.length - keep, s.length) } } }

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

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

उदाहरण 4. दिनांक प्रविष्टि घटक

डिजाइनर और उत्पाद निम्नानुसार तारीख दर्ज करने के लिए एक मुखौटा देखना चाहते हैं:

आइए इस बारे में सोचें कि इसे कैसे लागू किया जा सकता है।

विकल्प A: बस करो। कार्य सरल दिखता है, हल करना आसान है, कोई समस्या नहीं पैदा होनी चाहिए।

विकल्प बी: मास्क लाइब्रेरी का उपयोग करें। वह इस स्थिति में हमारे अनुकूल है।

विकल्प C: कर्सर स्थिति का नियंत्रण अक्षम करें। इस प्रकार, हम आवश्यकताओं को थोड़ा सरल करते हैं और हमारे लिए इस कार्यक्षमता को लागू करना आसान होगा।

विकल्प डी: एंड्रॉइड पर मानक तिथि इनपुट घटक का उपयोग करें और जिसे हम सभी ने देखा।

हम विकल्प सी पर आए।

विकल्प A. कार्य सरल लगता है। निश्चित रूप से हम इस कार्यक्षमता को लागू करने वाले पहले नहीं हैं। क्यों नहीं देखते हैं कि इंटरनेट पर उपयुक्त समाधान है या नहीं।

हम इस समाधान को लेते हैं, इसे कोड में जोड़ते हैं, इसे चलाते हैं। हम परीक्षण करना शुरू करते हैं:

 override fun onTextChanged(s: CharSequence, start: Int, before: Int, count: Int) { if (edited) { edited = false return } var working = getEditText() working = manageDateDivider(working, 2, start, before) working = manageDateDivider(working, 5, start, before) edited = true input.setText(working) input.setSelection(input.text.length) }

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

हम सभी को इसे निखारने की जरूरत है। मैं इससे बचना चाहूंगा, क्योंकि तब यह परीक्षकों का काम है, और फिर हमारे द्वारा कीड़े को ठीक करना, आदि।

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

हमारे पास पुस्तकालय नहीं था। और इसे एक छोटे घटक के लिए परियोजना में खींचने के लिए, जिसका उपयोग कहीं और नहीं किया जाता है, वह बहुत ही कम लग रहा था।

विकल्प D. मानक दिनांक प्रविष्टि घटक का उपयोग करें।

यह सबसे स्मार्ट समाधान की तरह लगता है। उसके साथ सब कुछ ठीक है, सिवाय एक छोटी सी खराबी के। जब आप इस घटक को खोलते हैं, तो आपके पास पहले से ही कुछ पूर्वनिर्धारित मूल्य, कुछ मान्य तिथि होती है। यदि आप अगले चरण में जाने के लिए एक वैध तिथि निर्धारित करते हैं, उदाहरण के लिए, 1 जनवरी, 1980, तो आपको लाखों उपयोगकर्ता प्राप्त होंगे जो उस दिन पैदा हुए थे। अन्यथा, आपको कई समान त्रुटियां मिलेंगी: उपयोगकर्ता पंजीकरण नहीं कर सकता क्योंकि वह बहुत पुराना है या बहुत छोटा है।

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

और एक और छोटा माइनस। ऐसा लगता है कि केवल उन्नत उपयोगकर्ता पहले राज्य से दूसरे में जा सकते हैं:

यदि न केवल उन्नत उपयोगकर्ता आपके एप्लिकेशन का उपयोग करते हैं, तो वे वांछित तारीख की तलाश में महीने के बाद महीने के माध्यम से सॉर्ट करेंगे।

इसलिए, हमने फैसला किया कि विकल्प ए इतना बुरा नहीं है। आपको इसे परिष्कृत करने और इसे थोड़ा सरल बनाने की आवश्यकता है:

 class DateEditText : AppCompatEditText(context, attrs, defStyleAttr) { private var canChange: Boolean = false private var actualText: StringBuilder = StringBuilder() override fun onSelectionChanged(selStart: Int, selEnd: Int) { super.onSelectionChanged(selStart, selEnd) if (!canChange) return canChange = false setSelection(actualText.length) canChange = true } }

उपयोगकर्ता द्वारा कर्सर की स्थिति बदलने पर विकल्प A के नुकसान दिखाई देने लगे। और हमने सोचा: "इस कर्सर को स्थानांतरित करने का अवसर क्यों दें?" और बस ऐसा करने पर प्रतिबंध लगा दिया।

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

उदाहरण 5. वीडियो स्ट्रीमिंग स्क्रीन पर उपकरण

वीडियो स्ट्रीमिंग शुरू करते समय, उत्पाद उपयोगकर्ताओं को कार्यक्षमता का उपयोग करने के तरीके सिखाने के लिए टूलटिप्स दिखाना चाहते थे।

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

यह सब लागू करना मुश्किल लग रहा था। हमने कुछ चीजों के लिए उत्पाद पूछा।

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

पहले, टूलटिप पुनरावृत्ति टाइमर स्वतंत्र थे:

हमने सर्वोच्च प्राथमिकता टूलटिप के लिए केवल टाइमर का समर्थन करने के लिए कहा:

तदनुसार, टाइमर ने हमारे लिए केवल टूलटिप 1 के लिए काम किया। जैसे ही टूलटिप 1 दिखाई दिया, इसे हटा दिया गया और अगली प्रक्रिया शुरू हुई।

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

उदाहरण 6. फ़ोटो को फिर से व्यवस्थित करना

यह डिजाइन हमारे पास आया:

हम इस निष्कर्ष पर पहुंचे कि इसे लागू करना काफी मुश्किल है, हमें विकास पर तीन दिन बिताने होंगे, और सोचा: "अगर उपयोगकर्ता को इसकी आवश्यकता होती है तो हमें यह नहीं पता होना चाहिए कि हमें ऐसा क्यों करना चाहिए?" हमने सुझाव दिया कि एक सरलीकृत संस्करण के साथ शुरुआत करें और मूल्यांकन करें कि यह सुविधा कितनी है।

यह पता चला कि उपयोगकर्ता इस कार्यक्षमता में रुचि रखते हैं। उसके बाद, हमने उस राज्य को फिर से प्रस्तुत करने में सुधार किया जो मूल डिजाइन पर था।

कुल:

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

उदाहरण 7. पिन इनपुट घटक

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

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

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

आप रूडी आर्टीम की रिपोर्ट से डिजाइन प्रणाली के बारे में अधिक जान सकते हैं।

इस बीच, पिन इनपुट घटक पर वापस जाएं। हम क्या चाहेंगे?

सही कीबोर्ड व्यवहार;
यूआई को पूरी तरह से अनुकूलित करने की क्षमता ताकि यह अलग-अलग अनुप्रयोगों में अलग दिखे;
इस घटक से डेटा का एक मानक स्ट्रीम प्राप्त करें, जैसा कि एक नियमित EditText से।

हमारे समाधान के विकल्प क्या थे?

विकल्प A: चार अलग-अलग EditText का उपयोग करें, जहां प्रत्येक पिन तत्व एक अलग EditText होगा।

विकल्प B: एक EditText का उपयोग करें, कुछ रचनात्मकता जोड़ें - और आपको जो चाहिए वह प्राप्त करें।

हमने विकल्प बी चुना।

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

इसलिए, हमने थोड़ा धोखा देने का फैसला किया और 0 से 0 के आकार का एक अदृश्य एडिट टेक्स्ट बनाया, जो डेटा स्रोत होगा:

 private fun createActualInput(lengthCount: Int) = EditText(context) .apply { inputType = InputType.TYPE_CLASS_NUMBER isClickable = false maxHeight = 0 maxWidth = 0 alpha = 0F addOrUpdateFilter(InputFilter.LengthFilter(lengthCount)) } private fun createPinItems(count: Int) { actualText = createActualInput(count) actualText.textChanges() .subscribe { updatePins(it.toString()) pinChangesRelay.accept(it) } overlay.clicks().subscribe { focus() } }

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

इसके अलावा, हम अदृश्य EditText के पाठ को बदलने और UI पर प्रदर्शित करने के लिए सदस्यता लेते हैं। उसके बाद, इस घटक से डेटा स्ट्रीम को बाहर निकालना हमारे लिए आसान है। वास्तव में, हमने मानक Android EditText का पुन: उपयोग किया, केवल आवश्यक तर्क जोड़ा।

परिणाम

ये सिद्धांत हमेशा लागू नहीं होते हैं। मैं आपको वे शर्तें दूंगा जिनके तहत वे अच्छी तरह से काम करेंगे।

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

इन सिद्धांतों का उपयोग कैसे करें? दुर्भाग्य से, संदर्भ से बाहर, कोई भी सिफारिश करना मुश्किल है। हालांकि, मैं आपको निम्नलिखित बातों पर ध्यान देने की सलाह दे सकता हूं।

आपको अधिकांश उदाहरणों के रूप में UI / UX के साथ समस्या हो सकती है, या आपको टूलटिप उदाहरण में व्यावसायिक तर्क के साथ समस्या हो सकती है। आपको अपने कार्य को कई छोटे उप-प्रकारों में विघटित करने का प्रयास करने की आवश्यकता है, और फिर उनका मूल्यांकन करें।

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

मैं जोड़ना चाहता हूं कि सभी लोग कभी-कभी गलतियाँ करते हैं। , , . , iOS. , . , . . , Win-Win .

:

PS , . , , . — , . ? .

हम सुविधाओं को तेजी से विभाजित करते हैं। Android के विकास में अनुभव