Android Activity Lifecycle – Step by Step

Android Activity Lifecycle – जैसाकि हमने पहले भी बताया कि प्रत्‍येक Android App वास्‍तव में Java Applet की तरह ही एक Framework पर आधारित होता है, जिसके अन्‍तर्गत Android App की प्रत्‍येक Activity की विभिन्‍न स्थितियों से सम्‍बंधित कुछ Methods होते हैं, जिन्‍हें Activity नाम की Base Class में Define किया गया है और अपने Android App में हमें इन्‍हीं Methods को Override करते हुए प्रत्‍येक Activity की प्रत्‍येक स्थिति के लिए Program Logics लिखने होते हैं।

अन्‍य शब्‍दों में कहें तो प्रत्‍येक Android App की एक Lifecycle होती है और इस Lifecycle के विभिन्‍न Important Points को कुछ निश्चित Methods द्वारा Represent किया जाता है। फलस्‍वरूप हमें किसी Particular Activity की किस State में क्‍या Operation Perform करवाना है, उस Operation से सम्‍बंधित Program Logics को उस Particular State से सम्‍बंधित Method को Override करके उसी Overridden Method में Specify करना होता है।

एक Android App के Lifecycle को User की जरूरत व उपलब्‍ध Resources के आधार पर पूरी तरह से Android Operating System यानी Android Platform द्वारा Manage किया जाता है।

उदाहरण के लिए हालांकि User अपने Android Device पर Web Browser Launch करना चाहता है, लेकिन Web Browser App Launch होगा या नहीं, इस बात को Device का Android System तय करता है। इसलिए Android Device का Android Platform ही Ultimate Manager होता है और इस बात को तय करता है कि कोई Specific Task Complete होगा या नहीं और यदि होगा तो किस तरह से।

Android Platform ही इस बात को तय करता है कि कब कोई Android App Load, Pause, Resume या Stop होगा।

यदि User किसी Activity को Currently Use कर रहा है, तो Android Platform उस Currently Running Activity को Highest Priority देता है जबकि यदि कोई Activity, Screen पर Currently Visible न हो, तो Android Platform उसे Lowest Priority देते हुए इस बात को तय करता है कि Currently Running Activity को अधिक Resource की आवश्‍यकता होने पर Inactive Activity को Shutdown करते हुए उसके Resources को Free करना है या नहीं, ताकि Currently Running Activity बिना किसी रूकावट के आसानी से Running रह सके।

यानी जिस Activity को Lower Priority प्राप्‍त होता है, Android System जरूरत होने पर बिना हमारी जानकारी के उस Activity को Shutdown भी कर देता है, ताकि उसके द्वारा Free हुए Resources को अन्‍य Currently Active Resource Hungry Activity को Allocate किया जा सके।

इस स्थिति में किसी Android App का Lifecycle एक आसान Logical Concept है लेकिन मूलत: ये बहुत ही Complicated है क्‍योंकि एक पूर्ण Android App में बहुत सारी चीजें प्रत्‍यक्ष रूप से Foreground में काम करती हैं तो बहुत सारी चीजें अप्रत्‍यक्ष रूप से Background में भी काम करती हैं और Android App का ठीक से काम करना इसी बात पर निर्भर है कि सभी अन्‍य चीजें भी ठीक तरीके से काम करें।

विशेष रूप से Android Application Architecture, मूलत: एक Component व Integration Oriented Architecture है जो हमें Rich User Experience, Code Reuse व Easy Application Integration की सुविधा तो देता है लेकिन साथ ही हमारे Application के Lifecycle Manager के लिए काफी Complexities भी Create करता है, जिसे एक Android App को ठीक से Run करने के लिए बहुत सारे जटिल काम Invisibly Background में करने पड़ते हैं।

