गतिविधि की लाइफ़साइकल

जब कोई उपयोगकर्ता आपके ऐप्लिकेशन पर नेविगेट करता है, उससे बाहर निकलता है, और वापस आता है, तो आपके ऐप्लिकेशन में मौजूद Activity के इंस्टेंस, अपनी लाइफ़साइकल में अलग-अलग स्थितियों से गुज़रते हैं. Activity क्लास कई कॉलबैक उपलब्ध कराती है. इनसे गतिविधि को पता चलता है कि स्थिति कब बदलती है या सिस्टम कब किसी गतिविधि को बना रहा है, रोक रहा है या फिर से शुरू कर रहा है. इसके अलावा, यह भी पता चलता है कि सिस्टम कब उस प्रोसेस को खत्म कर रहा है जिसमें गतिविधि मौजूद है.

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

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

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

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

इसके बाद, यह गतिविधि की स्थिति और सिस्टम की ओर से किसी प्रोसेस को बंद किए जाने की संभावना के बीच के संबंध के बारे में कम शब्दों में जानकारी देता है. आखिर में, इसमें गतिविधि की स्थितियों के बीच ट्रांज़िशन से जुड़े कई विषयों पर चर्चा की गई है.

लाइफ़साइकल को मैनेज करने के बारे में जानकारी पाने के लिए, Jetpack Compose में लाइफ़साइकल और यूज़र इंटरफ़ेस (यूआई) की स्थितियों को सेव करना लेख पढ़ें. इनमें सबसे सही तरीकों के बारे में भी बताया गया है. आर्किटेक्चर कॉम्पोनेंट के साथ-साथ गतिविधियों का इस्तेमाल करके, मज़बूत और प्रोडक्शन-क्वालिटी वाला ऐप्लिकेशन बनाने का तरीका जानने के लिए, ऐप्लिकेशन आर्किटेक्चर की गाइड देखें.

ऐक्टिविटी लाइफ़साइकल के कॉन्सेप्ट

गतिविधि पूरी होने की प्रोसेस के अलग-अलग चरणों के बीच नेविगेट करने के लिए, Activity क्लास छह कॉलबैक का एक मुख्य सेट उपलब्ध कराती है: onCreate, onStart, onResume, onPause, onStop, और onDestroy. गतिविधि के नई स्थिति में आने पर, सिस्टम इनमें से हर कॉलबैक को शुरू करता है.

पहली इमेज में, इस मॉडल को विज़ुअल के तौर पर दिखाया गया है.

पहली इमेज. गतिविधि पूरी होने की प्रोसेस का आसान इलस्ट्रेशन.

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

अगर उपयोगकर्ता गतिविधि पर वापस आता है, तो वह वहीं से शुरू होती है जहां उपयोगकर्ता ने उसे छोड़ा था. कुछ अपवादों को छोड़कर, बैकग्राउंड में चलने वाले ऐप्लिकेशन को गतिविधियां शुरू करने से रोका जाता है.

सिस्टम किसी प्रोसेस और उसमें मौजूद गतिविधियों को खत्म करेगा या नहीं, यह उस समय गतिविधि की स्थिति पर निर्भर करता है. स्टेट और मेमोरी से निकाले जाने के बीच के संबंध के बारे में ज़्यादा जानने के लिए, ऐक्टिविटी स्टेट और मेमोरी से निकाले जाने के बारे में सेक्शन देखें.

आपकी गतिविधि कितनी जटिल है, इसके आधार पर हो सकता है कि आपको लाइफ़साइकल के सभी तरीकों को लागू करने की ज़रूरत न पड़े. हालांकि, यह ज़रूरी है कि आप हर एक को समझें और उन्हें लागू करें, ताकि आपका ऐप्लिकेशन उपयोगकर्ताओं की उम्मीद के मुताबिक काम करे.

Compose और लाइफ़साइकल

Compose में, onStart या onResume जैसे ऐक्टिविटी कॉलबैक में, कारोबारी नियम या मैन्युअल ऑब्ज़र्वर सेटअप को सीधे तौर पर शामिल करने से बचें. इसके बजाय, लाइफ़साइकल के बारे में जानकारी देने वाले इफ़ेक्ट और स्टेट के बारे में जानकारी देने वाले ऑब्ज़र्वर का इस्तेमाल करें. ये स्क्रीन पर यूज़र इंटरफ़ेस (यूआई) की मौजूदगी के साथ अपने-आप अलाइन हो जाते हैं.

  • लाइफ़साइकल-अवेयर कलेक्शन: अपने ViewModel से फ़्लो इस्तेमाल करने के लिए, collectAsStateWithLifecycle का इस्तेमाल करें. यह एपीआई, यूज़र इंटरफ़ेस (यूआई) के 'शुरू हो गया' स्टेटस में आने पर, डेटा इकट्ठा करना अपने-आप शुरू कर देता है. साथ ही, यूज़र इंटरफ़ेस (यूआई) के बैकग्राउंड में जाने पर, डेटा इकट्ठा करना बंद कर देता है. इससे रिसॉर्स का बेवजह इस्तेमाल नहीं होता. फ़्लो को स्टेट के तौर पर इकट्ठा करने के बाद, लाइफ़साइकल इवेंट होने पर कोड चलाने के लिए, LifecycleEffects का इस्तेमाल किया जा सकता है.
  • लॉजिक का फ़्लो: इन एपीआई का इस्तेमाल करके, यूज़र इंटरफ़ेस (यूआई), कंपोज़िशन ट्री के ज़रिए लाइफ़साइकल की स्थिति पर नैचुरल तरीके से प्रतिक्रिया देता है. इससे यह पक्का होता है कि कारोबारी नियम सिर्फ़ तब लागू हो, जब उपयोगकर्ता कॉम्पोनेंट के साथ सक्रिय रूप से इंटरैक्ट कर रहा हो.

