סקירה כללית של 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 כמתווך.

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

Bluetooth

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

ענן

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

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

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

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

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

הגדרה

ל-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)

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

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

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

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

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

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

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