Service de suivi de course
Un service de suivi de course consigne sur le moment la distance, le temps, l'allure et l'itinéraire d'une course faite avec le téléphone, et ne montre à chaque personne connectée que ses propres enregistrements. Une fois la course terminée, l'enregistrement du jour s'ajoute à la liste, et les enregistrements des autres personnes ne sont pas visibles entre eux. On voit les mêmes enregistrements dans l'application mobile et sur le web.
Cet exemple montre une seule chose. L'application mobile et le web, deux écrans, utilisent ensemble un seul backend WEEGLOO. C'est pourquoi cette page présente d'abord le backend que l'application et le web partagent, puis se sépare vers l'application ou le web selon ce qui vous intéresse. Quel que soit le côté choisi, le backend est le même. C'est là tout le propos.
Ce que l'on construit
Au lieu d'un magasin de vêtements ou d'un blog, cet exemple est un service personnel de suivi de course. On voit les mêmes enregistrements sur deux écrans, l'application mobile et le web. On prévoit trois écrans côté application.
- Écran de connexion : vous vous connectez avec Google.
- Liste des enregistrements : une personne connectée voit les enregistrements de course qu'elle a consignés jusqu'à présent, du plus récent au plus ancien.
- Ajout d'un enregistrement : vous consignez la distance, le temps, l'allure, l'itinéraire et la date d'une course.
L'essentiel est que « chacun ne voit que ses propres enregistrements ». Une personne connectée ne reçoit que les enregistrements qu'elle a consignés, et les enregistrements des autres ne lui sont pas visibles. C'est cette condition qui rend nécessaires, plus loin, à la fois la connexion des membres et les autorisations.
Vous pouvez aller directement vers le côté qui vous intéresse. Pour construire l'application mobile, allez à Utiliser en application ; pour construire le web, à Utiliser sur le web. Cela dit, la partie « Le backend derrière les écrans » ci-dessous est commune à l'application comme au web : la parcourir d'abord relie bien les deux branches.
Le backend derrière les écrans (commun à l'application et au web)
Une fois les écrans construits et connectés, si vous dites à l'agent « Intègre ça avec WEEGLOO » (Connecter, Intégrer en une phrase), l'agent examine les écrans et met en place ce qu'il faut derrière eux. Une structure de données pour contenir les enregistrements de course (Content Type), la connexion Google (ServiceLogin), l'autorisation « seulement ses propres enregistrements » (ServiceUserRole), et la distribution qui, selon cette autorisation, envoie à chaque membre uniquement ses propres enregistrements. Ce backend est le même que vous commenciez par l'écran de l'application ou par celui du web, et l'application et le web l'utilisent ensemble tel quel. La façon de traiter chaque pièce isolément est couverte une à une dans Ajouter l'inscription et la connexion, Répartir les autorisations et Stocker et récupérer des données.
Voici les ressources réellement créées dans le Space Stride de cet exemple. Ce n'est pas un pas-à-pas pour configurer chacune d'elles ; c'est un aperçu de ce qui est apparu à la suite de « intègre ça ».
La structure qui contient les enregistrements de course
La première est la structure qui contient les enregistrements de course (Content Type), « Run ». Les valeurs d'une seule course sont réparties en cases par élément.
| Élément | Type de case | Obligatoire | Valeur qu'elle contient |
|---|---|---|---|
Date | Date | Obligatoire | La date de la course. Sert aussi de titre qui identifie l'enregistrement dans la liste. |
Distance (km) | Number | Obligatoire | La distance parcourue (en kilomètres). Elle accepte les décimales. |
Duration (seconds) | Integer | Obligatoire | Le temps mis (en secondes). À l'écran, il s'affiche en minutes et secondes, comme 41:05. |
Notes | Long Text | Facultatif | Une note pour la course de ce jour-là. |
Route photo | Media | Facultatif | Un fichier de carte d'itinéraire ou de photo. |
Il n'y a pas de case distincte qui stocke l'allure moyenne. C'est une valeur que l'on obtient à partir de la distance et du temps seuls, alors l'application la calcule et l'affiche sur le moment (le « auto-calculated » de l'écran d'ajout d'un enregistrement).
La connexion Google
La deuxième est le canal que les membres utilisent pour se connecter avec Google (ServiceLogin). Dans cet exemple, le nom est fixé à « Stride », et Google est la seule méthode de connexion activée. Une personne nouvellement connectée reçoit par défaut l'autorisation « Runner » ci-dessous. Une fois la connexion terminée, le résultat revient à l'écran, mais la façon dont il revient diffère un peu entre l'application et le web. Cette différence est traitée respectivement dans Utiliser en application et Utiliser sur le web.
L'autorisation « seulement ses propres enregistrements »
La troisième est l'autorisation que reçoivent les membres (ServiceUserRole), « Runner ». Les règles sont les suivantes.
| Ce qui peut être fait | Portée d'application |
|---|---|
| Créer un enregistrement | N'importe quel membre connecté |
| Lire un enregistrement | Seulement ceux qu'il a créés |
| Modifier un enregistrement | Seulement ceux qu'il a créés |
| Supprimer un enregistrement | Seulement ceux qu'il a créés |
Comme « lire » est limité à « seulement ceux qu'il a créés », la liste ne montre à chaque personne que ses propres enregistrements. Puisque les enregistrements que chaque membre peut lire ne sont que les siens, c'est précisément la liste qui est distribuée à cette personne. Cette règle s'applique de la même façon à l'application comme au web.
Enregistrements et photos
La quatrième est chaque enregistrement de course individuel (Content) et la photo d'itinéraire (Media). Ces deux-là ne sont pas créés à l'avance ; chacun est créé au nom d'un membre lorsqu'il consigne une course. Voici un enregistrement réellement consigné. La structure « Run » ci-dessus est remplie de valeurs, et une photo d'itinéraire est jointe à côté.
La distance 42.195 est un marathon complet. Le temps est conservé en secondes (ici, un enregistrement de 3 heures 53 minutes) et affiché à l'écran comme 3:53:00. La photo d'itinéraire est stockée séparément sous forme de fichier (Media), et l'enregistrement ne contient qu'un lien pointant vers ce fichier.
Utiliser en application
D'abord l'application mobile. On crée les écrans de l'application, puis on remplit ce qui se trouve derrière eux avec le backend derrière les écrans ci-dessus.
Créer les écrans de l'application et les intégrer
1. Créer les maquettes d'écran. Les trois écrans de « Ce que l'on construit » ci-dessus ont été produits en donnant à un LLM un prompt comme celui ci-dessous. Vous lui donnez une ligne sur le type d'application que vous faites, la liste des écrans et ce que chaque écran contient, ainsi qu'une direction de design.
Conçois les écrans d'une application de suivi de course. C'est une application mobile en mode portrait.
Écrans :
- Connexion : une ligne présentant l'application et un bouton « Continue with Google ».
- Liste des enregistrements (accueil) : un récapitulatif de la distance totale et du nombre de courses, une liste de cartes d'enregistrements de course (date, distance, temps, allure, miniature d'itinéraire) et un bouton d'ajout d'enregistrement.
- Ajout d'un enregistrement : les champs de saisie pour la date, la distance, le temps, l'allure, les notes et une photo d'itinéraire, plus l'enregistrement.
Fais quelque chose de net et de dynamique, pour que des chiffres comme la distance et l'allure se lisent d'un coup d'œil. Suis les conventions d'interface mobile.
Les écrans obtenus ainsi ne sont, à ce stade, que des écrans : pas encore de données ni de connexion.
2. Intégrer à WEEGLOO. Connectez l'agent à WEEGLOO et dites « Intègre ça avec WEEGLOO » : l'agent examine ces écrans et met en place le backend derrière les écrans ci-dessus.
Deux choses à prévoir parce qu'il s'agit d'une application
Le backend est exactement le même qu'en le construisant pour le web. Parce qu'il s'agit d'une application, il y a deux choses à prévoir.
- Déploiement : faire arriver l'application mobile finie entre les mains des gens (la publier sur un marché d'applications) se passe hors de WEEGLOO. Ce dont WEEGLOO se charge, ce sont les données, les membres et les autorisations derrière les écrans de l'application. (Le web n'a pas de marché d'applications. C'est traité dans Utiliser sur le web.)
- Rappel de connexion : la liaison qui rapatrie le résultat dans l'application une fois la connexion terminée diffère du web. Le résultat de connexion ne peut revenir que vers une adresse web, donc une étape supplémentaire est nécessaire : une page qui joue le rôle de relais intermédiaire et transmet ce résultat à l'application. Cette étape technique est traitée dans Auth API.
Vérifier que ce sont bien seulement ses propres enregistrements
La condition centrale « chacun ne voit que ses propres enregistrements » tient réellement dans l'application. Voici les écrans d'accueil de la même application ouverte avec deux comptes différents. C'est la même application, mais la distance totale, le nombre de courses et les enregistrements affichés dans la liste diffèrent tous.
Un compte n'affiche qu'une seule course de 5km, et l'autre n'affiche que deux courses, un marathon et un 3km. Leurs enregistrements ne sont pas visibles l'un pour l'autre. Stride contient les trois de ces enregistrements, mais chaque membre ne reçoit que les enregistrements qu'il a consignés. C'est le résultat du fait d'avoir limité la lecture à « seulement ceux qu'il a créés » dans L'autorisation « seulement ses propres enregistrements » ci-dessus.
Utiliser sur le web
Le web utilise tel quel le même backend que l'application. Le web lit le backend derrière les écrans ci-dessus et affiche les mêmes enregistrements.
Créer les écrans du web et les intégrer
Le web se fait aussi en deux pas, comme l'application.
1. Créer les maquettes d'écran du web. Comme pour l'application, vous donnez à un LLM un prompt comme celui ci-dessous pour produire les écrans du web. Le contenu est le même que pour l'application, mais adapté en une mise en page web pensée pour un écran large.
Conçois les écrans web d'un suivi de course. C'est un site web pour ordinateur de bureau.
Écrans :
- Connexion : une ligne présentant le service et un bouton « Continue with Google ».
- Liste des enregistrements (tableau de bord) : un récapitulatif de la distance totale, du nombre de courses et de l'allure moyenne, une liste d'enregistrements de course (date, distance, temps, allure, miniature d'itinéraire) et un bouton d'ajout d'enregistrement.
- Ajout d'un enregistrement : les champs de saisie pour la date, la distance, le temps, l'allure, les notes et une photo d'itinéraire, plus l'enregistrement.
Fais une mise en page qui tire parti de l'écran large, pour que des chiffres comme la distance et l'allure se lisent d'un coup d'œil. Suis les conventions d'interface web.
2. Intégrer à WEEGLOO. Dites à l'agent connecté « intègre ce web aussi avec WEEGLOO ». Si vous avez déjà construit l'application, l'agent ne remonte pas le backend derrière les écrans ci-dessus : il le raccorde tel quel. Aucune nouvelle ressource WEEGLOO n'est créée. La seule chose créée côté web, ce sont les écrans du web. (Si vous avez commencé par le web sans passer par l'application, c'est à ce moment que ce backend naît pour la première fois, et il en va de même si vous ajoutez l'application ensuite : il est utilisé tel quel. Dans les deux cas, le backend est le même.)
Cet écran web est le compte présenté dans Vérifier que ce sont bien seulement ses propres enregistrements (45.2km ce mois-ci, un marathon de 42.20km et un 3km), ouvert sur le web. La distance totale, le nombre de courses et les enregistrements sont identiques à l'accueil de l'application. Comme le backend est unique, le web montre sur un écran d'ordinateur de bureau exactement les données que l'application a montrées.
Deux choses qui diffèrent parce qu'il s'agit du web
Le web diffère aussi de l'application sur deux points, mais dans le sens inverse : cette fois, il y a plutôt moins de choses à prévoir.
- Déploiement : le web n'a pas besoin de marché d'applications. Vous mettez les fichiers web créés directement sur internet avec le Web Hosting (Mettre un site sur internet).
- Rappel de connexion : sur le web, le résultat de connexion revient directement vers une adresse web. La page-relais intermédiaire nécessaire dans l'application n'est pas requise sur le web.
L'autorisation reste la même : sur le web aussi, chaque membre ne voit que ses propres enregistrements. L'autorisation « seulement ses propres enregistrements » ci-dessus s'applique de la même façon au web.
Que faire ensuite
- Ajouter l'inscription et la connexion : couvre comment ajouter séparément une connexion qui accueille vos propres membres.
- Auth API : couvre l'étape technique consistant à rapatrier le résultat de connexion dans l'application.
- Répartir les autorisations : couvre comment définir les autorisations pour que les membres ne traitent que leurs propres éléments.
- Stocker et récupérer des données : couvre comment créer une structure de données et la remplir de contenu.
- Mettre un site sur internet : couvre comment déployer le web avec le Web Hosting.