एमवीपी की सेवा में राज्य मशीनें। यांडेक्स व्याख्यान

परिमित-राज्य मशीन (FSM) मॉडल का उपयोग एंड्रॉइड सहित विभिन्न प्रकार के प्लेटफार्मों के लिए कोड लिखने में किया जाता है। यह आपको कोड को कम बोझिल बनाने की अनुमति देता है, मॉडल-व्यू-प्रस्तोता (एमवीपी) प्रतिमान में अच्छी तरह से फिट बैठता है और सरल परीक्षण के लिए उधार देता है। डेवलपर व्लादिस्लाव कुज़नेत्सोव ने Droid पार्टी को बताया कि यह मॉडल Yandex.Disk एप्लिकेशन के विकास में कैसे मदद करता है।


- पहले, सिद्धांत के बारे में बात करते हैं। मुझे लगता है कि आप में से प्रत्येक ने एमवीपी और राज्य मशीन के बारे में सुना है, लेकिन हम इसे दोहराएंगे।



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

राज्य मशीन और एमवीपी, या कुछ इसी तरह का - शायद एमवीआई - सभी द्वारा उपयोग किया गया था।

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



यहाँ कुछ सार प्रोग्रामर का एक सरल आरेख है जो कभी-कभी सोता है, कभी-कभी खाता है, लेकिन ज्यादातर कोड लिखता है। यह हमारे लिए पर्याप्त है। एक परिमित राज्य मशीन की बड़ी संख्या में किस्में हैं, लेकिन यह हमारे लिए पर्याप्त है।



राज्य मशीन का दायरा काफी बड़ा है। प्रत्येक आइटम के लिए उनका उपयोग किया जाता है और सफलतापूर्वक लागू किया जाता है।



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

एक वाक्य में कौन कह सकता है कि एक कार्यक्रम क्या है? निष्पादन योग्य कोड? बहुत सामान्य, अधिक विस्तृत। एक एल्गोरिथ्म? एक एल्गोरिथ्म क्रियाओं का एक क्रम है।

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



तीन बूलियन झंडे के साथ एक साधारण वर्ग की कल्पना करें। यह सुनिश्चित करने के लिए कि आप इन झंडों के संयोजन के लिए सभी परिदृश्यों को कवर करते हैं, आपको 2। परिदृश्यों की आवश्यकता होगी। यह कहने के लिए गारंटी के साथ आठ परिदृश्यों को कवर करना आवश्यक है कि मैं सभी ध्वज संयोजनों को सुनिश्चित करने के लिए प्रसंस्करण कर रहा हूं। यदि आप एक और ध्वज जोड़ते हैं, तो यह आनुपातिक रूप से बढ़ जाता है।

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



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



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



हम कुछ राज्य की जांच करते हैं, जांचते हैं कि हम गणना कर रहे हैं, और "प्रतीक्षा" प्लग खींचें।



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



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




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

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

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

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

इस समस्या को कैसे हल करें? राज्य मशीन की शक्ति से।



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



यहां सुपर-डुपर कुछ भी नहीं है, अगली स्लाइड अधिक महत्वपूर्ण है।



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

हमारा चार्ट इस तरह दिखता है, जो इस संवाद की स्थिति का वर्णन करता है। कई राज्यों और उनके बीच संक्रमण के तर्क हैं।



कोड पर चलते हैं। राज्य ही, वहाँ कुछ भी महत्वपूर्ण नहीं है, मुख्य बात यह है कि इसकी तीन विधियाँ हैं: onnnter, जो प्रवेश करते समय, पहले अमान्य डेटा को कॉल करता है। ऐसा क्यों किया जाता है? ताकि जैसे ही हम राज्य में आते हैं, UI अपडेट हो जाता है। इसके अलावा अमान्य तरीका है, जिसे हम यूआई के साथ कुछ करने की जरूरत है, और onExit विधि, जिसमें हम राज्य से बाहर निकलते हैं तो हम कुछ कर सकते हैं।



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

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



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



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

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

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

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



SaveState को अग्रेषित करना आवश्यक है, अगर कोई समान पुस्तकालयों के साथ काम करता है, तो सब कुछ बहुत ही मामूली है। आप अपने हाथों से लिख सकते हैं। और दो विधियां बहुत महत्वपूर्ण हैं: संलग्न करें, ऑनस्टार्ट पर कॉल करें, और अलग करें, जिसे ऑनटॉप कहा जाता है।



उनका महत्व क्या है? प्रारंभ में, हमने onCreateView, onDestroyView में संलग्न और अलग करने की योजना बनाई, लेकिन यह काफी पर्याप्त नहीं था। यदि आपके पास एक दृश्य है, तो आपका पाठ अपडेट किया जा सकता है, या एक संवाद टुकड़ा दिखाई दे सकता है। और अगर आप onStop में नहीं फंसते हैं, और फिर टुकड़े को दिखाने की कोशिश करते हैं, तो आप उस प्रसिद्ध अपवाद को पकड़ लेंगे जिसे आप तब भी लेनदेन नहीं कर सकते जब हमारे पास अभी भी राज्य है। या तो प्रतिबद्ध राज्य हानि का उपयोग करें, या नहीं। इसलिए, हम ऑनटॉप में विस्तृत हैं, जबकि प्रस्तुतकर्ता वहां काम करना, राज्यों को स्विच करना, घटनाओं को पकड़ना जारी रखेगा। और उस समय जब शुरुआत होती है, हम दृश्य संलग्न घटना को ट्रिगर करेंगे, और प्रस्तुतकर्ता UI को वर्तमान स्थिति से मिलान करने के लिए अपडेट करेगा।




एक रिलीज़ विधि है, इसे आमतौर पर onDestroy में कहा जाता है, आप एक अलग और अतिरिक्त रूप से रिलीज़ संसाधन बनाते हैं।



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



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





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



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



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

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

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

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

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



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



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



और आखिरी - हम पूरे सिस्टम का परीक्षण कर सकते हैं। हम राज्य का निर्माण करते हैं, इसे एक घटना भेजते हैं और जांचते हैं कि सिस्टम कैसे व्यवहार करता है। हमारे पास परीक्षण के तीन चरण हैं। , UI, , , , .

, 70%. 80% . , .



, ? — . - .

. . - , , - , — , .

- , , , . , , . , , . - , , . , , . lock . - , .

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