Une brève discussion sur les applications Web progressives

Il y a un nouveau terme en 2016 : Progressive Web Application (PWA), un terme « générique » pour la conception réactive, la connectivité indépendante, la nouveauté, la sécurité, l'exploration, la repersonnalisation et l'installation. Applications/sites Web flexibles et pouvant être liés avec des applications natives. comme l'interactivité. Encore une fois, nous devons tous apprendre à gérer l’ensemble du concept PWA, nous devons avoir davantage de discussions et d’échanges d’idées, et déterminer ce qui rend nos sites Web plus judicieux – ne répétons pas ces erreurs lorsque nous commençons avec une conception Web réactive.

Qu'est-ce qu'une Progressive Web App

Une Progressive Web App (PWA) n'est fondamentalement pas différente d'un site Web ordinaire : elle est également composée de HTML, CSS et JavaScript, et réside dans le navigateur. milieu. Ce qui distingue une PWA d’un site Web normal, c’est une liste de 10 concepts fondamentaux auxquels elle doit répondre. Voici la liste tirée directement du site Web de Google Developers :

Sécurisé – Servi via HTTPS pour empêcher la surveillance du réseau et garantir que le contenu n'est pas falsifié.

Progressive – peut être utilisée par chaque utilisateur, quel que soit le navigateur utilisé, car elle est toujours basée sur le principe de l'amélioration progressive.

Responsive – adaptable à n'importe quel environnement : ordinateurs de bureau, smartphones Téléphone portable, tablette ou autre appareil.

Ne repose pas sur une connexion réseau - amélioré avec des techniciens de service, peut travailler hors ligne ou sur des réseaux de mauvaise qualité

Application de type natif - a une interaction de type application native et une navigation vers les utilisateurs comme natifs expérience des applications car elle est construite sur le modèle du shell de l'application.

Mises à jour continues – Grâce au processus de mise à jour du service worker, les applications peuvent toujours rester à jour.

Détectable – Identifiable en tant qu'« application » grâce aux métadonnées des manifestes du W3C et à l'enregistrement des techniciens de service, permettant aux moteurs de recherche de trouver des applications Web.

Revisitable – Faites en sorte que les utilisateurs reviennent facilement grâce à des fonctionnalités telles que les notifications push.

Installable – Permet aux utilisateurs de conserver les applications qui leur sont utiles sur leur écran d'accueil sans passer par l'App Store.

Linkable – Les applications peuvent être facilement partagées via une URL et peuvent être exécutées sans installation compliquée.

Le respect de ces directives garantira que votre application fonctionne correctement non seulement lorsqu'elle est affichée dans un navigateur, mais également lorsqu'elle est lancée uniquement via les raccourcis de l'écran d'accueil. Vous trouverez peut-être la formulation choisie par Google assez déroutante, mais ne vous inquiétez pas, nous vous expliquerons les règles une par une dans ce tutoriel.

Ce que ne sont pas les Progressive Web Apps

Le concept de PWA ne doit pas être confondu avec :

Application hybride basée sur Cordova

React Native

NativeScript

Electron et NW.js

Toutes les technologies mentionnées précédemment regroupent les applications HTML dans des fichiers exécutables, tels que .apk, .exe, etc., et doivent ensuite être téléchargées depuis Téléchargez-les depuis les magasins d'applications respectifs et installez-les sur l'appareil de l'utilisateur.

PWA ne nécessite pas d'installation et ne peut toujours pas être utilisée dans les magasins d'applications Google Play ou iTunes. Pour télécharger une PWA, visitez simplement son site Web et enregistrez-la comme raccourci sur votre écran d'accueil. Développer et maintenir des versions distinctes pour iOS et Android n'est plus un problème, mais la prise en charge du navigateur doit être prise en compte.

1. Sécurité

La plupart des applications Web progressives utilisent des API natives et des service Workers, des technologies qui gèrent des données sensibles et doivent être manipulées avec prudence. C'est pourquoi chaque PWA est accessible via une connexion HTTPS.

Si vous ne disposez pas d'un serveur avec un certificat SSL, le moyen le plus simple d'exécuter votre projet dans un environnement sécurisé consiste à utiliser les pages GitHub ou un service similaire. Tous les référentiels Github peuvent être hébergés directement via HTTPS, et GitHub et les pages GitHub sont gratuites pour les référentiels publics.