Compose और लाइफ़साइकल के बारे में ज़्यादा जानने के लिए, Jetpack Compose में लाइफ़साइकल देखें.

लाइफ़साइकल कॉलबैक

इस सेक्शन में, गतिविधि पूरी होने की प्रोसेस के दौरान इस्तेमाल किए जाने वाले कॉलबैक के तरीकों के बारे में जानकारी दी गई है. साथ ही, इन्हें लागू करने का तरीका बताया गया है.

कुछ कार्रवाइयां, गतिविधि पूरी होने की प्रोसेस के तरीकों में शामिल होती हैं. हालांकि, गतिविधि पूरी होने की प्रोसेस के बजाय, कॉम्पोनेंट में डिपेंडेंट कॉम्पोनेंट की कार्रवाइयों को लागू करने वाला कोड डालें. इसके लिए, आपको डिपेंडेंट कॉम्पोनेंट को लाइफ़साइकल के बारे में जानकारी देनी होगी. डिपेंडेंट कॉम्पोनेंट को लाइफ़साइकल के बारे में जानकारी देने का तरीका जानने के लिए, Jetpack Compose में लाइफ़साइकल देखें.

onCreate

आपको इस कॉलबैक को लागू करना होगा. यह कॉलबैक तब ट्रिगर होता है, जब सिस्टम पहली बार गतिविधि बनाता है. गतिविधि बनाने पर, वह बनाई गई स्थिति में चली जाती है. onCreate तरीके में, ऐप्लिकेशन को शुरू करने का बुनियादी लॉजिक लागू करें. यह लॉजिक, गतिविधि के पूरे लाइफ़साइकल में सिर्फ़ एक बार लागू होता है.

उदाहरण के लिए, onCreate को लागू करने से, डेटा को सूचियों से जोड़ा जा सकता है, गतिविधि को ViewModel से जोड़ा जा सकता है, और क्लास-स्कोप वाले कुछ वैरिएबल को इंस्टैंशिएट किया जा सकता है. इस तरीके को पैरामीटर savedInstanceState मिलता है. यह एक Bundle ऑब्जेक्ट है, जिसमें गतिविधि की पहले से सेव की गई स्थिति होती है. अगर गतिविधि पहले कभी मौजूद नहीं थी, तो Bundle ऑब्जेक्ट की वैल्यू शून्य होगी.

अगर आपके पास लाइफ़साइकल के बारे में जानकारी देने वाला कोई कॉम्पोनेंट है, जो आपकी गतिविधि की लाइफ़साइकल से जुड़ा है, तो उसे ON_CREATE इवेंट मिलता है. @OnLifecycleEvent के साथ एनोटेट किए गए तरीके को कॉल किया जाता है, ताकि लाइफ़साइकल के बारे में जानकारी देने वाला कॉम्पोनेंट, बनाई गई स्थिति के लिए ज़रूरी सेटअप कोड को लागू कर सके.

यहां दिए गए उदाहरण में, कम से कम गतिविधि में Text कंपोज़ेबल को इंटिग्रेट करने का तरीका बताया गया है:

class ExampleActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent { // In here, we can call composables!
            MaterialTheme {
                Greeting(name = "compose")
            }
        }
    }
}

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}

आपकी गतिविधि, 'बनाई गई' स्थिति में नहीं रहती. onCreate मेथड के पूरा होने के बाद, गतिविधि शुरू हो जाती है. इसके बाद, सिस्टम onStart और onResume मेथड को तुरंत कॉल करता है.

onStart

जब गतिविधि शुरू होती है, तो सिस्टम onStart को शुरू करता है. इस कॉल से, उपयोगकर्ता को गतिविधि दिखती है. ऐसा इसलिए होता है, क्योंकि ऐप्लिकेशन, गतिविधि को फ़ोरग्राउंड में लाने और इंटरैक्टिव बनाने के लिए तैयार होता है. उदाहरण के लिए, इस तरीके से यूज़र इंटरफ़ेस (यूआई) को मैनेज करने वाले कोड को शुरू किया जाता है.

जब ऐक्टिविटी, 'शुरू हो गई' स्थिति में जाती है, तो ऐक्टिविटी की लाइफ़साइकल से जुड़े किसी भी लाइफ़साइकल-अवेयर कॉम्पोनेंट को ON_START इवेंट मिलता है.

onStart मेथड तेज़ी से पूरा होता है. साथ ही, Created स्टेट की तरह ही, गतिविधि Started स्टेट में नहीं रहती. यह कॉलबैक पूरा होने के बाद, गतिविधि फिर से शुरू हो जाती है और सिस्टम onResume तरीके को शुरू करता है.

onResume

जब गतिविधि, फिर से शुरू होने की स्थिति में आती है, तो यह फ़ोरग्राउंड में आ जाती है. साथ ही, सिस्टम onResume कॉलबैक को शुरू करता है. इस स्थिति में, ऐप्लिकेशन उपयोगकर्ता के साथ इंटरैक्ट करता है. ऐप्लिकेशन इस स्थिति में तब तक रहता है, जब तक कि कोई ऐसी गतिविधि न हो जिससे उपयोगकर्ता का ध्यान ऐप्लिकेशन से हट जाए. जैसे, डिवाइस पर कोई फ़ोन कॉल आना, उपयोगकर्ता का किसी दूसरी गतिविधि पर जाना या डिवाइस की स्क्रीन बंद होना.

