タイルとウィジェットはどちらもリモート システムのサーフェスにコンテンツを表示しますが、構築には異なるアプローチが必要です。既存のタイルをウィジェットに移行するということは、リジッド レイアウトの生成から、動的な宣言型 UI への移行を意味します。これにより、新しい機能と簡素化された開発モデルが実現します。
実装戦略を選択する
従来のタイルを維持するアプリを移行する場合は、アプリがシステムにコンテンツを提供する方法を決定する必要があります。新しいウィジェットでは単一のウィジェット サービスを使用する必要がありますが、既存のタイルがあるアプリでは、両方のサービスを維持するか、単一のウィジェット サービスに統合するかを選択する必要があります。
推奨: デュアル サービス（タイル + ウィジェット）
既存のタイルがあるすべてのアプリで、タイルとウィジェットの両方を維持することをおすすめします。2 つの異なるサービスを提供することで、さまざまなデバイスで可能な限り最高のユーザー エクスペリエンスを実現できます。
- タイル サービス:
TileServiceを拡張し、androidx.wear.tiles.action.BIND_TILE_PROVIDERのインテント フィルタを宣言します。 - ウィジェット サービス:
GlanceWearWidgetServiceを拡張し、androidx.glance.wear.action.BIND_WIDGET_PROVIDERの インテント フィルタを宣言します。 - 論理グループ化: ウィジェット構成の
group属性を使用して、新しい実装を既存のTileServiceにリンクします。これにより、システムはこれらを単一の論理コンポーネントとして認識し、ユーザーの既存のカルーセル スロットを Wear OS 7 以降の新しいウィジェットに自動的に移行できます。
デュアル サービス設定のシステム動作:
| OS / デバイスの機能 | 結果のエクスペリエンス |
|---|---|
| Wear OS 3 | タイル が使用される |
| Wear OS 4、5、6 | タイル が使用される |
| Wear OS 7（高さの一部をサポートしていない、例: Google Pixel Watch） | タイル が使用される |
| Wear OS 7（高さの一部をサポートしている、例: Galaxy Watch） | ウィジェット が使用される |
代替: 単一のサービス（ウィジェットのみ）
1 つのサービスで両方のプロトコルを処理します。このアプローチは実装が高速ですが、互換モードに依存して、Wear OS の古いバージョンを実行しているデバイスでウィジェットをタイルに「適応」させます。
このアプローチを選択する場合:
- 両方のインテント フィルタを指定する: サービスには、
androidx.wear.tiles.action.BIND_TILE_PROVIDERとandroidx.glance.wear.action.BIND_WIDGET_PROVIDERの両方のインテント フィルタを含める必要があります。これにより、ウィジェットが Wear 4、5、6、7 のタイル サーフェスに表示されます（必要な場合）。 - 既存のサービス名を維持する（シームレスなアップグレードのため）: アクティブなタイルを置き換える場合は、同じサービス クラス名を維持することで、カルーセルにタイルがあるユーザーは新しいウィジェットに自動的に更新されます。Wear OS 7 では、ウィジェット構成 XML の
group属性を使用して、異なるコンポーネントを論理的にリンクしますが、Wear OS 7 より前のバージョンでは、サービス名を使用して「同じ」コンポーネントとして識別します。新しいサービス名を使用する場合でも、アプリは完全に機能しますが、Wear OS バージョン 6 以前を実行しているデバイスのユーザーは、ウィジェットをカルーセルに手動で再度追加する必要があります。
単一サービス設定のシステム動作:
| OS / デバイスの機能 | 結果のエクスペリエンス |
|---|---|
| Wear OS 3 | サポート対象外 |
| Wear OS 4、5、6 | ウィジェットは全画面表示のタイルとして表示 される |
| Wear OS 7（高さの一部をサポートしていない） | ウィジェットはタイルに変換 される |
| Wear OS 7（高さの一部をサポートしている） | ウィジェット が使用される |
*レンダラ 1.6 以降が必要です。
UI 翻訳のヒント
UI を ProtoLayout（タイル）から Remote Compose（ウィジェット）に翻訳する場合、メンタルモデルは命令型レイアウト ビルダーから、状態ドリブン型の Compose ベースのアーキテクチャに移行します。このアーキテクチャでは、UI の更新は再コンポーズによって処理されます。次の原則に留意してください。
- 宣言型 UI を採用する: 命令型の ProtoLayout ビルダー
(
LayoutElementBuilders) を、宣言型の Remote Compose の同等物 （RemoteText、RemoteColumn、RemoteBoxなど）に置き換えます。 - コア コンテンツ（
mainSlot）に焦点を当てる: 高さの一部をサポートするウィジェット（SMALLやLARGEコンテナタイプなど）は、焦点を絞った一目でわかるサーフェスを提供します。 高密度で全画面表示のタイル レイアウトを 1 対 1 で移植するのではなく、メイン コンテンツ領域内の主要な情報を強調するようにデザインを効率化します。 - エッジに揃えたアクションを再設計する: タイルのアーキテクチャでは、画面にぴったりと収まる
コンポーネントは、専用の
bottomSlotに固定されていました。EdgeButton高さの一部をサポートするウィジェットは、垂直方向にスクロールするサーフェスに直接統合されるため、この固定されたbottomSlotパラダイムは存在しません。エッジに揃えたボタンは、非常に目立つプライマリ アクションとして機能することが多いため、移行には、コンポーネントを直接置き換えるのではなく、意図的な UI の再設計が必要です。プライマリ アクションの代替 UX 戦略を評価します。- インライン アクション: インラインの
RemoteButtonをmainSlotレイアウトに直接統合します。 - コンテナのタップ:
PendingIntentActionを使用して、ウィジェット コンテナ全体をタップ可能にすることで、操作を統合します。 - コンテンツの方向性の転換: ウィジェットのフォーカスを再評価します。専用のアクション スロットがない場合は、ウィジェット サーフェスで特定のアクションを分離するのではなく、より豊富な一目でわかるデータを表示し、1 回タップしてアプリ全体を開くことを検討してください。
- インライン アクション: インラインの
- イベント処理を移行する（アクションとラムダ）: タイルは、UI を更新するために、サービス全体のコールバックをトリガーする操作（
LoadActionなど）に依存しています。 Wear ウィジェットはクライアントサイド ドリブンです。標準の Compose ラムダはリモートで実行できません。代わりに、シリアル化可能な宣言型アクション（ValueChangeやPendingIntentActionなど）を提供します。これらを 宣言型状態（例:rememberMutableRemoteInt）と組み合わせることで、 アプリのラウンドトリップなしで UI を即座に更新できます。 - サイズとタイプを調整する: レイアウトのサイズを移行する場合は、標準の
DpよりもRemoteDp（10.rdpなど）を使用した 遅延レイアウト解決を優先します。これにより、システム レンダラは表示時にピクセル値を正しく計算します。同様に、Remote Compose 拡張関数（Colorの場合は.rc、Stringの場合は.rs、Dpの場合は.rdp）を使用して、標準の Kotlin タイプと Remote Compose タイプをシームレスに変換します。 - サンプルコードを確認する: レイアウトの作成方法、セマンティック タイポグラフィの適用方法、Remote Compose での状態の管理方法の包括的な例については、Wear OS サンプル リポジトリで入手できる公式サンプルコードをご覧ください。