Di chuyển từ thẻ thông tin sang tiện ích

Lưu ý: Hướng dẫn di chuyển này chỉ áp dụng nếu bạn có một ô hiện tại mà bạn muốn di chuyển sang một Tiện ích Wear.

Mặc dù cả ô và tiện ích đều hiển thị nội dung của bạn trên một giao diện hệ thống từ xa, nhưng việc tạo chúng đòi hỏi các phương pháp riêng biệt. Việc di chuyển ô hiện có sang một tiện ích có nghĩa là bạn sẽ chuyển từ quá trình tạo bố cục cố định sang giao diện người dùng khai báo, linh hoạt, mở ra các chức năng mới và mô hình phát triển đơn giản.

Chọn chiến lược triển khai

Nếu đang di chuyển một ứng dụng duy trì một ô cũ, bạn phải quyết định cách ứng dụng của mình cung cấp nội dung cho hệ thống. Mặc dù các tiện ích hoàn toàn mới nên sử dụng một Dịch vụ tiện ích duy nhất, nhưng các ứng dụng có ô hiện tại phải chọn duy trì cả hai dịch vụ hoặc hợp nhất trên một Dịch vụ tiện ích duy nhất.

Đề xuất: Dịch vụ kép (ô vuông + tiện ích)

Duy trì cả ô và tiện ích là cách được đề xuất cho tất cả ứng dụng có ô hiện tại. Việc cung cấp 2 dịch vụ riêng biệt sẽ mang lại trải nghiệm người dùng tốt nhất có thể trên nhiều thiết bị.

• Dịch vụ thẻ thông tin: Mở rộng TileService và khai báo một bộ lọc ý định cho androidx.wear.tiles.action.BIND_TILE_PROVIDER.
• Dịch vụ tiện ích: Mở rộng GlanceWearWidgetService và khai báo một bộ lọc ý định cho androidx.glance.wear.action.BIND_WIDGET_PROVIDER.
• Nhóm logic: Sử dụng thuộc tính group trong cấu hình tiện ích để liên kết việc triển khai mới với TileService hiện có. Điều này cho phép hệ thống nhận dạng các thành phần này dưới dạng một thành phần logic duy nhất và tự động di chuyển vị trí băng chuyền hiện có của người dùng sang tiện ích mới trên Wear OS 7 trở lên.

Hành vi của hệ thống khi thiết lập dịch vụ kép:

Hệ điều hành / Khả năng của thiết bị	Trải nghiệm thu được
Wear OS 3	Đã sử dụng Tile
Wear OS 4, 5, 6	Đã sử dụng Tile
Wear OS 7 (Không hỗ trợ chiều cao một phần, ví dụ: Pixel Watch)	Đã sử dụng Tile
Wear OS 7 (Hỗ trợ một phần chiều cao, ví dụ: Galaxy Watch)	Tiện ích được dùng

Phương án thay thế: Một dịch vụ (chỉ tiện ích)

Một dịch vụ duy nhất xử lý cả hai giao thức. Mặc dù phương pháp này triển khai nhanh hơn, nhưng phương pháp này dựa vào chế độ tương thích để "điều chỉnh" tiện ích của bạn thành một ô trên các thiết bị chạy phiên bản Wear OS thấp hơn.

Nếu bạn chọn phương pháp này:

1. Chỉ định cả hai bộ lọc ý định: Dịch vụ của bạn phải có bộ lọc ý định cho cả androidx.wear.tiles.action.BIND_TILE_PROVIDER và androidx.glance.wear.action.BIND_WIDGET_PROVIDER. Điều này đảm bảo tiện ích của bạn xuất hiện trên các nền tảng ô trong Wear 4, 5, 6 và 7 (nếu cần).
2. Giữ nguyên tên dịch vụ hiện có (để nâng cấp liền mạch): Nếu bạn đang thay thế một ô đang hoạt động, việc giữ nguyên tên lớp dịch vụ sẽ đảm bảo rằng những người dùng có ô của bạn trong băng chuyền sẽ thấy ô đó tự động cập nhật thành tiện ích mới. Mặc dù Wear OS 7 sử dụng thuộc tính group trong XML cấu hình tiện ích để liên kết một cách hợp lý các thành phần khác nhau, nhưng các phiên bản Wear OS thấp hơn 7 lại dựa vào tên dịch vụ để xác định chúng là thành phần "giống nhau". Nếu bạn muốn sử dụng tên dịch vụ mới, ứng dụng của bạn vẫn hoạt động bình thường; tuy nhiên, người dùng trên các thiết bị chạy Wear OS phiên bản 6 trở xuống sẽ phải thêm lại tiện ích vào băng chuyền theo cách thủ công.

Hành vi của hệ thống đối với chế độ thiết lập một dịch vụ:

