EBA आर्किटेक्चर उर्फ ​​फुल-रिएक्टिविटी

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

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

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

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

समस्याओं

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

अध्याय 1. विकास ही हमारा सब कुछ है

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

interface NewTaskView { val newTaskAction: Observable<NewTaskAction> val taskNameChangeAction: Observable<String> val onChangeState: Consumer<SomeViewState> } 

पहले से ही यहां आप पकड़ को नोटिस कर सकते हैं: यहां देखें एमवीपी के कैनन से बहुत दूर है। प्रस्तुतकर्ता में एक विधि थी:

 fun bind(view: SomeView): Disposable 

बाहर, एक इंटरफ़ेस कार्यान्वयन पारित किया गया था जो प्रतिक्रियात्मक रूप से यूआई परिवर्तनों की सदस्यता लेता है। और यह पहले से ही एमवीआई की स्मैक है!

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

 compositeDisposable.add( Observable.merge(firstAction, secondAction) .observeOn(AndroidSchedulers.mainThread()) .subscribe(view.onChangeState)) return compositeDisposable 

 class SomeViewState(val progress: Boolean? = null, val error: Throwable? = null, val errorMessage: String? = error?.message, val result: TaskUi? = null) 

गतिविधि SomeViewStateMachine इंटरफ़ेस की वंशज थी:

 interface SomeViewStateMachine { fun toSuccess(task: SomeUiModel) fun toError(error: String?) fun toProgress() fun changeSomeButton(buttonEnabled: Boolean) } 

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

 class SomeViewStateResolver(private val stateMachine: SomeViewStateMachine) : Consumer<SomeViewState> { override fun accept(stateUpdate: SomeViewState) { if (stateUpdate.result != null) { stateMachine.toSuccess(stateUpdate.result) } else if (stateUpdate.error != null && stateUpdate.progress == false) { stateMachine.toError(stateUpdate.errorMessage) } else if (stateUpdate.progress == true) { stateMachine.toProgress() } else if (stateUpdate.someButtonEnabled != null) { stateMachine.changeSomeButton(stateUpdate.someButtonEnabled) } } } 

सहमत हूँ, कुछ अजीब एमवीपी, और एमवीआई से भी दूर। प्रेरणा की तलाश में।

अध्याय 2. Redux

अन्य डेवलपर्स के साथ उनकी समस्याओं के बारे में बात करते हुए, हमारे (तब भी) नेता सर्गेई बोइश्टन ने रेडक्स के बारे में सीखा।

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

कार्य
कार्रवाई का वर्णन करता है।

ActionCreator
वह एक सिस्टम विश्लेषक की तरह है: प्रारूप, ग्राहकों की आवश्यकताओं के विनिर्देश का अनुपालन करता है ताकि प्रोग्रामर उसे समझ सकें।
जब उपयोगकर्ता स्क्रीन पर क्लिक करता है, तो ActionsCreator एक एक्शन बनाता है जो मिडलवेयर (कुछ प्रकार के व्यावसायिक तर्क) पर जाता है। व्यापार तर्क हमें नया डेटा देता है जो एक विशेष Reducer प्राप्त करता है और आकर्षित करता है।

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

सरल ActionCreators (सावधान, जावास्क्रिप्ट!) के लिए नमूना कोड:

 export function addTodo(text) { return { type: ADD_TODO, text } } export function toggleTodo(index) { return { type: TOGGLE_TODO, index } } export function setVisibilityFilter(filter) { return { type: SET_VISIBILITY_FILTER, filter } } 

कम करने

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

संक्षेप में, Reducer जानता है कि विघटित / स्क्रीन को ताज़ा कैसे करें।

पेशेवरों:

• विघटित स्क्रीन अपडेट।
• अप्रत्यक्ष डेटा स्ट्रीम।

विपक्ष:

• पसंदीदा स्विच फिर से।
  

   function todoApp(state = initialState, action) { switch (action.type) { case SET_VISIBILITY_FILTER: return Object.assign({}, state, { visibilityFilter: action.filter }) case ADD_TODO: return Object.assign({}, state, { todos: [ ...state.todos, { text: action.text, completed: false } ] }) default: return state } 

• राज्य वस्तुओं का एक गुच्छा।
• ActionCreator और Reducer में तर्क का पृथक्करण।

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

अध्याय 3. ईबीए

ईबीए के संदर्भ में एक्शन और एक्शन क्रिएटर क्या है:

 typealias Action = () -> Unit typealias ActionMapper<T> = (T) -> Action interface ActionCreator<T> : (T) -> (Observable<Action>) 

हां, आर्किटेक्चर का आधा हिस्सा टाइपेलियास और एक इंटरफेस है। सादगी लालित्य के बराबर है!

किसी भी डेटा को प्रसारित किए बिना कुछ कॉल करने के लिए कार्रवाई की आवश्यकता है। चूंकि ActionCreator एक ऑब्जर्वेबल रिटर्न देता है, इसलिए हमें कुछ डेटा प्रसारित करने के लिए एक्शन को दूसरे लैम्ब्डा में लपेटना पड़ा। और इसलिए इसने ActionMapper - एक टाइप एक्शन किया, जिसके माध्यम से हम स्क्रीन / दृश्य को अपडेट करने के लिए जो आवश्यक है, उसे पारित कर सकते हैं।

मूल आसन:

वास्तुकला योजना :

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

ActionCreator

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

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

डिस्क्लेमर: कोड का प्रारूपण यहां ठीक नहीं है, मेरे पास लेख के लिए इसके नियम हैं ताकि कोड अच्छी तरह से पढ़ा जा सके।

 class LoadItemsActionCreator( private val getItems: () -> Observable<List<ViewTyped>>, private val showLoadedItems: ActionMapper<DiffResult<ViewTyped>>, private val diffCalculator: DiffCalculator<ViewTyped>, private val errorItem: ErrorView, private val emptyItem: ViewTyped? = null) : ActionOnEvent 

शब्दों द्वारा "उनके कॉल के इंटरफेस द्वारा" मेरा मतलब बिल्कुल यही था कि कैसे getItems घोषित किया जाता है (यहां ViewTyped सूचियों के साथ काम करने के लिए हमारा इंटरफ़ेस है)। वैसे, हमने इस ActionCreator को एप्लिकेशन के आठ अलग-अलग हिस्सों में पुन: उपयोग किया है, क्योंकि यह यथासंभव बहुमुखी लिखा गया है।

चूंकि घटनाएं एक प्रतिक्रियाशील प्रकृति की हैं, इसलिए हम अन्य ऑपरेटरों को जोड़कर एक श्रृंखला को इकट्ठा कर सकते हैं, उदाहरण के लिए, लोडिंग दिखाने के लिए startWith (showLoadingAction), और onErrorReturn (errorAction) एक त्रुटि के साथ स्क्रीन स्थिति दिखाने के लिए।
और यह सब प्रतिक्रियात्मक है!

उदाहरण

 class AboutFragment : CompositionFragment(R.layout.fragment_about) { override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) val component = AboutComponent( setVersionName = { { appVersion.text = it } }, openPdfAction = { (url, name) -> { openPdf(url, name) } }) val events = AboutEventsImpl( bindEvent = bindEvent, openPolicyPrivacyEvent = confidentialityPolicy.clicks(), openProcessingPersDataEvent = personalDataProtection.clicks(), unbindEvent = unBindEvent) component.binder().bind(events) } 

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

 val component = AboutComponent( setVersionName = { { appVersion.text = it } }, openPdfAction = { (url, name) -> { openPdf(url, name) } } ) 

घटक तर्क - कार्य / ActionMappers - ActionCreators के साथ दृश्य को जोड़ने में मदद करते हैं। ActionMapper'e setVersionName में हम प्रोजेक्ट के संस्करण को पास करते हैं और इस मान को स्क्रीन पर टेक्स्ट को असाइन करते हैं। OpenPdfAction में, किसी दस्तावेज़ के लिंक की एक जोड़ी और अगली स्क्रीन को खोलने के लिए एक नाम जहां उपयोगकर्ता इस दस्तावेज़ को पढ़ सकता है।

यहाँ घटक ही है:

 class AboutComponent( private val setVersionName: ActionMapper<String>, private val openPdfAction: ActionMapper<Pair<String, String>>) { fun binder(): AboutEventsBinder { val openPolicyPrivacy = OpenPdfActionCreator(openPdfAction, someUrlString) val openProcessingPersonalData = OpenPdfActionCreator(openPdfAction, anotherUrlString) val setVersionName = setVersionName.toSimpleActionCreator( moreComponent::currentVersionName ) return AboutEventsBinder(setVersionName, openPolicyPrivacy, openProcessingPersonalData) } } 

मुझे आपको याद दिलाना है कि:

 typealias Action = () -> Unit typealias ActionMapper<T> = (T) -> Action 

ठीक है, चलो आगे बढ़ते हैं।

 fun binder(): AboutEventsBinder 

आइए AboutEventsBinder के बारे में अधिक विस्तार से देखें।

 class AboutEventsBinder(private val setVersionName: ActionOnEvent, private val openPolicyPrivacy: ActionOnEvent, private val openProcessingPersonalData: ActionOnEvent) : BaseEventsBinder<AboutEvents>() { override fun bindInternal(events: AboutEvents): Observable<Action> { return Observable.merge( setVersionName(events.bindEvent), openPolicyPrivacy(events.openPolicyPrivacyEvent), openProcessingPersonalData(events.openProcessingPersDataEvent)) } } 

