Weegloo Docs - Application de suivi de course

Une application de suivi de course est une application mobile qui enregistre sur le moment la distance, le temps, l'allure et l'itinéraire de chaque course faite avec votre téléphone, et qui 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.

Cet exemple montre une seule chose. Une application mobile utilise exactement le même backend que celui d'un service web. Stocker des enregistrements, accueillir des membres et ne montrer à chaque personne que ses propres enregistrements ne diffère en rien entre le web et une application. C'est pourquoi cet exemple parcourt lui aussi, du début à la fin, la mise en place de ce backend (les données qui stockent les enregistrements, la connexion des membres et l'autorisation de ne voir que ses propres enregistrements), et pointe séparément les deux choses qui changent parce qu'il s'agit du mobile : le déploiement et la connexion qui rapatrie le résultat de connexion dans l'application.

Ce que l'on construit

Au lieu d'un magasin de vêtements ou d'un blog, cet exemple est une application personnelle de suivi de course. On prévoit trois écrans.

É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.

Concevoir d'abord les écrans, puis les connecter

Construire cette application soi-même se fait en deux pas. On crée d'abord les écrans de l'application, puis on confie à WEEGLOO ce qui se trouve derrière ces écrans.

1. Créer les maquettes d'écran. Les écrans 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 trois écrans de « Ce que l'on construit » ci-dessus sont le résultat de ce prompt. À ce stade, il n'y a encore ni données ni connexion : ce ne sont que les écrans.

2. Connecter à WEEGLOO. Connectez l'agent à WEEGLOO (Connecter) et dites ceci.

Intègre ça avec WEEGLOO.

Sans expliquer longuement ce que vous faites, l'agent examine ces écrans et met en place ce qu'il faut derrière eux. Ce flux où l'on confie tout est le même que Intégrer en une phrase.

Ce que WEEGLOO met en place derrière les écrans

Avec la seule instruction « intègre ça », l'agent regarde les écrans et met en place ces quatre choses. C'est le backend dont WEEGLOO se charge derrière les écrans.

Une structure de données pour contenir les enregistrements de course (Content Type). Elle contient des éléments comme la distance, le temps, l'allure, l'itinéraire et la date.
La connexion Google (ServiceLogin). Elle permet aux utilisateurs de l'application de s'inscrire et de se connecter eux-mêmes.
L'autorisation « seulement ses propres enregistrements ». Elle permet à une personne connectée de lire, écrire et supprimer uniquement les enregistrements qu'elle a consignés.
La distribution de ses propres enregistrements. Elle envoie à chaque personne connectée uniquement ses propres enregistrements sous forme de liste.

Ces quatre choses sont exactement ce dont vous avez besoin quand vous construisez le même service pour le web. 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. Si vous voulez joindre aussi une image de carte d'itinéraire ou une photo, vous pouvez ajouter un fichier (Media).

Les ressources réellement créé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 dans cette application à 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 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'application via la page-relais intermédiaire décrite dans Rapatrier le résultat de connexion dans l'application.

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. Parmi les quatre choses évoquées plus haut, le point 3 (autorisation) et le point 4 (distribution) découlent en fait ensemble de cette seule règle. 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.

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 dans l'application. 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é dans l'application 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. La liste et les cartes de « Ce que l'on construit » sont ce à quoi ressemblent ces enregistrements une fois que plusieurs se sont accumulés.

Les deux choses qui diffèrent du web

Jusqu'ici, tout est identique au web. Une application mobile utilise le même backend tel quel. Seules deux choses diffèrent parce qu'il s'agit du mobile.

Déploiement : le marché d'applications est hors de WEEGLOO

Un service web peut mettre un produit fini sur internet avec le Web Hosting (Mettre un site sur internet), mais faire arriver une 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.

La fonction de connexion elle-même se rattache de la même façon que sur le web. Ce qui diffère du web, c'est la connexion qui rapatrie le résultat dans l'application une fois la connexion terminée. 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 couverte dans Auth API.

Vérifier que ce sont bien seulement ses propres enregistrements

La condition centrale de cette application, « chacun ne voit que ses propres enregistrements », tient réellement. 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 (voir Les ressources réellement créées), 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.

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.