ภาพรวม

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

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

เหตุใดคุณจึงควรย้ายข้อมูล

สิทธิประโยชน์ของการใช้ Google Health API มีดังนี้

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

ย้ายข้อมูลผู้ใช้

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

กลยุทธ์การใช้ไลบรารีคู่

เนื่องจาก Fitbit Web API และ Google Health API ใช้ไลบรารี OAuth2 ที่แตกต่างกัน คุณจึงต้องจัดการช่วง "การบริดจ์" ที่มีไลบรารีทั้ง 2 รายการอยู่ในฐานของโค้ด

การจัดการการให้สิทธิ์แบบขนาน

• ห่อหุ้มไคลเอ็นต์: สร้างเลเยอร์การแยกส่วนหรืออินเทอร์เฟซสำหรับ "บริการด้านสุขภาพ" ซึ่งจะช่วยให้ส่วนอื่นๆ ของแอปขอข้อมูลได้โดยไม่ต้องทราบว่าไลบรารีใด (Fitbit OAuth หรือ Google OAuth) ทำงานอยู่สำหรับผู้ใช้รายนั้น
• การอัปเดตสคีมาฐานข้อมูล: อัปเดตตารางผู้ใช้ให้มีแฟล็ก oauth_type เช่น ใช้ fitbit สำหรับ Fitbit OAuth และ google สำหรับ Google OAuth
  • ผู้ใช้ใหม่: ใช้ Google Health API และไลบรารี Google OAuth เป็นค่าเริ่มต้น ตั้งค่า oauth_type เป็น google
  • ผู้ใช้ปัจจุบัน: ใช้ Fitbit Web API ต่อไปจนกว่าผู้ใช้จะทำ ขั้นตอนการให้ความยินยอมอีกครั้งเสร็จสมบูรณ์ ตั้งค่า oauth_type เป็น fitbit

ขั้นตอนการให้ความยินยอมอีกครั้งแบบ "ทีละขั้นตอน"

ให้ใช้แนวทางการให้สิทธิ์แบบเพิ่มทีละน้อย แทนการบังคับให้ผู้ใช้ออกจากระบบ

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

เพิ่มการคงผู้ใช้ไว้ให้ได้มากที่สุด

การให้ความยินยอมอีกครั้งเป็น "โซนอันตราย" ที่อาจทำให้ผู้ใช้เลิกใช้แอป โปรดปฏิบัติตามแนวทางปฏิบัติแนะนำด้าน UX ต่อไปนี้เพื่อป้องกันไม่ให้ผู้ใช้เลิกใช้แอป

การสื่อสารแบบ "เน้นคุณค่า"

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

• การรักษาความปลอดภัยที่ดียิ่งขึ้น: กล่าวถึงการปกป้องบัญชี และการยืนยันแบบ 2 ขั้นตอน (2FA) ระดับแนวหน้าของอุตสาหกรรมจาก Google
• ความน่าเชื่อถือ: เวลาซิงค์ที่เร็วขึ้นและการเชื่อมต่อข้อมูลที่เสถียรมากขึ้น
• การจำกัดการเข้าถึงฟีเจอร์: แจ้งให้ผู้ใช้ทราบอย่างสุภาพว่าฟีเจอร์ใหม่และ ประเภทข้อมูลต้องมีการอัปเดต

การกำหนดเวลาที่เหมาะสม

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

การเปรียบเทียบขั้นตอนการย้ายข้อมูล

ความแตกต่างที่ชัดเจนระหว่างขั้นตอนเก่าและขั้นตอนใหม่จะช่วยให้นักพัฒนาแอปเข้าใจจุดที่ตรรกะแยกออก

ฟีเจอร์	Fitbit Web API (เดิม)	Google Health API (Google Identity)
ไลบรารีการตรวจสอบสิทธิ์	โอเพนซอร์สมาตรฐาน	Google Identity Services (GIS) / Google Auth
บัญชีผู้ใช้	ข้อมูลเข้าสู่ระบบเดิมของ Fitbit	บัญชี Google
ประเภทโทเค็น	การเข้าถึง / การรีเฟรชเฉพาะของ Fitbit	โทเค็นเพื่อการเข้าถึง/การรีเฟรชที่ Google ออกให้
การจัดการขอบเขต	สิทธิ์แบบกว้าง	สิทธิ์แบบละเอียด / แบบเพิ่มทีละน้อย

จัดการความแตกต่างของการย้ายข้อมูลบัญชี

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

• ตรวจสอบความถูกต้องของโทเค็น: ใช้ BackgroundWorker เพื่อตรวจสอบว่าโทเค็น Fitbit ล้มเหลวโดยมีข้อผิดพลาด "ไม่ได้รับอนุญาต" หรือไม่ ซึ่งอาจบ่งบอกว่าผู้ใช้ได้ย้ายข้อมูลบัญชีแล้ว แต่แอปของคุณยังไม่พร้อม
• การล้มเหลวอย่างราบรื่น: หากการเรียก Fitbit OAuth ล้มเหลว ให้เปลี่ยนเส้นทางผู้ใช้ ไปยังหน้า "เชื่อมต่อ Fitbit อีกครั้ง" ที่กำหนดเองซึ่งใช้ขั้นตอน Google OAuth ใหม่ โดยเฉพาะ