Développer sa première PWA 2/3

Dans la première partie de l’article, nous avons vu ce qu’était une PWA (Progressive Web Application) et comment préparer son site à réagir comme une application. Passons à l’étape suivante : Construire un Web App Manifest et concevoir un Service Worker. C’est parti !

Construire un Web App Manifest

Le Manifest va permettre de donner des informations génériques sur notre application dans un fichier JSON. Le but est de pouvoir installer l’application sur l’écran d’accueil du téléphone pour fournir à l’utilisateur un accès plus rapide au contenu et une expérience plus riche. Il n’est donc pas obligatoire de passer par une boutique d’application pour les installer. Pour installer une PWA il faudra utiliser la fonctionnalité “Add to home screen”, en réalité il n’y a rien de particulier à faire pour Android qui nous montrera une boîte de dialogue pour y accéder (si le navigateur le permet) mais il faudra que l’utilisateur fasse une action manuelle sur iOS.

Techniquement, notre manifest sera dans un fichier avec l’extension “.webmanifest” qu’il faut référencer dans notre header HTML :

<link rel="manifest" href="/manifest.webmanifest">

Dans ce fichier, il y a énormément de choses que l’on peut préciser, voici la liste des clés les plus importantes à mon sens.

short_name et/ou name

Une des deux clés est au moins obligatoire. Si les deux sont fournies, name sera utilisée dans la plupart des cas et short_name sera utilisée si l’espace est limité (page d’accueil, launcher). Je vous conseille de préciser les deux pour un maximum de compatibilité.

icons

À l’installation, il est possible de définir un ensemble d’icônes que le téléphone pourra utiliser sur l’écran d’accueil, le launcher, le sélecteur d’apps, comme splash screen, etc…

La propriété icons prends en paramètre un tableau d’images. Pour Chrome sur Android, il faut au moins fournir une icône en 192×192 pixels et une en 512×512 pixels. Chrome est capable de les retailler en toutes les tailles nécessaires par l’OS. Pour plus de précision, il est possible de les fournir par incréments plus fins.

Il existe de nombreux outils permettant d’automatiser le découpage de ces icônes comme https://realfavicongenerator.net.

start_url

start_url est obligatoire et indique au navigateur où votre application doit démarrer lorsqu’elle est lancée, et l’empêche de démarrer sur la page sur laquelle l’utilisateur se trouvait lorsqu’il a ajouté votre application à son écran d’accueil.

Pensez à ce que l’utilisateur voudra faire une fois qu’il aura ouvert votre application, et utilisez la page la plus adaptée.

background_color

La propriété background_color est utilisée sur pour le splash screen de l’application (écran de lancement). Sur Android, l’icône (512×512 minimum, format PNG) sera affichée au-dessus du nom de l’application avec la couleur background_color en fond sur le reste de l’écran.

display

Elle permet de personnaliser l’interface qui sera utilisée quand l’appli est lancée. Quatre valeurs sont possibles :

• browser : l’application s’ouvre dans un nouvel onglet ou une nouvelle fenêtre. C’est la valeur par défaut.
• minimal-ui : l’application va ressembler et se comporter comme une application autonome, mais elle aura quelques éléments d’interface permettant de contrôler la navigation. Cela peut inclure que l’application ait une fenêtre différente, sa propre icône dans le lanceur d’applications, etc… Si le choix est indisponible, le type de display précédent sera utilisé.
• standalone : l’application va ressembler à une application autonome et se comporter comme telle. Dans ce mode, l’agent utilisateur va exclure les éléments d’interface qui permettent de contrôler la navigation mais peut inclure d’autres éléments comme une barre de statut.
• fullscreen : toute la zone d’affichage disponible est utilisée. Ce mode est plutôt adapté pour les jeux-vidéos.

scope

Le scope définit l’espace où l’utilisateur peut naviguer. Si il essaye d’accéder à une URL externe au scope, il sera redirigé vers une nouvelle page de navigateur. Attention à ce que la start_url soit bien comprise dans le scope.

theme_color

La theme_color définit la couleur de la barre d’outils, et peut se refléter dans l’aperçu de l’application dans le sélecteur d’apps. Elle doit être accompagnée de la métadonnée theme-color dans le header de notre page HTML.

________

