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

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

גישה לרשת

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

כאשר טלפון מסוים לא זמין, נעשה שימוש ב-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.
    }
}
connectivityManager.requestNetwork(
    NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
    callback
)

ConnectivityManager.NetworkCallback callback = new ConnectivityManager.NetworkCallback() {
    public void onAvailable(Network network) {
        super.onAvailable(network);
        // The Wi-Fi network has been acquired. Bind it to use this network by default.
        connectivityManager.bindProcessToNetwork(network);
    }

    public void onLost(Network network) {
        super.onLost(network);
        // Called when a network disconnects or otherwise no longer satisfies this request or callback.
    }
};
connectivityManager.requestNetwork(
        new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
        callback
);

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

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

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

connectivityManager.bindProcessToNetwork(null);
connectivityManager.unregisterNetworkCallback(callback);

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

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

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

context.startActivity(Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"))

context.startActivity(new Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"));

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

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

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

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

איור 1. תהליך של אפליקציית מוזיקה להורדת מוזיקה.

שיקולים לשימוש בעוצמה ובנתונים

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

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

כדי לשלוח התראות, צריך להשתמש ישירות בהעברת הודעות בענן ב-Firebase (FCM).

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

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

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

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

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

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

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

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

כדי לוודא שמשימות ברקע מתבצעות כמו שצריך, צריך להביא בחשבון עבור Doze ו-App Standby.

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

תזמון עם אילוצים

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

• מתזמנים בקשה שמחייבת רישות.

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

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

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

למידע נוסף, אפשר לעיין במאמר ההשפעה של מגבלות על תקופתיות.