बचपन से, मुझे निर्देश पढ़ना पसंद है। मैं बड़ा हो गया, लेकिन यह अभी भी मुझे आश्चर्यचकित करता है कि वयस्क निर्देशों के प्रति लापरवाह कैसे होते हैं: उनमें से कई सोचते हैं कि हर कोई जानता है, और एक ही समय में एक या दो कार्यों का उपयोग करते हैं, जबकि कई और भी हैं! आप में से कितने लोग माइक्रोवेव में तापमान रखने के लिए इस्तेमाल करते हैं? और वह लगभग सभी में है।

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

एक्टिविटी लाइफ़साइकल कॉलबैक क्या हैं?

इस इंटरफ़ेस को देखें, जब यह एपीआई 14 में दिखाई देता है तो यह कैसा दिखता है:

public interface ActivityLifecycleCallbacks {    void onActivityCreated(Activity activity, Bundle savedInstanceState);    void onActivityStarted(Activity activity);    void onActivityResumed(Activity activity);    void onActivityPaused(Activity activity);    void onActivityStopped(Activity activity);    void onActivitySaveInstanceState(Activity activity, Bundle outState);    void onActivityDestroyed(Activity activity); }

एपीआई 29 से शुरू होकर, इसमें कई नए तरीके जोड़े गए हैं।

 public interface ActivityLifecycleCallbacks {   default void onActivityPreCreated( @NonNull Activity activity, @Nullable Bundle savedInstanceState) { }   void onActivityCreated( @NonNull Activity activity, @Nullable Bundle savedInstanceState);   default void onActivityPostCreated( @NonNull Activity activity, @Nullable Bundle savedInstanceState) { }   default void onActivityPreStarted(@NonNull Activity activity) { }   void onActivityStarted(@NonNull Activity activity);   default void onActivityPostStarted(@NonNull Activity activity) { }   default void onActivityPreResumed(@NonNull Activity activity) { }   void onActivityResumed(@NonNull Activity activity);   default void onActivityPostResumed(@NonNull Activity activity) { }   default void onActivityPrePaused(@NonNull Activity activity) { }   void onActivityPaused(@NonNull Activity activity);   default void onActivityPostPaused(@NonNull Activity activity) { }   default void onActivityPreStopped(@NonNull Activity activity) { }   void onActivityStopped(@NonNull Activity activity);   default void onActivityPostStopped(@NonNull Activity activity) { }   default void onActivityPreSaveInstanceState( @NonNull Activity activity, @NonNull Bundle outState) { }   void onActivitySaveInstanceState( @NonNull Activity activity, @NonNull Bundle outState);   default void onActivityPostSaveInstanceState( @NonNull Activity activity, @NonNull Bundle outState) { }   default void onActivityPreDestroyed(@NonNull Activity activity) { }   void onActivityDestroyed(@NonNull Activity activity);   default void onActivityPostDestroyed(@NonNull Activity activity) { } }

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

प्रत्येक विधि गतिविधि जीवनचक्र की एक समान विधि को प्रदर्शित करती है और उस समय कहा जाता है जब आवेदन में किसी गतिविधि पर विधि को ट्रिगर किया जाता है। यही है, अगर आवेदन MainActivity के साथ शुरू होता है, तो सबसे पहले हमें ActivLifecycleCallback.onActivityCreated (MainActivity, null) के लिए कॉल मिलेगी।

महान, लेकिन यह कैसे काम करता है? यहां कोई जादू नहीं है: गतिविधि स्वयं रिपोर्ट करती है कि वे किस स्थिति में हैं। यहाँ Activity.onCreate () से कोड का एक टुकड़ा है:

  mFragments.restoreAllState(p, mLastNonConfigurationInstances != null           ? mLastNonConfigurationInstances.fragments : null); } mFragments.dispatchCreate(); getApplication().dispatchActivityCreated(this, savedInstanceState); if (mVoiceInteractor != null) {

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

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

एक्टिविटी लाइफ़ साइकल कॉलबैक कैसे बनाएं?

सभी कॉलबैक की तरह, आपको पहले उन्हें पंजीकृत करना होगा। हम Application.onCreate () में सभी ActivityLifecycleCallbacks पंजीकृत करते हैं, इसलिए हमें सभी गतिविधि और उन्हें प्रबंधित करने की क्षमता के बारे में जानकारी मिलती है।

 class MyApplication : Application() {   override fun onCreate() { super.onCreate() registerActivityLifecycleCallbacks(MyCallbacks()) } }

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

वह सब है। लेकिन आप इसे केवल खोज बॉक्स में ActivLifecycleCallbacks नाम दर्ज करके पा सकते हैं। गतिविधि जीवनचक्र लॉग करने के कई उदाहरण होंगे, लेकिन क्या यह दिलचस्प है? गतिविधि में कई सार्वजनिक विधियां (लगभग 400) हैं, और यह सब कई दिलचस्प और उपयोगी चीजें करने के लिए उपयोग किया जा सकता है।

इससे क्या हो सकता है?

तुम क्या चाहते हो? आवेदन में सभी गतिविधि में विषय को गतिशील रूप से बदलना चाहते हैं? कृपया: setTheme () विधि सार्वजनिक है, जिसका अर्थ है कि आप इसे किसी गतिविधि से कॉल कर सकते हैं: कॉलबैक:

 class ThemeCallback( @StyleRes val myTheme: Int ) : ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { activity.setTheme(myTheme) } }

