Bermigrasi dari kartu ke widget

Meskipun kartu dan widget menampilkan konten Anda di platform sistem jarak jauh, keduanya memerlukan pendekatan yang berbeda. Memigrasikan kartu yang ada ke widget berarti beralih dari pembuatan tata letak yang kaku ke UI deklaratif yang dinamis, sehingga membuka kemampuan baru dan model pengembangan yang disederhanakan.

Memilih strategi penerapan

Jika Anda memigrasikan aplikasi yang mempertahankan kartu lama, Anda harus memutuskan cara aplikasi menyediakan konten ke sistem. Meskipun widget baru harus menggunakan satu Layanan Widget, aplikasi dengan kartu yang ada harus memilih antara mempertahankan kedua layanan atau menggabungkan ke satu Layanan Widget.

Direkomendasikan: Layanan ganda (kartu + widget)

Mempertahankan kartu dan widget adalah jalur yang direkomendasikan untuk semua aplikasi yang memiliki kartu yang ada. Menyediakan dua layanan yang berbeda akan memberikan pengalaman pengguna terbaik di berbagai perangkat.

Perilaku Sistem untuk Penyiapan Layanan Ganda:

OS / Kemampuan Perangkat Pengalaman yang Dihasilkan
Wear OS 3 Kartu digunakan
Wear OS 4, 5, 6 Kartu digunakan
Wear OS 7 (Tidak ada dukungan tinggi sebagian, misalnya, Pixel Watch) Kartu digunakan
Wear OS 7 (Dukungan tinggi sebagian, misalnya, Galaxy Watch) Widget digunakan

Alternatif: Layanan tunggal (hanya widget)

Satu layanan menangani kedua protokol. Meskipun pendekatan ini lebih cepat diterapkan, pendekatan ini mengandalkan mode kompatibilitas untuk "mengadaptasi" widget Anda menjadi kartu di perangkat yang menjalankan Wear OS versi lebih rendah.

Jika Anda memilih pendekatan ini:

  1. Tentukan kedua filter intent: Layanan Anda harus menyertakan filter intent untuk androidx.wear.tiles.action.BIND_TILE_PROVIDER dan androidx.glance.wear.action.BIND_WIDGET_PROVIDER. Hal ini memastikan widget Anda ditampilkan di platform kartu di Wear 4, 5, 6, dan 7 (jika diperlukan).
  2. Pertahankan nama layanan yang ada (untuk upgrade yang lancar): Jika Anda mengganti kartu aktif, mempertahankan nama class layanan yang sama akan memastikan bahwa pengguna yang memiliki kartu Anda di carousel akan melihatnya otomatis diupdate ke widget baru. Meskipun Wear OS 7 menggunakan atribut group dalam XML konfigurasi widget untuk menautkan berbagai komponen secara logis, Wear OS versi lebih rendah dari 7 mengandalkan nama layanan untuk mengidentifikasinya sebagai komponen yang "sama". Jika Anda memilih untuk menggunakan nama layanan baru, aplikasi Anda akan tetap berfungsi dengan sempurna; namun, pengguna di perangkat yang menjalankan Wear OS versi 6 atau yang lebih rendah harus menambahkan kembali widget ke carousel mereka secara manual.

Perilaku Sistem untuk Penyiapan Layanan Tunggal:

OS / Kemampuan Perangkat Pengalaman yang Dihasilkan
Wear OS 3 Tidak didukung
Wear OS 4, 5, 6 Widget ditampilkan sebagai kartu layar penuh
Wear OS 7 (Tidak ada dukungan tinggi sebagian) Widget diterjemahkan ke kartu
Wear OS 7 (Dukungan tinggi sebagian) Widget digunakan

*Memerlukan perender 1.6+.

Tips Terjemahan UI

Saat menerjemahkan UI dari ProtoLayout (Kartu) ke Remote Compose (Widget), model mental akan beralih dari builder tata letak imperatif ke arsitektur berbasis Compose yang didorong oleh status, tempat update UI ditangani melalui rekomposisi. Perhatikan prinsip-prinsip berikut:

  • Adopsi UI Deklaratif: Ganti builder ProtoLayout imperatif (LayoutElementBuilders) dengan Remote Compose deklaratif yang setara, seperti RemoteText, RemoteColumn, dan RemoteBox.
  • Fokus pada Konten Inti (mainSlot): Widget tinggi sebagian (misalnya, jenis penampung SMALL dan LARGE) menyediakan platform yang terfokus dan dapat dilihat sekilas. Daripada memindahkan tata letak Kartu layar penuh yang padat satu per satu, sederhanakan desain Anda untuk menekankan informasi utama dalam area konten utama.
  • Desain Ulang Tindakan yang Diratakan di Tepi: Dalam arsitektur kartu, komponen yang menempel di layar seperti EdgeButton ditambatkan ke bottomSlot khusus. Karena widget tinggi sebagian terintegrasi langsung ke platform yang dapat di-scroll secara vertikal, paradigma bottomSlot tetap ini tidak lagi ada. Karena tombol yang diratakan di tepi sering kali berfungsi sebagai tindakan utama yang sangat menonjol, migrasi memerlukan desain ulang UI yang disengaja, bukan penggantian komponen langsung. Evaluasi strategi UX alternatif untuk tindakan utama Anda:
    • Tindakan Inline: Integrasikan RemoteButton inline langsung dalam tata letak mainSlot Anda.
    • Ketukan Penampung: Gabungkan interaksi dengan membuat seluruh penampung widget dapat diketuk menggunakan PendingIntentAction.
    • Pivot Konten: Evaluasi kembali fokus widget. Tanpa slot tindakan khusus, pertimbangkan untuk menampilkan data yang lebih kaya dan dapat dilihat sekilas serta mengandalkan satu ketukan untuk membuka aplikasi lengkap, bukan mengisolasi tindakan tertentu di platform widget.
  • Migrasikan Penanganan Peristiwa (Tindakan vs. Lambda): Kartu mengandalkan interaksi (seperti LoadAction) yang memicu callback layanan lengkap untuk memuat ulang UI. Widget Wear didorong oleh sisi klien. Lambda Compose standar tidak dapat dijalankan dari jarak jauh; sebagai gantinya, berikan Tindakan Deklaratif yang dapat diserialisasi (seperti ValueChange atau PendingIntentAction). Gabungkan tindakan ini dengan status deklaratif (misalnya, rememberMutableRemoteInt) untuk mendukung update UI instan tanpa perjalanan pulang pergi aplikasi.
  • Adaptasi Dimensi dan Jenis: Saat memigrasikan dimensi tata letak, sebaiknya gunakan resolusi tata letak yang ditangguhkan menggunakan RemoteDp (misalnya, 10.rdp) daripada Dp standar. Hal ini memastikan perender sistem menghitung nilai piksel dengan benar pada waktu tampilan. Demikian pula, gunakan fungsi ekstensi Remote Compose (.rc untuk Color, .rs untuk String, .rdp untuk Dp) untuk mengonversi jenis Kotlin dan Remote Compose standar dengan lancar.
  • Tinjau Kode Contoh: Untuk melihat contoh komprehensif tentang cara membuat tata letak, menerapkan tipografi semantik, dan mengelola status di Remote Compose, jelajahi kode contoh resmi yang tersedia di repositori Contoh Wear OS.