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 جديدة، لا يمكن نقل رموز الوصول وإعادة التحميل الحالية، ما يتطلّب من المستخدمين إعادة الموافقة على عملية الدمج المعدَّلة.
استخدام طريقتَي تسجيل الدخول
بما أنّ Fitbit Web API وGoogle Health API يستخدمان نظامَين مختلفَين لمعالجة عمليات تسجيل دخول المستخدمين، سيحتاج تطبيقك مؤقتًا إلى دعم الطريقتَين في الوقت نفسه، طالما أنّ Fitbit Web API لا تزال نشطة.
بدلاً من أن يطلب تطبيقك البيانات مباشرةً، يمكنك تنفيذ طبقة تحدّد ما إذا كان يجب التواصل مع Fitbit Web API أو Google Health API لمستخدم معيّن، حتى لا يحتاج باقي تطبيقك إلى الاهتمام بالتفاصيل.
عدِّل قاعدة بيانات المستخدمين لتضمين علامة (مثل oauth_type) لتحديد نظام تسجيل الدخول الذي يستخدمه كل مستخدم.
- بالنسبة إلى المستخدمين الجُدد: يمكنك إعدادهم تلقائيًا باستخدام Google Health API الجديد
(
oauth_type: google). - بالنسبة إلى المستخدمين الحاليين: يمكنك الاحتفاظ بهم على Fitbit Web API إلى أن يوافقوا على مشاركة بياناتهم (
oauth_type: fitbit).
لتجنُّب التأثير في تجربة المستخدم، ننصحك بعدم إجبار الجميع على تسجيل الخروج ثم تسجيل الدخول مرة أخرى. بدلاً من ذلك:
- عندما يتفاعل مستخدم لا يزال متصلاً بـ Fitbit Web API مع تطبيقك، يمكنك عرض إشعار ودّي يشجّعه على تعديل اتصاله.
- عندما يقبل المستخدم إجراء التعديل، يمكنك بدء عملية تسجيل الدخول إلى Google Health في ذلك الوقت.
- بعد نجاح عملية تسجيل الدخول إلى 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 الجديد، اتّبِع أفضل الممارسات التالية.
التواصل الذي يركّز على القيمة
لا تبدأ بالعبارة "لقد عدّلنا واجهة برمجة التطبيقات"، بل ابدأ بالمزايا التي يقدّمها دمج بيانات Google Health في تطبيقك، ولكن تأكّد من إعلام المستخدمين بأنّ عليهم إعادة إثبات صحة بيانات اعتمادهم إذا أرادوا مزامنة بياناتهم:
- اشرح بوضوح الميزات المتاحة في تطبيقك والتي يتم تشغيلها من خلال عملية الدمج، وصمِّم رسالتك بما يتناسب مع كيفية استفادة المستخدم من هذه الميزات.
- ركِّز على ميزاتك وقدِّم حالات استخدام بدلاً من تفاصيل التنفيذ الفني.
- لا تستخدم العبارة: "لن تتمكّن من الاتصال بـ Fitbit API".
- استخدم العبارة: "لمواصلة الاطّلاع على التمارين الرياضية التفصيلية التي تتضمّن بيانات معدّل ضربات القلب، يُرجى إعادة الموافقة على Google Health APIs."
وقت إشعار المستخدمين
في جميع الرسائل الموجّهة إلى المستخدمين، يجب الالتزام بـ إرشادات العلامة التجارية Google Health، واستخدام بانرات أو بطاقات أو تنبيهات قابلة للإغلاق.
- لا تبدأ شاشة إعادة الموافقة أثناء ممارسة المستخدم تمرينًا رياضيًا أو تسجيله شيئًا يدويًا.
- لا تجعل إعادة الموافقة إلزامية إلا بعد عدة أسابيع من التحذيرات، بالتزامن مع المواعيد النهائية الرسمية لإيقاف Fitbit Web API.
- إذا لم يُعد المستخدم الموافقة بعد الموعد النهائي، يمكنك توفير مسار استرداد سلس. يمكنك تقديم رسالة مساعدة في بانر أو بطاقة أو تلميح أدوات لمساعدة المستخدمين في فهم سبب فقدان بياناتهم وكيفية حلّ المشكلة.