इस ट्रिक को केवल घर पर ही दोहराएं
जुड़े पुस्तकालयों से कुछ गतिविधियाँ अपने कस्टम थीम का उपयोग कर सकती हैं। इसलिए, पैकेज या किसी अन्य संकेत की जांच करें जिसके द्वारा यह निर्धारित किया जा सकता है कि इस गतिविधि का विषय सुरक्षित रूप से बदला जा सकता है। उदाहरण के लिए, हम इस तरह के पैकेज की जांच करते हैं (कोटलिनोवस्की =) में:

 class ThemeCallback( @StyleRes val myTheme: Int ) : ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { val myPackage = "my.cool.application" activity .takeIf { it.javaClass.name.startsWith(myPackage) } ?.setTheme(myTheme) } }

क्या उदाहरण काम नहीं करता है? आप AndroidManifest में Application या Application में ThemeCallback रजिस्टर करना भूल गए होंगे।

एक और दिलचस्प उदाहरण चाहते हैं? आप आवेदन में किसी भी गतिविधि पर संवाद दिखा सकते हैं।

 class DialogCallback( val dialogFragment: DialogFragment ) : Application.ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { if (savedInstanceState == null) { val tag = dialogFragment.javaClass.name (activity as? AppCompatActivity) ?.supportFragmentManager ?.also { fragmentManager -> if (fragmentManager.findFragmentByTag(tag) == null) { dialogFragment.show(fragmentManager, tag) } } } } }

इस ट्रिक को केवल घर पर ही दोहराएं
बेशक, आपको हर स्क्रीन पर एक संवाद नहीं दिखाना चाहिए - हमारे उपयोगकर्ता इसके लिए हमसे प्यार नहीं करेंगे। लेकिन कभी-कभी कुछ विशिष्ट स्क्रीन पर ऐसा कुछ दिखाना उपयोगी हो सकता है।

