פונקציונליות שמתאימה להתקנה כמודול על פי דרישה היא פונקציונליות שרוב המשתמשים לא זקוקים לה בזמן ההתקנה. ריכזנו כאן כמה דוגמאות לתכונות באפליקציות שמתאימות למודולים על פי דרישה:
- עריכה והעלאה של סרטון באפליקציה שבה רוב המשתמשים רק צופים בסרטונים
- הוספת מתכון באפליקציה שבה רוב המשתמשים רק מדפדפים במתכונים של אחרים ומצטרפים אליהם
- פונקציונליות של עזרה ותמיכה כשרוב המשתמשים לא מבקשים עזרה, או לא מבקשים אותה באפליקציה
- ספריות גדולות לפונקציונליות שמשתמשים בה פחות, כמו תיעוד של באגים מפורטים ודיווח עליהם
- יכולות ספציפיות של תשלום או תשלום במסגרת תהליך התשלום
- חוויות מדיה ברזולוציה גבוהה מאוד או תכונות של מציאות מדומה (VR) או מציאות רבודה (AR)
במקרה הרגיל שבו המודולים האלה קטנים יחסית (פחות מ-10MB) ואין כשלים ברשת או כשלים אחרים, המשתמשים יכולים להוריד מודול על פי דרישה ולהשתמש בו במהירות רבה. כלומר, בדרך כלל אין הבדל בחוויה לעומת המצב שבו המודול היה נוכח בהתקנת האפליקציה.
בדף הזה מתוארות שיטות מומלצות שיעזרו לכם לבצע את הפעולות הבאות:
- חשוב לוודא שהמשתמשים מודעים לכך שיכול להיות שההורדה של מודולים גדולים יחסית לא תתבצע באופן מיידי, או שיהיו שגיאות בהתקנת המודולים, ושהם מרגישים שהם שולטים בכך.
- לשפר את חוויית העברת המודול, במיוחד במצבים שבהם אפשר לצפות שמשתמש יזדקק למודול מסוים.
אחרי שתקראו את המדריך הזה, תוכלו לנסות את האפליקציה לדוגמה של Play Core API כדי לראות איך השיטות המומלצות האלה פועלות.
עדכון המשתמש
כדאי להודיע למשתמש אם תכונה מסוימת לא זמינה באופן מיידי. אם משתמש מחליט להוריד את התכונה מ-Google Play, צריך להציג את התקדמות ההורדה.
אתם יכולים לעקוב אחרי סטטוס הבקשה כדי להציג את התקדמות ההורדה ואת סטטוס ההתקנה. עם זאת, סוג ממשק המשתמש שתרצו להציג עשוי להשתנות בהתאם לגודל ההורדה:
- במודולים קטנים יותר (כ-10MB או פחות) שאפשר להתקין במהירות רבה, כדאי להשתמש באינדיקטורים כמו סמלי ספינר או הודעה קצרה מסוג 'מורידים תוכן'.
- אם מדובר במודולים גדולים יותר, שההורדה וההתקנה שלהם עשויות להימשך כמה שניות או יותר, כדאי להציג סרגל התקדמות של ההורדה וההתקנה, כמו זה שמוצג באיור 1.
איור 1. הצגת הודעה וסרגל התקדמות כשמורידים ומתקינים תכונה על פי דרישה
דיווח על עיכובים וכשלים בהתקנה בצורה נעימה
אם ההורדה נכשלת או מתקדמת לאט יותר מהצפוי, חשוב להסביר למשתמש בצורה ברורה ושקופה מה קורה ומה הוא יכול לעשות, כפי שמתואר בתמונות 2 ו-3. לדוגמה, אם תעקבו אחרי סטטוס בקשת ההורדה והאפליקציה תקבל הודעת שגיאה מסוג API_NOT_AVAILABLE
, תוכלו להודיע למשתמש שהמכשיר שלו לא תומך בהורדות על פי דרישה.
![](https://developer.android.google.cn/static/studio/images/projects/dynamic-delivery/failed_download.png?authuser=1&hl=he)
איור 2. להסביר למשתמש למה לא ניתן להתקין תכונה בשלב הזה
![](https://developer.android.google.cn/static/studio/images/projects/dynamic-delivery/large_download.png?authuser=1&hl=he)
איור 3. הסבר למשתמש למה הורדת התכונה נמשכת יותר מהצפוי
הצגת הערך לפני שמתבצעת בקשה להרשאה להורדות גדולות
אם מודול על פי דרישה גדול (יותר מ-150MB), מערכת Google Play דורשת מהמשתמש להביע הסכמה לפני ההורדה.
לפני ששולחים בקשה לקבלת המודול, חשוב להסביר למשתמשים מה הערך שהוא יספק להם. חשוב לעזור להם להבין למה אתם מבקשים מהם את הבקשה הזו, כמו שאתם עושים כשאתם מבקשים הרשאות לאפליקציה. תקשורת פתוחה עם המשתמשים מגדילה את הסבירות שהם יאשרו את ההורדה.
לדוגמה, נניח שאתם מפתחים אפליקציית מסחר אלקטרוני, ואחת מהתכונות שלה מאפשרת למשתמשים למקם רהיטים ישירות בדירה שלהם באמצעות מציאות רבודה (AR). אפשר לשלוח הודעה כמו "רוצה לראות את הספה החדשה בסלון? התקנת תוכנת הצפייה במציאות רבודה'.
ביצוע ההורדה וההתקנה ברקע
הורדה והתקנה של מודולים צריכות להתבצע תמיד ברקע. כלומר, בזמן שהמשתמש מחכה שהתכונה תהיה זמינה, צריך לאפשר לו להמשיך להשתמש בחלקים אחרים של האפליקציה. כשהתכונה תהיה זמינה, צריך להציג התראה שמאפשרת למשתמש לעבור לשימוש בתכונה הזו לפי שיקול דעתו.
כפי שמוצג באיור 5, המשתמש ממשיך להשתמש באפליקציה ומקבל התראה כשההתקנה של התכונה על פי דרישה מסתיימת.
איור 5. במקום לשנות את ההקשר של המשתמש באופן פתאומי כשההתקנה של המודול מסתיימת, כדאי להודיע למשתמש שהתכונה המבוקשת מוכנה לשימוש.
כשהמודול יהיה מוכן לשימוש, עליכם להודיע למשתמש ולתת לו אפשרות להפעיל את התכונה. התבנית הזו מספקת למשתמש הקשר ושליטה בחוויה שלו.
במקרים מסוימים, תוכלו להשיק את התכונה ברגע שהיא תהיה מוכנה. עם זאת, מכיוון שהפעולה הזו עלולה להפריע לחוויית המשתמש, חשוב לשקול היטב אם ההתנהגות הזו צפויה ומתאימה.
פינוי נפח אחסון במכשיר כשלא צריך יותר את המודול
תכונה שימושית של כל המודולים של התכונות היא היכולת להסיר אותם בנפרד. אם אתם לא משתמשים יותר במודול תכונות מסוים, אתם יכולים לבקש מ-Google Play להסיר את המודול הזה כדי לצמצם את גודל האפליקציה במכשיר של המשתמש.
לדוגמה, יכול להיות שלאפליקציה שלכם יש תהליך קליטה מקיף, אולי עם מדיה עשירה. אחרי שהמשתמש משלים את תהליך ההצטרפות, או אחרי שהוא משתמש פעיל במשך פרק זמן מסוים, תוכלו להשתמש ב-Play Feature Delivery API כדי לבקש מ-Google Play להסיר רק את הרכיב הזה של האפליקציה.
חשוב לזכור שאפשר גם להסיר מאוחר יותר מודולים שכללתם בהתקנה הראשונית של האפליקציה. לדוגמה, מודול שמלמד משתמשים חדשים איך להשתמש באפליקציה הוא שימושי כשמשתמשים משתמשים באפליקציה בפעם הראשונה. עם זאת, כדי לצמצם את גודל האפליקציה, תוכלו להסיר את המודול אחרי שהמשתמשים משלימים את ההדרכה.
טיפים מתקדמים
בדרך כלל, צריך לטפל במצבים שבהם המשתמש מאותת במפורש על כוונה להשתמש בפונקציונליות של מודולי התכונות על פי דרישה.
עם זאת, כדאי לחזות מתי משתמש צפוי לקיים אינטראקציה עם תכונה לפני שהוא יסמן לכם שהוא רוצה להשתמש בה. לדוגמה, באפליקציה שמאפשרת להוריד ולהכין מתכונים, ההנחיות הבאות מתארות איך לבצע אופטימיזציה של חוויית העברת המודול על ידי צפייה מראש בצרכים של המשתמשים.
לחזות את הצורך של המשתמש בתכונה בסשן הנוכחי. כדאי לשקול אם המשתמשים יצטרכו ליצור חשבון באפליקציית המתכונים רק אם הם רוצים ליצור ולשתף מתכונים משלהם עם הקהילה. אתם יכולים להשתמש ביצירת החשבון כאות לכך שהמשתמש צפוי להוסיף מתכון משלו, ולהתחיל להוריד את מודול התכונה עוד לפני שהמשתמש מקייש על 'הוספת מתכון'. תוכלו להשתמש בגישה הזו בתהליכים אחרים באפליקציה כדי להפוך את תהליך ההורדה של התכונות לחלק יותר.
לחזות את הצורך של המשתמש בתכונה בסשן הקרוב. אם אתם לא צריכים שהאפליקציה תוריד ותתקין מודול על פי דרישה באופן מיידי, תוכלו לדחות את ההתקנה למועד שבו האפליקציה תפעל ברקע, ו-Google Play יטפל בהורדה ובהתקנה בשבילכם. לדוגמה, נניח שאתם רוצים להשיק מתכונים עונתיים חדשים לאפליקציית הבישול, אבל הם לא בעדיפות גבוהה בסשן הנוכחי של המשתמש. אתם יכולים לבקש מ-Play להוריד ולהתקין את המתכונים האלה כשהאפליקציה פועלת ברקע. האפשרות הזו שימושית במיוחד לתכונות גדולות יותר (יותר מ-10MB) שלא נדרשות כרגע, אבל סביר להניח שיהיה צורך בהן בעתיד.
לחזות את הצורך של המשתמש בתכונה לפני התקנת האפליקציה. מומלץ להוסיף תמיכה בהעברה מותנית כדי לכלול את התכונה בזמן ההתקנה על סמך מדינה המשתמש, יכולות החומרה של המכשיר ורמת ה-API. לדוגמה, יכול להיות שתרצו לכלול מתכונים שמכילים בשר חזיר במודולים מותנים ולהחריג את המודול הזה מהתקנת האפליקציה באזורים שבהם רוב התושבים נמנעים מאכילת בשר חזיר.