Android में निर्भरता इंजेक्शन का भविष्य

^{मैं आपके ध्यान में जेमी सेन्सन के मूल लेख का अनुवाद लाता हूं}

Android 9 पाई से पहले गतिविधि बनाना

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

आधुनिक एंड्रॉइड विकास के लिए DI बहुत महत्वपूर्ण है। यह आपको वर्गों के बीच उपयोग की जाने वाली सेवाओं के लिंक प्राप्त करते समय कोड की कुल मात्रा को कम करने की अनुमति देता है, और आमतौर पर एप्लिकेशन को घटकों में विभाजित करता है। इस लेख में, हम Android विकास में उपयोग की जाने वाली सबसे आम DI लाइब्रेरी Dagger 2 पर ध्यान केंद्रित करेंगे। यह माना जाता है कि आपको पहले से ही इस बात का बुनियादी ज्ञान है कि यह कैसे काम करता है, लेकिन सभी सूक्ष्मताओं को समझना आवश्यक नहीं है। यह ध्यान देने योग्य है कि यह लेख थोड़ा साहसिक है। यह दिलचस्प और सभी है, लेकिन अपने लेखन के समय, एंड्रॉइड 9 पाई प्लेटफॉर्म संस्करण पैनल पर भी दिखाई नहीं दिया, इसलिए यह विषय संभवतः कम से कम कई वर्षों तक रोजमर्रा के विकास के लिए प्रासंगिक नहीं होगा।

Android में आज निर्भरता इंजेक्शन

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

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

 @Module class AppModule(val appContext: Context) { @Provides @ApplicationScope fun provideApplicationContext(): Context = appContext @Provides @ApplicationScope fun provideRepository(context: Context): Repository = Repository(context) } 

अब हमें कक्षाओं के कार्यान्वयन को संभालने के लिए Component को परिभाषित करना होगा जिसमें हम अपने Repository का उपयोग करना चाहते हैं।

 @ApplicationScope @Component(modules = [AppModule::class]) interface ApplicationComponent { fun inject(activity: MainActivity) } 

अंत में, हम अपनी रिपॉजिटरी का उपयोग करने के लिए अपनी Activity को कॉन्फ़िगर कर सकते हैं। मान लीजिए हमने अपने ApplicationComponent का एक उदाहरण कहीं और बनाया।

 class MainActivity: AppCompatActivity() { @Inject lateinit var repository: Repository override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) //    application.applicationComponent.inject(this) //       } } 

वह सब है! हम सिर्फ डैगर का उपयोग करके आवेदन के भीतर निर्भरता इंजेक्शन स्थापित करते हैं। ऐसा करने के कई तरीके हैं, लेकिन यह सबसे आसान तरीका है।

वर्तमान दृष्टिकोण में क्या गलत है?

उपरोक्त उदाहरणों में, हमने दो अलग-अलग प्रकार के इंजेक्शन देखे, एक दूसरे से अधिक स्पष्ट।

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

 fun provideRepository(context: Context): Repository = Repository(context) 

इसके लिए हमें Context आवश्यकता थी, जिसे हमने प्रदान किया है provideApplicationContext() फ़ंक्शन।

दूसरा, अधिक स्पष्ट, जो हमने देखा वह क्षेत्र में वर्ग का कार्यान्वयन है । हमारे स्टोर को प्रदान करने के लिए इस पद्धति का उपयोग हमारे MainActivity में किया गया था। यहाँ हम Inject एनोटेशन का उपयोग करके खेतों को इंजेक्शन के प्राप्तकर्ता के रूप में परिभाषित करते हैं। फिर, हमारे onCreate फ़ंक्शन में onCreate हम ApplicationComponent बताते हैं कि हमारे क्षेत्रों में निर्भरता को इंजेक्ट किया जाना चाहिए। यह किसी कंस्ट्रक्टर में एम्बेड करने जितना साफ नहीं है, क्योंकि हमारे पास हमारे घटक का एक स्पष्ट संदर्भ है, जिसका अर्थ है कि एम्बेडिंग की अवधारणा हमारे आश्रित वर्गों में अलग हो रही है। एंड्रॉइड फ्रेमवर्क कक्षाओं में एक और दोष, क्योंकि हमें यह सुनिश्चित करने की आवश्यकता है कि हम जो पहली चीज करते हैं वह निर्भरता प्रदान करता है। यदि यह जीवन चक्र में गलत बिंदु पर होता है, तो हम गलती से किसी ऐसी वस्तु का उपयोग करने का प्रयास कर सकते हैं जिसे अभी तक आरंभ नहीं किया गया है।

