Health Connect API
Read and write Android Health Connect records from JavaScript — mirrors the WebViewGold HealthKit API on iOS so one web app covers both platforms.
L'API Health Connect lit et écrit des données de santé via Android Health Connect. Elle reflète la fonctionnalité iOS HealthKit de WebViewGold, de sorte que vous puissiez livrer une seule application web qui communique avec les données de santé sur les deux plateformes. Les lectures renvoient toujours les totaux du jour pour le type d'enregistrement demandé.
Lire un enregistrement :
<a href="readhealthkit://StepsRecord" onclick="setTimeout(show, 300)">
My steps today
</a>
<script>
function show() {
// Injected variable name matches the sanitized record name.
alert(StepsRecord); // e.g. "8421.0 steps"
}
</script>
Écrire un enregistrement :
Format : writehealthkit://<RecordName>//<value>
<a href="writehealthkit://StepsRecord//1000">Log 1000 steps</a>
En cas de succès, l'application injecte <RecordName> = "WRITE_SUCCESS". En cas d'échec, elle injecte le texte de l'erreur.
Enregistrements pris en charge : Tout type d'enregistrement Health Connect pour lequel votre application a demandé la permission. Les plus courants sont :
StepsRecordHeartRateRecordWeightRecordSleepSessionRecordHydrationRecordActiveCaloriesBurnedRecordDistanceRecord
Configuration :
- Installez Health Connect sur l'appareil (préinstallé sur Android 14+).
- Lors de la première utilisation, l'application ouvre la boîte de dialogue des permissions Health Connect ; l'utilisateur accorde l'autorisation de lecture et/ou d'écriture pour les types d'enregistrement demandés.
- Si Health Connect n'est pas pris en charge, la valeur injectée est remplacée par la chaîne
"Health Connect not supported".
Remarques : Les valeurs sont renvoyées sous la forme "<nombre> <unité>" (p. ex. "75.4 kg"). Nécessite Android 8.0 (API 26) ou supérieur.
Notes d’implémentation façon SDK
Considérez cette fonctionnalité comme une capacité native exposée à votre couche web : conservez votre site web de production ou votre PWA comme source de vérité, puis utilisez les indicateurs de configuration WebViewGold documentés, les commandes URL et les appels du pont JavaScript pour activer le comportement natif Android uniquement là où il apporte de la valeur. Cette approche garde votre base de code maintenable, car la même application web peut servir les navigateurs, WebViewGold pour Android et les autres plateformes WebViewGold avec un minimum de logique conditionnelle.
Pour des résultats fiables, privilégiez les points de terminaison HTTPS, des noms de routes stables, des états de succès/erreur explicites dans votre interface et de petites fonctions JavaScript qui encapsulent les appels natifs. Par exemple, une application web créée avec jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, une pile React/Vue/Angular personnalisée ou du HTML statique peut exposer un seul bouton ou gestionnaire d’événement qui déclenche l’API native WebViewGold tout en affichant une solution de repli élégante dans le navigateur.
- Modèle d’intégration recommandé : détectez le contexte de l’application, appelez l’API WebViewGold, puis mettez à jour votre interface web après le rappel natif ou le changement de route.
- Liste de vérification des tests : validez la fonctionnalité sur un appareil réel ou une build empaquetée, vérifiez les autorisations et le texte de revue du store, et confirmez que les utilisateurs navigateur uniquement reçoivent toujours une solution de repli utile.
- Avantage SEO : gardez les pages de fonctionnalités, les titres de routes et le contenu structuré indexables sur votre site web pendant que WebViewGold fournit l’enveloppe d’application native pour les utilisateurs Android.