Эта страница переведена с помощью Cloud Translation API.

Переход с плиток на виджеты

Хотя и плитки, и виджеты отображают контент на удаленной системной поверхности, для их создания требуются разные подходы. Переход от существующих плиток к виджетам означает переход от жесткой генерации макета к динамическому, декларативному пользовательскому интерфейсу, что открывает новые возможности и упрощает модель разработки.

Выберите стратегию внедрения.

Если вы переносите приложение, использующее устаревшие виджеты, вам необходимо решить, как ваше приложение будет предоставлять контент системе. В то время как совершенно новые виджеты должны использовать единую службу виджетов, приложения с существующими виджетами должны выбирать между использованием обеих служб или объединением на одной службе виджетов.

Рекомендуется: Двойной сервис (плитка + виджет)

Рекомендуется использовать как плитку, так и виджет для всех приложений, в которых уже есть плитка. Предоставление двух отдельных сервисов обеспечивает наилучшее взаимодействие с пользователем на разных устройствах.

Tile Service: Расширьте TileService и объявите фильтр намерений для androidx.wear.tiles.action.BIND_TILE_PROVIDER .
Сервис виджетов: Расширьте GlanceWearWidgetService и объявите фильтр намерений для 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 больше не существует. Поскольку кнопки, выровненные по краям, часто служили очень заметными основными действиями, переход на них требует целенаправленного перепроектирования пользовательского интерфейса, а не прямой замены компонентов. Оцените альтернативные стратегии UX для ваших основных действий:
- Встроенные действия: Интегрируйте встроенную RemoteButton непосредственно в макет mainSlot .
- Касания контейнера: Объедините взаимодействие, сделав весь контейнер виджета доступным для касаний с помощью PendingIntentAction .
- Изменение контента: пересмотрите направленность виджета. Если для него нет отдельного слота для действий, рассмотрите возможность отображения более подробной информации, которую можно быстро просмотреть, и используйте одно касание для открытия всего приложения, вместо того чтобы изолировать определенные действия на поверхности виджета.
Переход к обработке событий (действия против лямбда-функций): Tiles полагаются на взаимодействия (например, LoadAction ), запускающие полноценные обратные вызовы для обновления пользовательского интерфейса. Wear Widgets управляются на стороне клиента. Стандартные лямбда-функции Compose не могут выполняться удаленно; вместо этого предоставьте сериализуемые декларативные действия (например, ValueChange или PendingIntentAction ). Объедините их с декларативным состоянием (например, rememberMutableRemoteInt ), чтобы обеспечить мгновенное обновление пользовательского интерфейса без обмена данными между приложением и сервером.
Адаптация размеров и типов: При миграции размеров макета отдавайте предпочтение отложенному разрешению макета с использованием RemoteDp (например, 10.rdp ) вместо стандартного Dp . Это гарантирует, что системный рендерер правильно вычислит значения пикселей во время отображения. Аналогично, используйте функции расширения Remote Compose ( .rc для Color , .rs для String , .rdp для Dp ) для беспрепятственного преобразования стандартных типов Kotlin и Remote Compose.
Ознакомьтесь с примерами кода: чтобы увидеть исчерпывающие примеры создания макетов, применения семантической типографики и управления состоянием в Remote Compose, изучите официальные примеры кода, доступные в репозитории Wear OS Samples .