מבוא לפעילויות

המחלקה Activity היא רכיב חיוני ב-Android האפליקציה, והאופן שבו הפעילויות מופעלות ומתבצעות חלק ממודל האפליקציה של הפלטפורמה. בניגוד לפרדיגמות תכנות אילו אפליקציות מופעלות בשיטת main(), Android המערכת יוזמת קוד במכונה של Activity על ידי הפעלה של שיטות ספציפיות של קריאה חוזרת (callback) שמתאימות לשלבים ספציפיים של במחזור החיים שלו.

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

הקונספט של פעילויות

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

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

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

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

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

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

הגדרת המניפסט

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

להצהיר על פעילויות

כדי להצהיר על הפעילות שלך, עליך לפתוח את קובץ המניפסט ולהוסיף <activity> כצאצא של <application> לרכיב מסוים. לדוגמה:

<manifest ... >
  <application ... >
      <activity android:name=".ExampleActivity" />
      ...
  </application ... >
  ...
</manifest >

המאפיין היחיד הנדרש לאלמנט הזה הוא android:name, שמציין את שם הסיווג של הפעילות. אפשר גם להוסיף מאפיינים שמגדירים מאפייני פעילות כמו תווית, סמל או עיצוב של ממשק המשתמש. למידע נוסף על המאפיינים האלה ועל מאפיינים אחרים, אפשר לעיין <activity> מסמכי עזר של הפניות לרכיבים.

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

הצהרה על מסנני Intent

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

כדי ליהנות מהיתרונות של התכונה הזו, צריך להצהיר <intent-filter> במאפיין <activity>. ההגדרה של הרכיב הזה כוללת רכיב <action> וגם אופציונלי, <category> ו/או <data> לרכיב מסוים. הרכיבים האלה משולבות כדי לציין את סוג הכוונה שאליה הפעילות שלכם יכולה להגיב. עבור קטע הקוד הבא מראה איך להגדיר פעילות שולח נתוני טקסט, ומקבלת בקשות מפעילויות אחרות לעשות זאת:

<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
        <data android:mimeType="text/plain" />
    </intent-filter>
</activity>

כאן לדוגמה, <action> מציין שפעילות זו שולחת נתונים. הצהרה על <category> כי DEFAULT מאפשר את הפעילות כדי לקבל בקשות הפעלה. הרכיב <data> מציין את סוג הנתונים הפעילות הזו יכולה לשלוח. קטע הקוד הבא מראה איך לקרוא הפעילות שמתוארת למעלה:

Kotlin

val sendIntent = Intent().apply {
    action = Intent.ACTION_SEND
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, textMessage)
}
startActivity(sendIntent)

Java

// Create the text message with a string
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.setType("text/plain");
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);
// Start the activity
startActivity(sendIntent);

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

הצהרת ההרשאות

אפשר להשתמש במניפסט תג <activity> לשליטה אילו אפליקציות יכולות להתחיל פעילות מסוימת. פעילות של הורה לא יכולה להפעיל פעילות של ילדים, אלא אם שתי הפעילויות כוללות את אותן הרשאות . אם אתם מצהירים <uses-permission> של פעילות הורה, לכל פעילות צאצא חייבת להיות התאמה <uses-permission> לרכיב מסוים.

לדוגמה, אם האפליקציה רוצה להשתמש באפליקציה היפותטית בשם SocialApp, כדי לשתף פוסט ברשתות החברתיות, אפליקציית SocialApp עצמה צריכה להגדיר את ההרשאה שאפליקציה ששולחת קריאה לפעולה צריכה לכלול:

<manifest>
<activity android:name="...."
   android:permission=”com.google.socialapp.permission.SHARE_POST”

/>

לאחר מכן, כדי לקבל הרשאה לקרוא ל-SocialApp, האפליקציה צריכה להתאים להרשאה שהוגדרה מניפסט של SocialApp:

<manifest>
   <uses-permission android:name="com.google.socialapp.permission.SHARE_POST" />
</manifest>

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

ניהול מחזור החיים של הפעילות

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

onCreate()

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

כאשר onCreate() מסתיים, הקריאה החוזרת הבאה היא תמיד onStart().

onStart()

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

onResume()

המערכת מפעילה את הקריאה החוזרת הזו ממש לפני שהפעילות מתחילה. עם המשתמש. בשלב הזה, הפעילות נמצאת בראש הפעילות מקבץ, ומתעד את כל הקלט של המשתמשים. רוב הפונקציונליות העיקרית של אפליקציה היא מוטמע ב-method onResume().

הקריאה החוזרת של onPause() תמיד עוקב אחרי onResume().

onPause()

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

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

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

כשהרצת הפקודה onPause() תסתיים, הקריאה החוזרת הבאה היא onStop() או onResume(), בהתאם מתרחשת אחרי שהפעילות עוברת למצב השהיה.

onStop()

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

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

onstart()

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

הקריאה החוזרת הזו תמיד מגיעה אחרי onStart()

onDestroy()

המערכת מפעילה את הקריאה החוזרת הזו לפני שפעילות מושמדת.

הקריאה החוזרת הזו היא הקריאה הסופית שהפעילות מקבלת. onDestroy() הוא בדרך כלל מיושמות כדי לוודא שכל המשאבים של הפעילות. פורסמו כשהפעילות או התהליך שמכיל אותה מושמדים.

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