De la même manière que pour les icônes, il existe foultitudes d’applications pour générer et valider son manifest. Pour mon exemple j’ai utilisé https://app-manifest.firebaseapp.com pour générer mon manifest et mes icônes et https://www.pwabuilder.com pour le valider. Dans les DevTools Chrome, l’onglet Application permet aussi de vérifier tout ça. Voici le fichier que j’ai généré de mon côté :

{
 "name": "Démo de PWA",
 "short_name": "Ma PWA",
 "theme_color": "#00c58e",
 "background_color": "#ffffff",
 "display": "standalone",
 "scope": "/",
 "start_url": "/",
 "icons": [
   {
     "src": "/icons/icon-72x72.png",
     "sizes": "72x72",
     "type": "image/png"
   },
   ...
   {
     "src": "/icons/icon-512x512.png",
     "sizes": "512x512",
     "type": "image/png"
   }
 ],
 "lang": "French"
}

Le cas iOS

Maintenant qu’on a vu la théorie, il faut voir la réalité des choses : le support des Web Manifest par iOS est loin d’être parfait. Malheureusement, Apple a préféré gérer les choses différemment du standard W3C. Il y a donc quelques astuces à connaître pour supporter correctement iOS.

Le chemin vers l’icône doit être précisé dans un link apple-touch-icon, sa taille doit être de 180×180 pixels pour gérer un maximum de devices :

<link rel="apple-touch-icon" href="/icons/apple-touch-icon.png">

Il existait autrefois une métadonnée apple-mobile-web-app-capable pour que le site soit utilisable en dehors du navigateur. Elle est aujourd’hui dépréciée, et la seule manière de faire la même chose est de donner la valeur standalone à la clé display. Si on lui donne n’importe quelle autre valeur, l’application s’ouvrira systématiquement dans un navigateur. Attention à correctement gérer la navigation dans le site donc. Il est toujours intéressant d’ajouter la métadonnée pour conserver le support des anciennes versions d’iOS.

<meta name="apple-mobile-web-app-capable" content="yes">

Apple ne propose pas de générer le splash screen à partir des clés icons + name + background_color. Il faut préciser un link pour chaque type d’appareil où l’on voudra que l’application soit utilisable. Exemple pour l’iPhone X :

<link href="splashscreens/iphonex_splash.png"
     media="(device-width: 375px) and (device-height: 812px) and (-webkit-device-pixel-ratio: 3)"
     rel="apple-touch-startup-image" />

Elles peuvent être également générées depuis des services comme l’iOS splash screen Generator d’Appscope : https://appsco.pe/developer/splash-screens. 

Il est aussi possible de préciser si la barre de statut en haut doit être noire ou noire translucide (texte blanc sur fond sombre transparent) avec la métadonnée apple-mobile-web-app-status-bar-style et les valeurs black (default) ou black-translucent.

⚠️ edit mise à jour iOS 14.5 : des nouvelles valeurs sont disponibles mais ne respectent aucune règle logique. Voir https://firt.dev/ios-14.5/#status-bar-change pour plus de détails

<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

Pour supprimer des effets qu’on aurait sur navigateur, il est possible de spécifier du CSS pour supprimer la sélection et le highlighting de texte par exemple :

body {
  -webkit-user-select: none;
  -webkit-tap-highlight-color: transparent;
}

Dernier point concernant le support : du côté de Windows 10, il est aussi possible d’ajouter une métadonnée pour une bonne gestion de la couleur de fond de notre tile. Car oui : Windows 10 sait aussi installer les PWA comme des applications.

<meta name="msapplication-TileColor" content="#00c58e">

Vous l’aurez compris, on s’éloigne un peu de l’esprit de communion que l’on aurait souhaité avoir… Heureusement que tout cela ne bouge pas souvent.

Notre premier Service Worker

Après avoir passé notre site en HTTPS, l’avoir rendu responsive et l’avoir rendu installable sur les différentes plateformes, il est temps de concevoir notre Service Worker. Les Services Workers sont un type de Workers permettant entre autres de servir de proxy entre le navigateur et le réseau pour conserver une bonne expérience de navigation si le mobile est hors ligne.

C’est ce que nous allons construire dans la suite de l’article en profitant de l’API Cache. Ils permettent également d’envoyer des notifications push et d’utiliser des API de synchronisation en arrière-plan. Ce dernier point est tellement vaste qu’il mériterait à lui tout seul un article entier. Retenez tout de même que les notifications push sont pour le moment impossible sur les PWA iOS.

À la semaine prochaine pour la dernière partie et être prêt à développer sa première PWA !