Hệ điều hành / Khả năng của thiết bị	Trải nghiệm thu được
Wear OS 3	Không được hỗ trợ
Wear OS 4, 5, 6	Tiện ích hiển thị dưới dạng một ô toàn màn hình
Wear OS 7 (Không hỗ trợ chiều cao một phần)	Tiện ích được dịch sang một ô
Wear OS 7 (Hỗ trợ một phần chiều cao)	Tiện ích được dùng

*Cần có trình kết xuất 1.6 trở lên.

Mẹo dịch giao diện người dùng

Khi dịch giao diện người dùng từ ProtoLayout (Tiles) sang Remote Compose (Widgets), mô hình tư duy sẽ chuyển từ các trình tạo bố cục bắt buộc sang một kiến trúc dựa trên Compose, hướng đến trạng thái, trong đó các bản cập nhật giao diện người dùng được xử lý thông qua quá trình kết hợp lại. Hãy lưu ý các nguyên tắc sau:

• Áp dụng giao diện người dùng khai báo: Thay thế các trình tạo ProtoLayout bắt buộc (LayoutElementBuilders) bằng các thành phần Remote Compose khai báo tương đương, chẳng hạn như RemoteText, RemoteColumn và RemoteBox.
• Tập trung vào Nội dung cốt lõi (mainSlot): Các tiện ích có chiều cao một phần (ví dụ: các loại vùng chứa SMALL và LARGE) cung cấp một nền tảng tập trung và dễ xem. Thay vì chuyển một bố cục Ô dày đặc, toàn màn hình theo tỷ lệ 1:1, hãy đơn giản hoá thiết kế của bạn để nhấn mạnh thông tin chính trong vùng nội dung chính.
• Thiết kế lại các thao tác căn chỉnh theo cạnh: Trong cấu trúc ô, các thành phần ôm màn hình như EdgeButton được neo vào một bottomSlot chuyên dụng. Vì các tiện ích có chiều cao một phần tích hợp trực tiếp vào một bề mặt cuộn theo chiều dọc, nên mô hình bottomSlot cố định này không còn tồn tại nữa. Vì các nút căn chỉnh theo cạnh thường đóng vai trò là hành động chính nổi bật, nên việc di chuyển đòi hỏi phải thiết kế lại giao diện người dùng một cách có chủ ý thay vì hoán đổi trực tiếp thành phần. Đánh giá các chiến lược thay thế về trải nghiệm người dùng cho các hành động chính của bạn:
  • Hành động nội tuyến: Tích hợp RemoteButton nội tuyến ngay trong bố cục mainSlot.
  • Lượt nhấn vào vùng chứa: Hợp nhất hoạt động tương tác bằng cách làm cho toàn bộ vùng chứa tiện ích có thể nhấn vào bằng cách sử dụng PendingIntentAction.
  • Chuyển hướng nội dung: Đánh giá lại tiêu điểm của tiện ích. Nếu không có một vị trí thao tác chuyên dụng, hãy cân nhắc việc hiển thị dữ liệu phong phú hơn có thể xem nhanh và dựa vào một lần nhấn để mở toàn bộ ứng dụng thay vì tách biệt các thao tác cụ thể trên giao diện của tiện ích.
• Di chuyển tính năng Xử lý sự kiện (Thao tác so với Lambda): Các ô dựa vào các lượt tương tác (chẳng hạn như LoadAction) để kích hoạt lệnh gọi lại dịch vụ đầy đủ nhằm làm mới giao diện người dùng. Các tiện ích trên Wear được điều khiển phía máy khách. Không thể chạy các hàm lambda Compose tiêu chuẩn từ xa; thay vào đó, hãy cung cấp Thao tác khai báo có thể chuyển đổi tuần tự (chẳng hạn như ValueChange hoặc PendingIntentAction). Kết hợp các thao tác này với trạng thái khai báo (ví dụ: rememberMutableRemoteInt) để hỗ trợ các bản cập nhật giao diện người dùng tức thì mà không cần các chuyến khứ hồi của ứng dụng.
• Điều chỉnh kích thước và loại: Khi di chuyển kích thước bố cục, hãy ưu tiên giải pháp bố cục bị hoãn lại bằng cách sử dụng RemoteDp (ví dụ: 10.rdp) thay vì Dp tiêu chuẩn. Điều này đảm bảo trình kết xuất hệ thống tính toán chính xác các giá trị pixel tại thời gian hiển thị. Tương tự, hãy sử dụng các hàm tiện ích Remote Compose (.rc cho Color, .rs cho String, .rdp cho Dp) để chuyển đổi liền mạch các loại Kotlin tiêu chuẩn và Remote Compose.
• Xem xét mã mẫu: Để xem các ví dụ toàn diện về cách tạo bố cục, áp dụng kiểu chữ ngữ nghĩa và quản lý state trong Remote Compose, hãy khám phá mã mẫu chính thức có trong kho lưu trữ Wear OS Samples.