🧚🏻 🍁 💂🏼 RESS - मोबाइल एप्लिकेशन के लिए नया आर्किटेक्चर 🦕 💊 👋🏽

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

परिचय

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

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

मौजूदा समाधान खराब क्यों हैं?

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

1. आर्किटेक्चर सरल होना चाहिए

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

2. ओवर-इंजीनियरिंग खराब है

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

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

अब VIPER के बारे में, उदाहरण के लिए, इस लेख के आरेख पर देखें।

योजना

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

नया तरीका

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

तुरंत आरक्षण करें, यह आर्किटेक्चर REST क्लाइंट्स के लिए है। अन्य प्रकार के अनुप्रयोगों के लिए, यह शायद काम नहीं करेगा।

1. भंडारण

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

2. स्क्रीन

एंड्रॉइड के मामले में एप्लिकेशन स्क्रीन, यह आपकी गतिविधि है। अन्य शब्दों में, यह Apple के MVC की तरह एक नियमित ViewController है।

3. निवेदन

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

4. घटना

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

निम्नलिखित सरलीकृत कार्यान्वयन का एक उदाहरण है। कोड मान्यताओं के साथ लिखा गया था और इसकी जाँच नहीं की गई थी, इसलिए इसमें सिंटैक्स त्रुटियां और टाइपोस हो सकते हैं

प्रार्थना

public class Request { public interface RequestListener { default void onApiMethod1(Json answer) {} default void onApiMethod2(Json answer) {} } private static class RequestTask extends AsyncTask<Void, Void, String> { public RequestTask(String methodName) { this.methodName = methodName; } private String methodName; @Override protected String doInBackground(Void ... params) { URL url = new URL(Request.serverUrl + "/" + methodName); HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection(); // ... //      // ... return result; } @Override protected void onPostExecute(String result) { // ... //  JSON  result // ... Requestr.onHandleAnswer(methodName, json); } } private static String serverUrl = "myserver.com"; private static List<OnCompleteListener> listeners = new ArrayList<>(); private static void onHandleAnswer(String methodName, Json json) { for(RequestListener listener : listeners) { if(methodName.equals("api/method1")) listener.onApiMethod1(json); else if(methodName.equals("api/method2")) listener.onApiMethod2(json); } } private static void makeRequest(String methodName) { new RequestTask(methodName).executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR); } public static void registerListener(RequestListener listener) { listeners.add(listener); } public static void unregisterListener(RequestListener listener) { listeners.remove(listener); } public static void apiMethod1() { makeRequest("api/method1"); } public static void onApiMethod2() { makeRequest("api/method2"); } }

भंडारण

 public class DataStorage { public interface DataListener { default void onData1Changed() {} default void onData2Changed() {} } private static MyObject1 myObject1 = null; private static List<MyObject2> myObjects2 = new ArrayList<>(); public static void registerListener(DataListener listener) { listeners.add(listener); } public static void unregisterListener(DataListener listener) { listeners.remove(listener); } public static User getMyObject1() { return myObject1; } public static List<MyObject2> getMyObjects2() { return myObjects2; } public static Request.RequestListener listener = new Request.RequestListener() { private T fromJson<T>(Json answer) { // ... //    JSON // ... return objectT; } @Override public void onApiMethod1(Json answer) { myObject1 = fromJson(answer); for(RequestListener listener : listeners) listener.data1Changed(); } @Override public void onApiMethod2(Json answer) { myObject2 = fromJson(myObjects2); for(RequestListener listener : listeners) listener.data2Changed(); } }; }

स्क्रीन

 public class MyActivity extends Activity implements DataStorage.DataListener { private Button button1; private Button button2; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); button1.setOnClickListener((View) -> { Request.apiMethod1(); }); button2.setOnClickListener((View) -> { Request.apiMethod2(); }); updateViews(); } @Override protected void onPause() { super.onPause(); DataStorage.unregisterListener(this); } @Override protected void onResume() { super.onResume(); DataStorage.registerListener(this); updateViews(); } private void updateViews() { updateView1(); updateView2(); } private void updateView1() { Object1 data = DataStorage.getObject1(); // ... //     // ... } private void updateView2() { List<Object2> data = DataStorage.getObjects2(); // ... //     // ... } @Override public void onData1Changed() { updateView1(); } @Override public void onData2Changed() { updateView2(); } }

ऐप

