La API de Google Health es una solución integral creada desde cero que proporciona a los desarrolladores un acceso sólido a una amplia variedad de datos de salud de los usuarios con consentimiento y diversos tipos de datos. La API de Google Health utiliza una nueva consola para registrar tus apps, Google OAuth 2.0, nuevos tipos de datos, un nuevo esquema de extremos y un nuevo formato de respuesta.
Esta guía está diseñada para ayudar a los desarrolladores a migrar sus apps existentes de la API de Fitbit Web a la nueva API de Google Health. Incluye recomendaciones para garantizar una migración sin problemas y, al mismo tiempo, retener a los usuarios.
¿Por qué deberías migrar?
No se trata solo de una actualización, sino de una medida estratégica para garantizar que tus apps sean seguras y estén listas para los avances futuros en tecnología de la salud. Estos son algunos de los beneficios de usar la API de Google Health:
- Acceso a datos integrales: Obtén acceso sólido a una amplia variedad de datos de salud de los usuarios con consentimiento y diversos tipos de datos.
- Seguridad mejorada: Cumplimiento de las prácticas recomendadas de seguridad de Google, en consonancia con los estándares de seguridad, privacidad y identidad de Google.
- Coherencia: Elimina las inconsistencias heredadas en los formatos de datos, las zonas horarias, las unidades de medida y el manejo de errores para brindar una experiencia del desarrollador más intuitiva.
- Escalabilidad y preparación para el futuro: Está diseñada para adaptarse a las demandas futuras y admite protocolos modernos como gRPC.
La transición de la API de Fitbit Web a la API de Google Health implica más que modificaciones técnicas. Debido al cambio a una nueva biblioteca de OAuth, no se pueden transferir los tokens de acceso y actualización existentes, lo que requiere que los usuarios vuelvan a dar su consentimiento para tu integración actualizada.
Admite ambos métodos de acceso
Dado que la API de Fitbit Web y la API de Google Health usan sistemas diferentes para controlar los accesos de los usuarios, mientras las APIs de Fitbit Web sigan activas, tu app deberá admitir ambos métodos al mismo tiempo de forma temporal.
En lugar de que tu app solicite datos directamente, implementa una capa que decida si se comunicará con la API de Fitbit Web o la API de Google Health para un usuario específico, de modo que el resto de tu app no tenga que preocuparse por los detalles.
Actualiza tu base de datos de usuarios para incluir una marca (por ejemplo, oauth_type) que identifique qué sistema de acceso están usando.
- Para usuarios nuevos: Configúralos automáticamente con la nueva API de Google Health
(
oauth_type: google). - Para usuarios existentes: Manténlos en la API de Fitbit Web hasta que actualicen
su consentimiento (
oauth_type: fitbit).
Para evitar interrumpir la experiencia del usuario, te recomendamos que no obligues a todos a salir y volver a acceder. En su lugar, sigue estos pasos:
- Cuando un usuario que permanece conectado a las APIs de Fitbit Web interactúe con tu app, muéstrale una notificación amigable que lo aliente a actualizar su conexión.
- Cuando el usuario acepte la acción de actualización, activa el flujo de acceso de Google Health en ese momento.
- Una vez que el acceso a Google se realice correctamente, guarda las nuevas credenciales de Google en el perfil del usuario y cambia su marca
oauth_typedefitbitagoogle. Si tu configuración lo permite, cierra la sesión del antiguo sistema de Fitbit de forma programática revocando sus tokens para mantener todo ordenado y seguro.
Garantiza la continuidad de los datos
Cuando se realiza la transición de una integración de la API de Fitbit Web heredada a la API de Google Health, las aplicaciones para desarrolladores deben tener en cuenta un cambio en las estructuras de identificación de usuarios.
La API de Fitbit Web heredada identifica las cuentas con una cadena alfanumérica de 6 caracteres (como A1B2C3), mientras que la API de Google Health utiliza un healthUserId con formato de cadena de hasta 63 dígitos y caracteres.
Para cerrar esta brecha sin perder el contexto del usuario, los desarrolladores pueden consultar el
getIdentity extremo para obtener los IDs de usuario de Fitbit y Health.
Este extremo muestra una carga útil que contiene el legacyUserId y el nuevo healthUserId, lo que permite que las aplicaciones creen de forma dinámica una asignación entre los registros existentes y el nuevo sistema de cuentas.
Datos históricos de reabastecimiento
Si un usuario no se autentica en los nuevos extremos de la API de Google Health antes de que se desactiven los extremos heredados, sus datos seguirán disponibles siempre que continúe sincronizando su dispositivo con la app de Google Health. Sin embargo, es posible que haya una brecha en los datos de este usuario.
Para reabastecer sus datos, una vez que el usuario vuelva a autenticarse en los extremos nuevos, puedes usar nuestra API de Google Health para reabastecer sus datos históricos. Consulta Consulta datos históricos para obtener orientación.
Comunicación y sincronización
Para ayudar a tus usuarios a pasar de su OAuth de Fitbit existente al nuevo OAuth de Google, sigue estas prácticas recomendadas.
Comunicación centrada en el valor
No comiences con "Actualizamos nuestra API", sino con los beneficios de integrar los datos de Google Health en tu app, pero asegúrate de que sepan que deben volver a autenticarse si quieren que se sincronicen sus datos:
- Explica claramente qué funciones están disponibles en tu app y que funcionan con la integración, y adapta tu mensaje a la forma en que un usuario se beneficia de esas funciones.
- Enfócate en tus funciones y proporciona casos de uso en lugar de detalles técnicos de implementación.
- No digas: "No podrás conectarte a la API de Fitbit".
- Di: "Para seguir viendo entrenamientos detallados con datos de frecuencia cardíaca, vuelve a dar tu consentimiento para las APIs de Google Health".
Cuándo notificar a los usuarios
En todas las comunicaciones con los usuarios, respeta los lineamientos de la marca de Google Health, y usa alertas, tarjetas o banners que se puedan descartar.
- No actives la pantalla de consentimiento mientras un usuario está en medio de un entrenamiento o registra algo de forma manual.
- Solo haz que el consentimiento sea obligatorio después de varias semanas de advertencias, que coincidan con los plazos oficiales de baja de la API de Fitbit Web.
- Si un usuario no volvió a dar su consentimiento después de la fecha límite, proporciona una ruta de recuperación correcta. Proporciona un mensaje de ayuda en un banner, tarjeta o sugerencia que los ayude a comprender por qué faltan sus datos y cómo solucionarlo.