जब गतिविधि, फिर से शुरू होने की स्थिति में जाती है, तो गतिविधि की लाइफ़साइकल से जुड़े किसी भी लाइफ़साइकल-अवेयर कॉम्पोनेंट को ON_RESUME इवेंट मिलता है. यहां लाइफ़साइकल कॉम्पोनेंट, ऐसी किसी भी सुविधा को चालू कर सकते हैं जिसे कॉम्पोनेंट के दिखने और फ़ोरग्राउंड में होने के दौरान चलाने की ज़रूरत होती है. जैसे, कैमरे की झलक देखना.

जब कोई रुकावट डालने वाला इवेंट होता है, तो गतिविधि रुकी हुई स्थिति में चली जाती है और सिस्टम onPause कॉलबैक को शुरू करता है.

अगर गतिविधि, रोकी गई स्थिति से फिर से शुरू की गई स्थिति में वापस आती है, तो सिस्टम फिर से onResume तरीके को कॉल करता है. इसलिए, onResume को लागू करें, ताकि onPause के दौरान रिलीज़ किए गए कॉम्पोनेंट को शुरू किया जा सके. साथ ही, अन्य कॉम्पोनेंट को भी शुरू किया जा सके. ऐसा तब करना ज़रूरी है, जब गतिविधि फिर से शुरू की गई स्थिति में हो.

यहां लाइफ़साइकल के बारे में जानकारी रखने वाले कॉम्पोनेंट का एक उदाहरण दिया गया है. यह कॉम्पोनेंट, ON_RESUME इवेंट मिलने पर कैमरे को ऐक्सेस करता है:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun initializeCamera() {
        if (camera == null) {
            getCamera()
        }
    }
    ...
}

LifecycleObserver को ON_RESUME इवेंट मिलने के बाद, ऊपर दिया गया कोड कैमरे को शुरू करता है. हालांकि, मल्टी-विंडो मोड में आपकी गतिविधि पूरी तरह से दिख सकती है. भले ही, वह रोकी गई स्थिति में हो. उदाहरण के लिए, जब ऐप्लिकेशन मल्टी-विंडो मोड में हो और उपयोगकर्ता उस विंडो पर टैप करे जिसमें आपकी गतिविधि नहीं है, तो आपकी गतिविधि 'रुकी हुई' स्थिति में चली जाती है.

अगर आपको कैमरा सिर्फ़ तब चालू रखना है, जब ऐप्लिकेशन फिर से चालू हो (फ़ोरग्राउंड में दिख रहा हो और चालू हो), तो पहले दिखाए गए ON_RESUME इवेंट के बाद कैमरा शुरू करें. अगर आपको गतिविधि के रोके जाने के दौरान भी कैमरे को चालू रखना है, लेकिन वह गतिविधि दिखती रहे, जैसे कि मल्टी-विंडो मोड में, तो ON_START इवेंट के बाद कैमरे को शुरू करें.

हालांकि, गतिविधि रोके जाने के दौरान कैमरा चालू रखने से, मल्टी-विंडो मोड में फिर से शुरू किए गए किसी दूसरे ऐप्लिकेशन को कैमरे का ऐक्सेस नहीं मिल पाएगा. कभी-कभी, गतिविधि रोके जाने के दौरान कैमरे को चालू रखना ज़रूरी होता है. हालांकि, ऐसा करने से उपयोगकर्ता अनुभव खराब हो सकता है.

इस वजह से, ध्यान से सोचें कि मल्टी-विंडो मोड के संदर्भ में, शेयर किए गए सिस्टम के संसाधनों को कंट्रोल करने के लिए, लाइफ़साइकल में सबसे सही जगह कौनसी है. मल्टी-विंडो मोड के साथ काम करने के बारे में ज़्यादा जानने के लिए, मल्टी-विंडो मोड के साथ काम करना लेख पढ़ें.

इनिशलाइज़ेशन ऑपरेशन को पूरा करने के लिए, चाहे जो भी बिल्ड-अप इवेंट चुना जाए, यह पक्का करें कि रिसॉर्स को रिलीज़ करने के लिए, उससे जुड़े लाइफ़साइकल इवेंट का इस्तेमाल किया जाए. अगर आपने ON_START इवेंट के बाद कुछ शुरू किया है, तो उसे ON_STOP इवेंट के बाद रिलीज़ या खत्म करें. अगर आपने ON_RESUME इवेंट के बाद, इनिशलाइज़ किया है, तो ON_PAUSE इवेंट के बाद रिलीज़ करें.

ऊपर दिया गया कोड स्निपेट, कैमरे को शुरू करने वाले कोड को लाइफ़साइकल के बारे में जानकारी देने वाले कॉम्पोनेंट में डालता है. इस कोड को सीधे गतिविधि पूरी होने की प्रोसेस के लाइफ़साइकल कॉलबैक में भी डाला जा सकता है, जैसे कि onStart और onStop. हालांकि, हमारा सुझाव है कि ऐसा न करें. इस लॉजिक को लाइफ़साइकल के बारे में जानकारी रखने वाले किसी स्वतंत्र कॉम्पोनेंट में जोड़ने से, कॉम्पोनेंट को कई गतिविधियों में फिर से इस्तेमाल किया जा सकता है. इसके लिए, कोड को डुप्लीकेट करने की ज़रूरत नहीं पड़ती. लाइफ़साइकल के हिसाब से काम करने वाला कॉम्पोनेंट बनाने का तरीका जानने के लिए, Jetpack Compose में लाइफ़साइकल देखें.

