Przegląd

Interfejs Google Health API to kompleksowe rozwiązanie opracowane od podstaw, które zapewnia deweloperom niezawodny dostęp do szerokiego zakresu danych o zdrowiu użytkowników, na których korzystanie z tych danych wyrażono zgodę, oraz do różnych typów danych. Interfejs Google Health API korzysta z nowej konsoli do rejestrowania aplikacji, protokołu Google OAuth 2.0, nowych typów danych, nowego schematu punktów końcowych i nowego formatu odpowiedzi.

Ten przewodnik ma pomóc deweloperom w przeniesieniu dotychczasowych aplikacji korzystających z interfejsu Fitbit Web API do nowego interfejsu Google Health API. Zawiera on zalecenia, które pomogą zapewnić płynne przejście przy jednoczesnym zachowaniu użytkowników.

Dlaczego warto przenieść aplikację?

Nie jest to tylko aktualizacja, ale strategiczne działanie, które ma zapewnić bezpieczeństwo Twoich aplikacji i przygotować je na przyszłe postępy w technologii związanej ze zdrowiem. Oto niektóre zalety korzystania z interfejsu Google Health API:

  • Dostęp do kompleksowych danych: uzyskaj niezawodny dostęp do szerokiego zakresu danych o zdrowiu użytkowników, na których korzystanie z tych danych wyrażono zgodę, oraz do różnych typów danych.
  • Większe bezpieczeństwo: zgodność ze sprawdzonymi metodami Google dotyczącymi bezpieczeństwa, zgodność z normami Google w zakresie bezpieczeństwa, prywatności i tożsamości.
  • Spójność: eliminuje niezgodności w starszych formatach danych, strefach czasowych, jednostkach miary i obsłudze błędów, co zapewnia bardziej intuicyjną pracę dewelopera.
  • Skalowalność i odporność na przyszłe zmiany: interfejs został zaprojektowany tak, aby można go było skalować w celu zaspokojenia przyszłych potrzeb. Obsługuje też nowoczesne protokoły, takie jak gRPC.

Przejście z interfejsu Fitbit Web API na interfejs Google Health API wymaga więcej niż tylko zmian technicznych. Ze względu na przejście na nową bibliotekę OAuth nie można przenieść dotychczasowych tokenów dostępu i odświeżania. Użytkownicy muszą ponownie wyrazić zgodę na zaktualizowaną integrację.

Obsługa obu metod logowania

Interfejsy Fitbit Web API i Google Health API korzystają z różnych systemów do obsługi logowania użytkowników. Dopóki interfejsy Fitbit Web API będą aktywne, Twoja aplikacja będzie musiała tymczasowo obsługiwać obie metody jednocześnie.

Zamiast bezpośrednio prosić aplikację o dane, zaimplementuj warstwę, która będzie decydować, czy w przypadku danego użytkownika należy komunikować się z interfejsem Fitbit Web API czy Google Health API. Dzięki temu reszta aplikacji nie będzie musiała się martwić szczegółami.

Zaktualizuj bazę danych użytkowników, aby zawierała flagę (np. oauth_type), która będzie identyfikować, z którego systemu logowania korzystają użytkownicy.

  • W przypadku nowych użytkowników: automatycznie skonfiguruj dla nich nowy interfejs Google Health API (oauth_type: google).
  • W przypadku dotychczasowych użytkowników: pozostaw ich w interfejsie Fitbit Web API, dopóki nie zaktualizują zgody (oauth_type: fitbit).

Aby nie zakłócać komfortu użytkowników, zalecamy, aby nie zmuszać ich do wylogowania się i ponownego zalogowania. Zamiast tego:

  1. Gdy użytkownik, który pozostaje połączony z interfejsami Fitbit Web API, wejdzie w interakcję z Twoją aplikacją, wyświetl mu przyjazne powiadomienie zachęcające do zaktualizowania połączenia.
  2. Gdy użytkownik zaakceptuje działanie aktualizacji, od razu uruchom proces logowania w Google Health.
  3. Po pomyślnym zalogowaniu się w Google zapisz nowe dane logowania Google w profilu użytkownika i zmień flagę oauth_type z fitbit na google. Jeśli Twoja konfiguracja na to pozwala, programowo wyloguj użytkownika ze starego systemu Fitbit unieważniając jego tokeny aby zachować porządek i bezpieczeństwo.