Si vous testez simplement sur un serveur local, vous pouvez également essayer Ngrok. Il s'agit d'un petit outil qui peut établir un canal sécurisé entre n'importe quel hôte local en cours d'exécution et une URL publique. Ngrok est gratuit et disponible sur les systèmes Windows, Mac et Linux.

2. Progressif

Essentiellement, progressif signifie que la PWA doit utiliser des technologies Web largement prises en charge et fonctionner de manière égale sur autant de navigateurs que possible. Comme nous le savons tous, dans le monde du développement Web, cela est presque impossible, mais nous pouvons encore faire certaines choses pour atteindre une base d’utilisateurs plus large.

Par exemple, dans l'application PhotoBooth, nous utilisons l'API getUserMedia() pour accéder à la caméra matérielle d'un appareil. Sa prise en charge sur différents navigateurs est très incohérente : Safari ne le prend pas en charge du tout, et les navigateurs qui le prennent en charge nécessitent un préfixe et son utilisation varie.

Pour garantir que davantage de personnes puissent utiliser notre application, nous couvrons tous les préfixes :

  navigator.getMedia = ( 
    navigator.getUserMedia ||
    navigator.webkitGetUserMedia ||
    navigator.mozGetUserMedia ||
    navigator.msGetUserMedia
   );

Si tous les préfixes échouent, affichez une erreur :

if (!navigator.getMedia) {
    displayErrorMessage("你的浏览器不支持 navigator.getUserMedia 接口。");
}else {
    // 使用 Camera API
}

Si possible , des solutions de secours et des polyfills doivent être fournis. Le même principe s'applique au code CSS et HTML.

3. Responsive

Les applications doivent s'afficher correctement sur tous les appareils, quelle que soit la taille de l'écran. L'interface utilisateur de notre application est assez simple, nous n'utilisons donc que deux requêtes multimédias pour contrôler la taille de la police, le remplissage, la marge, etc.

N'ayez pas peur d'utiliser des bibliothèques et des frameworks CSS comme Bootstrap. Ils facilitent le travail avec les grilles de formulaires, la typographie et la réactivité générale.

4. Indépendant de la connexion réseau

C'est un point très important. L'utilisation de service Workers permet aux applications de s'exécuter même sans connexion Internet.

Certaines applications ne peuvent être que partiellement mises en cache : l'interface utilisateur est mise en cache et disponible hors ligne, et le contenu dynamique nécessite toujours un accès au serveur.

Certaines applications, comme notre application de démonstration PhotoBooth, peuvent être entièrement mises en cache. Tout le code source et les ressources seront enregistrés localement et l'application fonctionnera exactement de la même manière hors ligne et en ligne. Voici le code qui réalise cette magie :

Il s'agit d'une simplification excessive de Service Worker et doit être utilisé avec prudence dans les projets commerciaux.

Vous devez d’abord créer un fichier JavaScript de service worker et définir la logique qui le sous-tend.

sw.js

// 安装 service worker.
this.addEventListener('install', function(event) {
    event.waitUntil(
        caches.open('v1').then(function(cache) {
            // 如果这些资源中有任何资源不能保存，缓存就会失败
            return cache.addAll([
                // 路径是相对于缓存来源，而不是应用程序的目录。
                '/pwa-photobooth/',
                '/pwa-photobooth/index.html',
                '/pwa-photobooth/assets/css/styles.css',
                '/pwa-photobooth/assets/fonts/MaterialIcons-Regular.woff2',
                '/pwa-photobooth/assets/js/script.js',
                '/pwa-photobooth/assets/icons/ic-face.png',
                '/pwa-photobooth/assets/icons/ic-face-large.png',
                '/pwa-photobooth/manifest.json'
            ])
            .then(function() {
                console.log('成功! App 离线可用!');
            })
        })
    );
});
// 定义一个资源被请求时候会发生什么
// 对于我们的应用，我们以缓存优先的方式
self.addEventListener('fetch', function(event) {
    event.respondWith(
        // 试着从缓存中获取.
        caches.match(event.request)
        .then(function(response) {
            // 如果资源没有存储在缓存中，就回退到网络
            return response || fetch(event.request);
        })
    );
});

Ensuite, nous devons lier ce service worker au HTML.

index.html

// 注册 Service Worker.
if ('serviceWorker' in navigator) {
    // 路径是相对于缓存来源，而不是应用程序的目录.
    navigator.serviceWorker.register('/pwa-photobooth/sw.js')
    .then(function(reg) {
        console.log('Registration succeeded. Scope is ' + reg.scope);
    })
    .catch(function(error) {
        console.error('Registration failed with ' + error);
    });
}

