Read/Write Value API
Persist small strings on the device from JavaScript and read them back — for theme, language, session tokens, or onboarding state.
L'API Read/Write Value stocke de manière persistante une chaîne de caractères arbitraire sur l'appareil (via le stockage privé de l'application) et la relit dans votre JavaScript. Les valeurs persistent aux redémarrages de l'application et aux vidages du cache — sauf si le système d'exploitation efface les données de l'application.
Écrire une valeur :
Tout ce qui suit writevalue:// est stocké tel quel sous forme d'une seule chaîne. Concevez votre propre format (chaîne de requête, JSON, CSV — ce qui convient à votre application web) :
<a href="writevalue://darkmode=on;user=42">Save</a>
Lire une valeur :
Lorsque readvalue:// est déclenché, l'application injecte la chaîne stockée dans la WebView afin que votre JavaScript puisse la lire :
<a href="readvalue://" onclick="setTimeout(showSettings, 200)">Load</a>
<script>
function showSettings() {
console.log(window.appSettings || "no settings yet");
}
</script>
Cas d'usage typiques :
- Mémoriser le thème, la langue ou l'état d'onboarding d'un utilisateur hors ligne.
- Mettre en cache un jeton de session lorsque vous ne pouvez pas vous appuyer sur les cookies.
- Persister une petite préférence locale sans aller-retour avec le backend.
Remarques : Les valeurs sont spécifiques à chaque installation d'application et à chaque appareil — elles ne sont pas synchronisées entre appareils. Conservez des valeurs de petite taille ; cette API est destinée aux paramètres, pas au stockage de blobs.
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.