आदर्श रूप से, आपको पूरी तरह से वर्ग क्षेत्रों में कार्यान्वयन से छुटकारा पाना चाहिए। यह दृष्टिकोण उन वर्गों के लिए कार्यान्वयन की जानकारी को रोक देता है जिन्हें इसके बारे में जानने की आवश्यकता नहीं है, और संभवतः जीवनचक्र की समस्याओं का कारण बन सकते हैं। हमने इसे बेहतर करने के प्रयासों को देखा, और एंड्रॉइड पर डैगर एक बहुत विश्वसनीय तरीका है, लेकिन अंत में यह बेहतर होगा कि हम बस कंस्ट्रक्टर में एम्बेडिंग का उपयोग कर सकें। वर्तमान में, हम इस दृष्टिकोण का उपयोग कई फ्रेमवर्क कक्षाओं के लिए नहीं कर सकते हैं, जैसे कि "गतिविधि", "सेवा", "एप्लिकेशन", आदि, क्योंकि वे सिस्टम द्वारा हमारे लिए बनाए गए हैं। ऐसा लगता है कि फिलहाल हम कक्षाओं को खेतों में पेश करने पर अड़े हुए हैं। फिर भी, एंड्रॉइड 9 पाई कुछ दिलचस्प तैयार कर रहा है, जो, शायद, मौलिक रूप से सब कुछ बदल देगा।

Android 9 पाई में निर्भरता इंजेक्शन

जैसा कि लेख की शुरुआत में बताया गया है, एंड्रॉइड 9 पाई में एक AppComponentFactory वर्ग है। इसके लिए प्रलेखन बल्कि दुर्लभ है, और बस डेवलपर की वेबसाइट पर इस तरह पोस्ट किया गया है:

प्रकट तत्वों के निर्माण को नियंत्रित करने के लिए उपयोग किया जाने वाला इंटरफ़ेस।

यह पेचीदा है। यहां "मैनिफेस्ट एलिमेंट्स" उन वर्गों को संदर्भित करता है, जिन्हें हम अपने AndroidManifest मेनिफेस्ट फ़ाइल में सूचीबद्ध करते हैं - जैसे कि गतिविधि, सेवा और हमारे आवेदन वर्ग। यह हमें इन तत्वों के "निर्माण को नियंत्रित करने" की अनुमति देता है ... इसलिए, हे, क्या अब हम अपनी गतिविधियों को बनाने के लिए नियम निर्धारित कर सकते हैं? क्या खुशी है!

चलो गहरी खुदाई करें। हम AppComponentFactory विस्तार AppComponentFactory और AppComponentFactory विधि को ओवरराइड करके शुरू करेंगे।

 class InjectionComponentFactory: AppComponentFactory() { private val repository = NonContextRepository() override fun instantiateActivity(cl: ClassLoader, className: String, intent: Intent?): Activity { return when { className == MainActivity::class.java.name -> MainActivity(repository) else -> super.instantiateActivity(cl, className, intent) } } } 

अब हमें एप्लिकेशन टैग के अंदर अपने घटक कारखाने को घोषणा में घोषित करने की आवश्यकता है।

 <application android:allowBackup="true" android:label="@string/app_name" android:icon="@mipmap/ic_launcher" android:name=".InjectionApp" android:appComponentFactory="com.mypackage.injectiontest.component.InjectionComponentFactory" android:theme="@style/AppTheme" tools:replace="android:appComponentFactory"> 

अंत में, हम अपना एप्लिकेशन लॉन्च कर सकते हैं ... और यह काम करता है! हमारा NonContextRepository MainActivity कंस्ट्रक्टर के माध्यम से प्रदान किया जाता है। शान से!

कृपया ध्यान दें कि कुछ आरक्षण हैं। हम यहां Context का उपयोग नहीं कर सकते हैं, क्योंकि इसके अस्तित्व से पहले ही, हमारे कार्य के लिए कॉल होता है - यह भ्रामक है! हम आगे बढ़ सकते हैं ताकि निर्माणकर्ता हमारे अनुप्रयोग वर्ग को लागू कर दे, लेकिन देखते हैं कि डैगर इसे कैसे आसान बना सकते हैं।

