Lab web mobile : une application web adaptative et installable à construire dans le navigateur

Ce lab donne à chaque élève un JupyterLab à lui et une petite application web à travailler : un suivi d’habitudes avec une page, une feuille de style, un script, un manifeste et un service worker. Un second lien, Preview (aperçu), affiche l’application dans son état actuel : l’élève modifie un fichier dans JupyterLab, l’enregistre et recharge l’aperçu dans son propre navigateur, fenêtre rétrécie ou en mode appareil du navigateur, pour voir le rendu sur un téléphone.

Ce n’est pas un lab d’attaque. Aucune copie n’a de route vers Internet ni vers un autre élève : rien ne peut y être téléchargé et rien de ce qui s’y trouve ne peut atteindre quelqu’un d’autre.

Ce que les élèves apprennent

Pourquoi une page a besoin de la balise viewport pour être dessinée à la bonne largeur sur un téléphone, comment une feuille de style mobile d’abord ajoute des media queries à 600 et 900 pixels, et pourquoi un bouton devrait faire au moins environ 44 pixels pour être pressé du pouce. Puis les deux fichiers qui rendent une application web installable et utilisable hors ligne : le manifeste, avec un nom, des icônes et des couleurs, et un service worker qui enregistre une liste de fichiers dans un cache. Ils comparent aussi ce qu’une application web mobile peut faire et ne pas faire face à une application native. Le lab n’a pas de navigateur à lui : ce qu’un navigateur fait ensuite, comme proposer d’installer l’application, l’élève le voit dans le sien. Il convient aux initiations au développement web et à la conception mobile ; vérifiez la formulation exacte dans l’unité de votre propre organisme, aucune n’est citée ici.

L’exécuter dans le navigateur

Le lab démarre un seul service, jupyter, qui écrit l’application, deux icônes, un notebook et les petits scripts dans son dossier de travail, puis lance un petit serveur statique sur le dossier app/. Il utilise environ 80 Mo au repos, dans les 512 Mo qu’un service peut avoir. JupyterLab ne demande aucun jeton, car la porte de la plateforme sait déjà qui l’ouvre. Le terminal à côté du lab n’a pas de Python à lui : il atteint celui du lab avec docker exec jupyter, suivi de la commande à lancer à l’intérieur.

  1. Ouvrir la page Conteneur. Ouvrez « Créer » dans la barre et choisissez « Lancer un conteneur ». Tout le monde peut ouvrir la page, et le lab Git et le lab SQL se lancent sans compte. Tous les autres labs demandent un compte gratuit : créez-en un, connectez-vous, puis appuyez sur « Démarrer ».
  2. Trouver le lab. La carte « Laboratoires d’exemple » liste tous les exemples. Trouvez Web mobile : un suivi d’habitudes adaptatif.
  3. Appuyer sur Démarrer. « Démarrer » le lance tel quel, en un clic. « Modifier le fichier d’abord » ouvre le fichier compose pour que vous puissiez le changer avant de démarrer.
  4. L’ouvrir. Sur la page du lab, la barre du lab a deux liens, JupyterLab et Preview. Appuyez sur Preview pour voir l’application dans votre navigateur et rétrécissez la fenêtre. Appuyez sur JupyterLab et double-cliquez sur start.ipynb, ou appuyez sur « Ouvrir le terminal » et tapez docker exec jupyter python3 steps/viewport.py pour voir que la balise viewport est trouvée.

Ce qu’il faut demander aux élèves de rendre

Le fichier app/style.css, téléchargé depuis JupyterLab avec File, Download, une fois les petits boutons (le bouton Add, les boutons de filtre et le bouton rond « fait ») portés à au moins 44 pixels, et une ou deux phrases sur ce qu’ils ont changé et comment ils l’ont vérifié dans leur propre navigateur. Lancer steps/touch.py avant et après montre le changement : il commence avec quatre tailles sous 44 et une réponse terminée n’en a plus aucune. Rien n’est noté automatiquement, et la phrase montre si c’est compris. Pour un travail plus poussé, demandez le background_color manquant dans le manifeste, ou le fichier listé par le service worker qui n’existe pas, avec une note sur la raison pour laquelle l’installation échouerait sans cela.