onPause

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

  • ऐप्लिकेशन के चलने में रुकावट डालने वाला कोई इवेंट, मौजूदा गतिविधि को रोक देता है. इसके बारे में onResume कॉलबैक वाले सेक्शन में बताया गया है. यह सबसे आम मामला है.
  • मल्टी-विंडो मोड में, एक समय पर सिर्फ़ एक ऐप्लिकेशन पर फ़ोकस होता है. साथ ही, सिस्टम अन्य सभी ऐप्लिकेशन को रोक देता है.
  • किसी नई, आधी पारदर्शी गतिविधि के खुलने पर, वह गतिविधि रुक जाती है जो इसके पीछे होती है. जैसे, कोई डायलॉग बॉक्स. जब तक गतिविधि आंशिक रूप से दिखती है, लेकिन फ़ोकस में नहीं होती, तब तक वह रुकी रहती है.

जब कोई ऐक्टिविटी, रोकी गई स्थिति में जाती है, तो ऐक्टिविटी की लाइफ़साइकल से जुड़े किसी भी लाइफ़साइकल-अवेयर कॉम्पोनेंट को ON_PAUSE इवेंट मिलता है. यहां लाइफ़साइकल कॉम्पोनेंट, ऐसी किसी भी सुविधा को रोक सकते हैं जिसे कॉम्पोनेंट के फ़ोरग्राउंड में न होने पर चलाने की ज़रूरत नहीं होती. जैसे, कैमरे की झलक रोकना.

onPause तरीके का इस्तेमाल करके, उन कार्रवाइयों को रोकें या अडजस्ट करें जिन्हें जारी नहीं रखा जा सकता या जिन्हें Activity के रोके जाने के दौरान, सीमित तौर पर जारी रखा जा सकता है. साथ ही, जिन्हें आपको जल्द ही फिर से शुरू करना है.

onPause तरीके का इस्तेमाल करके, सिस्टम के संसाधनों, सेंसर (जैसे, जीपीएस) के हैंडल या ऐसे किसी भी संसाधन को रिलीज़ किया जा सकता है जो गतिविधि के रोके जाने पर बैटरी लाइफ़ पर असर डालता है और उपयोगकर्ता को उसकी ज़रूरत नहीं होती.

हालांकि, onResume के बारे में सेक्शन में बताया गया है कि अगर ऐप्लिकेशन मल्टी-विंडो मोड में है, तो रोकी गई गतिविधि अब भी पूरी तरह से दिख सकती है. मल्टी-विंडो मोड को बेहतर तरीके से सपोर्ट करने के लिए, यूज़र इंटरफ़ेस (यूआई) से जुड़े संसाधनों और कार्रवाइयों को पूरी तरह से रिलीज़ या अडजस्ट करने के लिए, onPause के बजाय onStop का इस्तेमाल करें.

ON_PAUSE इवेंट पर प्रतिक्रिया देने वाले LifecycleObserver का यह उदाहरण, पिछले ON_RESUME इवेंट के उदाहरण का दूसरा हिस्सा है. इसमें ON_RESUME इवेंट मिलने के बाद शुरू होने वाले कैमरे को रिलीज़ किया जाता है:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun releaseCamera() {
        camera?.release()
        camera = null
    }
    ...
}

इस उदाहरण में, LifecycleObserver को ON_PAUSE इवेंट मिलने के बाद, कैमरा रिलीज़ कोड को रखा गया है.

onPause को एक्ज़ीक्यूट होने में बहुत कम समय लगता है. इसलिए, ज़रूरी नहीं है कि सेव करने की प्रोसेस को पूरा करने के लिए, ज़रूरत के मुताबिक समय मिले. इस वजह से, ऐप्लिकेशन या उपयोगकर्ता का डेटा सेव करने, नेटवर्क कॉल करने या डेटाबेस ट्रांज़ैक्शन को लागू करने के लिए, onPause का इस्तेमाल न करें. ऐसा हो सकता है कि तरीका पूरा होने से पहले, यह काम पूरा न हो.

इसके बजाय, ज़्यादा लोड वाले शटडाउन ऑपरेशन onStop के दौरान करें. onStop के दौरान की जाने वाली सही कार्रवाइयों के बारे में ज़्यादा जानने के लिए, अगला सेक्शन देखें. डेटा सेव करने के बारे में ज़्यादा जानने के लिए, स्टेट को सेव और वापस लाने के बारे में सेक्शन देखें.

onPause तरीके के पूरा होने का मतलब यह नहीं है कि गतिविधि, रोकी गई स्थिति से बाहर निकल जाती है. इसके बजाय, गतिविधि इस स्थिति में तब तक बनी रहती है, जब तक कि गतिविधि फिर से शुरू नहीं हो जाती या उपयोगकर्ता को पूरी तरह से दिखना बंद नहीं हो जाती. अगर गतिविधि फिर से शुरू होती है, तो सिस्टम फिर से onResume कॉलबैक को शुरू करता है.

अगर गतिविधि, रोकी गई स्थिति से फिर से शुरू की गई स्थिति में वापस आती है, तो सिस्टम Activity इंस्टेंस को मेमोरी में सेव रखता है. साथ ही, सिस्टम के onResume को शुरू करने पर, उस इंस्टेंस को वापस लाता है. इस स्थिति में, आपको उन कॉम्पोनेंट को फिर से शुरू करने की ज़रूरत नहीं है जो Resumed स्थिति से पहले, कॉलबैक के किसी भी तरीके के दौरान बनाए गए थे. अगर गतिविधि पूरी तरह से दिखना बंद हो जाती है, तो सिस्टम onStop को कॉल करता है.

onStop

