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, खातों की पहचान के लिए छह वर्णों वाली अल्फ़ान्यूमेरिक स्ट्रिंग (जैसे, 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 API के लिए फिर से सहमति दें."
उपयोगकर्ताओं को सूचना कब दें
उपयोगकर्ताओं के साथ सभी तरह के कम्यूनिकेशन में, Google Health के ब्रैंड से जुड़ी गाइडलाइन का पालन करें. साथ ही, ऐसे बैनर, कार्ड या चेतावनियों का इस्तेमाल करें जिन्हें हटाया जा सकता है.
- जब कोई उपयोगकर्ता कसरत कर रहा हो या मैन्युअल तरीके से कुछ लॉग कर रहा हो, तब सहमति के लिए अनुरोध करने वाली स्क्रीन को ट्रिगर न करें.
- सहमति के लिए अनुरोध करने वाली स्क्रीन को, चेतावनी देने के कई हफ़्तों बाद ही अनिवार्य बनाएं. यह समय, Fitbit Web API को बंद करने की आधिकारिक समयसीमा के साथ मेल खाना चाहिए.
- अगर किसी उपयोगकर्ता ने, तय समयसीमा के बाद भी सहमति नहीं दी है, तो उसे डेटा वापस पाने का विकल्प दें. बैनर, कार्ड या टूलटिप में एक सहायता मैसेज दें. इससे उपयोगकर्ता को यह समझने में मदद मिलेगी कि उसका डेटा क्यों नहीं दिख रहा है और इसे कैसे ठीक किया जा सकता है.