Multi API Call (multiapicall://)
Appelez plusieurs APIs de données WebViewGold en une seule affectation window.location.href — idéal pour les web apps multiplateformes qui utilisent aussi la version iOS.
La fonctionnalité Multi API Call vous permet de déclencher plusieurs APIs WebViewGold en une seule affectation window.location.href. C'est particulièrement utile pour les applications web multiplateformes : les navigateurs basés sur Apple traitent plusieurs redirections de page dans le même script différemment d'Android — appeler window.location.href = "exampleAPItrigger" plusieurs fois dans le même script fonctionne sur Android, mais pas sur iOS. Avec multiapicall://, le même code web fonctionne sur les deux plateformes.
APIs prises en charge comme entrées :
- get-uuid
- getonesignalplayerid
- getappversion
- statusbarcolor (suivi de trois entrées pour les valeurs RGB)
- statusbartextcolor (suivi d'une entrée :
blackouwhite) - bottombarcolor (suivi de trois entrées pour les valeurs RGB)
- navbartextcolor (suivi d'une entrée :
blackouwhite)
Comment l'utiliser :
Séparez les noms des APIs (et leurs valeurs, le cas échéant) par des virgules (,) — sans espaces :
<script> // Exemple de combinaison : "getonesignalplayerid" et "getappversion" window.location.href = "multiapicall://getonesignalplayerid,getappversion"; </script>
Voici comment passer des valeurs aux APIs Dynamic UI :
<script> // Mettre la barre d'état en rouge, son texte en blanc et récupérer l'UUID — le tout en un seul appel window.location.href = "multiapicall://statusbarcolor,255,0,0,statusbartextcolor,white,get-uuid"; </script>
Remarque : Sur Android, appeler les APIs individuelles l'une après l'autre fonctionne également (p. ex. window.location.href = "get-uuid://"; suivi de window.location.href = "getappversion://";). Utilisez multiapicall:// si vous souhaitez partager un même code avec la version iOS de WebViewGold.
Cliquez ici pour voir une page web de démonstration de cette fonctionnalité. Inspectez la page pour consulter le code d'exemple.
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.