ב-Wear OS 6 מוצג API חדש, Watch Face Push, שיוצר הזדמנויות לתרחישי שימוש מתקדמים יותר בפרסום תצוגות שעון.
מתי כדאי להשתמש בהעברת תצוגת שעון
Watch Face Push הוא API ב-Wear OS שמאפשר למפתחים להוסיף, לעדכן או להסיר תצוגות שעון ישירות. ההרשאה לא נדרשת לפיתוח רגיל של תצוגת שעון.
תצוגות שעון שמשמשות עם Watch Face Push חייבות להיות כתובות ב-Watch Face Format. התוכן הזה יכול לכלול תצוגות שעון שנוצרו באמצעות Watch Face Designer, Watch Face Studio או כל כלי אחר שמייצר תצוגות שעון ב-Watch Face Format.
אפשר להשתמש ב-Watch Face Push API בכמה דרכים, אבל הטבלה הבאה מציגה את תרחישי השימוש העיקריים:
תרחיש לדוגמה | פתרון מומלץ | מורכבות |
---|---|---|
אני רוצה ליצור תצוגות שעון אישיות ולפרסם אותן. | להשתמש ב-Watch Face Format, באופן ישיר או באמצעות כלי כמו Watch Face Designer או Watch Face Studio, ולפרסם אותן ב-Google Play. | נמוכה |
אני רוצה ליצור אפליקציה לטלפון שמאפשרת למשתמשים לבחור תצוגות שעון מתוך אוסף שנבחר בקפידה, או לעצב ולהתאים אישית תצוגות שעון להתקנה ישירות בשעון עם Wear OS. | יוצרים אפליקציה לשעון ולטלפון באמצעות Watch Face Push API בשעון. | רחב |
מטרה
מקרה השימוש הקנוני ב-Watch Face Push API הוא יצירה של אפליקציית חנות. דרך האפליקציה הזו, משתמשים יכולים לבחור תצוגות שעון מתוך אוסף שנבחר בטלפון שלהם, ולשלוט ישירות בהתקנה של תצוגות השעון האלה בשעון המחובר שלהם.
שיקולים
לפרטים על יצירת תצוגות שעון, אפשר לעיין בהנחיות בנושא Watch Face Format: תצוגות שעון שנפרסות באמצעות Watch Face Push הן תצוגות שעון רגילות ב-Watch Face Format.
כשמעצבים את תצוגת השעון, חשוב להתחשב בשיקולים הבאים.
שמות של חבילות
תצוגות שעון שמותקנות באמצעות Watch Face Push חייבות לעמוד במוסכמה הבאה:
<app name>.watchfacepush.<watchface name>
… where <app name>
is the package name of the app calling the Watch Face
Push API.
לדוגמה, לאפליקציה עם שם החבילה com.example.mymarketplace
, אלה שמות החבילות התקינים של לוחות השעון:
com.example.mymarketplace.watchfacepush.watchface1
com.example.mymarketplace.watchfacepush.watchface2
com.example.mymarketplace.watchfacepush.another_watchface
ה-API דוחה תצוגות שעון שלא עומדות בדרישות של המוסכמה הזו.
תכולת החבילה
התוכן של קובץ ה-APK נאכף באופן מחמיר. חשוב לוודא ש-Watch Face Format עומד במגבלות הבאות: מבחינה טכנית, אפשר ליצור קובצי APK בפורמט Watch Face Format שמכילים קבצים של מטא-נתונים לא מזיקים וארטיפקטים אחרים, שאולי יתקבלו ב-Google Play אבל לא יעברו את האימות של Watch Face Push (ראו בהמשך).
אפשר להשתמש רק בקבצים או בנתיבים הבאים בכל קובץ APK של פני שעון:
/AndroidManifest.xml
/resources.arsc
/res/**
/META-INF/**
בנוסף, מותר להשתמש רק בתגים הבאים בקובץ AndroidManifest.xml
:
<manifest>
<uses-feature>
<uses-sdk>
<application>
<property>
<meta-data>
לבסוף, בחבילה צריך לציין minSdk
של לפחות 33
, ובתוך התג <application>
צריך לציין את המאפיין android:hasCode="false"
.
אימות
בניגוד לתצוגות שעון רגילות שמופצות דרך Google Play, באפליקציית Marketplace יש בדיקות שנועדו לוודא שכל תצוגת שעון מעוצבת היטב ומניבה ביצועים טובים.
מערכת Google Play משתמשת בבדיקות האימות הבאות כדי לוודא את האיכות של כל תצוגת שעון שמשתמשת ב-Watch Face Push:
- כל תצוגות השעון שמותקנות או מעודכנות באמצעות Watch Face Push API חייבות לעבור את כלי האימות של Watch Face Push.
- רק בכלי האימות הרשמי אפשר ליצור אסימוני אימות לשימוש עם ה-API.
- כלי האימות שבו משתמשים צריך להיות עדכני בזמן הפעלת האימות.
אין צורך לאמת מחדש קובץ APK שלא השתנה. התוקף של הטוקנים לא פג, גם אם הגרסה של כלי האימות שבה נעשה שימוש הוחלפה.
במקביל, מומלץ להריץ את האימות מחדש מדי פעם, כי הכלי לאימות מתעדכן באופן תקופתי.
הרצת כלי התיקוף
הכלי לאימות זמין בשלוש צורות:
- כלי CLI
- ספרייה לשימוש עם JVM
- ספרייה לשימוש ב-Android
שימוש בכלי האימות משורת הפקודה
- מקבלים את כלי האימות ממאגר Maven של Google.
מריצים את הכלי באופן הבא:
java -jar validator-push-cli-1.0.0-alpha06.jar \ --apk_path=<your watch face>.apk \ --package_name=<your marketplace package name>
אם הפעולה מצליחה, הפלט כולל אסימון אימות, שצריך לספק ל-Watch Face Push API כשמוסיפים או מעדכנים תצוגת שעון.
אם מתרחשת שגיאה, הפלט כולל פרטים על הבדיקה הספציפית שנכשלה.
שימוש בכלי לאימות ספריות
כוללים את מאגר Jitpack, שנדרש לתלות של מאמת:
repositories { ... google() maven { url = uri("https://jitpack.io") content { includeGroup("com.github.xgouchet") } } }
כוללים את התלות של כלי האימות בפרויקט:
// For use on JVM implementation("com.google.android.wearable.watchface.validator:1.0.0-alpha06") // For use on Android implementation("com.google.android.wearable.watchface.validator-android:1.0.0-alpha06")
מריצים את כלי התיקוף:
val validator = DwfValidatorFactory.create() val result = validator.validate(watchFaceFile, appPackageName) if (result.failures().isEmpty()) { val token = result.validationToken() println("Validation token: $token") // Validation success - continue with the token // ... } else { // There were failures, handle them accordingly - validation has failed. result.failures().forEach { failure -> println("FAILURE: ${failure.name()}: ${failure.failureMessage()}") // ... } }
דוגמה לשימוש בספרייה הזו מופיעה בדוגמה ב-GitHub. כדאי לעיין גם בספריית Portable Asset Compiler Kit (Pack), שיכולה לעזור לכם ליצור קובצי APK במכשיר לשימוש עם כלי האימות מבוסס-Android.
גודל ה-APK
צריך להקפיד במיוחד על תצוגות שעון מסוג Watch Face Push כדי לוודא שגודל ה-APK נשמר ברמה מינימלית: סביר להניח שקובץ ה-APK של תצוגת השעון יועבר מאפליקציית הטלפון לאפליקציית השעון באמצעות Bluetooth, וההעברה הזו עלולה להיות איטית.
יכול לקחת הרבה זמן להעביר קובץ APK גדול מדי, וזה פוגע בחוויית המשתמש וגם גורם לסוללה להתרוקן מהר יותר.
- כדאי להשתמש בספריות מתאימות כמו
pngquant
כדי לשמור על גודל קובץ התמונה ברמה המינימלית- הכללת התכונה בתהליך הפיתוח של אוסף תצוגות השעון
- בודקים שהמידות של התמונה מתאימות לקנה המידה שבו היא תשמש.
- חשוב לוודא שהתמונות נחתכו בצורה מתאימה כדי להסיר את הרקע שמסביב.
- הקטנת הגודל של קובצי גופן
- לדוגמה, אם משתמשים בגופן מסוים רק כדי להציג את השעה בפורמט
HH:MM
, אפשר להשתמש בכלי כמוpyftsubset
כדי להגביל את קובץ הגופן כך שיכיל רק את הגליפים הנדרשים. הפעולה הזו יכולה להקטין באופן משמעותי את הגודל של קובץ הגופן וקובץ ה-APK שמתקבלים. בפוסט הזה בבלוג אפשר לקרוא פרטים על צמצום הגודל של קובץ הגופן במקרים אחרים.
- לדוגמה, אם משתמשים בגופן מסוים רק כדי להציג את השעה בפורמט
בהנחיות לאופטימיזציה של השימוש בזיכרון יש הצעות נוספות לצמצום גודל ה-APK.
חתימה על APK
כמו בכל APK רגיל, צריך לחתום על כל תצוגות השעון. יוצרים מפתח שונה מזה שמשמש את האפליקציה הראשית, ומשתמשים במפתח השונה הזה לכל תצוגות השעון.
ארכיטקטורה
נבחן את שלושת הרכיבים העיקריים של המערכת:
- אחסון בענן: באפליקציית Marketplace הקנונית, עיצובי השעון שלכם נוצרים ומאוחסנים בענן, ומוכנים לשימוש על ידי המשתמשים. תצוגות השעון הן:
- חבילות APK מוכנות מראש בפורמט רגיל של תצוגת שעון
- כל אחת מהן מכילה רק תצוגת שעון אחת שמבוססת על פורמט תצוגת השעון
- אומתו באמצעות תהליך האימות של העברת פני השעון, ונשמרים יחד עם אסימון האימות המשויך.
- הם מוכנים לשחזור על ידי אפליקציית הטלפון כשצריך.
- אפליקציית הטלפון: אפליקציית הטלפון היא הדרך העיקרית שבה המשתמשים יוצרים אינטראקציה עם המערכת. הם יכולים:
- דפדוף וחיפוש בקטלוג של תצוגות השעון
- התקנה או החלפה של תצוגת השעון בשעון
- אפליקציה לשעון חכם: בדרך כלל לאפליקציה לשעון חכם אין ממשק משתמש משמעותי. האפליקציה משמשת בעיקר כגשר בין אפליקציית הטלפון לבין Watch Face Push APIs, עם הפונקציונליות הבאה:
- שימוש ב-Watch Face Push API כדי להתקין, לעדכן או להחליף תצוגות שעון
- בקשת ההרשאות הנדרשות והצגת הנחיה למשתמש
- הוספת תצוגת שעון שמוגדרת כברירת מחדל
- הוספת מטמון מינימלי של תצוגות שעון
- תקשורת בין הטלפון לשעון: התקשורת בין הטלפון לאפליקציה בשעון היא קריטית להצלחת חוויית השימוש הכוללת. שימוש בממשקי API של Wear OS Data Layer, שמאפשרים:
- זיהוי התקנה: באמצעות היכולות ו-
CapabilityClient
, אפליקציית הטלפון יכולה לזהות את היעדר אפליקציית השעון, ולהפך. אחרי ההודעה הזו, אפשר להפעיל intent לחנות Play כדי להתקין את גורם הצורה החסר. - ניהול מצב: באמצעות
DataClient
אוMessageClient
, הטלפון יכול להישאר מסונכרן עם מצב השעון. לדוגמה, לוודא שהטלפון יודע איזה תצוגת שעון מוגדרת. - העברת APK: באמצעות
ChannelClient
אוMessageClient
, אפשר לשלוח קובצי APK מהטלפון לשעון - הפעלה מרחוק: באמצעות
Messageclient
, הטלפון יכול להנחות את השעון לבצע קריאה ל-Watch Face Push API, למשל כדי להתקין תצוגת שעון.
- זיהוי התקנה: באמצעות היכולות ו-
פרטים נוספים זמינים במדריך בנושא Data Layer API.