 public class MyApp extends Application { @Override public void onCreate() { super.onCreate(); Request.registerListener(DataStorage.listener); } }

वही किन्नर, लेकिन समझ के लिए RESS के संदर्भ में

यह इस तरह काम करता है: जब आप बटन पर क्लिक करते हैं, तो अनुरोध के लिए वांछित विधि चिकोटी होती है, अनुरोध सर्वर को एक अनुरोध भेजता है, प्रतिक्रिया की प्रक्रिया करता है और पहले डाटास्टोर को सूचित करता है। DataStorage प्रतिक्रिया को पार्स करता है और घर पर डेटा को कैश करता है। अनुरोध तब वर्तमान में सक्रिय स्क्रीन को सूचित करता है, स्क्रीन डेटास्टोर से डेटा लेती है और UI को अपडेट करती है।

स्क्रीन संकेत और क्रमशः Resume और onPause में मध्यस्थता से सदस्यता समाप्त करता है। यह onResume के अलावा UI को भी अपडेट करता है। यह क्या देता है? सूचनाएं केवल वर्तमान सक्रिय गतिविधि में आती हैं, पृष्ठभूमि में अनुरोध को संसाधित करने या गतिविधि को चालू करने में कोई समस्या नहीं है। गतिविधि हमेशा अद्यतित रहेगी। अधिसूचना पृष्ठभूमि गतिविधि तक नहीं पहुंचेगी, और सक्रिय स्थिति में लौटने पर, डेटा को डेटास्टोर से लिया जाएगा। नतीजतन, जब आप स्क्रीन को घुमाते हैं और गतिविधि को फिर से बनाते हैं तो कोई समस्या नहीं है।

और इस सब के लिए, एंड्रॉइड एसडीके से डिफ़ॉल्ट एपीआई पर्याप्त हैं।

भविष्य की आलोचना के लिए प्रश्न और उत्तर

1. लाभ क्या है?

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

2. AsyncTask एक बुरा आदमी है, कम से कम Retrofit लो!

हाँ? और इस कोड में क्या समस्याएं आती हैं? मेमोरी लीक? नहीं, यहाँ AsyncTask सक्रियण के लिंक को संग्रहीत नहीं करता है, लेकिन केवल एक स्थैतिक विधि का लिंक है। जवाब खो गया है? नहीं, जवाब हमेशा स्थैतिक DataStorage के लिए आता है जब तक कि आवेदन को मार नहीं दिया जाता है। ठहराव पर गतिविधि को ताज़ा करने की कोशिश कर रहा है? नहीं, सूचनाएं केवल सक्रिय गतिविधि में आती हैं।

और यहां रेट्रोफिट कैसे मदद कर सकता है? जरा यहां देखिए। लेखक ने RxJava, Retrofit लिया और अभी भी एक समस्या को हल करने के लिए बैसाखी को काटता है जो RESS के पास नहीं है।

3. स्क्रीन एक ही ViewController है! तर्क और प्रस्तुति को अलग करने की जरूरत है, गिरफ्तारी!

इस मंत्र को पहले ही गिरा दें। REST सेवा के लिए एक विशिष्ट क्लाइंट सर्वर पक्ष के लिए एक बड़ा दृश्य है। आपके सभी व्यावसायिक तर्क एक बटन या पाठ क्षेत्र के लिए सही स्थिति सेट करना है। आप वहां क्या साझा करने जा रहे हैं? कहो इसे बनाए रखना आसान होगा? 1 टन आसान के साथ 1 फ़ाइल के बजाय 3 टन कोड के साथ 3 फाइलें बनाए रखें? लगभग। और अगर हमारे पास 5 टुकड़ों के साथ गतिविधि है? यह पहले से ही 3 x (5 + 1) = 18 फाइलें है।

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

लेकिन बड़ी परियोजनाओं में ViewController बहुत बढ़ता है? इसलिए आपने बड़े प्रोजेक्ट नहीं देखे हैं। 5 हजार लाइनों वाली अगली साइट के लिए आपका REST क्लाइंट एक छोटी परियोजना है, और 5 हजार लाइनें केवल इसलिए हैं क्योंकि प्रत्येक स्क्रीन पर 5 कक्षाएं हैं। 100 + स्क्रीन और 10 लोगों की कई टीमों के साथ RESS पर वास्तव में बड़ी परियोजनाएं बहुत अच्छी लगती हैं। बस कुछ अनुरोध और संग्रहण करें। और बोल्ड स्क्रीन के लिए स्क्रीन में बड़े यूआई तत्वों के लिए अतिरिक्त स्क्रीन होती है, उदाहरण के लिए, समान टुकड़े। उसी पैमाने के एमवीपी पर एक परियोजना बस प्रस्तुतकर्ता, इंटरफेस, सक्रियण, टुकड़े और असंबद्ध कनेक्शनों के एक समूह में डूब जाएगी। और VIPER के लिए संक्रमण आम तौर पर पूरी टीम को एक दिन छोड़ देगा।

निष्कर्ष

मुझे उम्मीद है कि यह लेख कई डेवलपर्स को वास्तुकला पर अपने विचारों पर पुनर्विचार करने के लिए प्रोत्साहित करेगा, न कि अमूर्त का उत्पादन करने और सरल और अधिक समय-परीक्षण किए गए समाधानों को देखने के लिए।

RESS - मोबाइल एप्लिकेशन के लिए नया आर्किटेक्चर