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

नेविगेशन ग्राफ

मल्टी-मॉड्यूल एप्लिकेशन डिज़ाइन करते समय याद रखने वाली सबसे महत्वपूर्ण बात निर्भरता है। मॉड्यूल निर्भरता पेड़ में निर्भरता को एक दिशा में निर्देशित किया जाना चाहिए।

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

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

बात सस्ती है। मुझे कोड दिखाओ

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

मॉड्यूल के अंदर नेविगेशन तक पहुंच

जब एक स्क्रीन से दूसरे मॉड्यूल में एक स्क्रीन को एक संक्रमण बनाने का समय आता है, तो सवाल उठता है - कैसे?

दरअसल, फ़ीचर मॉड्यूल के अंदर नेविगेशन आईडी तक एक्शन आईडी प्राप्त करने के लिए कोई एक्सेस नहीं है जिसे NavController को निष्पादित करना होगा।

यह इंटरफेस का उपयोग करके DI को लागू करके हल किया गया है। ऐप मॉड्यूल से नेविगेशन के वैश्विक ग्राफ के आधार पर फ़ीचर मॉड्यूल के बजाय, हम एक इंटरफ़ेस बनाएंगे और इसे व्हाट्सएवनकोमांडपॉइडर कहेंगे, जिसके चर नेविगेशन कमांड हैं।

SplashNavCommandProvider.kt

interface SplashNavCommandProvider { val toAuth: NavCommand val toMain: NavCommand } 

कमांड प्रोवाइडर इंटरफ़ेस ही ऐप मॉड्यूल में लागू किया जाएगा, और नेविगेशन कमांड क्लास में वही फ़ील्ड होंगे जो NavController.navigate विधि के लिए तर्क हैं

NavCommand.kt

 data class NavCommand( val action: Int, var args: Bundle? = null, val navOptions: NavOptions? = null ) 

आइए देखें कि यह व्यवहार में कैसा दिखता है। स्प्लैश स्क्रीन से, 2 संक्रमण संभव हैं: प्राधिकरण स्क्रीन और मुख्य कार्यात्मक स्क्रीन तक। छप मॉड्यूल में, एक इंटरफ़ेस बनाएँ:

SplashNavCommandProvider.kt

 interface SplashNavCommandProvider { val toAuth: NavCommand val toMain: NavCommand } 

ऐप मॉड्यूल में, हम इस इंटरफ़ेस का कार्यान्वयन बनाते हैं और डी फ्रेमवर्क (मेरे पास डैगर) का उपयोग करके, हम इसे मॉड्यूल को स्प्लैश इंटरफ़ेस के माध्यम से प्रदान करते हैं।

SplashNavCommandProviderImpl.kt - कमांडप्रोविडर का कार्यान्वयन

 class SplashNavCommandProviderImpl @Inject constructor() : SplashNavCommandProvider { override val toAuth: NavCommand = NavCommand(R.id.action_splashFragment_to_authFragment) override val toMain: NavCommand = NavCommand(R.id.action_splashFragment_to_mainFragment) } 

SplashNavigationModule.kt - निर्भरता प्रदान करने के लिए DI मॉड्यूल

 @Module interface SplashNavigationModule { @Binds fun bindSplashNavigator(impl: SplashNavCommandProviderImpl): SplashNavCommandProvider } 

AppActivityModule.kt - अनुप्रयोग का मुख्य DI मॉड्यूल

 @Module interface AppActivityModule { @FragmentScope @ContributesAndroidInjector( modules = [ SplashNavigationModule::class ] ) fun splashFragmentInjector(): SplashFragment … } 

छप मॉड्यूल में, हम एमवी (यहां) में प्रस्तुतकर्ता को या तो प्रस्तुतकर्ता या ViewModel को लागू करते हैं ...

SplashViewModel.kt

 class SplashViewModel @Inject constructor( private val splashNavCommandProvider: SplashNavCommandProvider ) ... 

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

स्पलैशनावरमॉन्डपॉइडर के कार्यान्वयन को सीधे टुकड़े में लागू करना संभव होगा, लेकिन फिर हम नेविगेशन का परीक्षण करने की क्षमता खो देते हैं।

फ्रैगमेंट में, संक्रमण को पूरा करने के लिए, आपको NavController प्राप्त करने की आवश्यकता है। यदि वर्तमान स्क्रीन एक नेस्टेड टुकड़ा नहीं है, तो हम बस नवीकंट्रोलर को findNavController () विधि से प्राप्त करते हैं और उस पर नेविगेट विधि कहते हैं:

 findNavController().navigate(toMain) 

टुकड़े के लिए एक एक्सटेंशन लिखकर आप इसे थोड़ा और सुविधाजनक बना सकते हैं

FragmentExt.kt

 fun Fragment.navigate(navCommand: NavCommand) { findNavController().navigate(navCommand.action, navCommand.args, navCommand.navOptions) } 

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

फिर टुकड़े के अंदर नेविगेशन इस तरह दिखेगा

 navigate(toMain) 

नेस्टेड फ्रेगमेंट्स

नेस्टेड टुकड़ों में नेविगेशन दो प्रकार के हो सकते हैं:

• एक नेस्टेड कंटेनर में संक्रमण
• कंटेनर में एक या अधिक स्तरों पर जाना। उदाहरण के लिए, एक वैश्विक गतिविधि होस्ट

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

GlobalHostModule.kt - वैश्विक होस्ट आईडी निर्भरता प्रदान करने के लिए DI मॉड्यूल

 @Provides @GlobalHost fun provideGlobalHostId(): Int = R.id.host_global 

AppActivityModule.kt - अनुप्रयोग का मुख्य DI मॉड्यूल

 @FragmentScope @ContributesAndroidInjector( modules = [ GlobalHostModule::class, ProfileNavigationModule::class, ... ] ) fun profileKnownFragmentInjector(): ProfileKnownFragment 

टुकड़ा में मेजबान आईडी निर्भरता एम्बेड

 @Inject @GlobalHost var hostId = 0 

जब टुकड़े टुकड़े हो जाते हैं, तो यह प्रत्येक मेजबान के लिए क्वालीफायर बनाने या मौजूदा क्वालीफायर नाम का उपयोग करने के लायक है ताकि डैगर समझें कि कौन सा इंट प्रदान करना है।

GlobalHost.kt

 @Qualifier @Retention(AnnotationRetention.RUNTIME) annotation class GlobalHost 

वांछित होस्ट की निर्भरता आईडी के टुकड़े में प्राप्त होने के बाद, आप होस्ट आईडी द्वारा NavController प्राप्त कर सकते हैं। हम किसी भी कंटेनर में संक्रमण करने की क्षमता के लिए हमारे विस्तार में सुधार करेंगे:

FragmentExt.kt

 fun Fragment.navigate(navCommand: NavCommand, hostId: Int? = null) { val navController = if (hostId == null) { findNavController() } else { Navigation.findNavController(requireActivity(), hostId) } navController.navigate(navCommand.action, navCommand.args, navCommand.navOptions) } 

स्निपेट में कोड

 navigate(toAuth, hostId) 

ये मल्टी-मॉड्यूल आर्किटेक्चर में जेटपैक का उपयोग करके नेविगेट करने का मुख्य आकर्षण थे। यदि आपके कोई प्रश्न हैं, तो मुझे टिप्पणियों में उनका जवाब देने में खुशी होगी :)