🤴🏾 💪🏾 🐖 एंड्रॉइड आर्किटेक्चर में ज़ेन पृथक घटकों 🧘🏿 🧖🏿 😼

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

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

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

यह आलेख एंड्रॉइड आर्किटेक्चर के बारे में लेखों की श्रृंखला में तीसरा लेख है। पहले दो के लिंक:

खराब जुड़े घटकों पर ध्यान न दें।

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

हम आमतौर पर यहां समाप्त होते हैं और कहते हैं कि हमने कनेक्टिविटी के मामले में हर संभव प्रयास किया है।

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

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

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

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

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

ब्लैक बॉक्स घटक

यदि हम चाहते हैं कि घटक आसानी से और पुन: प्रयोज्य हो, तो इसके लिए हमें दो चीजों के बारे में जानने की आवश्यकता नहीं है:

जहाँ इसका उपयोग किया जाता है;
अन्य घटकों के बारे में जो इसके आंतरिक कार्यान्वयन से संबंधित नहीं हैं।

कारण स्पष्ट है: यदि आप बाहरी दुनिया के बारे में नहीं जानते हैं, तो आप इसके साथ नहीं जुड़े होंगे।

हम वास्तव में घटक से क्या चाहते हैं:

अपने स्वयं के इनपुट (इनपुट) और आउटपुट (आउटपुट) डेटा को परिभाषित करें;
यह मत सोचो कि यह डेटा कहाँ से आता है या कहाँ जाता है;
यह आत्मनिर्भर होना चाहिए ताकि हमें इसके उपयोग के लिए घटक की आंतरिक संरचना को जानने की आवश्यकता न हो।

आप घटक को एक ब्लैक बॉक्स, या एक एकीकृत सर्किट पर विचार कर सकते हैं। उसके पास इनपुट और आउटपुट संपर्क हैं। आप उन्हें मिलाप - और microcircuit एक ऐसी प्रणाली का हिस्सा बन जाते हैं जिसके बारे में वह कुछ भी नहीं जानता है।

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

लेकिन तब A, B के बारे में जानता है और हम इससे बचना चाहते हैं।

बेशक, इस तरह की योजना निम्न-स्तरीय कार्यान्वयन सुविधाओं के लिए समझ में आती है। लेकिन अगर हमें एक पुन: प्रयोज्य घटक की आवश्यकता होती है जो स्व-निहित ब्लैक बॉक्स की तरह काम करता है, तो हमें यह सुनिश्चित करने की आवश्यकता है कि यह बाहरी इंटरफेस, विधि के नाम, या रिटर्न मान के बारे में कुछ भी नहीं जानता है।

हम अप्रत्यक्षता से गुजरते हैं

लेकिन इंटरफ़ेस के नाम और तरीकों के बिना, हम कुछ भी नहीं कह सकते हैं! एक अप्रत्यक्ष डेटा स्ट्रीम का उपयोग करने के लिए सभी शेष है, जिसमें हमें बस इनपुट मिलता है और आउटपुट उत्पन्न होता है:

सबसे पहले, यह एक सीमा की तरह लग सकता है, लेकिन इस तरह के समाधान के कई फायदे हैं, जिनके बारे में नीचे चर्चा की जाएगी।

पहले लेख से हम जानते हैं कि विशेषताएं (फ़ीचर) अपने स्वयं के इनपुट डेटा (विश) और अपने स्वयं के आउटपुट डेटा (राज्य) को परिभाषित करती हैं। इसलिए, यह उनके लिए कोई मायने नहीं रखता है कि विश कहां से आती है या राज्य कहां जाता है।

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

अब व्यू लें और इसे डिज़ाइन करें ताकि यह एक सेल्फ-मेड मॉड्यूल भी हो।

सबसे पहले, दृश्य जितना संभव हो उतना सरल होना चाहिए ताकि वह केवल अपने आंतरिक कार्यों को संभाल सके।

किस तरह के कार्य? उनमें से दो हैं:

प्रतिपादन ViewModel (इनपुट);
उपयोगकर्ता के कार्यों (आउटपुट) के आधार पर ViewEvents को ट्रिगर करना।

ViewModel का उपयोग क्यों करें? सुविधा की स्थिति को सीधे क्यों नहीं खींचते?

(गैर) स्क्रीन पर एक विशेषता प्रदर्शित करना कार्यान्वयन का हिस्सा नहीं है। यदि डेटा कई स्रोतों से आता है, तो दृश्य खुद को प्रस्तुत करने में सक्षम होना चाहिए।
दृश्य में राज्य की जटिलता को प्रतिबिंबित करने की आवश्यकता नहीं है। ViewModel में केवल रेडी-टू-शो जानकारी होनी चाहिए जो इसे सरल रखने के लिए आवश्यक है।

इसके अलावा, देखें निम्नलिखित में दिलचस्पी नहीं होनी चाहिए:

