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

עם Wear OS by Google, שעון יכול לתקשר עם רשת ישירות, בלי גישה לטלפון Android או iOS. אל תשתמשו ב-Data Layer API כדי לקשר אפליקציה ל-Wear OS לרשת. במקום זאת, פועלים לפי ההנחיות והשלבים שמפורטים במדריך הזה.

גישה לרשת

אפליקציות ל-Wear OS יכולות לשלוח בקשות לרשת. כששעון מחובר לטלפון באמצעות Bluetooth, תעבורת הרשת של השעון מועברת בדרך כלל דרך הטלפון.

כשאין אפשרות להתקשר לטלפון, נעשה שימוש ברשתות Wi-Fi וברשתות סלולריות, בהתאם לחומרה של השעון. פלטפורמת Wear OS מטפלת במעברים בין רשתות.

אפשר להשתמש בפרוטוקולים כמו HTTP,‏ TCP ו-UDP. עם זאת, ממשקי ה-API של android.webkit, כולל המחלקה CookieManager, לא זמינים. אפשר להשתמש בקובצי Cookie על ידי קריאה וכתיבה של כותרות בבקשות ובתגובות.

משתמשים ב-WorkManager לבקשות אסינכרוניות, כולל בדיקה במרווחי זמן קבועים.

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

גישה לרשת עם רוחב פס גבוה

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

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

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

בקשה לקישוריות Wi-Fi

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

val callback = object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network: Network) {
        super.onAvailable(network)
        // The Wi-Fi network has been acquired. Bind it to use this network by default.
        connectivityManager.bindProcessToNetwork(network)
    }

    override fun onLost(network: Network) {
        super.onLost(network)
        // Called when a network disconnects or otherwise no longer satisfies this request
        // or callback.
    }
}

fun requestWifiNetwork() {
    connectivityManager.requestNetwork(
        NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
        callback
    )
}
Network.kt

יכול להיות שייקח זמן עד שהשעון יתחבר לרשת, כי יכול להיות שרדיו ה-Wi-Fi או הרדיו הסלולרי של השעון כבויים כדי לחסוך בסוללה. אם השעון לא מצליח להתחבר לרשת, לא מתבצעת קריאה לשיטה onAvailable() של מופע NetworkCallback.

אחרי שמפעילים את onAvailable(), המכשיר מנסה להישאר מחובר לרשת ה-Wi-Fi עד שמפסיקים את NetworkCallback. כדי לחסוך בחיי הסוללה, צריך לשחרר את הקריאה החוזרת כמו בדוגמה הבאה כשכבר לא צריך רשת Wi-Fi.

connectivityManager.bindProcessToNetwork(null)
connectivityManager.unregisterNetworkCallback(callback)
Network.kt

הפעלת פעילות של הגדרות Wi-Fi

כשמבקשים להתחבר לרשת Wi-Fi, המערכת מנסה להתחבר לרשת שמורה אם יש רשת כזו שהוגדרה ונמצאת בטווח. אם אין רשת Wi-Fi שמורה שזמינה, לא מתבצעת קריאה לשיטת ההחזרה onAvailable של מופע NetworkCallback.

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

val networkSettingsAction = "com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"
val intent = Intent(networkSettingsAction).apply {
    addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
}
context.startActivity(intent)
Network.kt

כדי להפעיל את פעילות ההגדרות, לאפליקציה שלכם צריכה להיות הרשאת CHANGE_WIFI_STATE.

שיקולים לגבי ממשק המשתמש

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

שיקולים לגבי צריכת חשמל ושימוש בנתונים

כדי לחסוך בסוללה ולצמצם את השימוש בחבילת הגלישה, כדאי לדחות משימות לא חיוניות ברשת, כמו דיווח על ניתוח נתונים או איסוף יומנים, עד שמכשיר Wear OS יתחבר מחדש באמצעות Bluetooth או Wi-Fi, במקום באמצעות LTE או חיבור בתשלום לפי נפח.

העברת הודעות בענן

כדי לשלוח התראות, משתמשים ישירות ב-Firebase Cloud Messaging (FCM).

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

‫FCM פועל היטב עם Doze והוא הדרך המומלצת לשליחת התראות לשעון.

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

הודעת FCM היא בפורמט JavaScript Object Notation ‏(JSON) ויכולה לכלול מטען ייעודי (payload) אחד או את שניהם:

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

מידע נוסף ודוגמאות למטענים זמינים במאמר בנושא סוגי הודעות.

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

שימוש בשירותים ברקע

כדי לוודא שמשימות ברקע מבוצעות בצורה נכונה, צריך להתחשב במצב שינה ובהמתנה של האפליקציה.

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

תזמון עם מגבלות

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

• קביעת מועד לבקשה שדורשת רשת.

  מציינים אם הערך של NetworkType הוא CONNECTED או UNMETERED. ‫UNMETERED מיועד להעברות נתונים גדולות, ואילו CONNECTED מיועד להעברות קטנות.

• לתזמן בקשה בזמן הטעינה.

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

מידע נוסף זמין במדריך בנושא ההשפעה של אילוצים על עבודה תקופתית ב-WorkManager.