ย้ายข้อมูลจากไทล์ไปยังวิดเจ็ต

แม้ว่าทั้งไทล์และวิดเจ็ตจะแสดงเนื้อหาของคุณบนพื้นผิวของระบบระยะไกล แต่การสร้างไทล์และวิดเจ็ตต้องใช้วิธีการที่แตกต่างกัน การย้ายข้อมูลไทล์ที่มีอยู่ไปยังวิดเจ็ตหมายถึงการเปลี่ยนจากการสร้างเลย์เอาต์แบบคงที่ไปเป็น UI แบบไดนามิกและแบบประกาศ ซึ่งจะช่วยปลดล็อกความสามารถใหม่ๆ และรูปแบบการพัฒนาที่เรียบง่าย

เลือกกลยุทธ์การติดตั้งใช้งาน

หากกำลังย้ายข้อมูลแอปที่ยังคงใช้ไทล์เดิม คุณต้องตัดสินใจว่าแอปจะแสดงเนื้อหาต่อระบบอย่างไร ในขณะที่วิดเจ็ตใหม่ควรใช้บริการวิดเจ็ตเดียว แอปที่มีไทล์อยู่แล้วต้องเลือกระหว่างการรักษาทั้ง 2 บริการหรือรวมไว้ในบริการวิดเจ็ตเดียว

แนะนำ: บริการคู่ (ไทล์ + วิดเจ็ต)

การดูแลทั้งวิดเจ็ตและไทล์เป็นแนวทางที่แนะนำสำหรับแอปทั้งหมดที่มีไทล์อยู่แล้ว การให้บริการที่แตกต่างกัน 2 อย่างจะมอบประสบการณ์การใช้งานที่ดีที่สุด เท่าที่จะเป็นไปได้ในอุปกรณ์ต่างๆ

  • บริการไทล์: ขยาย 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 มีการใช้ Tile
Wear OS 4, 5, 6 มีการใช้ Tile
Wear OS 7 (ไม่รองรับความสูงบางส่วน เช่น Pixel Watch) มีการใช้ Tile
Wear OS 7 (รองรับความสูงบางส่วน เช่น Galaxy Watch) มีการใช้วิดเจ็ต

ทางเลือก: บริการเดียว (วิดเจ็ตเท่านั้น)

บริการเดียวจะจัดการทั้ง 2 โปรโตคอล แม้ว่าวิธีนี้จะใช้เวลาในการ ติดตั้งใช้งานน้อยกว่า แต่ก็ต้องอาศัยโหมดความเข้ากันได้เพื่อ "ปรับ" วิดเจ็ตให้เป็นไทล์ ในอุปกรณ์ที่ใช้ Wear OS เวอร์ชันต่ำกว่า

หากเลือกใช้วิธีนี้

  1. ระบุตัวกรอง Intent ทั้ง 2 รายการ: บริการของคุณต้องมีตัวกรอง Intent สำหรับทั้ง androidx.wear.tiles.action.BIND_TILE_PROVIDER และ androidx.glance.wear.action.BIND_WIDGET_PROVIDER ซึ่งจะช่วยให้มั่นใจได้ว่าวิดเจ็ตจะแสดงบนพื้นผิวของไทล์ใน Wear 4, 5, 6 และ 7 (หากจำเป็น)
  2. คงชื่อบริการที่มีอยู่ (เพื่อการอัปเกรดที่ราบรื่น): หากคุณกำลังแทนที่ไทล์ที่ใช้งานอยู่ การใช้ชื่อคลาสบริการเดียวกันจะช่วยให้ผู้ใช้ที่มีไทล์ของคุณในภาพสไลด์เห็นการอัปเดตเป็นวิดเจ็ตใหม่โดยอัตโนมัติ แม้ว่า 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 ขึ้นไป

เคล็ดลับการแปล UI