ये सभी ViewModels कहाँ से आते हैं;
क्या होता है जब ViewEvent ट्रिगर होता है;
किसी भी व्यावसायिक तर्क;
विश्लेषणात्मक ट्रैकिंग;
प्रवेश;
अन्य कार्य।

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

interface FooView : Consumer<ViewModel>, ObservableSource<Event> { data class ViewModel( val title: String, val bgColor: Int ) sealed class Event { object ButtonClicked : Event() data class TextFocusChanged(val hasFocus: Boolean) : Event() } }

एक Android कार्यान्वयन होना चाहिए:

उनकी आईडी से Android दृश्य ढूंढें।
ViewModel से मान सेट करके उपभोक्ता इंटरफ़ेस की स्वीकार पद्धति को लागू करें।
विशिष्ट घटनाओं को उत्पन्न करने के लिए यूआई के साथ बातचीत करने के लिए श्रोताओं (ClickListeners) को सेट करें।

एक उदाहरण:

 class FooViewImpl @JvmOverloads constructor( context: Context, attrs: AttributeSet? = null, defStyle: Int = 0, private val events: PublishRelay<Event> = PublishRelay.create<Event>() ) : LinearLayout(context, attrs, defStyle), FooView, // delegate implementing ObservableSource to our Relay ObservableSource<Event> by events { // 1. find the views private val title: TextView by lazy { findViewById<TextView>(R.id.title)} private val panel: ViewGroup by lazy { findViewById<ViewGroup>(R.id.panel)} private val button: Button by lazy { findViewById<Button>(R.id.button)} private val editText: EditText by lazy { findViewById<EditText>(R.id.editText)} // 2. set listeners to trigger Events override fun onFinishInflate() { super.onFinishInflate() button.setOnClickListener { events.accept(Event.ButtonClicked) } editText.setOnFocusChangeListener { _, hasFocus -> events.accept(Event.TextFocusChanged(hasFocus)) } } // 3. render the ViewModel override fun accept(vm: ViewModel) { title.text = vm.title panel.setBackgroundColor(ContextCompat.getColor(context, vm.bgColor)) } }

यदि फ़ीचर और व्यू तक सीमित नहीं है, तो इस दृष्टिकोण से कोई अन्य घटक कैसा दिखेगा:

 interface GenericBlackBoxComponent : Consumer<Input>, ObservableSource<Output> { sealed class Input sealed class Output }

अब पैटर्न के साथ सब कुछ स्पष्ट है!

एकजुट, एकजुट, एकजुट!

लेकिन क्या होगा अगर हमारे पास अलग-अलग घटक हैं और उनमें से प्रत्येक का अपना इनपुट और आउटपुट है? हम उन्हें कनेक्ट करेंगे!

सौभाग्य से, यह आसानी से बिंदर का उपयोग करके किया जा सकता है, जो सही गुंजाइश बनाने में भी मदद करता है, जैसा कि हम दूसरे लेख से जानते हैं:

 // will automatically dispose of the created rx subscriptions when the lifecycle ends: val binder = Binder(lifecycle) // connect some observable sources to some consumers with element transformation: binder.bind(outputA to inputB using transformer1) binder.bind(outputB to inputA using transformer2)

पहला लाभ: संशोधनों के बिना विस्तार करना आसान है

ब्लैक बॉक्स के रूप में असंबंधित घटकों का उपयोग जो केवल अस्थायी रूप से जुड़े हुए हैं, हमें मौजूदा घटकों को संशोधित किए बिना नई कार्यक्षमता जोड़ने की अनुमति देता है।

एक सरल उदाहरण लें:

यहाँ, सुविधाएँ (F) और दृश्य (V) बस एक दूसरे से जुड़े हुए हैं।

संबंधित बाइंडिंग होगी:

 bind(feature to view using stateToViewModelTransformer) bind(view to feature using uiEventToWishTransformer)