जब उपयोगकर्ता को आपकी गतिविधि नहीं दिखती, तो वह रुकी हुई स्थिति में चली जाती है. साथ ही, सिस्टम onStop कॉलबैक को शुरू करता है. ऐसा तब हो सकता है, जब हाल ही में लॉन्च की गई कोई गतिविधि पूरी स्क्रीन को कवर कर लेती है. जब गतिविधि पूरी हो जाती है और उसे बंद करना होता है, तब सिस्टम onStop को भी कॉल करता है.

जब ऐक्टिविटी, Stopped स्टेटस में जाती है, तो ऐक्टिविटी की लाइफ़साइकल से जुड़े किसी भी लाइफ़साइकल-अवेयर कॉम्पोनेंट को ON_STOP इवेंट मिलता है. यहां लाइफ़साइकल कॉम्पोनेंट, ऐसे किसी भी फ़ंक्शन को रोक सकते हैं जिसे चलाने की ज़रूरत नहीं है. ऐसा तब होता है, जब कॉम्पोनेंट स्क्रीन पर न दिख रहा हो.

onStop तरीके में, उन संसाधनों को रिलीज़ करें या अडजस्ट करें जिनकी ज़रूरत नहीं है. ऐसा तब करें, जब उपयोगकर्ता को ऐप्लिकेशन न दिख रहा हो. उदाहरण के लिए, हो सकता है कि आपका ऐप्लिकेशन ऐनिमेशन को रोक दे या जगह की सटीक जानकारी के अपडेट से, जगह की अनुमानित जानकारी के अपडेट पर स्विच कर दे. onPause के बजाय onStop का इस्तेमाल करने का मतलब है कि यूज़र इंटरफ़ेस (यूआई) से जुड़ा काम जारी रहता है. भले ही, उपयोगकर्ता आपकी गतिविधि को मल्टी-विंडो मोड में देख रहा हो.

साथ ही, सीपीयू पर ज़्यादा लोड डालने वाले शटडाउन ऑपरेशन के लिए, onStop का इस्तेमाल करें. उदाहरण के लिए, अगर आपको डेटाबेस में जानकारी सेव करने के लिए कोई बेहतर समय नहीं मिल रहा है, तो ऐसा onStop के दौरान किया जा सकता है. यहां दिए गए उदाहरण में, onStop को लागू करने का तरीका बताया गया है. इससे ड्राफ़्ट नोट के कॉन्टेंट को स्थायी स्टोरेज में सेव किया जाता है:

override fun onStop() {
    super.onStop()

    // Delegate the save operation to the ViewModel, which handles the
    // background thread operations (e.g., using Kotlin Coroutines and Room).
    noteViewModel.saveDraft()
}

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

'रुकी हुई' स्थिति से, गतिविधि या तो उपयोगकर्ता के साथ इंटरैक्ट करने के लिए वापस आती है या गतिविधि पूरी हो जाती है और बंद हो जाती है. अगर गतिविधि फिर से शुरू होती है, तो सिस्टम onRestart को शुरू करता है. अगर Activity का निष्पादन पूरा हो जाता है, तो सिस्टम onDestroy को कॉल करता है.

onDestroy

onDestroy को गतिविधि के खत्म होने से पहले कॉल किया जाता है. सिस्टम, इस कॉलबैक को दो में से किसी एक वजह से ट्रिगर करता है:

  1. गतिविधि खत्म हो रही है, क्योंकि उपयोगकर्ता ने गतिविधि को पूरी तरह से खारिज कर दिया है या गतिविधि पर finish को कॉल किया गया है.
  2. कॉन्फ़िगरेशन में बदलाव होने की वजह से, सिस्टम कुछ समय के लिए गतिविधि को बंद कर रहा है. जैसे, डिवाइस को रोटेट करना या मल्टी-विंडो मोड में जाना.

जब गतिविधि, खत्म होने की स्थिति में पहुंचती है, तो गतिविधि की लाइफ़साइकल से जुड़े लाइफ़साइकल-अवेयर कॉम्पोनेंट को ON_DESTROY इवेंट मिलता है. यहां लाइफ़साइकल कॉम्पोनेंट, Activity के खत्म होने से पहले, अपनी ज़रूरत के हिसाब से किसी भी चीज़ को मिटा सकते हैं.

Activity को नष्ट करने की वजह जानने के लिए, उसमें लॉजिक डालने के बजाय, ViewModel ऑब्जेक्ट का इस्तेमाल करें. इससे आपको Activity के लिए काम का व्यू डेटा मिलेगा. अगर कॉन्फ़िगरेशन में बदलाव की वजह से Activity को फिर से बनाया जाता है, तो ViewModel को कुछ भी करने की ज़रूरत नहीं होती. ऐसा इसलिए, क्योंकि इसे सुरक्षित रखा जाता है और Activity के अगले इंस्टेंस को दिया जाता है.

अगर Activity को फिर से नहीं बनाया जाता है, तो ViewModel में onCleared मेथड को कॉल किया जाता है. इससे, नष्ट होने से पहले, ज़रूरी डेटा को मिटाया जा सकता है. isFinishing तरीके का इस्तेमाल करके, इन दोनों स्थितियों के बीच अंतर किया जा सकता है.

अगर गतिविधि खत्म हो रही है, तो onDestroy वह आखिरी लाइफ़साइकल कॉलबैक है जो गतिविधि को मिलता है. अगर कॉन्फ़िगरेशन में बदलाव की वजह से onDestroy को कॉल किया जाता है, तो सिस्टम तुरंत एक नया गतिविधि इंस्टेंस बनाता है. इसके बाद, नए कॉन्फ़िगरेशन में उस नए इंस्टेंस पर onCreate को कॉल करता है.