เมื่อแปล UI จาก ProtoLayout (ไทล์) เป็น Remote Compose (วิดเจ็ต) โมเดลความคิดจะเปลี่ยนจากเครื่องมือสร้างเลย์เอาต์แบบคำสั่งเป็นสถาปัตยกรรมที่อิงตามสถานะและ Compose ซึ่งมีการจัดการการอัปเดต UI ผ่านการจัดองค์ประกอบใหม่ โปรดคำนึงถึงหลักการต่อไปนี้

  • ใช้ UI แบบประกาศ: แทนที่ตัวสร้าง ProtoLayout แบบคำสั่ง (LayoutElementBuilders) ด้วย Remote Compose ที่เทียบเท่าแบบประกาศ เช่น RemoteText, RemoteColumn และ RemoteBox
  • มุ่งเน้นที่เนื้อหาหลัก (mainSlot): วิดเจ็ตที่มีความสูงบางส่วน (เช่น ประเภทคอนเทนเนอร์ SMALL และ LARGE) จะแสดงพื้นผิวที่เน้นและดูได้อย่างรวดเร็ว แทนที่จะพอร์ตเลย์เอาต์การ์ดแบบเต็มหน้าจอที่หนาแน่นแบบ 1:1 ให้ปรับปรุง การออกแบบเพื่อเน้นข้อมูลหลักภายในพื้นที่เนื้อหาหลัก
  • ออกแบบการดำเนินการที่จัดแนวขอบใหม่: ในสถาปัตยกรรมของไทล์ คอมโพเนนต์ที่ยึดติดกับหน้าจอ เช่น EdgeButton จะยึดกับ bottomSlot โดยเฉพาะ เนื่องจากวิดเจ็ตความสูงบางส่วนผสานรวมเข้ากับ พื้นผิวที่เลื่อนในแนวตั้งโดยตรง bottomSlot รูปแบบคงที่นี้จึงไม่มีอยู่อีกต่อไป เนื่องจากปุ่มที่จัดแนวขอบมักทำหน้าที่เป็นการดำเนินการหลักที่โดดเด่นมาก การย้ายข้อมูลจึงต้องมีการออกแบบ UI ใหม่โดยไตร่ตรองมาอย่างดี แทนที่จะเป็นการสลับคอมโพเนนต์โดยตรง ประเมินกลยุทธ์ UX ทางเลือกสำหรับ การกระทําหลัก
    • การดำเนินการในบรรทัด: ผสานรวม RemoteButton ในบรรทัดโดยตรง ภายในเลย์เอาต์ mainSlot
    • การแตะคอนเทนเนอร์: รวมการโต้ตอบโดยทำให้คอนเทนเนอร์วิดเจ็ตทั้งหมดแตะได้โดยใช้ PendingIntentAction
    • การเปลี่ยนแนวทางเนื้อหา: ประเมินโฟกัสของวิดเจ็ตอีกครั้ง หากไม่มีช่องการดำเนินการเฉพาะ ให้พิจารณาแสดงข้อมูลที่ดูได้อย่างรวดเร็วที่ละเอียดยิ่งขึ้น และใช้การแตะครั้งเดียวเพื่อเปิดแอปพลิเคชันแบบเต็มแทนที่จะแยกการดำเนินการเฉพาะบนพื้นผิววิดเจ็ต
  • ย้ายข้อมูลการจัดการเหตุการณ์ (การดำเนินการเทียบกับ Lambda): ไทล์อาศัยการโต้ตอบ (เช่น LoadAction) ที่ทริกเกอร์การเรียกกลับของบริการแบบเต็มเพื่อรีเฟรช UI วิดเจ็ต Wear ทำงานฝั่งไคลเอ็นต์ Lambda ของ Compose มาตรฐานไม่สามารถเรียกใช้จากระยะไกลได้ แต่ให้ระบุการดำเนินการแบบประกาศที่ทำให้เป็นอนุกรมได้ (เช่น ValueChange หรือ PendingIntentAction) รวมการดำเนินการเหล่านี้กับสถานะแบบประกาศ (เช่น rememberMutableRemoteInt) เพื่อรองรับการอัปเดต UI ทันทีโดยไม่ต้องมีการรับส่งข้อมูลในแอป
  • ปรับมิติข้อมูลและประเภท: เมื่อย้ายข้อมูลมิติข้อมูลเลย์เอาต์ ให้ใช้ การแก้ปัญหาเลย์เอาต์ที่เลื่อนออกไปโดยใช้ RemoteDp (เช่น 10.rdp) แทน Dp มาตรฐาน ซึ่งจะช่วยให้ตัวแสดงผลของระบบคำนวณค่าพิกเซล ได้อย่างถูกต้องในเวลาที่แสดง ในทำนองเดียวกัน ให้ใช้ฟังก์ชันส่วนขยาย Remote Compose (.rc สำหรับ Color, .rs สำหรับ String, .rdp สำหรับ Dp) เพื่อแปลงประเภท Kotlin มาตรฐานและ Remote Compose ได้อย่างราบรื่น
  • ตรวจสอบโค้ดตัวอย่าง: หากต้องการดูตัวอย่างที่ครอบคลุมเกี่ยวกับวิธีสร้างเลย์เอาต์ ใช้การจัดรูปแบบข้อความเชิงความหมาย และจัดการสถานะใน Remote Compose ให้สำรวจโค้ดตัวอย่างอย่างเป็นทางการที่มีอยู่ในที่เก็บตัวอย่าง Wear OS