Désormais, tous les fichiers du projet seront enregistrés dans le navigateur de l'utilisateur. Toutes les variables et objets JavaScript doivent également être stockés dans localStorage ou IndexDB autant que possible.

5. Références natives de classe

Lors de la création d'une PWA, il est recommandé de suivre un concept de conception appelé architecture shell d'application. Cela semble compliqué, mais cela se résume en réalité à ceci : les applications sont divisées en deux composants principaux : le shell et le contenu.

Le shell contient tous les éléments statiques de l'interface utilisateur, tels que les en-têtes, les menus, les tiroirs, etc. Lors de la mise en cache de l'application, le shell doit toujours être enregistré sur l'appareil car nous voulons qu'il soit toujours disponible. De cette façon, lorsque les utilisateurs sans connexion Internet ouvrent l'application, ils ne verront pas d'écran vide ni de dinosaure en cours d'exécution. Ils verront plutôt l'interface de l'application en cache et les messages d'erreur appropriés.

内容驻留在外壳内。它也可以被缓存，但是没有必要这样做，因为内容通常是动态的，会频繁发生改变，并且每个页面加载时都可能是不同的。

6. 持续更新

一旦被缓存了，PWA 会总是从本地存储加载。不过，如果以任何方式修改了 service workersw.js，那么在下一个页面加载时，新版本就会被下载和安装。

this.addEventListener('install', function(event) {
    event.waitUntil(
        caches.open('v1.0.1').then(function(cache) {
            // ...
        })
    );
});

通过使用 service worker 更新，我们可以重新下载资源，删除旧缓存，或者彻底修改 service worker 逻辑。你可以从这篇 Google 开发者文章中，学到更多有关 SW 更新过程的知识。

7. 可发现

通过给应用程序添加一个 Web Manifest，可以提供有关应用程序的各种信息，并且可以修改应用程序在用户设备上的显示方式。它允许应用程序被带自定义图标的方式保存到主屏幕上，在一个单独的浏览器窗口中启动，以及很多其它很酷的东西。

Web Manifest 是以一个简单 JSON 文件的形式出现：

manifest.json

{
  "name": "Progressive Web App: PhotoBooth",
  "short_name": "PhotoBooth",
  "description": "Simple Progressive Web App for taking selfies.",
  "icons": [{
      "src": "assets/icons/ic-face.png",
      "type": "image/png",
      "sizes": "72x72"
    }, {
      "src": "assets/icons/ic-face-large.png",
      "type": "image/png",
      "sizes": "144x144 256x256" 
    }],
  "start_url": "index.html",
  "display": "standalone",
  "background_color": "#fff",
  "theme_color": "#fff",
  "orientation": "portrait"
}

大多数属性是自解释的，所以我们只讲讲较为重要的一些属性。要查看完整的 Web manifest 格式，以及所有可用的字段，请到这里。

Shortname – 这是应用保存到主屏幕上时的名称。

Icons – 不同分辨率的图标数组。

Display – 定义应用打开的方式。我们选择的是独立（standalone)，所以启动 PhoneBooth 时，会以全屏窗口出现，没有浏览器导航栏或者菜单。它还会被看作为多任务中的一个单独的应用。

要注册 Manifest 文件，必须把它链接到 HTML 中：

<!-- Web Manifest -->
<link rel="manifest" href="manifest.json">

Safari 还不支持 Web Manifest 标准，但是我们可以用如下的苹果特定的 meta 标记，定义类原生应用的行为：

<!-- Meta tag for app-like behaviour in iOS -->
<meta name=”apple-mobile-web-app-capable” content=”yes”>

8. 可再次访问

通知推送不再只限于原生应用。多亏了 service worker 和 Push API，Web 应用程序也可以发送消息给 Android 通知栏。并不是所有应用都可以从这个功能受益，但是当正确使用此功能时，通知确实可以帮助吸引用户。

这个主题已经超出了本教程的范围，因为推送很复杂，值得用一个完整的课程讲解。如果你依然想在你的 Web 应用中实现通知推送，这里有一些最好的学习资源：

Google 开发者网站上的《推送通知：及时、相关和准确》 – 这里.

Google 开发者网站上的《开放 Web 上的推送通知 – 这里.

MDN 上的《使用 Push API》 – 这里.