onDestroy कॉलबैक, उन सभी संसाधनों को रिलीज़ करता है जो पहले के कॉलबैक से रिलीज़ नहीं किए गए थे. जैसे, onStop.

गतिविधि की स्थिति और मेमोरी से हटाना

सिस्टम, रैम को खाली करने के लिए प्रोसेस को बंद कर देता है. सिस्टम किसी प्रोसेस को बंद करेगा या नहीं, यह उस समय प्रोसेस की स्थिति पर निर्भर करता है. प्रोसेस की स्थिति, प्रोसेस में चल रही गतिविधि की स्थिति पर निर्भर करती है. टेबल 1 में, प्रोसेस की स्थिति, गतिविधि की स्थिति, और सिस्टम के प्रोसेस को बंद करने की संभावना के बीच के संबंध को दिखाया गया है. यह टेबल सिर्फ़ तब लागू होती है, जब कोई प्रोसेस, ऐप्लिकेशन के अन्य कॉम्पोनेंट को नहीं चला रही हो.

हत्या की संभावना

प्रोसेस की स्थिति

गतिविधि की आखिरी स्थिति

सबसे कम

फ़ोरग्राउंड (फ़ोकस किया गया या फ़ोकस किया जाने वाला)

फिर से शुरू की गई

कम

दिख रहा है (फ़ोकस नहीं किया गया)

शुरू किया गया/रोका गया

ज़्यादा

बैकग्राउंड (नहीं दिख रहा है)

रोका गया

सबसे अच्छी

खाली

खत्म किया गया

टेबल 1. प्रोसेस लाइफ़साइकल और गतिविधि की स्थिति के बीच संबंध.

सिस्टम, मेमोरी खाली करने के लिए किसी गतिविधि को सीधे तौर पर बंद नहीं करता. इसके बजाय, यह उस प्रोसेस को बंद कर देता है जिसमें गतिविधि चल रही होती है. इससे न सिर्फ़ गतिविधि खत्म होती है, बल्कि प्रोसेस में चल रही अन्य चीज़ें भी खत्म हो जाती हैं. सिस्टम की वजह से ऐप्लिकेशन की प्रोसेस बंद होने पर, अपनी गतिविधि के यूज़र इंटरफ़ेस (यूआई) की स्थिति को सेव करने और उसे वापस लाने का तरीका जानने के लिए, स्थिति को सेव करने और वापस लाने के बारे में सेक्शन देखें.

उपयोगकर्ता, सेटिंग में जाकर ऐप्लिकेशन मैनेजर का इस्तेमाल करके भी किसी प्रोसेस को बंद कर सकता है. इससे, उससे जुड़ा ऐप्लिकेशन बंद हो जाता है.

प्रोसेस के बारे में ज़्यादा जानने के लिए, प्रोसेस और थ्रेड की खास जानकारी देखें.

ट्रांज़िएंट यूज़र इंटरफ़ेस (यूआई) की स्थिति को सेव करना और उसे पहले जैसा करना

उपयोगकर्ता को उम्मीद होती है कि कॉन्फ़िगरेशन में बदलाव होने पर भी, गतिविधि का यूज़र इंटरफ़ेस (यूआई) पहले जैसा ही रहेगा. जैसे, स्क्रीन को घुमाने या मल्टी-विंडो मोड में स्विच करने पर. हालांकि, कॉन्फ़िगरेशन में इस तरह का बदलाव होने पर, सिस्टम डिफ़ॉल्ट रूप से गतिविधि को खत्म कर देता है. इससे गतिविधि के इंस्टेंस में सेव किया गया यूज़र इंटरफ़ेस (यूआई) का कोई भी स्टेटस मिट जाता है.

इसी तरह, अगर कोई उपयोगकर्ता कुछ समय के लिए आपके ऐप्लिकेशन से किसी दूसरे ऐप्लिकेशन पर स्विच करता है और फिर वापस आपके ऐप्लिकेशन पर आता है, तो उसे यूज़र इंटरफ़ेस (यूआई) की स्थिति पहले जैसी ही दिखनी चाहिए. हालांकि, जब उपयोगकर्ता डिवाइस का इस्तेमाल नहीं कर रहा होता है और आपकी गतिविधि बंद होती है, तो सिस्टम आपके ऐप्लिकेशन की प्रोसेस को खत्म कर सकता है.

जब सिस्टम की पाबंदियों की वजह से गतिविधि बंद हो जाती है, तो उपयोगकर्ता के यूज़र इंटरफ़ेस (यूआई) की अस्थायी स्थिति को सेव रखें. इसके लिए, ViewModel (जटिल कारोबारी नियम और स्क्रीन की स्थिति के लिए), Jetpack Compose rememberSaveable एपीआई (यूज़र इंटरफ़ेस (यूआई) की हल्की स्थिति के लिए), और/या लोकल स्टोरेज का इस्तेमाल करें. सिस्टम के व्यवहार की तुलना में उपयोगकर्ता की उम्मीदों के बारे में ज़्यादा जानने के लिए, यूज़र इंटरफ़ेस (यूआई) की स्थितियां सेव करें लेख पढ़ें. इसमें यह भी बताया गया है कि सिस्टम से शुरू की गई गतिविधि और ऐप्लिकेशन की प्रोसेस बंद होने के दौरान, यूज़र इंटरफ़ेस (यूआई) की स्थिति के जटिल डेटा को बेहतर तरीके से कैसे सुरक्षित रखा जा सकता है.

