אירועים שונים, חלקם מופעלים על ידי משתמשים וחלקם מופעלים על ידי המערכת, יכולים לגרום לActivity לעבור ממצב אחד למצב אחר. במסמך הזה מתוארים כמה מקרים נפוצים שבהם מתרחשים מעברים כאלה, ומוסבר איך לטפל בהם.
מידע נוסף על מצבי הפעילות זמין במאמר מחזור החיים של הפעילות. במאמר סקירה כללית על ViewModel מוסבר איך אפשר להשתמש בכיתה ViewModel כדי לנהל את מחזור החיים של הפעילות.
מתרחש שינוי בתצורה
יש מספר אירועים שיכולים להפעיל שינוי בהגדרות. הדוגמה הבולטת ביותר היא שינוי בין כיוון לאורך לכיוון לרוחב. מקרים אחרים שיכולים לגרום לשינויים בהגדרות כוללים שינויים בהגדרות השפה או במכשיר הקלט.
כשמתרחש שינוי בהגדרות, הפעילות נמחקת ונוצרת מחדש. הפעולה הזו מפעילה את הקריאות החוזרות הבאות במופע הפעילות המקורי:
נוצרת מופע חדש של הפעילות, והקריאות החוזרות הבאות מופעלות:
כדי לשמור על מצב ממשק המשתמש של פעילות במהלך שינויים בהגדרות, אפשר להשתמש בשילוב של מכונות ViewModel, השיטה onSaveInstanceState() או אחסון מקומי עקבי. ההחלטה איך לשלב בין האפשרויות האלה תלויה ברמת המורכבות של נתוני ממשק המשתמש, בתרחישי לדוגמה של האפליקציה ובשיקול של מהירות האחזור לעומת השימוש בזיכרון. מידע נוסף על שמירת המצב של ממשק המשתמש של הפעילות זמין במאמר שמירה של מצבי ממשק משתמש.
טיפול בבקשות תמיכה במצב ריבוי חלונות
כשאפליקציה עוברת למצב חלונות מרובים, שזמין ב-Android 7.0 (רמת API 24) ואילך, המערכת מעדכנת את הפעילות שפועלת על שינוי בתצורה, וכך עוברת את מעברי מחזור החיים שתוארו למעלה.
ההתנהגות הזו מתרחשת גם אם משנים את הגודל של אפליקציה שכבר פועלת במצב ריבוי חלונות. הפעילות יכולה לטפל בשינוי ההגדרה בעצמה, או לאפשר למערכת למחוק את הפעילות וליצור אותה מחדש עם המאפיינים החדשים.
מידע נוסף על מחזור החיים של חלונות מרובים זמין בהסבר על מחזור החיים של חלונות מרובים בדף תמיכה בריבוי חלונות.
במצב 'חלונות מרובים', יש שתי אפליקציות שגלויות למשתמש, אבל רק האפליקציה שבה המשתמש מקיים אינטראקציה נמצאת בחזית ומוקד ההתעניינות. הפעילות הזו נמצאת בסטטוס 'המשך', והאפליקציה בחלון השני נמצאת בסטטוס 'השהיה'.
כשהמשתמש עובר מאפליקציה א' לאפליקציה ב', המערכת קוראת ל-onPause() באפליקציה א' ול-onResume() באפליקציה ב'. המערכת עוברת בין שתי השיטות האלה בכל פעם שהמשתמש עובר בין אפליקציות.
מידע נוסף על מצב ריבוי חלונות זמין במאמר תמיכה במצב ריבוי חלונות.
פעילות או תיבת דו-שיח מופיעות בחזית
אם פעילות או תיבת דו-שיח חדשה מופיעות בחזית, תופסות את המיקוד ומכסות חלקית את הפעילות המתבצעת, הפעילות המכוסה מאבדת את המיקוד ונכנסת למצב מושהה. לאחר מכן, המערכת קוראת ל-onPause().
כשהפעילות המכוסה חוזרת לחזית ומקבלת שוב את המיקוד, המערכת קוראת ל-onResume().
אם פעילות חדשה או תיבת דו-שיח חדשה מופיעות בחזית, תופסות את המיקוד ומכסות לחלוטין את הפעילות המתבצעת, הפעילות המכוסה מאבדת את המיקוד ונכנסת לסטטוס 'מושהה'. לאחר מכן, המערכת מבצעת ברצף מהיר שיחות אל onPause() ו-onStop().
כשאותה מופע של הפעילות המכוסה חוזר לחזית, המערכת קוראת ל-onRestart(), ל-onStart() ול-onResume() בפעילות. אם מדובר במופע חדש של הפעילות המכוסה שעוברת לרקע, המערכת לא קוראת ל-onRestart(), אלא רק ל-onStart() ול-onResume().
המשתמש מקייש על 'הקודם' או מבצע תנועה ל'הקודם'
אם פעילות מסוימת נמצאת בחזית והמשתמש מקייש עליה או מבצע תנועת חזרה, הפעילות עוברת דרך פונקציות ה-call back onPause(), onStop() ו-onDestroy(). הפעילות נהרסת ומוסרת מהמקבץ האחורי.
כברירת מחדל, הפונקציה הלא פוליגונמית onSaveInstanceState() לא מופעלת במקרה כזה. ההתנהגות הזו מבוססת על ההנחה שהמשתמש מקייש על 'חזרה' בלי לצפות לחזור לאותה מופע של הפעילות.
עם זאת, אפשר לשנות את השיטה onBackPressed() כדי להטמיע התנהגות מותאמת אישית, למשל הצגת תיבת דו-שיח שבה המשתמש מתבקש לאשר שהוא רוצה לצאת מהאפליקציה.
אם מבטלים את הגדרת ברירת המחדל של השיטה onBackPressed(), מומלץ מאוד להפעיל את super.onBackPressed() מהשיטה שבה בוטלה הגדרת ברירת המחדל. אחרת, התנהגות המערכת של לחצן החזרה עשויה להרתיע את המשתמש.
המערכת מפסיקה את תהליך האפליקציה
אם אפליקציה נמצאת ברקע והמערכת צריכה לפנות זיכרון לאפליקציה בחזית, המערכת יכולה להרוג את האפליקציה ברקע. כשהמערכת מחסלת אפליקציה, אין ערובה לכך ש-onDestroy() תתועד באפליקציה.
למידע נוסף על האופן שבו המערכת מחליטה אילו תהליכים למחוק, אפשר לקרוא את המאמרים מצב הפעילות והוצאה מהזיכרון ותהליכים ומחזור החיים של האפליקציה.
במאמר שמירה ושחזור של מצב ממשק המשתמש הזמני מוסבר איך לשמור את מצב ממשק המשתמש של הפעילות כשהמערכת מפסיקה את תהליך האפליקציה.