Push.js 库，提供处理推送通知的更清洁的 API – 这里.

9. 可安装

默认情况下，任何网站都可以用 Chrome 浏览器菜单的 "添加到主屏幕" 按钮，保存到主屏幕上。不过，让用户以这种方式 "安装" 应用程序可能有点难，因为大多数人完全不知道这个功能。

Heureusement, il existe un moyen pour l'application d'inviter l'utilisateur à l'enregistrer, à l'aide d'une simple fenêtre contextuelle d'installation. Pour empêcher les développeurs d'abuser de ces fenêtres contextuelles, leur affichage par programmation n'est pas autorisé. Au lieu de cela, ces fenêtres apparaîtront d'elles-mêmes lorsque l'application remplira les conditions suivantes :

Avoir un manifeste Web valide.

Un Service Worker valide est installé.

Accédez à l'application via HTTPS.

Nous remplissons toutes les conditions mentionnées ci-dessus, donc après que l'utilisateur ait visité le site Web plusieurs fois, il recevra cette invite :

Linkable<.>

Les applications PWA sont accessibles à toute personne disposant d'un simple navigateur, de sorte que l'application peut être partagée simplement via son URL. Aucun outil tiers n'est requis pour découvrir ou installer ces applications.

Si l'application fonctionne en mode autonome, il est également judicieux d'ajouter un bouton de partage dans l'application, car la barre d'adresse et le menu du navigateur ne sont pas visibles.

Enfin

Au-delà de la réactivité

Après ma première expérience avec le design réactif, j'ai réalisé qu'il était important de donner à la conception et à la programmation des équipements spéciaux est une route sans retour. Il n'existe aucun site Web prêt pour la production que je puisse réaliser du premier coup, mais d'autres équipements non spéciaux feront l'affaire. Aujourd’hui, l’ajout de requêtes média est la première chose à laquelle la plupart des gens pensent lorsqu’ils découvrent une urgence stylistique sur mobile, et c’est très bien.

Si je pensais au design réactif maintenant, cela signifierait faire bien plus que des requêtes multimédias et un formatage flexible du contenu. En créant des sites Web réactifs, j'ai réalisé que de plus en plus de personnes avaient besoin d'adaptabilité, de performances et de contenu. J'ai réalisé qu'il ne sert à rien de rendre un site Web réactif adapté ou performant si vous l'oubliez. Je préférerais de loin avoir un site rapide et accessible plutôt qu’un site au design réactif, inaccessible et surchargé, conçu pour s’adapter à l’écran à chaque fois que je l’ouvre.

Idem pour Service Worker, lorsque je l'ai d'abord pensé comme une simple solution hors ligne, j'ai réalisé de nombreux aspects de performances et des façons de rendre le site Web plus accessible et plus facile à utiliser.

Créez un site Web progressif – pas seulement de nom

Une application Web progressive – connectivité réactive et indépendante, nouvelle, sécurisée, explorable, re-personnalisable, installable, applications pouvant être liées (sites Web de base) viennent avec d'excellentes interactions de type natif, mais il y a un mot que nous ne devrions jamais oublier : progressif.

Je comprends qu'il est difficile de promouvoir l'optimisation de la mise à niveau du Web progressif, je pense donc que les nommer applications Web progressives est excellent. J'aimerais que plus de gens créent des sites Web progressifs. Les utilisateurs diront : « Pouvez-vous contribuer à rendre notre site progressif ? » Dans ce cas, l'optimisation et les mises à niveau progressives ne sont pas seulement une chose temporaire : tout le monde voudra le faire.

Les applications web progressives sont une opportunité

Nous chercherons toujours les meilleures solutions pour mettre en œuvre des applications web progressives au début. J'espère que cela sensibilisera davantage de personnes à l'optimisation progressive des mises à niveau. J'espère que les gens ne feront pas la même erreur lorsqu'ils se concentreront sur leur appareil. La conception réactive a changé ma façon de créer des sites Web. Désormais, je pense davantage au contenu Web, à l'accessibilité, aux performances et aux utilisateurs. J'espère sensibiliser davantage de personnes aux fondamentaux du Web lors de la création de PWA (Progressive Web Apps).

Nous n’avons pas besoin de répéter les erreurs du passé. C'est une erreur qu'une PWA ne fonctionne que sur des appareils spécifiques. Concentrons-nous sur la partie « progressive » lors de la création d’une PWA, plutôt que sur « l’application » elle-même.