סקירה כללית של Data Layer API

‫Wearable Data Layer API, שהוא חלק מ-Google Play Services, מספק ערוץ תקשורת בין מכשירים לבישים (כמו שעונים חכמים) לבין מכשירים ניידים מחוברים (בדרך כלל סמארטפונים). זו דרך לסנכרן ולהעביר נתונים בין המכשירים.

תרחישים נפוצים לדוגמה

השתמשו ב-Data Layer API כשהאינטראקציה היא רק בין השעון לטלפון. לדוגמה:

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

במקרים רבים, כדאי להשתמש בתשתית הענן הקיימת, למשל:

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

בתרחישים כאלה, צריך להשתמש בנקודות הקצה ובתשתית הקיימות שלכם, במקום ב-Data Layer API.

אפשרויות לתקשורת

הנתונים מועברים באחת מהדרכים הבאות:

1. ישירות, כשיש חיבור Bluetooth בין מכשיר Wear OS למכשיר אחר.
2. דרך רשת זמינה, כמו LTE או Wi-Fi, באמצעות צומת רשת בשרתים של Google כמתווך.

כל הלקוחות של שכבת הנתונים יכולים להחליף נתונים באמצעות Bluetooth או באמצעות הענן, בהתאם לחיבורים שזמינים למכשירים. חשוב לזכור שנתונים שמועברים באמצעות שכבת הנתונים עשויים בשלב כלשהו להשתמש בשרתים בבעלות Google.

Bluetooth

כשהמכשירים מחוברים באמצעות Bluetooth, שכבת הנתונים משתמשת בחיבור הזה. יש ערוץ מוצפן אחד בין המכשירים, באמצעות הצפנת Bluetooth רגילה, שמנוהל על ידי Google Play Services.

ענן

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

אבטחת התקשורת

כדי לספק תקשורת מאובטחת יותר בין האפליקציה שמותקנת במכשיר Wear OS לבין אותה אפליקציה שמותקנת במכשיר שניתן להחזיק ביד קרוב, Google Play Services אוכפת את ההגבלות הבאות:

• שם החבילה צריך להיות זהה בכל המכשירים.
• החתימה של החבילה צריכה להיות זהה בכל המכשירים.

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

הגדרה

ל-Wearable Data Layer API יש את יחסי התלות הבאים:

• הגרסה העדכנית של Google Play Services.
• מכשיר Wear OS או אמולטור של Wear OS.

מוסיפים את יחסי התלות הבאים לקובץ build.gradle של מודול Wear:

dependencies {
    ...
    implementation("com.google.android.gms:play-services-wearable:20.0.1")
}

להקל על תהליך ההתאמה הראשוני

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

• מתקינים את האפליקציה במכשיר השני.
• מפעילים את האפליקציה במכשיר השני.
• מפעילים פעילות ספציפית במכשיר השני.
• מפעילים את האפליקציה הנלווית.

גישה לשכבת הנתונים

כדי להפעיל את Data Layer API, משתמשים במחלקה Wearable כדי לקבל מופעים של מחלקות הלקוח השונות, כמו DataClient ו-MessageClient.

מידע נוסף זמין בדוגמה של DataLayer.

שימוש בלקוח מינימלי

כדי ליצור לקוח, אפשר להשתמש בקוד לדוגמה הבא:

val dataClient = Wearable.getDataClient(this)
DataLayerActivity.kt

val available = try {
    GoogleApiAvailability.getInstance()
        .checkApiAvailability(client)
        .await()
    true
} catch (e: AvailabilityException) {
    // API is not available in this device.
    false
}
DataLayerActivity.kt

ההקשר יכול להיות כל הקשר תקין של Android. אם אתם משתמשים ב-API במסגרת Activity, השתמשו ב-method‏ getDataClient() של המחלקה Wearable. כך, אינטראקציות מסוימות יכולות להופיע כתיבות דו-שיח במקום כהתראות, למשל כשמבקשים מהמשתמש לעדכן את הגרסה של Google Play Services.

כברירת מחדל, קריאות חוזרות (callbacks) למאזינים מתבצעות בשרשור ה-UI הראשי של האפליקציה. כדי לבצע קריאות חוזרות (callbacks) בשרשור אחר, משתמשים באובייקט WearableOptions כדי לציין Looper בהתאמה אישית.

מידע נוסף זמין במאמר העזרה בנושא WearableOptions.Builder.

יצירה מחדש של מופעי לקוח לפי הצורך

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

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