שינויים במצב הפעילות

אירועים שונים, חלקם מופעלים על ידי המשתמש וחלקם על ידי המערכת, יכולים לגרום ל-Activity לעבור ממצב אחד למצב אחר. במסמך הזה מתוארים כמה מקרים נפוצים שבהם מתרחשים מעברים כאלה, ומוסבר איך לטפל בהם.

מידע נוסף על מצבי פעילות זמין במאמר בנושא מחזור החיים של פעילות. כדי לקבל מידע על האופן שבו המחלקה ViewModel יכולה לעזור לכם לנהל את מחזור החיים של הפעילות, אפשר לעיין בסקירה הכללית של ViewModel.

ברוב המקרים של שינויים בפעילות, לא צריך להגיב ישירות לקריאות חוזרות במחזור החיים של הפעילות. מכיוון ש-Compose בונה מחדש את ממשקי המשתמש מהמצב, אפשר לנצל את היתרון של קומפוזיציה מחדש אוטומטית על ידי אחסון המצב במקום מתאים, כמו rememberSaveable או ViewModel.

מתרחש שינוי בהגדרה

יש מספר אירועים שיכולים להפעיל שינוי בהגדרה. הדוגמה הבולטת ביותר היא שינוי בין מצב לאורך למצב לרוחב. מקרים אחרים שיכולים לגרום לשינויים בהגדרות כוללים שינויים בהגדרות השפה או במכשיר הקלט.

כשמתרחש שינוי בהגדרות, הפעילות נהרסת ונוצרת מחדש. הפעולה הזו מפעילה את הקריאות החוזרות (callbacks) הבאות במופע הפעילות המקורי:

1. onPause
2. onStop
3. onDestroy

מופע חדש של הפעילות נוצר, וההתקשרות חזרה הבאה מופעלת:

1. onCreate
2. onStart
3. onResume

בדרך כלל לא מתקשרים ישירות עם הפונקציות האלה כשכותבים הודעה. במקום זאת, צריך להשתמש ב-Lifecycle API כדי לעקוב אחרי שינויים במצב. ב-Compose, אפשר להשתמש ב-LocalLifecycleOwner.current כדי לקבל את מחזור החיים הנוכחי ולהוסיף observer, וכך להגיב לאירועים.

כדי לשמור את מצב ממשק המשתמש של פעילות מסוימת כשמתבצעים שינויים בהגדרות, אפשר להשתמש בשילוב של מופעי ViewModel, rememberSaveable או אחסון מקומי מתמשך. ההחלטה איך לשלב בין האפשרויות האלה תלויה במורכבות של נתוני ממשק המשתמש, בתרחישי השימוש באפליקציה ובשיקולים של מהירות אחזור הנתונים לעומת השימוש בזיכרון. ברוב תרחישי השימוש, כדאי להעלות את הסטטוס לרכיב ViewModel ולהשתמש ב-rememberSaveable כדי לוודא שהסטטוס נשמר גם כשמבצעים שינויים בהגדרות וגם כשהמערכת מבצעת השבתת תהליך. מידע נוסף על שמירת מצב ממשק המשתמש של הפעילות זמין במאמר שמירת מצבי ממשק המשתמש.

כשפעילות נוצרת מחדש בגלל שינוי בהגדרה, הקומפוזיציה הראשונית מושמדת. שימוש ב-ViewModel או ב-rememberSaveable מבטיח שהמצב של ממשק המשתמש ישוחזר בקומפוזיציה החדשה.

מידע נוסף זמין במאמרים מחזור החיים ב-Jetpack פיתוח נייטיב ומצב ב-Jetpack פיתוח נייטיב.

טיפול במקרים של ריבוי חלונות

כשמכניסים אפליקציה למצב מרובה חלונות, שזמין ב-Android 7.0 (רמת API‏ 24) ומעלה, המערכת מודיעה על שינוי בהגדרות לפעילות שפועלת, וכך עוברת את המעברים במחזור החיים שמתוארים למעלה.

ההתנהגות הזו מתרחשת גם אם משנים את הגודל של אפליקציה שכבר פועלת במצב ריבוי חלונות. הפעילות יכולה לטפל בשינוי ההגדרה בעצמה, או לאפשר למערכת להרוס את הפעילות וליצור אותה מחדש עם המאפיינים החדשים.

מידע נוסף על מחזור החיים של ריבוי חלונות מופיע בהסבר על מחזור החיים של ריבוי חלונות במאמר תמיכה במצב ריבוי חלונות.

