Exigences WebView
Ce qu'une WebView doit supporter pour qu'une expérience OmniLab fonctionne dans votre app.
Confirmez ces points avant que votre équipe mobile ne commence. Chacun a un mode de défaillance qui ressemble à une expérience cassée plutôt qu'à un réglage manquant : c'est ce qui les rend coûteux à découvrir tard.
La WebView elle-même
- JavaScript activé. Rien ne se charge sans lui. Il est désactivé par défaut dans certaines configurations Android.
- Un composant WebView récent. Utilisez le composant standard de la plateforme ou un wrapper maintenu. Les navigateurs intégrés anciens échouent sur les animations et les mises en page modernes, et l'échec se traduit généralement par un écran blanc plutôt que par une erreur.
- Cookies et stockage local autorisés, y compris pour le domaine OmniLab. L'expérience s'en sert pour reconnaître un participant d'un écran à l'autre ; les bloquer donne l'impression d'une déconnexion en plein parcours.
- Un conteneur plein écran ou bord à bord. Une WebView dans une boîte courte à hauteur fixe rogne les jeux.
Permissions
Les permissions sont accordées par votre app, pas par OmniLab. La WebView doit aussi transmettre la demande navigateur à la demande native — activer la permission dans le manifeste ne suffit pas.
| L'expérience utilise | Votre app doit accorder |
|---|---|
| Un jeu de scan ou photo, un envoi de ticket | La caméra |
| Une expérience liée à un lieu ou un magasin | La localisation |
| Une saisie voix ou vidéo | Le microphone |
| Une récompense ou un billet téléchargeable | Le stockage de fichiers, et un moyen d'ouvrir le fichier |
Testez chacune sur un vrai appareil. Les simulateurs accordent les permissions différemment et passeront là où un vrai téléphone échoue.
Pourquoi la connexion fonctionne ici
Une WebView charge l'expérience comme page, et non à l'intérieur d'une page : OmniLab est donc first-party dans cette vue. Les cookies se comportent normalement, les sessions persistent, et transmettre un membre connecté via fci fonctionne sans configuration supplémentaire.
Une chose à éviter : ne construisez pas votre propre page HTML dans la WebView pour y placer l'expérience dans une iframe. Cela recrée la situation tierce qu'une WebView simple évite, et la connexion cesse de fonctionner. Pointez la WebView directement sur l'adresse de l'expérience.
Clavier et formulaires
Si l'expérience comporte un formulaire ou une étape de connexion, vérifiez que le clavier ne couvre pas le champ en cours de saisie, et que la vue défile pour le garder visible. C'est le défaut WebView le plus fréquent, et il vous coûte l'inscription.
Session et navigation
- Décidez ce que fait votre contrôle retour en cours d'expérience. Quitter l'expérience à mi-parcours doit être volontaire, pas accidentel.
- Vérifiez que l'expérience survit au passage de l'app en arrière-plan puis à son retour.
- Vérifiez qu'une perte de connexion produit quelque chose dont le participant peut se remettre.
Tailles d'écran
Testez le plus petit téléphone supporté et la plus grande tablette. Testez les deux orientations si votre app autorise la rotation.