rememberSaveable, कॉन्फ़िगरेशन में होने वाले बदलावों और सिस्टम की वजह से ऐप्लिकेशन की प्रोसेस बंद होने की समस्या को अपने-आप मैनेज करता है. इसके लिए, यह बैकग्राउंड में स्टेट को बंडल करता है. इससे गतिविधि के लेवल पर बॉयलरप्लेट की ज़रूरत नहीं पड़ती और आपको बेहतर अनुभव मिलता है.

इंस्टेंस की स्थिति

कुछ मामलों में, ऐप्लिकेशन के सामान्य व्यवहार की वजह से आपकी गतिविधि बंद हो जाती है. जैसे, जब उपयोगकर्ता 'वापस जाएं' बटन दबाता है या आपकी गतिविधि finish तरीके को कॉल करके, खुद के बंद होने का सिग्नल देती है.

जब उपयोगकर्ता'वापस जाएं' बटन दबाता है या गतिविधि अपने-आप खत्म हो जाती है, तो आपकी गतिविधि खत्म हो जाती है. ऐसे में, सिस्टम और उपयोगकर्ता, दोनों के लिए Activity का वह इंस्टेंस हमेशा के लिए खत्म हो जाता है. इन स्थितियों में, उपयोगकर्ता की उम्मीदें सिस्टम के व्यवहार से मेल खाती हैं. साथ ही, आपको कोई अतिरिक्त काम नहीं करना पड़ता.

हालांकि, अगर सिस्टम की सीमाओं (जैसे, कॉन्फ़िगरेशन में बदलाव या मेमोरी की कमी) की वजह से सिस्टम गतिविधि को बंद कर देता है, तो असल Activity इंस्टेंस खत्म हो जाता है. हालांकि, सिस्टम को याद रहता है कि वह मौजूद था. अगर उपयोगकर्ता गतिविधि पर वापस जाने की कोशिश करता है, तो सिस्टम उस गतिविधि का एक नया इंस्टेंस बनाता है. इसके लिए, वह सेव किए गए डेटा के सेट का इस्तेमाल करता है. इस डेटा में, गतिविधि के खत्म होने के समय की स्थिति की जानकारी होती है.

सिस्टम, पिछली स्थिति को वापस लाने के लिए जिस सेव किए गए डेटा का इस्तेमाल करता है उसे इंस्टेंस स्टेट कहा जाता है. यह की-वैल्यू पेयर का कलेक्शन होता है. डिफ़ॉल्ट रूप से, सिस्टम आपके यूज़र इंटरफ़ेस (यूआई) लेआउट की बुनियादी जानकारी सेव करने के लिए, इंस्टेंस स्टेट का इस्तेमाल करता है. जैसे, उपयोगकर्ता का टेक्स्ट इनपुट या स्क्रोल पोज़िशन.

सिस्टम के इस व्यवहार को rememberSaveable का इस्तेमाल करके हुक किया जाता है. अगर आपकी गतिविधि का इंस्टेंस मिटाकर फिर से बनाया जाता है, तो rememberSaveable में रैप किया गया कोई भी यूज़र इंटरफ़ेस (यूआई) स्टेट अपने-आप वापस आ जाता है. इसके लिए, आपको गतिविधि के लेवल पर कोई अतिरिक्त कोड डालने की ज़रूरत नहीं होती.

हालांकि, आपकी गतिविधि में ज़्यादा जटिल स्थिति की जानकारी हो सकती है, जिसे आपको वापस लाना है. जैसे, उपयोगकर्ता का डेटा, नेटवर्क से मिले जवाब या उपयोगकर्ता की प्रोग्रेस को ट्रैक करने वाले मेंबर वैरिएबल. इंस्टेंस स्टेट मैकेनिज़्म (और, इसके एक्सटेंशन, rememberSaveable) का इस्तेमाल, बहुत कम डेटा को सेव करने के लिए किया जाता है. ऐसा इसलिए, क्योंकि इसके लिए मुख्य थ्रेड पर सीरियलाइज़ेशन की ज़रूरत होती है और यह सिस्टम-प्रोसेस मेमोरी का इस्तेमाल करता है.

ज़्यादा डेटा सेव करने के लिए, एक साथ कई तरीके इस्तेमाल करें. जैसे, परसिस्टेंट लोकल स्टोरेज, ViewModel क्लास, और Compose स्टेट होइस्टिंग. इनके बारे में यूज़र इंटरफ़ेस (यूआई) की स्थितियां सेव करना लेख में बताया गया है.

rememberSaveable का इस्तेमाल करके, आसान और लाइटवेट यूज़र इंटरफ़ेस (यूआई) स्टेट को सेव करना

जब आपकी गतिविधि बंद होने लगती है, तो सिस्टम स्टेट की जानकारी को इंस्टेंस स्टेट बंडल में सेव करने की तैयारी करता है. सिस्टम के इस व्यवहार का इस्तेमाल करने के लिए, सीधे तौर पर अपने कंपोज़ेबल फ़ंक्शन में rememberSaveable का इस्तेमाल करें. rememberSaveable, गतिविधि को फिर से बनाने के दौरान, यूज़र इंटरफ़ेस (यूआई) की अस्थायी स्थिति को अपने-आप सेव और वापस लाता है. जैसे, उपयोगकर्ता का टेक्स्ट इनपुट या स्क्रोल की पोज़िशन.

कस्टम और कम साइज़ वाली स्थिति की जानकारी (जैसे, गेम में उपयोगकर्ता की प्रोग्रेस) सेव करने के लिए, rememberSaveable का इस्तेमाल करके अपनी स्थिति की जानकारी दें. Compose फ़्रेमवर्क, इंस्टेंस स्टेट बंडल के सीरियलाइज़ेशन को बैकग्राउंड में मैनेज करता है:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}