במצב מרובה חלונות, למרות ששתי אפליקציות גלויות למשתמש, רק האפליקציה שהמשתמש מקיים איתה אינטראקציה נמצאת בחזית ומוגדרת כפעילה. הפעילות הזו נמצאת במצב 'המשך', ואילו האפליקציה בחלון השני נמצאת במצב 'השהיה'.

כשהמשתמש עובר מאפליקציה א' לאפליקציה ב', המערכת קוראת ל-onPause באפליקציה א' ול-onResume באפליקציה ב'. הוא עובר בין שתי השיטות האלה בכל פעם שהמשתמש עובר בין האפליקציות.

פרטים נוספים על מצב ריבוי חלונות זמינים במאמר בנושא תמיכה במצב ריבוי חלונות.

פעילות או תיבת דו-שיח מופיעות בחזית

אם פעילות או תיבת דו-שיח חדשה מופיעות בחזית, מקבלות את המיקוד ומכסות חלקית את הפעילות שמתבצעת, הפעילות המכוסה מאבדת את המיקוד ועוברת למצב מושהה. לאחר מכן, המערכת קוראת לפונקציה onPause.

כשהפעילות המוסתרת חוזרת לחזית וממוקדת שוב, המערכת קוראת ל-onResume.

אם פעילות או תיבת דו-שיח חדשה מופיעות בחזית, מקבלות את המיקוד ומכסות לחלוטין את הפעילות שמתבצעת, הפעילות המכוסה מאבדת את המיקוד ועוברת למצב 'הופסקה'. לאחר מכן המערכת מתקשרת במהירות לonPause ול-onStop.

כשאותו מופע של הפעילות המכוסה חוזר לחזית, המערכת קוראת לפעילות את onRestart,‏ onStart ו-onResume. אם מדובר במופע חדש של הפעילות המכוסה שעובר לרקע, המערכת לא קוראת ל-onRestart, אלא רק ל-onStart ול-onResume.

השינוי בפריסת המסך לא מושפע מהצגת תיבות דו-שיח בחזית. עם זאת, תופעות לוואי שקשורות למחזור החיים, כמו תהליכים ואנימציות, צריכות להשתמש בממשקי API שמודעים למחזור החיים (כמו collectAsStateWithLifecycle) כדי להשהות ולחדש את הפעולה באופן אוטומטי לפי הצורך. מידע נוסף זמין במאמר State ו-Jetpack פיתוח נייטיב.

המשתמש מקיש על החץ חזרה או מבצע תנועת חזרה

אם פעילות נמצאת בחזית והמשתמש מקיש על לחצן החזרה או מבצע תנועת חזרה, הפעילות עוברת דרך קריאות החזרה (callback) של onPause,‏ onStop ו-onDestroy. הפעילות מושמדת ומוסרת ממקבץ פעילויות קודמות (back stack).

באפליקציה עם פעילות אחת, כמו ברוב אפליקציות Compose, rememberSaveable לא ישמור את המצב אם רכיב ה-Composable יוסר ממחסנית הניווט. הסיבה לכך היא שכשהמשתמש מקיש על 'הקודם', אין ציפייה שהוא יחזור לאותו מופע, ולכן כל המצב נמחק.

כדי להטמיע התנהגות מותאמת אישית של לחצן 'הקודם', כמו הצגת תיבת דו-שיח שבה המשתמש מתבקש לאשר שהוא רוצה לצאת מהאפליקציה, משתמשים ב-NavigationEventHandler API.

המערכת משביתה את תהליך האפליקציה

אם אפליקציה פועלת ברקע והמערכת צריכה לפנות זיכרון בשביל אפליקציה שפועלת בחזית, המערכת יכולה להרוג את האפליקציה שפועלת ברקע. כשהמערכת הורגת אפליקציה, אין ערובה לכך שהשיטה onDestroy תיקרא באפליקציה.

כדי לקרוא מידע נוסף על האופן שבו המערכת מחליטה אילו תהליכים להפסיק, אפשר לעיין במאמרים מצב הפעילות והוצאה מהזיכרון ותהליכים ומחזור החיים של האפליקציה.

במאמר שמירה ושחזור של מצב ממשק משתמש זמני מוסבר איך לשמור את מצב ממשק המשתמש של הפעילות כשהמערכת מפסיקה את התהליך של האפליקציה.