ActionViews या मुझे बचपन से बॉयलरप्लेट कैसे पसंद नहीं है

नमस्कार, हेब्र! इस लेख में मैं विभिन्न दृश्य प्रकारों के प्रदर्शन को स्वचालित करने के लिए अपना स्वयं का तंत्र बनाने का अनुभव साझा करना चाहता हूं: ContentView, LoadingView, NoInternetView, EmptyContentView, ErrorView।

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

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

ActionViews

मेरे एक सहयोगी ने कहा कि दृश्य के व्यवहार को मानकीकृत करना असंभव था, लेकिन मैंने अभी भी इसे करने की कोशिश की। और कर दिया।

मानक एप्लिकेशन स्क्रीन, जिसका डेटा सर्वर से लिया गया है, उसे कम से कम 5 राज्यों को संसाधित करना चाहिए:

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

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

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

ऐसे दृश्य के साथ काम करने का मानक तरीका (या शायद एक नहीं) है।

RxJava के साथ काम करने वाले तरीकों में, आपको ActionViews के सभी प्रकारों के लिए इनपुट तर्क जोड़ने और ActionViews को दिखाने और छिपाने के लिए इन कॉलों में कुछ तर्क जोड़ना होगा, जैसा कि यहाँ किया गया है:

public void getSomeData(LoadingView loadingView, ErrorView errorView, NoInternetView noInternetView, EmptyContentView emptyContentView) { mApi.getProjects() .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .doOnSubscribe(disposable -> { loadingView.show(); noInternetView.hide(); emptyContentView.hide(); }) .doFinally(loadingView::hide) .flatMap(projectResponse -> { /*    */ }) .subscribe( response -> {/*   */}, throwable -> { if (ApiUtils.NETWORK_EXCEPTIONS .contains(throwable.getClass())) noInternetView.show(); else errorView.show(throwable.getMessage()); } ); } 

लेकिन इस पद्धति में बड़ी मात्रा में बॉयलरप्लेट हैं, और डिफ़ॉल्ट रूप से हम इसे पसंद नहीं करते हैं। और इसलिए मैंने रूटीन कोड को कम करने पर काम शुरू किया।

स्तर ऊपर

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

अब हमारा कोड इस तरह दिखता है:

 public void getSomeData(LoadingView loadingView, ErrorView errorView, NoInternetView noInternetView, EmptyContentView emptyContentView) { mApi.getProjects() .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .compose(RxUtil::loading(loadingView)) .compose(RxUtil::emptyContent(emptyContentView)) .compose(RxUtil::noInternet(errorView, noInternetView)) .subscribe(response -> { /*   */ }, RxUtil::error(errorView)); } 

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

निर्णायक बिंदु

तंत्र के कई पुनर्लेखन के बाद, मैं इस विकल्प पर आया:

 public void getSomeData() { execute(() -> mApi.getProjects(), new BaseSubscriber<>(response -> { /*   */ })); } 

मैंने अपने तंत्र को लगभग 10-15 बार फिर से लिखा, और हर बार यह पिछले संस्करण से बहुत अलग था। मैं आपको सभी संस्करण नहीं दिखाऊंगा, चलो दो अंतिम लोगों पर ध्यान केंद्रित करें। पहले तुम सिर्फ देखते थे।

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

भविष्य में इस तरह के एक कोड को बनाए रखने के लिए कठिन और कठिन हो जाएगा, और इसमें स्वयं काफी गंभीर नुकसान और समस्याएं थीं जो महत्वपूर्ण थीं:

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

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

अलविदा जावा!

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

पहले तो वह बहुत ज्यादा नहीं दिखे। लेकिन अब वह लगभग सभी कमियों से वंचित है, जो सिद्धांत रूप में हो सकता है।

यहाँ हमारा पिछला कोड है, लेकिन अंतिम संस्करण में:

 fun getSomeData() { api.getProjects() .withActionViews(view) .execute(onComplete = { /*   */ }) } 

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

 fun getSomeData() { api.getProjects() .withActionViews( view, doOnLoadStart = { /* */ }, doOnLoadEnd = { /* */ }) .execute(onComplete = { /*   */ }) } 

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

 fun getSomeData(projectLoadingView: LoadingView) { mApi.getPosts(1, 1) .withActionViews( view, loadingView = projectLoadingView ) .execute(onComplete = { /*   */ }) } 

मैंने आपको इस तंत्र की बहुत क्रीम दिखाई, लेकिन इसकी अपनी कीमत भी है।
सबसे पहले, आपको काम करने के लिए CustomViews बनाने की आवश्यकता होगी:

 class SwipeRefreshLayout : android.support.v4.widget.SwipeRefreshLayout, LoadingView { constructor(context: Context) : super(context) constructor(context: Context, attrs: AttributeSet) : super(context, attrs) } 