Une leçon de base sur ce lab

Mobile Web Basics est une petite leçon travaillée dans ce lab. L’élève y liste l’application, demande trois fichiers au serveur d’aperçu, trouve la balise viewport, liste les media queries, compte les boutons sous 44 pixels, vérifie le manifeste et la liste de fichiers du service worker.

Les comptes personnels gratuits l’ont dans le module Basics, qui est sur l’accueil, chaque établissement peut la copier depuis le dossier Basics de la Bibliothèque. Elle est volontairement petite : elle montre à un enseignant ce qu’est une leçon travaillée dans un lab, et le lab fait le reste. Copiez-la dans un module à vous pour la modifier.

Le code sur GitHub

Le fichier compose n’a pas de Dockerfile : il lance une seule image publique standard, le scipy-notebook des Jupyter Docker Stacks, figée sur une étiquette datée, sous son propre compte sans privilège avec 512 Mo de mémoire. L’image est sous licence BSD-3-Clause et nous ne la distribuons pas. Le fichier écrit l’application à partir d’un texte fixe au démarrage : chaque copie est identique et rien n’est téléchargé. Les limites sont honnêtes : l’application est petite, il n’y a ni navigateur ni téléphone dans le lab, un navigateur peut refuser un service worker sur une adresse non sécurisée, rien ne peut être installé depuis Internet, et rien n’est conservé à l’arrêt du lab : l’élève télécharge donc ses fichiers avant.

Le proposer comme travail

Indiquez dans la tâche ce qu’il faut rendre.

  1. Créer le lab. Dans votre module, ajoutez une tâche et choisissez la carte « Lab de conteneurs », puis « Dans un dépôt GitHub ». Indiquez https://github.com/mitsurutech/lab-mobile-web avec la branche main. Le fichier compose par défaut est compose.yaml. Faites d’abord un fork du dépôt si vous voulez le modifier, par exemple pour modifier l’application.
  2. Publier et l’essayer. « Publier » fige le commit qui vous a été montré : un changement ultérieur dans le dépôt ne modifie donc pas un lab que vous avez déjà proposé. Démarrez d’abord votre propre copie.
  3. Le distribuer. Attribuez-le comme n’importe quelle tâche, avec une échéance si vous le souhaitez, et indiquez dans la tâche ce qu’il faut faire et ce qu’il faut rendre.
  4. Noter ce qui est rendu. Ouvrez la copie d’un élève et le travail rendu, notez-le et renvoyez-le avec un motif s’il demande un complément.

Essayer ce lab, et ce qu’il coûte

Un compte personnel gratuit permet de suivre les leçons de base de ce lab, avec chaque mois assez de crédit gratuit pour suivre la plupart des leçons, sans carte. Pour une classe, un établissement a ses 365 premiers jours gratuits pour 50 élèves au plus, puis paie par élève et par an, tous les labs compris et les enseignants gratuits.

Questions fréquentes

Comment les élèves voient-ils la mise en page sur téléphone ?
Le lab n’a pas de navigateur à lui. Ils ouvrent le lien Preview dans leur propre navigateur et rétrécissent la fenêtre, ou utilisent le mode appareil du navigateur s’il en a un. Cela montre la mise en page. Cela ne montre pas ce que le pouce ressent ni comment se comporte le navigateur du téléphone : un vrai téléphone est préférable quand on en a un.
Pourquoi le service worker ne s’installe-t-il pas sur le lien d’aperçu ?
Un navigateur n’autorise un service worker que sur une adresse sécurisée, et le lien d’aperçu peut ne pas en être une dans tous les navigateurs. L’application fonctionne quand même sans lui. La console du navigateur dit s’il a été refusé. Le script steps/offline.py vérifie dans tous les cas la liste de fichiers et montre celui qui n’existe pas.
Pourquoi n’y a-t-il ni jeton ni mot de passe à saisir ?
Les pages web d’un lab ne sont atteintes que par la porte de la plateforme, qui sait déjà qui vous êtes et ne laisse entrer que vous et le personnel qui enseigne votre module. JupyterLab est donc lancé sans jeton. Ne le lancez pas ainsi sur une machine que quelqu’un d’autre peut atteindre.