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

הצומת מבוסס-הענן נשלט על ידי שרת בבעלות Google
איור 1. דוגמה לרשת של צמתים עם מכשירים ניידים ומכשירי Wear OS.

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

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

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

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

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

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

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

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

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

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

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

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

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

‫Bluetooth

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

ענן

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

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

כדי לספק תקשורת מאובטחת יותר בין האפליקציה שמותקנת במכשיר WearOS לבין אותה אפליקציה שמותקנת במכשיר נייד בקרבת מקום, מערכת 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:19.0.0")
}

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

‫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, אתם צריכים להשתמש בשיטה getDataClient() של המחלקה Wearable. כך, אינטראקציות מסוימות מופיעות כתיבות דו-שיח ולא כהתראות, למשל כשמבקשים מהמשתמש לעדכן את הגרסה של Google Play Services.

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

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

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

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

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