ActionOnEvent एक अन्य टाइपेलियास है, इसलिए हर बार लिखना नहीं है।

 ActionCreator<Observable<*>> 

AboutEventsBinder में, हम ActionCreators पास करते हैं और, उन्हें इनवॉइस करते हुए, एक विशेष ईवेंट में बाँधते हैं। लेकिन यह समझने के लिए कि यह सब कैसे जोड़ता है, आइए आधार वर्ग - बेसइवैंट्सबाइंडर को देखें।

 abstract class BaseEventsBinder<in EVENTS : BaseEvents>( private val uiScheduler: Scheduler = AndroidSchedulers.mainThread() ) { fun bind(events: EVENTS) { bindInternal(events).observeOn(uiScheduler) .takeUntil(events.unbindEvent) .subscribe(Action::invoke) } protected abstract fun bindInternal(events: EVENTS): Observable<Action> } 

हम परिचित बाइंडेंट विधि को देखते हैं, जिसे हमने उत्तराधिकारी में फिर से परिभाषित किया है। अब बाइंड विधि पर विचार करें। सारा जादू यहां है। हम BaseEvents इंटरफ़ेस के उत्तराधिकारी को स्वीकार करते हैं, इसे घटनाक्रम और क्रियाओं को जोड़ने के लिए bindInternal को पास करते हैं। एक बार जब हम कहते हैं कि जो भी आता है, हम ui- स्ट्रीम पर अमल करते हैं और सदस्यता लेते हैं। हम एक दिलचस्प हैक भी देखते हैं - takeUntil।

 interface BaseEvents { val unbindEvent: EventObservable } 

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

 val openPolicyPrivacy = OpenPdfActionCreator(openPdfAction, policyPrivacyUrl) val openProcessingPersonalData = OpenPdfActionCreator(openPdfAction, personalDataUrl) 

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

 class OpenPdfActionCreator( private val openPdfAction: ActionMapper<Pair<String, String>>, private val pdfUrl: String) : ActionOnEvent { override fun invoke(event: EventObservable): Observable<Action> { return event.map { openPdfAction(pdfUrl to pdfUrl.substringAfterLast(FILE_NAME_DELIMITER)) } } } 

ActionCreator कोड भी यथासंभव सरल है, यहाँ हम कुछ स्ट्रिंग जोड़तोड़ करते हैं।

आइए घटक पर वापस जाएं और निम्नलिखित ActionCreator पर विचार करें:

 setVersionName.toSimpleActionCreator(moreComponent::currentVersionName) 

एक बार हम भी वही और स्वाभाविक रूप से सरल ActionCreators लिखने के लिए आलसी हो गए। हमने कोटलिन की शक्ति का इस्तेमाल किया और विस्तार लिखा। उदाहरण के लिए, इस मामले में, हमें ActionMapper को एक स्थिर स्ट्रिंग पास करने की आवश्यकता है।

 fun <R> ActionMapper<R>.toSimpleActionCreator( mapper: () -> R): ActionCreator<Observable<*>> { return object : ActionCreator<Observable<*>> { override fun invoke(event: Observable<*>): Observable<Action> { return event.map { this@toSimpleActionCreator(mapper()) } } } } 

ऐसे समय होते हैं जब हमें कुछ भी प्रसारित करने की आवश्यकता नहीं होती है, लेकिन केवल कुछ कार्रवाई को कॉल करें - उदाहरण के लिए, निम्न स्क्रीन खोलने के लिए:

 fun Action.toActionCreator(): ActionOnEvent { return object : ActionOnEvent { override fun invoke(event: EventObservable): Observable<Action> { return event.map { this@toActionCreator } } } } 

इसलिए, घटक के साथ, खंड पर वापस जाएं:

 val events = AboutEventsImpl( bindEvent = bindEvent, openPolicyPrivacyEvent = confidentialityPolicy.throttleFirstClicks(), openProcessingPersDataEvent = personalDataProtection.throttleFirstClicks(), unbindEvent = unBindEvent) 

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

 fun <T> NaviComponent.observe(event: Event<T>): Observable<T> = RxNavi.observe(this, event) val unBindEvent: Observable<*> = observe(Event.DESTROY_VIEW) val bindEvent: Observable<*> = Observable.just(true)  val bindEvent = observe(Event.POST_CREATE) 