मान लीजिए कि हम इस सिस्टम में कुछ UI इवेंट्स की ट्रैकिंग जोड़ना चाहते हैं।

 internal object AnalyticsTracker : Consumer<AnalyticsTracker.Event> { sealed class Event { object ProfileImageClicked: Event() object EditButtonClicked : Event() } override fun accept(event: AnalyticsTracker.Event) { // TODO Implement actual tracking } }

अच्छी खबर यह है कि हम इसे मौजूदा आउटपुट व्यू चैनल का फिर से उपयोग करके कर सकते हैं:

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

 bind(feature to view using stateToViewModelTransformer) bind(view to feature using uiEventToWishTransformer) // +1 line, nothing else changed: bind(view to analyticsTracker using uiEventToAnalyticsEventTransformer)

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

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

दूसरा फायदा: बार-बार इस्तेमाल करना आसान

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

हालांकि, यह दृष्टिकोण कक्षाओं तक सीमित नहीं है। इंटरफेस का उपयोग करने का यह तरीका हमें किसी भी आकार के स्व-निहित प्रतिक्रियाशील घटकों का वर्णन करने की अनुमति देता है।

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

हम निम्नलिखित लेखों में से एक में इस पर लौटेंगे और उच्च-स्तरीय घटकों को जोड़ने के लिए इस तकनीक के उपयोग के उदाहरणों पर विचार करेंगे।

पहला सवाल: बाइंडिंग कहां रखी जाए?

अमूर्तता का स्तर चुनें। वास्तुकला के आधार पर, यह एक गतिविधि, एक टुकड़ा, या कुछ ViewController हो सकता है। मुझे उम्मीद है कि आप अभी भी उन हिस्सों में अमूर्त के कुछ स्तर हैं जहां कोई UI नहीं है। उदाहरण के लिए, डि संदर्भ वृक्ष के कुछ स्कोप में।
UI के इस भाग के समान स्तर पर बाइंडिंग के लिए एक अलग वर्ग बनाएँ। यदि यह FooActivity, FooFragment, या FooViewController है, तो आप इसके बगल में FooBindings डाल सकते हैं।
सुनिश्चित करें कि आप FooBindings को उसी घटक उदाहरणों में एम्बेड करते हैं जिसका उपयोग आप गतिविधि, खंड, आदि में करते हैं।
बाइंडिंग का दायरा बनाने के लिए, गतिविधि या खंड जीवन चक्र का उपयोग करें। यदि यह लूप एंड्रॉइड से बंधा नहीं है, तो आप मैन्युअल रूप से ट्रिगर बना सकते हैं, उदाहरण के लिए, जब डीआई गुंजाइश बना या नष्ट कर सकते हैं। दूसरे लेख में गुंजाइश के अन्य उदाहरणों का वर्णन किया गया है।

दूसरा प्रश्न: परीक्षण

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

फ़ीचर के मामले में, इसका मतलब है:

यह जांचने की क्षमता कि कुछ इनपुट डेटा अपेक्षित स्थिति (आउटपुट) उत्पन्न करता है या नहीं।

और देखें:

हम परीक्षण कर सकते हैं कि क्या कोई विशेष ViewModel (इनपुट) UI की अपेक्षित स्थिति की ओर जाता है;
हम परीक्षण कर सकते हैं कि UI के साथ सहभागिता का अनुकरण अपेक्षित ViewEvent (आउटपुट) में आरंभीकरण की ओर जाता है या नहीं।

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

हमारे मामले में, बाइंडर्स घटकों को जोड़ने के लिए जिम्मेदार हैं:

 // this is wherever you put your bindings, depending on your architecture class BindingEnvironment( private val component1: Component1, private val component2: Component2 ) { fun createBindings(lifecycle: Lifecycle) { val binder = Binder(lifecycle) binder.bind(component1 to component2 using Transformer()) } }

हमारे परीक्षणों को निम्नलिखित की पुष्टि करनी चाहिए:

1. ट्रांसफॉर्मर (मैपर्स)।

कुछ कनेक्शन में मैपर्स होते हैं, और आपको यह सुनिश्चित करने की आवश्यकता होती है कि वे तत्वों को सही ढंग से रूपांतरित करें। ज्यादातर मामलों में, इसके लिए एक बहुत ही सरल इकाई परीक्षण पर्याप्त होता है, क्योंकि मैपर आमतौर पर बहुत सरल होते हैं:

 @Test fun testCase1() { val transformer = Transformer() val testInput = TODO() val actualOutput = transformer.invoke(testInput) val expectedOutput = TODO() assertEquals(expectedOutput, actualOutput) }

2. संचार।

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

 class BindingEnvironmentTest { lateinit var component1: ObservableSource<Component1.Output> lateinit var component2: Consumer<Component2.Input> lateinit var bindings: BindingEnvironment @Before fun setUp() { val component1 = PublishRelay.create() val component2 = mock() val bindings = BindingEnvironment(component1, component2) } @Test fun testBindings() { val simulatedOutputOnLeftSide = TODO() val expectedInputOnRightSide = TODO() component1.accept(simulatedOutputOnLeftSide) verify(component2).accept(expectedInputOnRightSide) } }

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

विचार के लिए भोजन

यद्यपि ब्लैक बॉक्स के ग्राफ के रूप में हमारी प्रणाली का वर्णन सामान्य समझ के लिए अच्छा है, यह केवल तब तक काम करता है जब तक कि सिस्टम का आकार अपेक्षाकृत छोटा हो।

पांच से आठ बाध्यकारी लाइनें स्वीकार्य हैं। लेकिन, अधिक जुड़े होने पर, यह समझना मुश्किल होगा कि क्या हो रहा है:

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

कारण घटकों का उपयोग है - ब्लैक बॉक्स या कुछ और?

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

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

एक समाधान की खोज में हमें बहुत समय लगा, और यह अभी भी जारी है। हम निम्नलिखित लेखों में इस समस्या से निपटने के तरीके के बारे में बात करने की योजना बनाते हैं। संपर्क में रहें!

एंड्रॉइड आर्किटेक्चर में ज़ेन पृथक घटकों