ภาพรวม

Google Health API เป็นโซลูชันที่ครอบคลุมซึ่งสร้างขึ้นตั้งแต่ต้น โดยมอบสิทธิ์เข้าถึงที่เชื่อถือได้แก่นักพัฒนาแอปเพื่อเข้าถึงข้อมูลด้านสุขภาพของผู้ใช้ที่ได้รับความยินยอมและข้อมูลประเภทต่างๆ มากมาย Google Health API ใช้คอนโซลใหม่สำหรับการลงทะเบียนแอป, Google OAuth 2.0, ข้อมูลประเภทใหม่, สคีมาปลายทางใหม่ และรูปแบบการตอบกลับใหม่

คู่มือนี้ออกแบบมาเพื่อช่วยให้นักพัฒนาแอปย้ายข้อมูลแอป Fitbit Web API ที่มีอยู่ไปยัง Google Health API ใหม่ โดยมีคำแนะนำเพื่อให้การย้ายข้อมูลเป็นไปอย่างราบรื่นพร้อมทั้งรักษาผู้ใช้ไว้

เหตุผลที่ควรย้ายข้อมูล

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

  • เข้าถึงข้อมูลที่ครอบคลุม: เข้าถึงข้อมูลด้านสุขภาพของผู้ใช้ที่ได้รับความยินยอม และข้อมูลประเภทต่างๆ มากมายได้อย่างเชื่อถือได้
  • ความปลอดภัยที่เพิ่มขึ้น: ปฏิบัติตามแนวทางปฏิบัติแนะนำด้านความปลอดภัยของ Google ซึ่งสอดคล้องกับมาตรฐานด้านความปลอดภัย ความเป็นส่วนตัว และข้อมูลประจำตัวของ Google
  • ความสอดคล้อง: ขจัดความไม่สอดคล้องเดิมในรูปแบบข้อมูล เขตเวลา หน่วยวัด และการจัดการข้อผิดพลาด เพื่อให้ประสบการณ์การใช้งานของนักพัฒนาแอปเป็นไปอย่างราบรื่นยิ่งขึ้น
  • ความสามารถในการปรับขนาดและการเตรียมพร้อมสำหรับอนาคต: ออกแบบมาให้ปรับขนาดได้ตามความต้องการในอนาคตและรองรับโปรโตคอลที่ทันสมัย เช่น gRPC

การเปลี่ยนจาก Fitbit Web API เป็น Google Health API ไม่ได้มีเพียงการแก้ไขทางเทคนิคเท่านั้น เนื่องจากการเปลี่ยนไปใช้ไลบรารี OAuth ใหม่ ระบบจึงโอนโทเค็นการเข้าถึงและการรีเฟรชที่มีอยู่ไม่ได้ ผู้ใช้จึงต้องให้ความยินยอมอีกครั้งสำหรับการผสานรวมที่อัปเดตแล้ว

รองรับวิธีการเข้าสู่ระบบทั้ง 2 วิธี

เนื่องจาก Fitbit Web API และ Google Health API ใช้ระบบที่แตกต่างกันในการจัดการการเข้าสู่ระบบของผู้ใช้ แอปของคุณจึงต้องรองรับทั้ง 2 วิธีพร้อมกันชั่วคราวในขณะที่ Fitbit Web API ยังคงใช้งานได้

ให้สร้างเลเยอร์ที่ตัดสินใจว่าจะสื่อสารกับ Fitbit Web API หรือ Google Health API สำหรับผู้ใช้รายใดรายหนึ่งแทนที่จะให้แอปขอข้อมูลโดยตรง เพื่อให้ส่วนอื่นๆ ของแอปไม่ต้องกังวลเกี่ยวกับรายละเอียด

อัปเดตฐานข้อมูลผู้ใช้ให้มีแฟล็ก (เช่น oauth_type) เพื่อระบุระบบการเข้าสู่ระบบที่ผู้ใช้กำลังใช้อยู่

  • สำหรับผู้ใช้ใหม่: ตั้งค่าให้ใช้ Google Health API ใหม่โดยอัตโนมัติ (oauth_type: google)
  • สำหรับผู้ใช้เดิม: ให้ผู้ใช้ใช้ Fitbit Web API ต่อไปจนกว่าจะอัปเดต ความยินยอม (oauth_type: fitbit)

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

  1. เมื่อผู้ใช้ที่ยังคงเชื่อมต่อกับ Fitbit Web API มีส่วนร่วมกับแอปของคุณ ให้แสดงการแจ้งเตือนที่เป็นมิตรเพื่อกระตุ้นให้ผู้ใช้อัปเดตการเชื่อมต่อ
  2. เมื่อผู้ใช้ยอมรับการดำเนินการอัปเดต ให้ทริกเกอร์โฟลว์การเข้าสู่ระบบ Google Health ทันที
  3. เมื่อเข้าสู่ระบบ Google สำเร็จแล้ว ให้บันทึกข้อมูลเข้าสู่ระบบ Google ใหม่ลงในโปรไฟล์ของผู้ใช้และเปลี่ยนแฟล็ก oauth_type จาก fitbit เป็น google หากการตั้งค่าอนุญาต ให้ลงชื่อออกจากระบบ Fitbit เก่าโดย การเพิกถอน โทเค็น ของผู้ใช้แบบเป็นโปรแกรมเพื่อรักษาความเรียบร้อยและความปลอดภัย