और यहां एक और मामला है: क्या होगा यदि हमें एक गतिविधि शुरू करने की आवश्यकता है सब कुछ यहां सरल है: गतिविधि.startActivity () - और इसे छोड़ दिया। लेकिन क्या होगा अगर हमें Activity.startActivityForResult () कॉल करने के बाद परिणाम की प्रतीक्षा करनी पड़े? मेरे पास एक नुस्खा है:

 class StartingActivityCallback : Application.ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { if (savedInstanceState == null) { (activity as? AppCompatActivity) ?.supportFragmentManager ?.also { fragmentManager -> val startingFragment = findOrCreateFragment(fragmentManager) startingFragment.listener = { resultCode, data -> // handle response here } // start Activity inside StartingFragment } } } private fun findOrCreateFragment( fragmentManager: FragmentManager ): StartingFragment { val tag = StartingFragment::class.java.name return fragmentManager .findFragmentByTag(tag) as StartingFragment? ?: StartingFragment().apply { fragmentManager .beginTransaction() .add(this, tag) .commit() } } }

उदाहरण में, हम केवल फ्रैगमेंट को छोड़ देते हैं, जो गतिविधि शुरू करता है और परिणाम प्राप्त करता है, और फिर इसके प्रसंस्करण को हमें सौंप देता है। सावधान रहें: यहाँ हम जाँचते हैं कि हमारी गतिविधि AppCompatActivity है, जो अनंत लूप का कारण बन सकती है। अन्य शर्तों का उपयोग करें।

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

 interface Screen { val screenName: String }

अब हम इसे वांछित गतिविधि में लागू करते हैं:

 class NamedActivity : Activity(), Screen { override val screenName: String = "First screen" }

उसके बाद हम इस तरह की गतिविधि के लिए विशेष गतिविधिलिफ़साइकल कॉलबैक सेट करते हैं:

 class AnalyticsActivityCallback( val sendAnalytics: (String) -> Unit ) : Application.ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { if (savedInstanceState == null) { (activity as? Screen)?.screenName?.let(sendAnalytics) } } }

आप देखते हैं? हम सिर्फ इंटरफ़ेस की जांच करते हैं और यदि लागू किया जाता है, तो एनालिटिक्स भेजें।

फिक्सिंग के लिए दोहराएं। यदि आपको कुछ और मापदंडों को फेंकने की आवश्यकता है तो क्या करें? इंटरफ़ेस बढ़ाएँ:

 interface ScreenWithParameters : Screen { val parameters: Map<String, String> }

हम लागू करते हैं:

 class NamedActivity : Activity(), ScreenWithParameters { override val screenName: String = "First screen" override val parameters: Map<String, String> = mapOf("key" to "value") }

हम जहाज:

 class AnalyticsActivityCallback( val sendAnalytics: (String, Map<String, String>?) -> Unit ) : Application.ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { if (savedInstanceState == null) { (activity as? Screen)?.screenName?.let { name -> sendAnalytics( name, (activity as? ScreenWithParameters)?.parameters ) } } } }

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

मान लीजिए कि हमारे पास कुछ उपकरण हैं:

 class CoolToolImpl { val extraInfo = "i am dependency" }

वयस्क प्रोग्रामर की तरह इसे इंटरफेस के साथ बंद करें:

 interface CoolTool { val extraInfo: String } class CoolToolImpl : CoolTool { override val extraInfo = "i am dependency" }

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

 interface RequireCoolTool { var coolTool: CoolTool } class CoolToolActivity : Activity(), RequireCoolTool { override lateinit var coolTool: CoolTool } class InjectingLifecycleCallbacks : ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { (activity as? RequireCoolTool)?.coolTool = CoolToolImpl() } }

अपने अनुप्रयोग में InjectingLifecycleCallbacks पंजीकृत करना याद रखें, इसे चलाएं और यह काम करता है।

और परीक्षण करने के लिए मत भूलना:

 @RunWith(AndroidJUnit4::class) class DIActivityTest { @Test fun `should access extraInfo when created`() { // prepare val mockTool: CoolTool = mock() val application = getApplicationContext<android.app.Application>() application.registerActivityLifecycleCallbacks( object : Application.ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { (activity as? RequireCoolTool)?.coolTool = mockTool } }) // invoke launch<DIActivity>(Intent(application, DIActivity::class.java)) // assert verify(mockTool).extraInfo } }

लेकिन बड़ी परियोजनाओं पर, यह दृष्टिकोण अच्छी तरह से पैमाने पर नहीं होगा, इसलिए मैं किसी से किसी भी डीआई फ्रेमवर्क को दूर नहीं करने जा रहा हूं। जहां प्रयासों को संयोजित करना और तालमेल हासिल करना बेहतर होता है। मैं आपको Dagger2 का उदाहरण दिखाऊंगा। यदि आपके पास प्रोजेक्ट में कुछ बुनियादी गतिविधि है जो AndroidInjection.inject (इस) जैसा कुछ करता है, तो इसे फेंकने का समय है। इसके बजाय, निम्नलिखित करें:

निर्देशों के अनुसार, हम आवेदन में DispatchingAndroidInjector लागू करते हैं;
प्रत्येक गतिविधि के लिए DispatchingAndroidInjector.maybeInject () कॉल करने वाली एक एक्टिविटी लाइफ़ साइकल कॉलबैक बनाएँ;
ApplicationLifecycleCallbacks को अनुप्रयोग में पंजीकृत करें।

 class MyApplication : Application() { @Inject lateinit var dispatchingAndroidInjector: DispatchingAndroidInjector<Any> override fun onCreate() { super.onCreate() DaggerYourApplicationComponent.create().inject(this); registerActivityLifecycleCallbacks( InjectingLifecycleCallbacks( dispatchingAndroidInjector ) ) } } class InjectingLifecycleCallbacks( val dispatchingAndroidInjector: DispatchingAndroidInjector<Any> ) : ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) {       dispatchingAndroidInjector.maybeInject(activity) } }

और उसी प्रभाव को अन्य DI फ्रेमवर्क के साथ प्राप्त किया जा सकता है। कोशिश करें और टिप्पणियों में लिखें कि क्या हुआ।

संक्षेप में देना

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

एक्टिविटी लाइफ़साइकल कॉलबैक - सार्वजनिक एपीआई में एक अंधा स्थान

एक्टिविटी लाइफ़साइकल कॉलबैक क्या हैं?

एक्टिविटी लाइफ़ साइकल कॉलबैक कैसे बनाएं?

इससे क्या हो सकता है?

संक्षेप में देना

More articles: