اگرچه هم کاشیها و هم ویجتها محتوای شما را روی سطح سیستم از راه دور نمایش میدهند، اما ساخت آنها نیاز به رویکردهای متمایزی دارد. انتقال کاشی موجود شما به یک ویجت به معنای گذار از تولید طرحبندی سفت و سخت به یک رابط کاربری پویا و اعلانی است که قابلیتهای جدید و یک مدل توسعه ساده را آزاد میکند.
استراتژی پیادهسازی خود را انتخاب کنید
اگر در حال انتقال برنامهای هستید که یک کاشی قدیمی را حفظ میکند، باید تصمیم بگیرید که برنامه شما چگونه محتوا را به سیستم ارائه میدهد. در حالی که ویجتهای کاملاً جدید باید از یک سرویس ویجت واحد استفاده کنند، برنامههایی که کاشیهای موجود دارند باید بین حفظ هر دو سرویس یا ادغام در یک سرویس ویجت واحد، یکی را انتخاب کنند.
توصیه شده: سرویس دوگانه (کاشی + ویجت)
حفظ همزمان کاشی و ویجت، مسیر پیشنهادی برای همه برنامههایی است که کاشی موجود دارند. ارائه دو سرویس مجزا، بهترین تجربه کاربری ممکن را در دستگاههای مختلف فراهم میکند.
- سرویس Tile:
TileServiceبسط داده و یک فیلتر intent برایandroidx.wear.tiles.action.BIND_TILE_PROVIDERتعریف کنید. - سرویس ویجت:
GlanceWearWidgetServiceبسط داده و یک فیلتر intent برایandroidx.glance.wear.action.BIND_WIDGET_PROVIDERتعریف کنید. - گروهبندی منطقی: از ویژگی
groupدر پیکربندی ویجت برای پیوند پیادهسازی جدید بهTileServiceموجود خود استفاده کنید. این به سیستم اجازه میدهد تا آنها را به عنوان یک جزء منطقی واحد تشخیص دهد و به طور خودکار جایگاه چرخ فلک موجود کاربر را به ویجت جدید در Wear OS 7 یا بالاتر منتقل کند.
رفتار سیستم برای راهاندازی سرویس دوگانه:
| قابلیت سیستم عامل / دستگاه | تجربه حاصل |
|---|---|
| سیستم عامل Wear OS 3 | کاشی استفاده شده است |
| از سیستم عاملهای ۴، ۵، ۶ استفاده کنید | کاشی استفاده شده است |
| سیستم عامل Wear OS 7 (بدون پشتیبانی از ارتفاع جزئی، مثلاً Pixel Watch) | کاشی استفاده شده است |
| سیستم عامل Wear OS 7 (پشتیبانی از ارتفاع جزئی، مثلاً در گلکسی واچ) | ویجت استفاده شده است |
جایگزین: سرویس تکی (فقط ویجت)
یک سرویس واحد هر دو پروتکل را مدیریت میکند. اگرچه این رویکرد سریعتر پیادهسازی میشود، اما برای «تطبیق» ویجت شما با کاشی در دستگاههایی که نسخههای پایینتر 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 7 (بدون پشتیبانی جزئی از ارتفاع) | ویجت به یک کاشی تبدیل شده است |
| سیستم عامل Wear OS 7 (پشتیبانی جزئی از ارتفاع) | ویجت استفاده شده است |
*به رندرر ۱.۶+ نیاز دارد.
نکات ترجمه رابط کاربری
هنگام ترجمه رابط کاربری خود از ProtoLayout (Tiles) به Remote Compose (Widgets)، مدل ذهنی از سازندگان طرحبندی ضروری به یک معماری مبتنی بر Compose و مبتنی بر وضعیت تغییر میکند که در آن بهروزرسانیهای رابط کاربری از طریق ترکیب مجدد مدیریت میشوند. اصول زیر را در نظر داشته باشید:
- رابط کاربری اعلانی را اتخاذ کنید: سازندههای ProtoLayout دستوری (
LayoutElementBuilders) را با معادلهای اعلانی Remote Compose مانندRemoteText،RemoteColumnوRemoteBoxجایگزین کنید. - تمرکز روی محتوای اصلی (
mainSlot): ویجتهای با ارتفاع جزئی (مثلاً انواع کانتینرهایSMALLوLARGE) سطحی متمرکز و قابل مشاهده ارائه میدهند. به جای اینکه یک طرحبندی کاشی متراکم و تمام صفحه را به صورت یک به یک منتقل کنید، طراحی خود را ساده کنید تا بر اطلاعات اصلی در ناحیه محتوای اصلی تأکید شود. - طراحی مجدد اقدامات همتراز با لبه: در معماری کاشیها، اجزای دربرگیرنده صفحه نمایش مانند
EdgeButtonبه یکbottomSlotاختصاصی متصل بودند. از آنجا که ویجتهای با ارتفاع جزئی مستقیماً در یک سطح پیمایش عمودی ادغام میشوند، این الگویbottomSlotثابت دیگر وجود ندارد. از آنجا که دکمههای همتراز با لبه اغلب به عنوان اقدامات اصلی بسیار برجسته عمل میکردند، مهاجرت به جای تعویض مستقیم اجزا، نیاز به طراحی مجدد عمدی رابط کاربری دارد. استراتژیهای جایگزین UX را برای اقدامات اصلی خود ارزیابی کنید:- اقدامات درونخطی: یک
RemoteButtonدرونخطی را مستقیماً در طرحبندیmainSlotخود ادغام کنید. - ضربههای کانتینر: با استفاده از
PendingIntentActionتعامل را با قابل ضربه کردن کردن کل کانتینر ویجت، یکپارچه کنید. - چرخش محتوا: تمرکز ویجت را دوباره ارزیابی کنید. بدون یک جایگاه اقدام اختصاصی، به جای جداسازی اقدامات خاص روی سطح ویجت، به نمایش دادههای غنیتر و قابل مشاهدهتر و تکیه بر یک ضربه برای باز کردن کل برنامه فکر کنید.
- اقدامات درونخطی: یک
- مدیریت رویداد مهاجرت (اکشنها در مقابل لامبداها): کاشیها به تعاملاتی (مانند
LoadAction) متکی هستند که فراخوانیهای کامل سرویس را برای بهروزرسانی رابط کاربری فعال میکنند. ویجتهای Wear سمت کلاینت هدایت میشوند. لامبداهای استاندارد Compose را نمیتوان از راه دور اجرا کرد؛ در عوض، اکشنهای اعلانی قابل سریالسازی (مانندValueChangeیاPendingIntentAction) را ارائه میدهند. این موارد را با حالت اعلانی (مثلاًrememberMutableRemoteInt) ترکیب کنید تا از بهروزرسانیهای فوری رابط کاربری بدون رفت و برگشت برنامه پشتیبانی شود. - تطبیق ابعاد و انواع: هنگام انتقال ابعاد طرحبندی، وضوح طرحبندی به تعویق افتاده با استفاده از
RemoteDp(مثلاً10.rdp) را بهDpاستاندارد ترجیح دهید. این کار تضمین میکند که رندرکننده سیستم مقادیر پیکسل را در زمان نمایش به درستی محاسبه میکند. به طور مشابه، از توابع افزونه Remote Compose (.rcبرایColor،.rsبرایString،.rdpبرایDp) برای تبدیل یکپارچه انواع استاندارد Kotlin و Remote Compose استفاده کنید. - بررسی نمونه کد: برای دیدن نمونههای جامع از نحوه ساخت طرحبندیها، اعمال تایپوگرافی معنایی و مدیریت وضعیت در Remote Compose، نمونه کد رسمی موجود در مخزن نمونههای Wear OS را بررسی کنید.