एक से दो आवेदन कैसे करें। Tinkoff जूनियर अनुभव

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

— , ̆ 14 . , (, ), , , (, ).

।

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

ग्रैड फ्लेवर

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

उपमोडल

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

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

मल्टी-मॉड्यूल वास्तुकला

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

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

नतीजतन, हम दो एप्लिकेशन मॉड्यूल प्राप्त करना चाहते थे: वयस्क और जूनियर और कुछ सामान्य कोर मॉड्यूल। हमने दो विकल्पों की पहचान की है:

• कॉमन कोड को आम कॉमन मॉड्यूल में डालना। यह दृष्टिकोण "अधिक सही" है, लेकिन इसमें अधिक समय लगता है। हमने अनुमान लगाया कि कोड का पुन: उपयोग लगभग 80% है।
  
• एप्लिकेशन मॉड्यूल को लाइब्रेरी में परिवर्तित करें और इस लाइब्रेरी को पतले वयस्क और जूनियर मॉड्यूल से कनेक्ट करें। यह विकल्प तेज़ है, लेकिन यह Tinkoff Junior के लिए कोड लाएगा जिसे कभी भी निष्पादित नहीं किया जाएगा।
  

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

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

एप्लिकेशन को लाइब्रेरी में बदलना

किसी एप्लिकेशन को लाइब्रेरी में बदलने के लिए प्रलेखन के सरल निर्देश हैं । इसमें चार सरल बिंदु शामिल हैं और, यह प्रतीत होता है, कोई कठिनाई नहीं होनी चाहिए:

1. ओपन मॉड्यूल build.gradle फ़ाइल
2. मॉड्यूल कॉन्फ़िगरेशन से ApplicationId निकालें
3. फ़ाइल की शुरुआत में, apply plugin: 'com.android.application' जगह apply plugin: 'com.android.application' apply plugin: 'com.android.library' साथ apply plugin: 'com.android.library'
4. परिवर्तनों को सहेजें और एंड्रॉइड स्टूडियो में प्रोजेक्ट को सिंक्रोनाइज़ करें ( फाइल> ग्रैडल फाइल के साथ सिंक प्रोजेक्ट )

हालाँकि, रूपांतरण में कई दिन लग गए और परिणामी अंतर इस तरह निकला:

• 183 फाइलें बदलीं
• 1601 सम्मिलन (+)
• 1920 विलोपन (-)

क्या गलत हुआ?

सबसे पहले, पुस्तकालयों में, संसाधन पहचानकर्ता स्थिरांक नहीं हैं। पुस्तकालयों में, अनुप्रयोगों के रूप में, संसाधन पहचानकर्ताओं की एक सूची के साथ एक R.java फ़ाइल उत्पन्न होती है। और पुस्तकालयों में, पहचानकर्ता मान स्थिर नहीं होते हैं। जावा आपको गैर-स्थिर मूल्यों पर स्विच करने की अनुमति नहीं देता है, और सभी स्विचों को अगर-और के साथ प्रतिस्थापित किया जाना चाहिए।

 // Application int id = view.getId(); switch(id) { case R.id.button1: action1(); break; case R.id.button2: action2(); break; } // Library int id = view.getId(); if (id == R.id.button1) { action1(); } else if (id == R.id.button2) { action2(); } 

इसके बाद, हम एक पैकेज टक्कर में आए।
मान लें कि आपके पास एक लाइब्रेरी है जिसमें पैकेज = com.example है , और पैकेज = com.example.app के साथ आवेदन इस लाइब्रेरी पर निर्भर करता है। फिर कक्षा com.example.R को लाइब्रेरी में उत्पन्न किया जाएगा, और com.example.app.R , क्रमशः अनुप्रयोग में। अब हम एप्लिकेशन में com.example.MainActivity गतिविधि बनाते हैं, जिसमें हम आर-क्लास तक पहुंचने का प्रयास करेंगे। स्पष्ट आयात के बिना, पुस्तकालय के आर-वर्ग का उपयोग किया जाएगा, जिसमें आवेदन संसाधन निर्दिष्ट नहीं हैं, लेकिन केवल पुस्तकालय संसाधन हैं। हालांकि, एंड्रॉइड स्टूडियो त्रुटि को उजागर नहीं करता है, और जब आप कोड से संसाधन तक स्विच करने का प्रयास करते हैं, तो सबकुछ ठीक हो जाएगा।

कटार

हम निर्भरता इंजेक्शन के लिए एक ढांचे के रूप में डैगर का उपयोग करते हैं।
प्रत्येक मॉड्यूल में एक्टिविटीज़, टुकड़े और सेवाएं शामिल हैं, हमारे पास नियमित इंटरफेस हैं जो इन संस्थाओं के लिए इंजेक्शन विधियों का वर्णन करते हैं। एप्लिकेशन मॉड्यूल ( वयस्क और जूनियर ) में, डैगर घटक इंटरफेस इन इंटरफेस से विरासत में मिला है। मॉड्यूल में, हम घटकों को इस मॉड्यूल के लिए आवश्यक इंटरफेस में लाते हैं।

Multibindingi

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

जायके

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

निष्कर्ष

कुछ ही समय में हमने एक नया आवेदन लागू किया है। अब हम दो अनुप्रयोगों में नई कार्यक्षमता को एक बार में लिखते हैं।

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