मिलो - डैगर मल्टी-बाइंड्स

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

आइए पहले हमारी गतिविधि सेट करें कि आगे कहां जाना है।

 class MainActivity @Inject constructor( private val repository: NonContextRepository ): Activity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) //       } } 

यह तुरंत दिखाता है कि निर्भरता इंजेक्शन का लगभग कोई उल्लेख नहीं है । केवल एक चीज जो हम देखते हैं, वह है कंस्ट्रक्टर से पहले Inject एनोटेशन।

अब आपको घटक और डैगर मॉड्यूल को बदलने की आवश्यकता है:

 @Component(modules = [ApplicationModule::class]) interface ApplicationComponent { fun inject(factory: InjectionComponentFactory) } 

 @Module(includes = [ComponentModule::class]) class ApplicationModule { @Provides fun provideRepository(): NonContextRepository = NonContextRepository() } 

ज्यादा कुछ नहीं बदला है। अब हमें केवल अपने घटक कारखाने को लागू करने की आवश्यकता है, लेकिन हम अपने प्रकट तत्व कैसे बनाते हैं? यहां हमें एक ComponentModule आवश्यकता है। आइए देखें:

 @Module abstract class ComponentModule { @Binds @IntoMap @ComponentKey(MainActivity::class) abstract fun bindMainActivity(activity: MainActivity): Any @Binds abstract fun bindComponentHelper(componentHelper: ComponentHelper): ComponentInstanceHelper } @Target(AnnotationTarget.FUNCTION, AnnotationTarget.PROPERTY_GETTER, AnnotationTarget.PROPERTY_SETTER) @Retention(AnnotationRetention.RUNTIME) @MapKey internal annotation class ComponentKey(val clazz: KClass<out Any>) 

हाँ, ठीक है, बस कुछ एनोटेशन। यहां हम अपनी Activity को एक मानचित्र से जोड़ते हैं, इस मानचित्र को हमारे ComponentHelper वर्ग में लागू करते हैं और इस ComponentHelper प्रदान करते हैं - सभी दो Binds निर्देशों में। डैगर को पता है कि MainActivity एनोटेशन के लिए हमारी MainActivity को तुरंत कैसे MainActivity जा सकता है Inject इसलिए यह प्रदाता को इस वर्ग के लिए "बाइंड" कर सकता है, स्वचालित रूप से कंस्ट्रक्टर के लिए आवश्यक निर्भरता प्रदान करता है। हमारे ComponentHelper इस प्रकार है।

 class ComponentHelper @Inject constructor( private val creators: Map<Class<out Any>, @JvmSuppressWildcards Provider<Any>> ): ComponentInstanceHelper { @Suppress("UNCHECKED_CAST") override fun <T> resolve(className: String): T? = creators .filter { it.key.name == className } .values .firstOrNull() ?.get() as? T } interface InstanceComponentHelper { fun <T> resolve(className: String): T? } 

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

अंत में, हमें अपने नए सहायक वर्ग का उपयोग करने के लिए अपने AppComponentFactory बदलाव करने की आवश्यकता है।

 class InjectionComponentFactory: AppComponentFactory() { @Inject lateinit var componentHelper: ComponentInstanceHelper init { DaggerApplicationComponent.create().inject(this) } override fun instantiateActivity(cl: ClassLoader, className: String, intent: Intent?): Activity { return componentHelper .resolve<Activity>(className) ?.apply { setIntent(intent) } ?: super.instantiateActivity(cl, className, intent) } } 

कोड फिर से चलाएँ। यह सब काम करता है! क्या खुशी है?

कंस्ट्रक्टर कार्यान्वयन मुद्दे

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

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

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

निष्कर्ष

एंड्रॉइड 9 पाई ने हमारे फ्रेमवर्क वर्गों में निर्भरता प्रदान करने के लिए कंस्ट्रक्टर में एम्बेडिंग का उपयोग करने का एक तरीका पेश किया, जैसे कि "गतिविधि" और "एप्लिकेशन"। हमने देखा कि डैगर मल्टी-बाइंडिंग के साथ, हम आसानी से आवेदन स्तर पर निर्भरता प्रदान कर सकते हैं।

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