ऐसा करना आवश्यक भी नहीं हो सकता है। फिलहाल, मैं इस तंत्र को बेहतर बनाने के लिए प्रतिक्रिया एकत्र कर रहा हूं और सुझाव स्वीकार कर रहा हूं। CustomViews का उपयोग करने के लिए हमें एक मुख्य कारण इंटरफ़ेस से विरासत में मिला है, जो बताता है कि यह किस प्रकार का ActionView है। यह सुरक्षा के लिए है, क्योंकि जब आप देखें प्रकार को withActionsViews विधि में निर्दिष्ट करते समय गलती से गलती कर सकते हैं।

यह वही है जो withActionsViews विधि से दिखता है:

 fun <T> Observable<T>.withActionViews( view: ActionsView, contentView: View = view.contentActionView, loadingView: LoadingView? = view.loadingActionView, noInternetView: NoInternetView? = view.noInternetActionView, emptyContentView: EmptyContentView? = view.emptyContentActionView, errorView: ErrorView = view.errorActionView, doOnLoadStart: () -> Unit = { doOnLoadSubscribe(contentView, loadingView) }, doOnLoadEnd: () -> Unit = { doOnLoadComplete(contentView, loadingView) }, doOnStartNoInternet: () -> Unit = { doOnNoInternetSubscribe(contentView, noInternetView) }, doOnNoInternet: (Throwable) -> Unit = { doOnNoInternet(contentView, errorView, noInternetView) }, doOnStartEmptyContent: () -> Unit = { doOnEmptyContentSubscribe(contentView, emptyContentView) }, doOnEmptyContent: () -> Unit = { doOnEmptyContent(contentView, errorView, emptyContentView) }, doOnError: (Throwable) -> Unit = { doOnError(errorView, it) } ) { /**/ } 

यह डरावना लग रहा है, लेकिन सुविधाजनक और तेज! जैसा कि आप देख सकते हैं, इनपुट मापदंडों में यह loadingView को स्वीकार करता है: LoadingView? .. यह हमें ActionView प्रकार के साथ त्रुटियों के खिलाफ प्रेरित करता है।

तदनुसार, कार्य करने के तंत्र के लिए, आपको कुछ सरल कदम उठाने की आवश्यकता है:

• हमारे लेआउट में जोड़ें हमारे ActionViews, जो कस्टम हैं। मैंने पहले से ही उनमें से कुछ बनाये हैं, और आप उन्हें इस्तेमाल कर सकते हैं।
• HasActionsView इंटरफ़ेस लागू करें और कोड में ActionViews के लिए ज़िम्मेदार डिफ़ॉल्ट चर को ओवरराइड करें:
  

   override var contentActionView: View by mutableLazy { recyclerView } override var loadingActionView: LoadingView? by mutableLazy { swipeRefreshLayout } override var noInternetActionView: NoInternetView? by mutableLazy { noInternetView } override var emptyContentActionView: EmptyContentView? by mutableLazy { emptyContentView } override var errorActionView: ErrorView by mutableLazy { ToastView(baseActivity) } 

• या उस वर्ग से विरासत में, जिसमें हमारे एक्शन व्यू पहले से ही ओवरराइड हैं। इस स्थिति में, आपको अपने लेआउट में कड़ाई से निर्दिष्ट आईडी का उपयोग करना होगा:

  
  

   abstract class ActionsFragment : Fragment(), HasActionsView { override var contentActionView: View by mutableLazy { findViewById<View>(R.id.contentView) } override var loadingActionView: LoadingView? by mutableLazy { findViewByIdNullable<View>(R.id.loadingView) as LoadingView? } override var noInternetActionView: NoInternetView? by mutableLazy { findViewByIdNullable<View>(R.id.noInternetView) as NoInternetView? } override var emptyContentActionView: EmptyContentView? by mutableLazy { findViewByIdNullable<View>(R.id.emptyContentView) as EmptyContentView? } override var errorActionView: ErrorView by mutableLazy { ToastView(baseActivity) } } 

  
  
• एक बॉयलर के बिना काम का आनंद लें!

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

 import kotlinx.android.synthetic.main.fr_gifts.contentView as recyclerView 

आगे क्या है?

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

जबकि मैं एक लेख लिख रहा था ...

मैं पुस्तकालयों के रूप में सब कुछ व्यवस्थित करने में कामयाब रहा:

• ActionViews-ViewModel - MVVM के लिए
• एक्शन व्यू-एमवीपी - एमवीपी के लिए

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

यदि आपके पास तंत्र की कार्यक्षमता और संचालन में सुधार के लिए कोई सुझाव और सिफारिशें हैं, तो मुझे उनकी बात सुनकर खुशी होगी। टिप्पणियों में आपका स्वागत है और, बस, मेरे टेलीग्राम: @tanchuev पर

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

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

पीपीपीएस यदि आप मेरे काम में रुचि रखते हैं, तो हम 28 सितंबर को मॉस्को में एमबीएलटी डीईवी 2018 इंटरनेशनल मोबाइल डेवलपर्स कॉन्फ्रेंस में व्यक्तिगत रूप से चर्चा कर सकते हैं। वैसे, शुरुआती पक्षी टिकट पहले से ही बाहर चल रहे हैं!