אפליקציות Wear OS עצמאיות לעומת אפליקציות ל-Wear OS לא עצמאיות

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

תכנון האפליקציה

אפשר להשתמש בקובץ Android App Bundle כדי ליצור באופן אוטומטי ערכות חבילה ל-Android (APK) שעברו אופטימיזציה בהתאם להגדרת המכשיר של כל משתמש, של אפליקציות. כך המשתמשים יכולים להוריד רק את הקוד והמשאבים שהם צריכים כדי להריץ את האפליקציה.

למידע על הגדרת האפליקציה להפצה באמצעות בחנות Google Play, אפשר לעיין במאמר לארוז ולהפיץ אפליקציות ל-Wear OS ואת המדריך לתחילת העבודה עם קובצי Android App Bundle.

באפליקציות חדשות, רמת ה-API המטורגטת חייבת להיות 30 ומעלה. מידע נוסף זמין במאמר הבא: עמידה בדרישות ה-API לטירגוט של Google Play רמת דרישה. מגדירים את targetSdkVersion עד לרמת API 30 (Wear OS 3) כדי להבטיח שהאפליקציה תפעל כמו שצריך בגרסת הפלטפורמה העדכנית ביותר.

למידע על בקשות רשת וגישה לרשת ברוחב פס גבוה: ראה גישה לרשת וסנכרון ב-Wear OS

הגדרת אפליקציה כאפליקציה ל-Wear OS

עליך להגדיר את התג <uses-feature> בקובץ המניפסט של Android. כדי לציין שמדובר באפליקציית שעון, צריך להוסיף רשומה כמו:

  <manifest>
  ...
  <uses-feature android:name="android.hardware.type.watch" />
  ...
  </manifest>
  

איך לזהות אפליקציה כעצמאית או כאפליקציה שאינה עצמאית

אפליקציה לשעון נחשבת כאפליקציה עצמאית או לא עצמאית:

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

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

Google מאמתת את הדיוק של סטטוס האפליקציה הנפרדת בזמן האפליקציה להצגת מודעות. הערך הזה משפיע על החשיפה של אפליקציות בחנות Play בתאריך מכשירים ללא שיתוף אינטרנט, כמו מכשירי Wear OS שלא מותאמים להחזקה ביד מכשירים. אפליקציות שאינן עצמאיות, וכן אפליקציות שמפתחים מפתחים לא נכון להגדיר כ"עצמאי" — לא זמין למשתמשים במכשירים מכשירים.

באפליקציה ל-Wear OS, מגדירים את הערך של הרכיב meta-data com.google.android.wearable.standalone בקובץ המניפסט של Android כדי להצהיר אם האפליקציה שלך היא עצמאית או לא.

אם אפליקציית השעון היא אפליקציה עצמאית לחלוטין, צריך לציין הזה לחנות Google Play על ידי הגדרת הערך של com.google.android.wearable.standalone עד true:

<application>
...
  <meta-data
    android:name="com.google.android.wearable.standalone"
    android:value="true" />
...
</application>

אם אפליקציית השעון היא לא עצמאית ותלויה באפליקציה אחרת כדי להפעיל את התכונות העיקריות: הגדרת הערך של com.google.android.wearable.standalone כ- false. המשמעות היא שאפליקציית השעון דורשת מכשיר אחר, אבל לא להשפיע על קידום האפליקציה בחנות Google Play.

הערה: גם אם הערך של com.google.android.wearable.standalone הוא false, השעון שאפשר להתקין לפני שמתקינים את אפליקציית הטלפון. לכן, אם מזהה שטלפון נלווה לא כולל את אפליקציית הטלפון הנדרשת, כפי שמתואר בדף הזה, ולבקש מהמשתמש להתקין את אפליקציית הטלפון.

קוד משותף ואחסון נתונים

אפשר לשתף את הקוד בין אפליקציה ל-Wear OS לבין אפליקציה לטלפון. לדוגמה, קוד נפוץ לרישות יכול להיות בספרייה משותפת.

אופציונלי: אפשר להוסיף קוד שספציפיים לגורם צורה, יכולים להיות במודול נפרד.

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

זיהוי האפליקציה שלכם במכשיר אחר

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

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

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

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

צריך לבדוק אם חנות Play זמינה ב- במכשיר, מכיוון שלא כל הטלפונים — כמו מכשירי iPhone — תומכים חנות Play.

הקטעים הבאים מתארים שיטות מומלצות לשני תרחישים:

• לאפליקציית השעון הנפרדת נדרשת אפליקציה לטלפון.
• לאפליקציה לטלפון נדרשת אפליקציה נפרדת לשעון.

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

צריך לציין שמות של יכולות לזיהוי האפליקציות שלך

לאפליקציה שתואמת לכל סוג מכשיר (שעון או טלפון), צריך לציין מחרוזת ייחודית לשם היכולת קובץ res/values/wear.xml.

לדוגמה, במודול לנייד, הקובץ wear.xml יכולים לכלול את האפשרויות הבאות:

<resources xmlns:tools="http://schemas.android.com/tools"
        tools:keep="@array/android_wear_capabilities">
    <string-array name="android_wear_capabilities">
        <item>verify_remote_example_phone_app</item>
    </string-array>
</resources>

במודול Wear OS, הקובץ wear.xml כולל ערך שונה עבור שם היכולת, כמו:

<resources xmlns:tools="http://schemas.android.com/tools"
        tools:keep="@array/android_wear_capabilities">
    <string-array name="android_wear_capabilities">
        <item>verify_remote_example_wear_app</item>
    </string-array>
</resources>

מידע נוסף זמין במאמר יכולות פרסום.

זיהוי אפליקציות ופתיחה של כתובת URL משעון

אפליקציית השעון יכולה לזהות אם טלפון נלווה של משתמש כולל את אפליקציית טלפון. כך עושים זאת:

1. משתמשים ב CapabilityClient כדי לבדוק אם האפליקציה לטלפון מותקנת בטלפון המותאם. מידע נוסף זמין במאמר דגימה של כלי עזר של Datalayer ב-GitHub.
2. אם אפליקציית הטלפון לא מותקנת בטלפון, השתמשו PhoneDeviceType.getPhoneDeviceType() עד לבדוק את סוג הטלפון. פרטים נוספים זמינים בקטע הבא.
3. אם המיקום PhoneDeviceType.DEVICE_TYPE_ANDROID מוחזר, הטלפון הוא טלפון Android. שיחת טלפון RemoteActivityHelper.startRemoteActivity() במכשיר Wear OS כדי פותחים את חנות Play בטלפון. שימוש ב-URI של השוק לטלפון אפליקציה, שעשויה להיות שונה מה-URI של אפליקציית Wear. לדוגמה, השתמשו ב- URI של שוק, כמו: market://details?id=com.example.android.wearable.wear.finddevices

4. אם המיקום PhoneDeviceType.DEVICE_TYPE_IOS מוחזר, הטלפון הוא טלפון iOS ללא Play החנות זמינה. פותחים את App Store ב-iPhone התקשרות אל RemoteActivityHelper.startRemoteActivity() ב-Wear מכשיר עם מערכת הפעלה. אפשר לציין את כתובת ה-URL של האפליקציה ב-iTunes, למשל https://itunes.apple.com/us/app/yourappname

   ב-Wear OS, אי אפשר לקבוע באופן פרוגרמטי אם שהאפליקציה לטלפון מותקנת במכשיר iOS. השיטה המומלצת היא מנגנון מצד המשתמש כדי להפעיל באופן ידני של App Store.

הערה: צריך להשתמש ב-API RemoteActivityHelper שתואר קודם לכן כדי לציין שכל כתובת URL תיפתח בטלפון מהשעון, ושלא נדרשת אפליקציית טלפון.

פרטים על זיהוי סוג הטלפון המותאם

הנה קטע קוד שמשתמש בשיטה getPhoneDeviceType() כדי בדיקת סוג הטלפון שאליו מותאם השעון:

Kotlin

var phoneDeviceType: Int = PhoneDeviceType.getPhoneDeviceType(context)

Java

int phoneDeviceType = PhoneDeviceType.getPhoneDeviceType(context);

הערך שהוחזר על ידי getPhoneDeviceType() היא אחת מהאפשרויות הבאות:

הערך המוחזר	תיאור
DEVICE_TYPE_ANDROID	הטלפון הנלווה הוא מכשיר Android.
DEVICE_TYPE_IOS	הטלפון הנלווה הוא מכשיר iOS.
DEVICE_TYPE_UNKNOWN	הטלפון הנלווה הוא מכשיר לא ידוע.
DEVICE_TYPE_ERROR	אירעה שגיאה בקביעת סוג הטלפון המותאם. בדיקה נוספת צריך לבצע מאוחר יותר.

זיהוי אפליקציות החל מטלפון Android

טלפון Android יכול לזהות אם מכשירי Wear OS של משתמש כוללים את אפליקציית השעון. כך עושים זאת:

1. באמצעות NodeClient, כאן נמצאים כל השעונים שמקושרים למכשיר של המשתמש בטלפון. מידע נוסף זמין במאמר דגימה של כלי עזר של Datalayer ב-GitHub.
2. באמצעות CapabilityClient, יש לבדוק באילו מהשעונים של המשתמש יש שהאפליקציה הותקנה.
3. אם האפליקציה לא מותקנת בכל השעונים של המשתמש, צריך לאפשר למשתמש לפתוח את חנות Play בשאר מכשירי Wear OS מהטלפון באמצעות השיטה RemoteActivityHelper.startRemoteActivity(). שימוש ב-URI של השוק לאפליקציית Wear OS. הוא יכול להיות שונה מה-URI של אפליקציית הטלפון. לדוגמה, שימוש ב-URI של שוק כמו: market://details?id=com.example.android.wearable.wear.finddevices

נתוני מיקום של שעונים שהותאמו למכשירי iPhone

לשעונים שהותאמו למכשירי iPhone, יש להשתמש ספק מיקום משולב (FLP) לקבלת נתוני מיקום בשעון. מידע נוסף זמין במאמר הבא: זיהוי המיקום ב-Wear OS.

אם הטלפון הנלווה זמין, FLP משתמש בטלפון הנלווה לצורך נתוני מיקום.

מקבלים רק את הנתונים הנחוצים

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

כששעון מחובר באמצעות חיבור Bluetooth LE, האפליקציה עשויה גישה לרוחב פס של רק 4KB לשנייה, בהתאם בשעון. לכן, מומלץ לבצע את הפעולות הבאות:

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

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

דוגמאות קוד נוספות

דגימת העוזרים של Datalayer ממחישה עוד יותר את השימוש בממשקי ה-API שמפורטים בדף הזה.