ตรวจสอบว่าข้อมูลต่อเนื่อง

เมื่อเปลี่ยนการผสานรวมจาก Fitbit Web API เดิมเป็น Google Health API แอปพลิเคชันของนักพัฒนาแอปต้องคำนึงถึงการเปลี่ยนแปลงโครงสร้างการระบุตัวตนของผู้ใช้

Fitbit Web API เดิมจะระบุบัญชีโดยใช้สตริงตัวอักษรและตัวเลข 6 ตัว (เช่น A1B2C3) ในขณะที่ Google Health API ใช้ healthUserId ที่จัดรูปแบบเป็นสตริงตัวเลขและตัวอักษรสูงสุด 63 ตัว

นักพัฒนาแอปสามารถค้นหาปลายทาง getIdentity เพื่อรับรหัสผู้ใช้ Fitbit และ Health เพื่อลดช่องว่างนี้โดยไม่สูญเสียบริบทของผู้ใช้ ปลายทางนี้จะแสดงเพย์โหลดที่มีทั้ง legacyUserId และ healthUserId ใหม่ ซึ่งช่วยให้แอปพลิเคชันสร้างการแมประหว่างระเบียนที่มีอยู่กับระบบบัญชีใหม่แบบไดนามิกได้

ทดแทนข้อมูลย้อนหลัง

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

หากต้องการทดแทนข้อมูลของผู้ใช้ เมื่อผู้ใช้ตรวจสอบสิทธิ์กับปลายทางใหม่แล้ว คุณสามารถใช้ Google Health API ของเราเพื่อทดแทนข้อมูลย้อนหลังของผู้ใช้ได้ ดูคำแนะนำได้ที่ ค้นหาข้อมูลย้อนหลัง

การสื่อสารและเวลา

ทำตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อช่วยให้ผู้ใช้เปลี่ยนจาก Fitbit OAuth ที่มีอยู่เป็น Google OAuth ใหม่

การสื่อสารที่เน้นคุณค่า

อย่าเริ่มต้นด้วย "เราอัปเดต API แล้ว" แต่ให้เริ่มต้นด้วยประโยชน์ของการผสานรวมข้อมูล Google Health เข้ากับแอปของคุณ แต่ต้องแจ้งให้ผู้ใช้ทราบว่าต้องตรวจสอบสิทธิ์อีกครั้งหากต้องการให้ข้อมูลซิงค์

  • อธิบายอย่างชัดเจนว่าแอปของคุณมีฟีเจอร์ใดบ้างที่ขับเคลื่อนโดยการผสานรวม และปรับข้อความให้เหมาะกับวิธีที่ผู้ใช้จะได้รับประโยชน์จากฟีเจอร์เหล่านั้น
  • มุ่งเน้นที่ฟีเจอร์ของคุณและแสดงกรณีการใช้งานแทนที่จะแสดงรายละเอียดการติดตั้งใช้งานทางเทคนิค
  • อย่าพูดว่า: "คุณจะเชื่อมต่อกับ Fitbit API ไม่ได้"
  • ให้พูดว่า: "หากต้องการดูการออกกำลังกายโดยละเอียดพร้อมข้อมูลอัตราการเต้นของหัวใจต่อไป โปรดให้ความยินยอมอีกครั้งสำหรับ Google Health API"

เวลาที่ควรแจ้งผู้ใช้

ในการสื่อสารกับผู้ใช้ทั้งหมด ให้ปฏิบัติตาม หลักเกณฑ์เกี่ยวกับแบรนด์ Google Health, และใช้แบนเนอร์ การ์ด หรือการแจ้งเตือนที่ปิดได้

  • อย่าทริกเกอร์หน้าจอการขอความยินยอมอีกครั้งขณะที่ผู้ใช้กำลังออกกำลังกายหรือบันทึกข้อมูลบางอย่างด้วยตนเอง
  • บังคับให้ขอความยินยอมอีกครั้งหลังจากผ่านไปหลายสัปดาห์ที่มีการเตือน ซึ่งตรงกับกำหนดเวลาการเลิกใช้งาน Fitbit Web API อย่างเป็นทางการ
  • หากผู้ใช้ไม่ให้ความยินยอมอีกครั้งหลังจากกำหนดเวลาสิ้นสุดแล้ว ให้เตรียมเส้นทางการกู้คืนข้อมูลอย่างราบรื่น แสดงข้อความช่วยเหลือใน แบนเนอร์, การ์ด หรือ คำแนะนำเครื่องมือ ที่จะช่วยให้ผู้ใช้เข้าใจว่าทำไมข้อมูลจึงหายไปและวิธีแก้ไข