उदाहरण के लिए मानलो कि एक User A किसी से User B से Phone Call पर बात कर रहा है। User B, User A से कोई Information मांगता है, जो कि उस Webpage में है, जिसका URL User A के Mail Box में Saved एक Email में है। वह Information देने के लिए User A को Phone Call के दौरान ही अपना Email App Open करना पड़ता है और उस Webpage के Hyperlink पर Click करना पड़ता है, जिस पर Information Exist है।

हम समझ सकते हैं कि इस पूरी प्रक्रिया के दौरान User A को कुल चार Android Apps के बीच Switch करना पड़ता है: Home Application, Talk Application, Email Application व Web Browser Application और जब User A, एक Application से दूसरे Application पर Navigate करता है, तो इस Navigation में उसे किसी प्रकार की कोई परेशानी पैदा नहीं होती यानी User का Experience काफी Seamless होता है। हालांकि प्रत्‍येक Application से दूसरे पर Switching के दौरान Background में Android System, Current Application की State को Save व Restore करता रहता है।

यानी Application A से Application B पर Navigate करते समय Application B की Activity को Load करने से पहले Application A की Activity की State को Save करना तथा Activity B से फिर से Activity A पर लौटने पर Activity A को पिछली Values से Restore करना, ये सारा काम Android System द्वारा Background में Continuously Automatically Handle किया जाता रहता है।

उदाहरण के लिए जब User A, Phone Call App से Email App जाता है, तो Phone Call App के Metadata को Save करने के बाद ही Email App को Launch किया जाता है। सरल शब्‍दों में कहें तो Android System किसी भी नई Activity को Launch करने से पहले Current Activity के Metadata को Save करता है, ताकि जब उस दूसरी Activity का काम समाप्‍त करके फिर से Backtrack करते हुए Current Activity पर पहुँचा जाए, तो Android System द्वारा Current Activity की State को फिर से Restore किया जा सके।

जबकि यदि इस Navigation के दौरान Memory की समस्‍या पैदा हो यानी सभी Android Apps को समानान्‍तर रूप से रन करना सम्‍भव न हो, तो उस स्थिति में Lowest Priority वाले Android App को Shutdown करते हुए उसके Memory को Release करना व उस Released Memory को फिर से Current Android App Activity को Allocate करना है अथवा कब किस Activity को Pause, Resume या Restart करना है, इन सभी बातों का निर्णय Android System द्वारा अपने स्‍वयं के स्‍तर पर Automatically लिया जाता है।

Android System, अपने किसी Application व उसके Components के Lifecycle के संदर्भ में काफी Sensitive होता है। इसलिए एक Stable Android App Develop करने के लिए हमें Android App से सम्‍पूर्ण Lifecycle व Lifecycle के दौरान Trigger होने वाले विभिन्‍न Events के बारे में अच्‍छी तरह से समझना जरूरी होता है ताकि हम Trigger होने वाले किसी Specific Event के Response में Execute होने वाले Appropriate Event Handler को Create कर सकें।

वे Processes, जो हमारे Android App व उसके Components को Run करते हैं, बहुत सारे Lifecycle Events से होते हुए गुजरते हैं और Android System प्रत्‍येक Lifecycle Event के Response में कुछ Callback Methods को Invoke करता है, जिन्‍हें हम हमारे Android App के प्रत्‍येक State Change के लिए Implement कर सकते हैं। यानी किसी Particular Event के Response में होने वाले State Change के लिए अपने Implemented Methods को Execute करवा सकते हैं:

protected void onCreate(Bundle savedInstanceState);
protected void onStart();
protected void onRestart();
protected void onResume();
protected void onPause();
protected void onStop();
protected void onDestroy();

ये सभी Methods किसी Activity की Lifecycle को Represent करते हैं के किसी Specific State Change Event को Represent करते हैं, इसलिए इस बात को समझना बहुत जरूरी है कि Android System द्वारा कब और किस State Change Event के Response में किस Method को Call किया जाता है ताकि हम एक Stable Android App Implement कर सकें।

यदि हम इन सभी Callback Methods को Android Application की Lifecycle Represent करने के लिए एक चित्र के रूप में प्रदर्शित करें, तो कुछ निम्‍नानुसार तरीके से कर सकते हैं:

यहां ध्‍यान देने वाली बात ये भी है कि हमें सभी Methods को Implement करना जरूरी नहीं है बल्कि हम हमारे Android App की किसी Activity के Lifecycle में जिस Point पर किसी Task को Perform करना होता है, उस Point पर Trigger होने वाले Event से सम्‍बंधित Event Handler या Callback Method को ही Implement करना होता है।

Android System हमारे Application की Activities को इस बात के आधार पर Start या Stop कर सकता है कि Android System के अन्‍य हिस्‍सों में क्‍या हो रहा है। उदाहरण के लिए यदि हमारे Android Device में उतनी Free Memory उपलब्‍ध न हो, जितनी एक नए Android App को Launch करने के लिए जरूरी है, तो हम चाहे जितनी बार उस नए Android App को Launch करने की कोशिश कर लें, Android System उसे तब तक Start नहीं करेगा, जब तक कि हम किसी पहले से Running Android App को Shutdown करते हुए उसकी Memory को Release न कर दें, ताकि उस Released Memory को Android System द्वारा हमारे नए Android App को Launch करने के लिए Use किया जा सके।

जब हम Android Device पर किसी Android App को Launch करते हैं, तो उस Android App की Display होने वाली First Screen यानी First Activity को Create करने के लिए Android System onCreate() Method को Call करता है और onCreate() Method के Just बाद में हमेंशा onStart() Method Call होता है लेकिन onStart() के Call होने से Just पहले हमेंशा onCreate() Method Call ही Call हो, ऐसा जरूरी नहीं है क्‍योंकि onStart() Method उस स्थिति में भी Call हो सकता है, जबकि हमारा Android App Stop हो गया हो।

जब onStart() Method Call होता है, तो उस समय तक हमारा Activity, User के सामने Visible नहीं होता बल्कि Visible होने ही वाला होता है। यानी onStart() Method, Activity के Visible होने से Just पहले की स्थिति को Represent करता है।

onStart() के Just बाद में onResume() Method Call होता है और ये Method Exactly उस समय Call होता है, जब हमारे Android App का First Activity, User के सामने Visible होता है जिसके साथ User Interact कर सकता है।

जब User इस Current Activity के Visible रहते हुए ही किसी अन्‍य Activity पर Move करता है, तो उस स्थिति में Android System, Current Activity के लिए onPause() Method Call करता है और एक Android App के लिए जब onPause() Method Call होता है तो फिर उस App के लिए या तो onResume() Method Call हो सकता है या फिर onStop() Method हो सकता है।

यदि User अपनी पिछली Activity पर फिर से Backtrack करता हुआ Return होता है, तो उसके लिए onResume() Method Call होता है लेकिन यदि वह Activity, User के लिए पूरी तरह से Invisible हो जाता है, तो उस स्थिति में उस Activity के लिए onStop() Method Call होता है।

जबकि यदि एक बार किसी Activity के लिए onStop() Method Call होने के बाद यदि वह User के सामने फिर से Visible होता है, तो उस स्थिति में उस Activity के लिए onRestart() Method Call होता है।

लेकिन यदि हमारा Activity, User के सामने Visible नहीं रहता बल्कि Stack में अपने Activate किए जाने का Wait कर रहा होता है, और उसी दौरान Android System किसी कारणवश उस Activity को Kill करना चाहता है, तो उस Inactive Android App को पूरी तरह से Shutdown करने के लिए onDestroy() Method को Call करता है।

इसी प्रक्रिया को यदि हम थोड़ा और बेहतर तरीके से समझने की कोशिश करें, तो Android App की Activity Lifecycle को उनके States व उन States से Associated Callback Methods को निम्‍नानुसार Represent कर सकते हैं:

जैसाकि कि हमने पिछले Section में Discuss किया, एक Activity की Lifecycle में वह कई States से गुजरता है और सभी States के दौरान Android System उससे Associated एक Callback Method को Call करता है लेकिन Activity की Lifecycle के दौरान मूलत: कुल तीन ही States (Resumed, Paused, Stopped) अन्‍त तक Static रहते हैं:

