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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

लिखें और लाइफ़साइकल

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

• लाइफ़साइकल की जानकारी वाला कलेक्शन: ViewModel से फ़्लो इस्तेमाल करने के लिए, collectAsStateWithLifecycle का इस्तेमाल करें. जब यूज़र इंटरफ़ेस (यूआई) Started स्टेट में होता है, तब यह एपीआई अपने-आप डेटा इकट्ठा करना शुरू कर देता है. जब यूज़र इंटरफ़ेस (यूआई) बैकग्राउंड में चला जाता है, तब यह डेटा इकट्ठा करना बंद कर देता है. इससे, संसाधनों का ज़रूरत से ज़्यादा इस्तेमाल नहीं होता. स्टेट के तौर पर फ़्लो इकट्ठा करने के बाद, 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!")
}
InteroperabilityAPIsSnippets.kt

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

onStart

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

जब ऐक्टिविटी, Started स्थिति में चली जाती है, तब लाइफ़साइकल के बारे में जानकारी रखने वाला कोई भी कॉम्पोनेंट, ऐक्टिविटी के लाइफ़साइकल से जुड़ा होता है. इसे ON_START इवेंट मिलता है.

onStart मेथड तुरंत पूरा हो जाता है. साथ ही, Created स्टेट की तरह, ऐक्टिविटी Started स्टेट में नहीं रहती है. यह कॉलबैक पूरा होने के बाद, गतिविधि Resumed स्थिति में आ जाती है. इसके बाद, सिस्टम 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 कॉलबैक के बारे में बताए गए सेक्शन में इसके बारे में बताया गया है. इससे मौजूदा गतिविधि रुक जाती है. यह सबसे सामान्य मामला है.
• मल्टी-विंडो मोड में, किसी भी समय सिर्फ़ एक ऐप्लिकेशन पर फ़ोकस किया जाता है. साथ ही, सिस्टम अन्य सभी ऐप्लिकेशन को रोक देता है.
• डायलॉग बॉक्स जैसी नई और कुछ हद तक पारदर्शी गतिविधि खुलने पर, उसके पीछे मौजूद गतिविधि रुक जाती है. जब तक गतिविधि आंशिक रूप से दिखती है, लेकिन फ़ोकस में नहीं होती, तब तक वह रुकी रहती है.

जब कोई गतिविधि Paused स्थिति में चली जाती है, तब गतिविधि के लाइफ़साइकल से जुड़ा कोई भी लाइफ़साइकल-अवेयर कॉम्पोनेंट, 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
    }
    ...
}

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

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

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

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

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

onStop

जब आपकी गतिविधि उपयोगकर्ता को नहीं दिखती है, तब वह Stopped स्टेट में चली जाती है. साथ ही, सिस्टम 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 के लिए काम का व्यू डेटा भी शामिल किया जा सकेगा. अगर कॉन्फ़िगरेशन में बदलाव की वजह से Activity को फिर से बनाया जाता है, तो ViewModel को कुछ भी करने की ज़रूरत नहीं होती. ऐसा इसलिए, क्योंकि इसे सुरक्षित रखा जाता है और अगले Activity इंस्टेंस को दिया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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))
    )
}
StateOverviewSnippets.kt

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

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

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

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

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

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

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 तरीका काम करेगा.

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

अन्य संसाधन

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

कॉन्टेंट देखता है

• गतिविधि का लाइफ़साइकल (व्यू)