ईवेंट्स इंटरफ़ेस एक विशेष स्क्रीन की घटनाओं का वर्णन करता है, साथ ही इसे बेसइवेन्ट्स का वारिस होना चाहिए। निम्नलिखित हमेशा इंटरफ़ेस का कार्यान्वयन है। इस मामले में, घटनाएँ स्क्रीन पर आने वालों के साथ एक के बाद एक होने लगीं, लेकिन ऐसा होता है कि आपको दो घटनाओं को एक साथ रखने की आवश्यकता होती है।

उदाहरण के लिए, एक त्रुटि के मामले में खोलने और फिर से लोड करने पर स्क्रीन लोड होने की घटनाओं को एक में जोड़ा जाना चाहिए - बस स्क्रीन लोड करना।

 interface AboutEvents : BaseEvents { val bindEvent: EventObservable val openPolicyPrivacyEvent: EventObservable val openProcessingPersDataEvent: EventObservable } class AboutEventsImpl(override val bindEvent: EventObservable, override val openPolicyPrivacyEvent: EventObservable, override val openProcessingPersDataEvent: EventObservable, override val unbindEvent: EventObservable) : AboutEvents 

हम टुकड़े पर लौटते हैं और सब कुछ एक साथ जोड़ते हैं! हम घटक को हमारे लिए बाइंडर बनाने और वापस करने के लिए कहते हैं, फिर हम उस पर बाइंड विधि कहते हैं, जहां हम स्क्रीन घटनाओं को देखने वाली वस्तु को पास करते हैं।

 component.binder().bind(events) 

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

अध्याय 4. बोनस

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

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

चरण 1 हम TrackAnalytics में घटनाओं को लपेटकर BaseEventsBinder बेस क्लास को थोड़ा बदल देते हैं:

 abstract class BaseEventsBinder<in EVENTS : BaseEvents>( private val trackAnalytics: TrackAnalytics<EVENTS> = EmptyAnalyticsTracker(), private val uiScheduler: Scheduler = AndroidSchedulers.mainThread()) { @SuppressLint("CheckResult") fun bind(events: EVENTS) { bindInternal(trackAnalytics(events)).observeOn(uiScheduler) .takeUntil(events.unbindEvent) .subscribe(Action::invoke) } protected abstract fun bindInternal(events: EVENTS): Observable<Action> } 

चरण 2 हम पिछड़े संगतता को बनाए रखने के लिए और उन वारिसों को नहीं तोड़ने के लिए, जिन्होंने अभी तक एनालिटिक्स की आवश्यकता नहीं है, ट्रैकअनालिटिक्स चर का एक स्थिर कार्यान्वयन बनाते हैं:

 interface TrackAnalytics<EVENTS : BaseEvents> { operator fun invoke(events: EVENTS): EVENTS } class EmptyAnalyticsTracker<EVENTS : BaseEvents> : TrackAnalytics<EVENTS> { override fun invoke(events: EVENTS): EVENTS = events } 

चरण 3 हम वांछित स्क्रीन के लिए TrackAnalytics इंटरफ़ेस का कार्यान्वयन लिखते हैं - उदाहरण के लिए, प्रोजेक्ट सूची स्क्रीन के लिए:

 class TrackProjectsEvents : TrackAnalytics<ProjectsEvents> { override fun invoke(events: ProjectsEvents): ProjectsEvents { return object : ProjectsEvents by events { override val boardClickEvent = events.boardClickEvent.trackTypedEvent { allProjectsProjectClick(it.title) } override val openBoardCreationEvent = events.openBoardCreationEvent.trackEvent { allProjectsAddProjectClick() } override val openCardsSearchEvent = events.openCardsSearchEvent.trackEvent { allProjectsSearchBarClick() } } } } 

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

 inline fun <T> Observable<T>.trackEvent(crossinline event: AnalyticsSpec.() -> Unit): Observable<T> = doOnNext { event(analyticsSpec) } inline fun <T> Observable<T>.trackTypedEvent(crossinline event: AnalyticsSpec.(T) -> Unit): Observable<T> = doOnNext { event(analyticsSpec, it) } 

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

 class ProjectsEventsBinder( private val loadItems: LoadItemsActionCreator, private val refreshBoards: ActionOnEvent, private val openBoard: ActionCreator<Observable<BoardId>>, private val openScreen: ActionOnEvent, private val openCardSearch: ActionOnEvent, trackAnalytics: TrackAnalytics<ProjectsEvents>) : BaseEventsBinder<ProjectsEvents>(trackAnalytics) 

आप GitHub पर अन्य उदाहरण देख सकते हैं।

क्यू एंड ए

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

इस लेख को लिखने में उनकी मदद के लिए टिंकॉफ बिजनेस मोबाइल डेवलपमेंट टीम के सहयोगियों का धन्यवाद।