גם המשבצות וגם הווידג'טים מציגים את התוכן שלכם בממשק של מערכת מרוחקת, אבל צריך להשתמש בגישות שונות כדי ליצור אותם. העברת המשבצת הקיימת לווידג'ט משמעותה מעבר מיצירת פריסה קשיחה לממשק משתמש דינמי ודקלרטיבי, וקבלת גישה ליכולות חדשות ולמודל פיתוח פשוט יותר.
בחירה של אסטרטגיית הטמעה
אם מעבירים אפליקציה שכוללת רכיב של כרטיס מדור קודם, צריך להחליט איך האפליקציה מספקת תוכן למערכת. בווידג'טים חדשים לגמרי צריך להשתמש בשירות ווידג'טים יחיד, אבל באפליקציות עם משבצות קיימות צריך לבחור בין שמירה על שני השירותים לבין איחוד לשירות ווידג'טים יחיד.
מומלץ: שירות כפול (אריח + ווידג'ט)
מומלץ לשמור גם על משבצת וגם על ווידג'ט בכל האפליקציות שיש להן משבצת קיימת. הספקת שני שירותים נפרדים מספקת את חוויית המשתמש הטובה ביותר האפשרית במכשירים שונים.
- Tile Service: הרחבת
TileServiceוהצהרה על מסנן Intent עבורandroidx.wear.tiles.action.BIND_TILE_PROVIDER. - שירות הווידג'ט: הרחבת
GlanceWearWidgetServiceוהצהרה על מסנן Intent עבורandroidx.glance.wear.action.BIND_WIDGET_PROVIDER. - קיבוץ לוגי: משתמשים במאפיין
groupבהגדרות הווידג'ט כדי לקשר את ההטמעה החדשה ל-TileServiceהקיים. כך המערכת יכולה לזהות אותם כרכיב לוגי יחיד ולהעביר באופן אוטומטי את משבצת הקרוסלה הקיימת של המשתמש לווידג'ט החדש ב-Wear OS 7 ומעלה.
התנהגות המערכת בהגדרה של שירות כפול:
| מערכת הפעלה / יכולת המכשיר | חוויית המשתמש שמתקבלת |
|---|---|
| Wear OS 3 | נעשה שימוש בכרטיס המידע |
| Wear OS 4, 5, 6 | נעשה שימוש בכרטיס המידע |
| Wear OS 7 (אין תמיכה בגובה חלקי, למשל Pixel Watch) | נעשה שימוש בכרטיס המידע |
| Wear OS 7 (תמיכה בגובה חלקי, למשל, Galaxy Watch) | נעשה שימוש בווידג'ט |
חלופה: שירות יחיד (ווידג'ט בלבד)
שירות יחיד מטפל בשני הפרוטוקולים. הגישה הזו מהירה יותר להטמעה, אבל היא מסתמכת על מצב תאימות כדי 'להתאים' את הווידג'ט שלכם לריבוע במכשירים שפועלת בהם גרסה ישנה יותר של Wear OS.
אם בוחרים בגישה הזו:
- מציינים את שני מסנני ה-Intent: השירות צריך לכלול מסנני Intent גם ל-
androidx.wear.tiles.action.BIND_TILE_PROVIDERוגם ל-androidx.glance.wear.action.BIND_WIDGET_PROVIDER. כך מוודאים שהווידג'ט יוצג בפלטפורמות של Wear 4, 5, 6 ו-7 (במקומות שנדרש). - שמירה על שם השירות הקיים (לשדרוגים חלקים): אם אתם מחליפים משבצת פעילה, שמירה על אותו שם של מחלקת השירות מבטיחה שמשתמשים שהמשבצת שלכם נמצאת בקרוסלה שלהם יראו שהיא מתעדכנת אוטומטית לווידג'ט החדש. ב-Wear OS 7, נעשה שימוש במאפיין
groupבקובץ ה-XML של הגדרות הווידג'ט כדי לקשר באופן לוגי בין רכיבים שונים. בגרסאות של Wear OS מתחת ל-7, המערכת מסתמכת על שם השירות כדי לזהות אותם כרכיב "זהה". אם אתם מעדיפים להשתמש בשם שירות חדש, האפליקציה עדיין תפעל בצורה מושלמת. עם זאת, משתמשים במכשירים עם Wear OS בגרסה 6 ומטה יצטרכו להוסיף מחדש את הווידג'ט לגלגל האפליקציות שלהם באופן ידני.
התנהגות המערכת בהגדרה של שירות יחיד:
| מערכת הפעלה / יכולת המכשיר | חוויית המשתמש שמתקבלת |
|---|---|
| Wear OS 3 | לא נתמך |
| Wear OS 4, 5, 6 | הווידג'ט מוצג כמשבצת במסך מלא |
| Wear OS 7 (אין תמיכה בגובה חלקי) | הווידג'ט מתורגם לרכיב מוטמע |
| Wear OS 7 (תמיכה בגובה חלקי) | נעשה שימוש בווידג'ט |
*נדרשת גרסה 1.6 ואילך של כלי העיבוד.
טיפים לתרגום ממשק משתמש
כשמתרגמים את ממשק המשתמש מ-ProtoLayout (Tiles) ל-Remote Compose (Widgets), המודל המנטלי משתנה מבוני פריסות אימפרטיביים לארכיטקטורה מבוססת-Compose שמבוססת על מצב, שבה עדכונים בממשק המשתמש מטופלים באמצעות קומפוזיציה מחדש. חשוב לזכור את העקרונות הבאים:
- שימוש בממשק משתמש הצהרתי: מחליפים את ה-builders של ProtoLayout האימפרטיביים (
LayoutElementBuilders) במקבילים הצהרתיים של Remote Compose, כמוRemoteText,RemoteColumnו-RemoteBox. - מתמקדים בתוכן הליבה (
mainSlot): ווידג'טים בגובה חלקי (למשל, סוגי המאגריםSMALLו-LARGE) מספקים משטח ממוקד שקל להסתכל עליו. במקום להעביר פריסת משבצות צפופה במסך מלא אחד לאחד, כדאי לייעל את העיצוב כדי להדגיש את המידע העיקרי באזור התוכן הראשי. - עיצוב מחדש של פעולות שמוצמדות לקצה: בארכיטקטורת המשבצות, רכיבים שמוצמדים לקצה המסך כמו
EdgeButtonעוגנו לbottomSlotייעודי. ווידג'טים בגובה חלקי משולבים ישירות במשטח גלילה אנכי, ולכן אין יותר פרדיגמה קבועה שלbottomSlot. לחצנים שמוצמדים לקצה משמשים לעיתים קרובות כפעולות ראשיות בולטות מאוד, ולכן המיגרציה דורשת עיצוב מחדש מכוון של ממשק המשתמש ולא החלפה ישירה של רכיב. הערכת אסטרטגיות חלופיות של חוויית משתמש לפעולות הראשיות:- פעולות בתוך השורה: שילוב של
RemoteButtonבתוך השורה ישירות בפריסתmainSlot. - הקשה על קונטיינר: אפשר לאחד את האינטראקציה על ידי הפיכת כל קונטיינר הווידג'ט לניתן להקשה באמצעות
PendingIntentAction. - שינוי מהותי בתוכן: הערכה מחדש של המיקוד של הווידג'ט. אם אין מקום לפעולה ייעודית, כדאי להציג נתונים עשירים יותר במבט חטוף ולהסתמך על הקשה אחת כדי לפתוח את האפליקציה המלאה, במקום לבודד פעולות ספציפיות בווידג'ט.
- פעולות בתוך השורה: שילוב של
- העברת הטיפול באירועים (פעולות לעומת פונקציות Lambda): הרכיבים מסתמכים על אינטראקציות (כמו
LoadAction) שמפעילות קריאות חוזרות (callback) מלאות לשירות כדי לרענן את ממשק המשתמש. הווידג'טים של Wear מופעלים בצד הלקוח. אי אפשר להריץ מרחוק פונקציות למדה רגילות של Compose. במקום זאת, צריך לספק פעולות הצהרתיות שניתנות לסריאליזציה (כמוValueChangeאוPendingIntentAction). אפשר לשלב אותן עם מצב הצהרתי (למשל,rememberMutableRemoteInt) כדי לתמוך בעדכונים מיידיים של ממשק המשתמש בלי נסיעות הלוך ושוב של האפליקציה. - התאמת המאפיינים והסוגים: כשמעבירים מאפייני פריסה, עדיף להשתמש בפתרון פריסה מושהה באמצעות
RemoteDp(למשל,10.rdp) במקום ב-Dpהרגיל. כך המערכת תוכל לחשב נכון את ערכי הפיקסלים בזמן הצגת המודעה. באופן דומה, אפשר להשתמש בפונקציות הרחבה של Remote Compose (.rcל-Color,.rsל-String,.rdpל-Dp) כדי להמיר בצורה חלקה סוגים רגילים של Kotlin ו-Remote Compose. - בדיקת קוד לדוגמה: כדי לראות דוגמאות מקיפות לאופן שבו אפשר ליצור פריסות, להחיל טיפוגרפיה סמנטית ולנהל ערך דינמי ב-Remote Compose, אפשר לעיין בקוד לדוגמה הרשמי שזמין במאגר Wear OS Samples.