على الرغم من أنّ كلاً من المربّعات والأدوات يعرض المحتوى على مساحة عرض نظام بعيد، فإنّ إنشاءها يتطلّب اتّباع نُهج مختلفة. يعني نقل المربّع الحالي إلى أداة الانتقال من إنشاء تنسيق ثابت إلى واجهة مستخدم ديناميكية تعريفية، ما يتيح إمكانات جديدة ونموذج تطوير مبسّط.
اختيار استراتيجية التنفيذ
إذا كنت تنقل تطبيقًا يحتفظ بمربّع قديم، عليك تحديد الطريقة التي يقدّم بها تطبيقك المحتوى إلى النظام. في حين أنّ الأدوات الجديدة تمامًا يجب أن تستخدم خدمة أداة واحدة، يجب أن تختار التطبيقات التي تتضمّن مربّعات حالية بين الاحتفاظ بكلتا الخدمتين أو دمجها في خدمة أداة واحدة.
الخيار المقترَح: خدمة مزدوجة (مربّع + أداة)
إنّ الاحتفاظ بمربّع وأداة هو المسار المقترَح لجميع التطبيقات التي تتضمّن مربّعًا حاليًا. يوفّر تقديم خدمتين مختلفتَين أفضل تجربة مستخدم ممكنة على الأجهزة المختلفة.
- خدمة المربّع: يمكنك توسيع
TileServiceوالإفصاح عن فلتر هدف لـandroidx.wear.tiles.action.BIND_TILE_PROVIDER. - خدمة الأداة: يمكنك توسيع
GlanceWearWidgetServiceوالإفصاح عن intent filter لـandroidx.glance.wear.action.BIND_WIDGET_PROVIDER. - التجميع المنطقي: استخدِم السمة
groupفي إعدادات الأداة لربط التنفيذ الجديد بـTileService. يسمح ذلك للنظام بالتعرّف عليها كمكوّن منطقي واحد ونقل تلقائيًا فتحة العرض الدوّار الحالية للمستخدم إلى الأداة الجديدة على Wear OS 7 أو الإصدارات الأحدث.
سلوك النظام عند إعداد خدمة مزدوجة:
| نظام التشغيل / إمكانات الجهاز | التجربة الناتجة |
|---|---|
| Wear OS 3 | يتم استخدام المربّع |
| Wear OS 4 و5 و6 | يتم استخدام المربّع |
| Wear OS 7 (لا يتوافق مع الارتفاع الجزئي، مثل Pixel Watch) | يتم استخدام المربّع |
| Wear OS 7 (يتوافق مع الارتفاع الجزئي، مثل Galaxy Watch) | يتم استخدام الأداة |
الخيار البديل: خدمة واحدة (الأداة فقط)
تتعامل خدمة واحدة مع كلا البروتوكولَين. على الرغم من أنّ هذا النهج أسرع في التنفيذ، فإنّه يعتمد على وضع التوافق "لتكييف" الأداة لتصبح مربّعًا على الأجهزة التي تعمل بإصدارات أقل من Wear OS.
إذا اخترت هذا النهج:
- حدِّد كلا فلترَي الهدف: يجب أن تتضمّن خدمتك فلترَي هدف لكل من
androidx.wear.tiles.action.BIND_TILE_PROVIDERوandroidx.glance.wear.action.BIND_WIDGET_PROVIDER. يضمن ذلك عرض الأداة على مساحات عرض المربّعات في Wear 4 و5 و6 و7 (عند اللزوم). - احتفِظ باسم الخدمة الحالي (لإجراء الترقيات بسلاسة): إذا كنت تستبدل مربّعًا نشطًا، فإنّ الاحتفاظ باسم فئة الخدمة نفسه يضمن أن يرى المستخدمون الذين لديهم المربّع في العرض الدوّار تحديثه تلقائيًا إلى الأداة الجديدة. في حين أنّ Wear OS 7 يستخدم السمة
groupفي ملف XML لإعدادات الأداة لربط المكوّنات المختلفة منطقيًا، فإنّ إصدارات Wear OS الأقل من 7 تعتمد على اسم الخدمة لتحديدها على أنّها المكوّن "نفسه". إذا كنت تفضّل استخدام اسم خدمة جديد، سيظل تطبيقك يعمل بشكلٍ مثالي، ولكن على المستخدمين على الأجهزة التي تعمل بإصدار Wear OS 6 أو إصدار أقل إعادة إضافة الأداة يدويًا إلى العرض الدوّار.
سلوك النظام عند إعداد خدمة واحدة:
| نظام التشغيل / إمكانات الجهاز | التجربة الناتجة |
|---|---|
| Wear OS 3 | غير متاح |
| Wear OS 4 و5 و6 | تُعرض الأداة كمربّع بملء الشاشة |
| Wear OS 7 (لا يتوافق مع الارتفاع الجزئي) | تتم ترجمة الأداة إلى مربّع |
| Wear OS 7 (يتوافق مع الارتفاع الجزئي) | يتم استخدام الأداة |
*تتطلّب هذه الميزة الإصدار 1.6 من أداة العرض أو إصدارًا أحدث.
نصائح بشأن ترجمة واجهة المستخدم
عند ترجمة واجهة المستخدم من ProtoLayout (المربّعات) إلى Remote Compose (الأدوات)، ينتقل النموذج الذهني من أدوات إنشاء التنسيقات الإلزامية إلى بنية مستندة إلى الحالة ومستندة إلى Compose، حيث تتم معالجة تحديثات واجهة المستخدم من خلال إعادة الإنشاء. يُرجى مراعاة المبادئ التالية:
- استخدام واجهة مستخدم تعريفية: استبدِل أدوات إنشاء ProtoLayout الإلزامية
(
LayoutElementBuilders) بمكافئاتها التعريفية في Remote Compose، مثلRemoteTextوRemoteColumnوRemoteBox. - التركيز على المحتوى الأساسي (
mainSlot): توفّر الأدوات ذات الارتفاع الجزئي (مثل أنواع الحاوياتSMALLوLARGE) مساحة عرض مركزة وسريعة التصفّح. بدلاً من نقل تنسيق مربّع كثيف بملء الشاشة بشكلٍ مطابق، يمكنك تبسيط التصميم للتركيز على المعلومات الأساسية في منطقة المحتوى الرئيسية. - إعادة تصميم الإجراءات المحاذية للحافة: في بنية المربّعات، كانت المكوّنات التي تملأ الشاشة، مثل
EdgeButton، مثبّتة فيbottomSlotمخصّصة. بما أنّ الأدوات ذات الارتفاع الجزئي تتكامل مباشرةً مع مساحة عرض يتم التمرير فيها عموديًا، لم يعُد نموذجbottomSlotالثابت هذا موجودًا. بما أنّ الأزرار المحاذية للحافة غالبًا ما كانت بمثابة إجراءات أساسية بارزة جدًا، فإنّ نقلها يتطلّب إعادة تصميم متعمّدة لواجهة المستخدم بدلاً من استبدال المكوّنات مباشرةً. يمكنك تقييم استراتيجيات تجربة المستخدم البديلة لإجراءاتك الأساسية:- الإجراءات المضمّنة: يمكنك دمج
RemoteButtonمضمّن مباشرةً في تنسيقmainSlot - عمليات النقر على الحاوية: يمكنك دمج التفاعل من خلال جعل حاوية الأداة بأكملها
قابلة للنقر باستخدام
PendingIntentAction. - تغيير محور المحتوى: يمكنك إعادة تقييم محور التطبيق المصغّر. بدون فتحة إجراء مخصّصة، يمكنك عرض بيانات أكثر تفصيلاً وسريعة التصفّح والاعتماد على نقرة واحدة لفتح التطبيق الكامل بدلاً من عزل إجراءات معيّنة على مساحة عرض الأداة.
- الإجراءات المضمّنة: يمكنك دمج
- نقل معالجة الأحداث (الإجراءات مقابل تعبيرات lambda): تعتمد المربّعات على التفاعلات (مثل
LoadAction) التي تؤدي إلى تشغيل عمليات معاودة الاتصال بالخدمة الكاملة لتحديث واجهة المستخدم. تستند أدوات Wear إلى جهة العميل. لا يمكن تشغيل تعبيرات lambda العادية في Compose عن بُعد، لذا عليك تقديم إجراءات تعريفية قابلة للتسلسل (مثلValueChangeأوPendingIntentAction). يمكنك دمج هذه الإجراءات مع الحالة التعريفية (مثلrememberMutableRemoteInt) لدعم تحديثات واجهة المستخدم الفورية بدون عمليات تبادل البيانات مع التطبيق. - تكييف الأبعاد والأنواع: عند نقل أبعاد التنسيق، يُفضّل
استخدام حلّ التنسيق المؤجّل باستخدام
RemoteDp(مثل10.rdp) بدلاً من الـDpالعادية. يضمن ذلك أن يحسب عارض النظام قيم البكسل بشكلٍ صحيح في وقت العرض. وبالمثل، استخدِم دوال Remote Compose الإضافية (.rcلـColorو.rsلـStringو.rdpلـDp) لتحويل أنواع Kotlin وRemote Compose العادية بسلاسة. - مراجعة الرمز النموذجي: للاطّلاع على أمثلة شاملة حول كيفية إنشاء التنسيقات وتطبيق الطباعة الدلالية وإدارة الحالة في Remote Compose، يمكنك استكشاف الرمز النموذجي الرسمي المتاح في مستودع نماذج Wear OS.