Resumed State

जब Activity Resumed State में होता है, तब वह User के लिए Foreground में Visible रहता है और User इस Activity के साथ Interact कर सकता है। इस स्थिति को कई बार Running State के नाम से भी जाना जाता है और जब भी कोई नया Android App Launch किया जाता है, वह Android App Created व Started States से होता हुआ सीधा Resumed State में पहुँच जाता है और प्रत्‍येक State के लिए Android System क्रमश: onCreate(), onStart() व onResume() Methods Call करता है।

Paused State

Activity के इस State में वह किसी अन्‍य Activity द्वारा Partially Covered हो जाता है।

उदाहरण के लिए मानलो कि आप एक Game खेल रहे हैं, तभी अचानक कोई Message आता है। Message आते ही उसके Notification से Game Activity के Screen का कुछ हिस्‍सा Newly Display होने वाले एक Semi-Transparent Notification Activity से ढ़क जाता है व Game के लिए onPause() Method Call होता है और Game Paused State में चला जाता है और तब तक कोई User Input Accept नहीं कर सकता, जब तक कि आप Notification Activity को Manually Close न कर दें।

यहां ध्‍यान देने वाली बात ये है कि इस प्रकार का Semi-Transparent Notification Activity, Current Activity को पूरी तरह से नहीं ढ़कता बल्कि Current Activity के केवल कुछ हिस्‍से को ही ढ़कता है और जैसे ही उस Partial Activity को Terminate किया जाता है, पिछलs Game App फिर से Resumed State में चला जाता है यानी पूरी तरह से Visible हो जाता है और User Input Accept कर सकता है।

Stopped State

Activity के इस State में वह किसी अन्‍य Activity द्वारा पूरी तरह से Covered कर लिया जाता है। परिणामस्‍वरूप Current Activity किसी अन्‍य Activity से पूरी तरह से Hide हो जाती है व Background में चली जाती है और Current Activity को Stop करने के लिए Android System द्वारा onStop() Method Call किया जाता है।

इस State में Current Activity Instance व उसके सभी State Information जैसे कि Member Variables को Access किया जा सकता है लेकिन उसके Codes किसी भी स्थिति में Execute नहीं होते।

जब Activity Stopped State में हेाता है, तब यदि User उस बाद में Launch की गई Activity को Close करते हुए फिर से पिछली Activity पर आता है, तो उस Activity के लिए क्रमश:  onPause() व onResume() Method Call होता है व Activity फिर से Visible हो जाता है जबकि यदि किसी कारणवश Android System को अधिक Resources की जरूरत पड़े तो वह onDestroy() Method को Call करते हुए इस Stopped Activity को Destroy यानी Shutdown भी कर देता है।

इस प्रकार से हालांकि एक Android Application की Activity Lifecycle के विभिन्‍न States के लिए कई Callback Methods समय-समय पर Execute होते हैं, लेकिन ज्‍यादातर परिस्थितियों में हमें मूलत: onCreate(), onResume() व onPause() Methods को ही Implement करना होता है।

onCreate() Method को हम हमारी Activity का User Interface Create करने के लिए Implement करते हैं व User Interface से सम्‍बंधित विभिन्‍न Components, Widgets आदि को Trigger होने वाले Events के साथ Bind करते हैं।

onPause() Method में हम हमारे Application के Critical Data को Data Store में Save करने से सम्‍बंधित Codes लिख सकते हैं क्‍योंकि यही वह अन्तिम Safe Method होता है, जिसे Android System द्वारा हमारे Application को Kill करने से पहले Call किया जाता है।

onStop() व onDestroy() Method, इन दोनों के Call होने की कोई गारन्‍टी नहीं होती। इसलिए हमारे Android App से सम्‍बंधित Critical Codes के लिए हम इन पर भरोसा नहीं कर सकते।