उपयोगकर्ता की प्राथमिकताओं या डेटाबेस के डेटा जैसे स्थायी डेटा को सेव करने के लिए, सही मौकों का फ़ायदा उठाएं. जैसे, जब आपकी गतिविधि फ़ोरग्राउंड में हो. अगर ऐसा कोई मौका नहीं मिलता है, तो onStop तरीके के दौरान, सेव रहने वाला डेटा सेव करें.

सेव किए गए इंस्टेंस स्टेट का इस्तेमाल करके, गतिविधि के यूज़र इंटरफ़ेस (यूआई) की स्थिति को पहले जैसा करना

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

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}

गतिविधियां और नेविगेशन

कोई ऐप्लिकेशन अपने लाइफ़टाइम के दौरान कई बार एक स्क्रीन से दूसरी स्क्रीन पर स्विच कर सकता है. जैसे, जब उपयोगकर्ता डिवाइस के 'वापस जाएं' बटन पर टैप करता है या कोई नया डेस्टिनेशन चुनता है. मॉडर्न Android ऐप्लिकेशन, आम तौर पर सिंगल-ऐक्टिविटी आर्किटेक्चर का इस्तेमाल करते हैं. हर स्क्रीन के लिए एक नई Activity शुरू करने के बजाय, आपका ऐप्लिकेशन एक ही Activity को होस्ट करता है. साथ ही, उस गतिविधि में कंपोज़ेबल स्क्रीन को स्वैप करने के लिए, Navigation कॉम्पोनेंट का इस्तेमाल करता है.

Jetpack Compose के ऐप्लिकेशन में आधुनिक और Compose-फ़र्स्ट नेविगेशन लागू करने का तरीका जानने के लिए, Jetpack Compose की Navigation 3 लाइब्रेरी से जुड़ी गाइड देखें.

एक गतिविधि से दूसरी गतिविधि शुरू करना

किसी गतिविधि को किसी समय दूसरी गतिविधि शुरू करने की ज़रूरत पड़ सकती है. उदाहरण के लिए, जब किसी ऐप्लिकेशन को मौजूदा स्क्रीन से नई स्क्रीन पर जाना हो, तब इसकी ज़रूरत पड़ती है.

आपकी गतिविधि को शुरू होने वाली नई गतिविधि से नतीजा चाहिए या नहीं, इसके आधार पर नई गतिविधि को startActivity या startActivityForResult तरीके का इस्तेमाल करके शुरू किया जाता है. दोनों ही मामलों में, आपको Intent ऑब्जेक्ट पास करना होगा.

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

startActivity

अगर नई गतिविधि को कोई नतीजा दिखाने की ज़रूरत नहीं है, तो मौजूदा गतिविधि startActivity तरीके को कॉल करके इसे शुरू कर सकती है.

अपने ऐप्लिकेशन में काम करते समय, आपको अक्सर किसी जानी-पहचानी गतिविधि को लॉन्च करना पड़ता है. उदाहरण के लिए, यहां दिए गए कोड स्निपेट में SignInActivity नाम की गतिविधि को लॉन्च करने का तरीका बताया गया है.

val context = LocalContext.current

Button(onClick = {
    val intent = Intent(context, SignInActivity::class.java)
    context.startActivity(intent)
}) {
    Text("Sign In")
}

बाहरी गतिविधियां शुरू करना

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

इसके लिए, आपको Intent ऑब्जेक्ट का इस्तेमाल करके, यह बताना होगा कि आपको किस तरह की कार्रवाई करनी है. इसके बाद, सिस्टम किसी दूसरे ऐप्लिकेशन से सही गतिविधि लॉन्च करता है.

उदाहरण के लिए, अगर आपको उपयोगकर्ता को ईमेल भेजने की अनुमति देनी है, तो यह इंटेंट बनाया जा सकता है:

val intent = Intent(Intent.ACTION_SEND).apply {
    putExtra(Intent.EXTRA_EMAIL, recipientArray)
}
startActivity(intent)

अगर आपको कोई बाहरी गतिविधि लॉन्च करनी है और नतीजा वापस पाना है (जैसे कि कैमरा ऐप्लिकेशन को फ़ोटो लेने और इमेज वापस करने के लिए कहना), तो बंद किए जा चुके startActivityForResult कॉलबैक के बजाय, आधुनिक Activity नतीजे वाले एपीआई का इस्तेमाल करें.

गतिविधियों को मैनेज करना

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

लाइफ़साइकल कॉलबैक का क्रम अच्छी तरह से तय होता है. खास तौर पर, जब दो गतिविधियां एक ही प्रोसेस में हों. दूसरे शब्दों में, एक ही ऐप्लिकेशन में हों और एक गतिविधि दूसरी गतिविधि को शुरू कर रही हो. जब ऐक्टिविटी A, ऐक्टिविटी B को शुरू करती है, तब होने वाली कार्रवाइयों का क्रम यहां दिया गया है:

  1. गतिविधि A का onPause तरीका लागू होता है.
  2. गतिविधि B के onCreate, onStart, और onResume तरीके, क्रम से लागू होते हैं. अब उपयोगकर्ता का फ़ोकस गतिविधि B पर है.
  3. अगर गतिविधि A अब स्क्रीन पर नहीं दिख रही है, तो इसका onStop तरीका लागू होता है.

लाइफ़साइकल कॉलबैक के इस क्रम की मदद से, एक गतिविधि से दूसरी गतिविधि में जानकारी के ट्रांज़िशन को मैनेज किया जा सकता है.

अन्य संसाधन

गतिविधि पूरी होने की प्रोसेस के बारे में ज़्यादा जानने के लिए, ये अतिरिक्त संसाधन देखें:

कॉन्टेंट देखना