Maîtrisez l'API Wake Lock pour empêcher la mise en veille de l'écran dans vos applications web. Une analyse approfondie de l'implémentation, des meilleures pratiques et des cas d'utilisation pour une meilleure expérience utilisateur.
API Wake Lock : Guide complet pour empêcher la mise en veille de l'écran
Dans le paysage numérique moderne, l'expérience utilisateur (UX) est primordiale. Une interaction fluide et ininterrompue peut faire la différence entre un utilisateur ravi et un utilisateur frustré. L'un des points de friction les plus courants, mais souvent négligé, est l'écran de l'appareil qui s'éteint à un moment inopportun. Imaginez suivre une recette complexe, faire une présentation cruciale depuis votre tablette, ou afficher un billet numérique à une porte d'embarquement, pour voir l'écran s'assombrir. C'est le problème que l'API Wake Lock résout avec élégance.
Ce guide complet explorera l'API Wake Lock depuis ses fondements. Nous couvrirons ce qu'elle est, pourquoi elle est essentielle pour certaines applications, comment l'implémenter correctement, et les meilleures pratiques pour garantir que vous l'utilisiez de manière responsable. Que vous soyez un développeur web chevronné ou un débutant, vous acquerrez les connaissances nécessaires pour améliorer vos applications web et offrir une expérience utilisateur supérieure.
Le problème fondamental : Gestion agressive de l'alimentation vs. Besoins de l'utilisateur
Les fabricants d'appareils et les développeurs de systèmes d'exploitation travaillent sans relâche pour optimiser l'autonomie de la batterie. L'un de leurs principaux outils est une gestion agressive de l'alimentation, qui inclut l'assombrissement puis l'extinction de l'écran après une courte période d'inactivité. Pour la plupart des cas d'utilisation, comme la lecture d'articles ou la consultation d'e-mails, c'est une fonctionnalité fantastique qui préserve la précieuse autonomie de la batterie.
Cependant, ce comportement devient un obstacle majeur pour les applications où l'utilisateur est engagé mais n'interagit pas physiquement avec l'écran. Considérez ces scénarios courants à l'échelle mondiale :
- Arts culinaires : Un utilisateur suit une recette sur sa tablette. Ses mains sont couvertes de farine, et l'écran s'éteint juste avant qu'il ait besoin de vérifier la prochaine étape.
- Prise de parole en public : Un présentateur utilise une présentation web. Il s'arrête pour développer un point, et l'écran s'assombrit, perturbant le déroulement de sa présentation.
- Voyages et événements : Un voyageur a sa carte d'embarquement, un code QR, affichée sur son téléphone. À la porte d'embarquement, il doit tapoter l'écran à plusieurs reprises pour le maintenir allumé pendant qu'il fait la queue.
- Fitness et santé : Quelqu'un suit une séance de yoga ou d'entraînement par intervalles à haute intensité (HIIT) sur le web, et la minuterie de mise en veille de l'écran interrompt son entraînement.
Par le passé, les développeurs recouraient à des "bidouilles" intelligentes mais inefficaces pour résoudre ce problème, comme la lecture d'une vidéo silencieuse en boucle en arrière-plan. Ces méthodes n'étaient pas fiables, consommaient des ressources inutiles et ne constituaient pas une solution standardisée. Le web avait besoin d'une meilleure solution — un mécanisme formel, efficace et respectueux de l'utilisateur pour gérer l'état de l'écran. C'est là que l'API Wake Lock entre en jeu.
Présentation de l'API Wake Lock
L'API Wake Lock est une norme web moderne qui fournit un mécanisme formel pour qu'une application web demande un "verrou de veille", empêchant l'écran d'un appareil de s'assombrir ou de se verrouiller. C'est un outil simple mais puissant, conçu avec la sécurité, l'efficacité et le consentement de l'utilisateur au cœur de ses principes.
Les caractéristiques clés de l'API incluent :
- Centré sur l'utilisateur : Il ne peut être activé qu'en réponse à un geste de l'utilisateur, comme un clic ou un tapotement. Un site web ne peut pas acquérir un verrou de veille silencieusement en arrière-plan.
- Conscient de la visibilité : Le verrou de veille est automatiquement libéré lorsque l'onglet ou la fenêtre n'est plus visible. C'est une fonctionnalité essentielle pour la sécurité et l'économie d'énergie.
- Contextes sécurisés uniquement : L'API n'est disponible que sur les pages servies via HTTPS, renforçant les normes de sécurité web modernes.
- Efficace : C'est une fonctionnalité native du navigateur, ce qui la rend beaucoup plus économe en énergie que les solutions de contournement précédentes.
Actuellement, l'API prend en charge un seul type de verrou de veille : 'screen'. Ce type empêche l'écran de s'éteindre. Bien que certaines plateformes natives aient le concept d'un verrou de veille system (qui maintient le CPU en fonctionnement), celui-ci n'est pas exposé au web pour des raisons de sécurité et de stabilité.
Mise en œuvre de l'API Wake Lock : Tutoriel étape par étape
Maintenant, plongeons dans les aspects pratiques de l'utilisation de l'API Wake Lock. Nous allons construire une implémentation robuste qui couvre la détection de fonctionnalité, la demande et la libération du verrou, et la gestion des changements de visibilité.
Étape 1 : Détection de la fonctionnalité
Avant d'essayer d'utiliser une API moderne, la première étape est toujours de vérifier si le navigateur de l'utilisateur la prend en charge. Cette pratique, connue sous le nom de détection de fonctionnalité, garantit que votre application ne plantera pas sur les navigateurs plus anciens. Vous pouvez vérifier la présence de l'API Wake Lock en regardant si 'wakeLock' existe sur l'objet navigator.
if ('wakeLock' in navigator) {
// L'API Wake Lock est prise en charge.
console.log('L\'API Screen Wake Lock est prise en charge !');
} else {
// L'API Wake Lock n'est pas prise en charge.
console.log('L\'API Screen Wake Lock n\'est pas prise en charge sur ce navigateur.');
}
Cette simple vérification vous permet de fournir une solution de repli ou simplement de masquer la fonctionnalité pour les utilisateurs sur des navigateurs non pris en charge, un principe connu sous le nom de dégradation gracieuse.
Étape 2 : Demander un verrou de veille d'écran
Demander un verrou de veille est une opération asynchrone car elle peut nécessiter une autorisation de l'utilisateur ou d'autres vérifications. Par conséquent, la méthode navigator.wakeLock.request() renvoie une Promise. La méthode prend un argument : le type de verrou que vous demandez, qui pour l'instant est toujours 'screen'.
Parce que c'est une API basée sur les Promises, la meilleure façon de la gérer est avec une structure async/await à l'intérieur d'un bloc try...catch. Le bloc try gérera l'acquisition réussie du verrou, et le bloc catch gérera les erreurs, telles que le refus de l'autorisation par l'utilisateur ou le fait que le document ne soit pas actif.
Créons une fonction pour demander le verrou :
// Déclarer une variable globale pour contenir la sentinelle du verrou de veille.
let wakeLockSentinel = null;
const requestWakeLock = async () => {
if ('wakeLock' in navigator) {
try {
wakeLockSentinel = await navigator.wakeLock.request('screen');
wakeLockSentinel.addEventListener('release', () => {
console.log('Le verrou de veille d\'écran a été libéré');
});
console.log('Le verrou de veille d\'écran est actif');
} catch (err) {
// La requête a échoué - peut-être que l'utilisateur a refusé l'autorisation.
console.error(`${err.name}, ${err.message}`);
}
}
};
Décortiquons cela :
- Nous déclarons une variable
wakeLockSentineldans une portée plus large. Cette variable contiendra l'objet qui représente notre verrou actif. - À l'intérieur du bloc
try, nous attendons (await) le résultat denavigator.wakeLock.request('screen'). - En cas de succès, la promesse se résout avec un objet
WakeLockSentinel. Cet objet est notre clé pour gérer le verrou. - Nous ajoutons ensuite un écouteur d'événement à la sentinelle pour l'événement
'release'. Cet événement se déclenche lorsque le verrou est libéré pour une raison quelconque (par exemple, changement de visibilité de l'onglet, libération manuelle), ce qui est utile pour mettre à jour votre interface utilisateur.
Étape 3 : Comprendre l'objet `WakeLockSentinel`
Lorsque vous réussissez à acquérir un verrou de veille, vous obtenez un objet WakeLockSentinel. Cet objet est votre interface avec le verrou. Il possède deux caractéristiques clés :
- Méthode
release(): Une méthode que vous pouvez appeler pour libérer manuellement le verrou de veille. Elle renvoie unePromisequi se résout une fois que le verrou est libéré. - Propriété
released: Un booléen qui estfalselorsque le verrou est actif et devienttrueune fois qu'il est libéré. - Propriété
type: Une chaîne de caractères qui reflète le type de verrou acquis (par exemple,'screen').
Étape 4 : Libérer le verrou de veille
Tout aussi important que d'acquérir un verrou est de savoir quand et comment le libérer. Vous не devriez pas garder l'écran allumé indéfiniment. Libérez le verrou dès que l'utilisateur a terminé la tâche qui le nécessitait.
Par exemple, dans une application de présentation, vous pourriez libérer le verrou lorsque l'utilisateur retourne à l'éditeur de diapositives. Dans une application de recettes, vous pourriez avoir un bouton qui dit "J'ai fini de cuisiner" qui libère le verrou.
Voici comment vous pouvez créer une fonction pour libérer manuellement le verrou :
const releaseWakeLock = async () => {
if (wakeLockSentinel) {
await wakeLockSentinel.release();
wakeLockSentinel = null;
}
};
Cette fonction vérifie si un wakeLockSentinel existe. Si c'est le cas, elle appelle la méthode release() puis réinitialise la variable sentinelle à null. C'est une bonne pratique pour la gestion de l'état, indiquant clairement qu'aucun verrou n'est actuellement actif.
Étape 5 : La partie la plus importante - Gérer les changements de visibilité
Un principe de conception fondamental de l'API Wake Lock est que les verrous sont liés à la visibilité de la page. Si un utilisateur passe à un autre onglet ou minimise la fenêtre, le navigateur libère automatiquement le verrou de veille. C'est une fonctionnalité cruciale pour préserver la batterie et respecter le contrôle de l'utilisateur.
Cependant, que se passe-t-il lorsque l'utilisateur revient à votre onglet ? Le verrou a disparu. Une implémentation robuste doit écouter les changements de visibilité et ré-acquérir le verrou s'il était actif avant que l'utilisateur ne quitte la page.
Nous pouvons y parvenir en écoutant l'événement visibilitychange sur le document.
const handleVisibilityChange = async () => {
if (wakeLockSentinel !== null && document.visibilityState === 'visible') {
// L'onglet est devenu visible et nous avions un verrou de veille auparavant.
// Ré-acquérons-le.
await requestWakeLock();
}
};
document.addEventListener('visibilitychange', handleVisibilityChange);
Dans ce gestionnaire, nous vérifions deux conditions : un verrou de veille était-il précédemment actif (c'est-à-dire, wakeLockSentinel n'est pas null), et le document est-il maintenant visible ? Si les deux sont vraies, nous appelons à nouveau notre fonction requestWakeLock. Cela garantit une expérience transparente pour l'utilisateur. Notez que lorsque le verrou est automatiquement libéré en raison d'un changement de visibilité, la propriété released de notre objet wakeLockSentinel original devient vraie, mais notre référence de variable existe toujours. Une meilleure approche pourrait être d'utiliser un drapeau séparé.
Mettre tout ensemble : Un exemple robuste
Combinons tout cela dans un exemple complet et réutilisable. Nous utiliserons un simple bouton pour activer et désactiver le verrou de veille, et nous gérerons tous les cas limites que nous avons discutés.
<h2>Démo de l'API Wake Lock</h2>
<p>Cliquez sur le bouton pour activer ou désactiver le verrou de veille de l'écran.</p>
<button id="wakeLockToggleButton">Activer le verrou de veille</button>
<p id="wakeLockStatus">Statut : Inactif</p>
<script>
let wakeLockSentinel = null;
// Éléments de l'interface utilisateur
const toggleButton = document.getElementById('wakeLockToggleButton');
const statusDiv = document.getElementById('wakeLockStatus');
// Fonction pour demander le verrou de veille
const requestWakeLock = async () => {
try {
wakeLockSentinel = await navigator.wakeLock.request('screen');
// Écouter les événements de libération
wakeLockSentinel.addEventListener('release', () => {
// Le verrou de veille a été libéré.
statusDiv.textContent = 'Statut : Inactif';
toggleButton.textContent = 'Activer le verrou de veille';
// Nous mettons la sentinelle à null pour que notre gestionnaire de visibilité sache que le verrou est libéré.
wakeLockSentinel = null;
});
statusDiv.textContent = 'Statut : Actif - Votre écran ne se mettra pas en veille.';
toggleButton.textContent = 'Désactiver le verrou de veille';
console.log('Le verrou de veille de l'écran est actif.');
} catch (err) {
// La requête a échoué.
statusDiv.textContent = `Statut : Erreur - ${err.name}, ${err.message}`;
console.error(`La demande de Wake Lock a échoué : ${err.name}, ${err.message}`);
}
};
// Fonction pour libérer le verrou de veille
const releaseWakeLock = async () => {
if (wakeLockSentinel) {
await wakeLockSentinel.release();
wakeLockSentinel = null;
}
};
// Écouteur d'événement pour le bouton de bascule
toggleButton.addEventListener('click', async () => {
if (wakeLockSentinel) {
await releaseWakeLock();
} else {
await requestWakeLock();
}
});
// Ré-acquérir le verrou de veille si la page redevient visible
document.addEventListener('visibilitychange', async () => {
// Cette vérification est importante. Nous voulons seulement ré-acquérir le verrou
// s'il était actif avant que l'onglet ne soit masqué. Cependant, la sentinelle
// est libérée automatiquement, nous avons donc besoin d'un drapeau ou d'une vérification distincte.
// Une logique plus simple est de vérifier si l'utilisateur *voulait* qu'il soit activé.
// Pour cette démo, supposons que si le bouton indique "Désactiver", l'utilisateur le veut activé.
if (document.visibilityState === 'visible' && toggleButton.textContent === 'Désactiver le verrou de veille') {
await requestWakeLock();
}
});
// Vérification initiale de la prise en charge de l'API
if (!('wakeLock' in navigator)) {
statusDiv.textContent = 'Statut : API Wake Lock non prise en charge.';
toggleButton.disabled = true;
}
</script>
Meilleures pratiques et considérations globales
L'API Wake Lock est un outil puissant, et un grand pouvoir implique de grandes responsabilités. En abuser peut entraîner des batteries épuisées et une mauvaise expérience utilisateur. Voici quelques meilleures pratiques essentielles à suivre.
1. Utilisez-le avec parcimonie et uniquement lorsque c'est nécessaire
N'activez pas un verrou de veille par défaut sur l'ensemble de votre site web. Il ne doit être utilisé que pour des vues ou des parcours utilisateur spécifiques où il apporte un avantage clair. Par exemple, sur un site d'actualités, vous n'avez pas besoin d'un verrou de veille pour la page d'accueil, mais cela pourrait être une option configurable par l'utilisateur pour la vue de l'article principal.
2. Initiez-le sur une action de l'utilisateur
L'API exige déjà un geste de l'utilisateur pour la demande initiale. Adoptez ce principe. La meilleure pratique est de lier le verrou de veille à une action explicite de l'utilisateur, comme cliquer sur un bouton "Démarrer la présentation", un interrupteur "Activer le mode cuisine", ou lire une vidéo d'entraînement. Cela garantit que l'utilisateur est en contrôle et comprend pourquoi l'écran reste allumé.
3. Fournissez un retour visuel clair
Informez l'utilisateur lorsqu'un verrou de veille est actif. Cela peut être une petite icône, un message de statut ("Le mode présentation est actif"), ou un changement dans l'interface utilisateur. Surtout, vous devez également fournir un moyen facile et évident pour l'utilisateur de désactiver le verrou de veille. Cela respecte l'autonomie de l'utilisateur et évite les situations où il ne peut pas mettre son écran en veille quand il le souhaite.
4. Gérez le cycle de vie avec soin
Libérez toujours le verrou de veille lorsqu'il n'est plus nécessaire. Si un utilisateur termine sa présentation ou quitte la page de la recette, la logique de votre application doit automatiquement libérer le verrou. Ne comptez pas uniquement sur l'utilisateur pour le désactiver manuellement ou changer d'onglet.
5. Pensez à l'autonomie de la batterie
La raison principale pour laquelle les écrans s'éteignent est d'économiser la batterie. Bien que votre application puisse être importante, une batterie déchargée est un problème beaucoup plus grand pour l'utilisateur. Pesez toujours le bénéfice pour l'expérience utilisateur par rapport au coût de la consommation d'énergie accrue. Pour les tâches de longue durée, envisagez de rappeler à l'utilisateur que l'écran est maintenu allumé et peut consommer plus de batterie.
6. La dégradation gracieuse est essentielle
L'API Wake Lock n'est pas encore prise en charge par tous les navigateurs. Votre application doit fonctionner parfaitement sans elle. Le verrou de veille doit être traité comme une amélioration progressive — une fonctionnalité qui améliore l'expérience des utilisateurs sur les navigateurs compatibles mais dont l'absence ne casse pas la fonctionnalité de base pour les autres.
Conclusion : Une nouvelle norme pour des expériences ininterrompues
L'API Wake Lock est une avancée significative pour la plateforme web. Elle remplace les anciennes bidouilles inefficaces par une solution standardisée, sécurisée et soucieuse de la consommation d'énergie à un problème courant d'expérience utilisateur. En permettant aux applications web d'empêcher la mise en veille de l'écran de manière contrôlée et conviviale, elle débloque un nouveau niveau d'interactivité pour un large éventail d'applications — des outils de présentation et kiosques numériques aux applications de fitness et de cuisine utilisées par des personnes du monde entier.
En comprenant ses mécanismes, en l'implémentant de manière robuste et en adhérant aux meilleures pratiques, vous pouvez tirer parti de cette API pour éliminer un point de friction majeur pour l'utilisateur. N'oubliez pas de l'utiliser judicieusement, de toujours donner la priorité au contrôle et à la conscience de l'utilisateur, et de créer des applications qui offrent une expérience transparente, ininterrompue et vraiment agréable.