Android वातावरण

प्रस्तावना

दूर 2012 से, हेब्रा के खुले स्थानों में, मुझे टिप्पणी याद है:

... अगर शुरू से ही कोई मामला नहीं है, तो डिवाइस रहेगा
अधूरा है, एक शेल्फ पर धूल गिर जाएगी ...

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

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

विभिन्न प्रकार की असेंबली के लिए, मैंने पर्यावरण चर के विवरण के साथ विभिन्न कॉन्फ़िगरेशन फ़ाइलों का उपयोग किया। लेकिन समस्या यह थी कि वास्तविक कोड में मूल्य को आगे बढ़ाने के लिए, प्रत्येक प्रकार के लिए एक ही कोड लिखना आवश्यक था।

समस्या

Google हमें प्रत्येक के लिए कस्टम मानों को अग्रेषित करने की क्षमता देता है
विधानसभा ।

android { //... buildTypes { release { buildConfigField("String", "HOST_URL", "\"prod.com\"") } debug { buildConfigField("String", "HOST_URL", "\"debug.com\"") } } } 

Build.gradle स्क्रिप्ट का विश्लेषण करने के बाद, android उपकरण buildTypes और productFlavors से buildConfigFileds के सभी मान लेगा और प्रत्येक प्रकार की असेंबली के लिए BuildConfig फाइलें जनरेट करेगा :

 public final class BuildConfig { //... // Fields from build type: release public static final String HOST_URL = "prod.com"; } 

पहली नज़र में कोई समस्या नहीं। खासकर जब आपके आवेदन में इतने सारे स्वाद और कस्टम मूल्य नहीं हैं। मेरी परियोजना में> 20 और 3 वातावरण (आंतरिक / अल्फा / उत्पादन) थे। जाहिर है, मेरे लिए केवल एक ही समस्या थी - बॉयलरप्लेट से छुटकारा पाने के लिए।

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

समस्या को हल करने का तरीका

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

यदि हम थोड़ा पीछे जाते हैं, तो हमारे पास एक मध्यवर्ती कदम है: buildConfigField से BuildConfig वर्ग के क्षेत्र में। लेकिन यह कौन करता है? सब कुछ बहुत सुंदर है, आप जिस तरह से सभी एंड्रॉइड प्रोजेक्ट में कनेक्ट होते हैं, उसके लिए जिम्मेदार है।

 apply plugin: "com.android.application" 

यह वह है जो इस तथ्य के लिए जिम्मेदार है कि आपकी build.gradle फ़ाइल का विश्लेषण करने के बाद, BuildConfig वर्ग अपने स्वयं के खेतों के साथ प्रत्येक स्वाद के लिए उत्पन्न होगा। इस तरह, मैं अपनी दवा लिख ​​सकता हूं जो com.android.application की क्षमताओं का विस्तार करेगी और बचाएगी
मुझे इस सिरदर्द से।

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

निर्णय

ऊपर हमने समाधान की संरचना का पता लगाया, केवल एक चीज जो बची है, वह है इसे जीवन में उतारना। ऐसा लगता है कि एक सामान्य समाधान फ़ाइल एक्सटेंशन द्वारा एक तुच्छ समाधान और एक समस्या को हल किया जा सकता है। शुरू में, मैंने ऐसा किया।

 ```groovy class Constants { // Environments properties path pattern, store your config files in each folders of pattern static final CONFIG_PROPERTY_PATTERN = "config/%s/config.properties" } android.buildTypes.all { buildType -> buildConfigFields(buildType, buildType.name) } android.applicationVariants.all { appVariant -> buildConfigFields(appVariant, appVariant.flavorName) } private def buildConfigFields(Object variant, String variantName) { def properties = getProperties(variantName) properties.each { key, value -> variant.buildConfigField( parseValueType(value), toConfigKey(key), value ) } } // Convert config property key to java constant style private def toConfigKey(String key) { return key.replaceAll("(\\.)|(-)", "_") .toUpperCase() } // Parse configuration value type private def parseValueType(String value) { if (value == null) { throw new NullPointerException("Missing configuration value") } if (value =~ "[0-9]*L" ) { return "Long" } if (value.isInteger()) { return "Integer" } if (value.isFloat()) { return "Float" } if ("true" == value.toLowerCase() || "false" == value.toLowerCase()) { return "Boolean" } return "String" } private def getProperties(String variantName) { def propertiesPath = String.format( Constants.CONFIG_PROPERTY_PATTERN, variantName ) def propertiesFile = rootProject.file(propertiesPath) def properties = new Properties() // Do nothing, when configuration file doesn't exists if (propertiesFile.exists()) { properties.load(new FileInputStream(propertiesFile)) } return properties } ``` 

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

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

और प्लग-इन और उपयोगकर्ता को रिमोट डिलीवरी से क्या समस्याएं हल होंगी?

• एक आलसी प्रोग्रामर की समस्या। हम समस्या की जड़ और संभावित समाधानों को समझने के लिए बहुत आलसी हैं। हमारे लिए कुछ ऐसा लेना आसान है जो आपके पहले ही हो चुका है और उसका उपयोग करें।
• समर्थन करते हैं। इसमें कोड समर्थन, इसके विकास और अवसरों का विस्तार शामिल है। अपनी समस्या को हल करते समय, मैंने केवल कोड में केवल प्रोब्रोसिवनिह वातावरण को हल किया, पूरी तरह से संसाधनों को अग्रेषित करने की संभावना के बारे में भूल गया।
• कोड की गुणवत्ता। एक राय है कि कुछ डेवलपर्स खुले स्रोत कोड को भी नहीं देखते हैं जो परीक्षणों द्वारा कवर नहीं किए जाते हैं। यह 2019 है और हम आसानी से कोड की गुणवत्ता को ट्रैक करने के लिए सेवाओं को जोड़ सकते हैं https://sonarcloud.io या https://codecov.io/
• विन्यास। बिल्ड फ़ाइल एक्सटेंशन मुझे इस कोड की जांच करने और मैन्युअल रूप से बदलाव करने के लिए मजबूर करता है। मेरे मामले में, मुझे हमेशा बिल्डटाइप्स या प्रोडक्टफ्लवर्स के लिए कॉन्फ़िगरेशन का उपयोग करने की आवश्यकता नहीं है, मैं एक चीज या एक बार में सभी चाहता हूं।
• धूल भरी शेल्फ की सफाई। मैंने आखिरकार उनमें से एक को साफ किया और अपने छोटे से कमरे के इस निर्णय को आगे बढ़ाने में सक्षम था।

प्लगइन लिखते समय मैं विवरण और समस्याओं में नहीं जाता, यह एक नए विषय पर खींच रहा है। आप इसके एकीकरण के साथ निर्णय ले सकते हैं, अपने विचार का प्रस्ताव कर सकते हैं या अपना योगदान दे सकते हैं
यहाँ ।