Zapewnienie ciągłości danych

Podczas przenoszenia integracji ze starszego interfejsu Fitbit Web API na interfejs Google Health API aplikacje deweloperów muszą uwzględnić zmianę w strukturach identyfikacji użytkowników.

Starszy interfejs Fitbit Web API identyfikuje konta za pomocą 6-znakowego ciągu alfanumerycznego (np. A1B2C3), natomiast interfejs Google Health API używa parametru healthUserId sformatowanego jako ciąg składający się z maksymalnie 63 cyfr i znaków.

Aby zlikwidować tę różnicę bez utraty kontekstu użytkownika, deweloperzy mogą wysyłać zapytania do punktu końcowego getIdentity, aby uzyskać identyfikatory użytkowników Fitbita i Health. Ten punkt końcowy zwraca ładunek zawierający zarówno legacyUserId, jak i nowy healthUserId, co umożliwia aplikacjom dynamiczne tworzenie mapowania między dotychczasowymi rekordami a nowym systemem kont.

Uzupełnianie danych historycznych

Jeśli użytkownik nie uwierzytelni się w nowych punktach końcowych interfejsu Google Health API, zanim starsze punkty końcowe zostaną wyłączone, jego dane będą nadal dostępne, dopóki będzie synchronizować urządzenie z aplikacją Google Health. Możesz jednak mieć lukę w danych tego użytkownika.

Aby uzupełnić dane, gdy użytkownik ponownie uwierzytelni się w nowych punktach końcowych, możesz użyć interfejsu Google Health API. Więcej informacji znajdziesz w artykule Wyświetlanie danych historycznych.

Komunikacja i czas

Aby pomóc użytkownikom przejść z dotychczasowego protokołu Fitbit OAuth na nowy protokół Google OAuth, postępuj zgodnie z tymi sprawdzonymi metodami.

Komunikacja z naciskiem na korzyści

Nie zaczynaj od komunikatu „Zaktualizowaliśmy nasz interfejs API”, ale od korzyści wynikających z integracji danych Google Health z Twoją aplikacją. Pamiętaj jednak, aby poinformować użytkowników, że jeśli chcą synchronizować dane, muszą ponownie się uwierzytelnić:

  • Wyraźnie wyjaśnij, jakie funkcje są dostępne w Twojej aplikacji dzięki integracji, i dostosuj komunikat do tego, jakie korzyści użytkownik może odnieść z tych funkcji.
  • Zamiast szczegółów technicznych implementacji skup się na funkcjach i podaj przykłady zastosowań.
  • Nie mów: „Nie będzie można połączyć się z interfejsem Fitbit API”.
  • Powiedz: "Aby nadal wyświetlać szczegółowe treningi z danymi o tętni, ponownie wyraź zgodę na korzystanie z interfejsów Google Health API."

Kiedy powiadomić użytkowników

We wszystkich komunikatach do użytkowników przestrzegaj wytycznych dotyczących marki Google Health, i używaj banerów, kart lub alertów, które można zamknąć.

  • Nie wyświetlaj ekranu ponownego wyrażenia zgody, gdy użytkownik jest w trakcie treningu lub ręcznie rejestruje dane.
  • Ponowne wyrażenie zgody stało się obowiązkowe dopiero po kilku tygodniach ostrzeżeń, które zbiegły się z oficjalnymi terminami wycofania interfejsu Fitbit Web API.
  • Jeśli użytkownik nie wyrazi ponownie zgody po ostatecznym terminie, zapewnij mu możliwość odzyskania danych. Wyświetl komunikat pomocy w banerze, karcie lub dymku który pomoże użytkownikowi zrozumieć, dlaczego brakuje jego danych, i jak to naprawić.