admin- Posted on
La mise à jour d’une application peut parfois être un petit casse-tête, selon que vous êtes seul ou plusieurs à travailler sur l’application, et que celle-ci est à l’état prototype ou déployé.
Fort heureusement, il est possible de rendre tout cela facile ! Le tout est de comprendre les subtilités de chaque méthode.
Passons en revue les différents cas possibles.
Niveau 1 : le bouton “Save”
L’incontournable, évidemment.
Vous vous contentez de cliquer sur le bouton bleu “Save” qui est en haut à droite de l’éditeur, alias votre meilleur ami :
Et ça rendra effective les modifications opérées jusque là.
Si l’application est déjà ouverte sur votre téléphone, il vous suffira de la rafraîchir pour avoir le dernier état enregistré. “Easy-peasy, lemon-squeazy”, comme disent les anglophones !
Le saviez-vous ?
AppSheet ne permettant pas (encore) la co-édition comme on le ferait sur un document bureautique comme Sheets ou Docs, si un autre utilisateur est aussi en train de travailler sur l’éditeur, il verra ce sympathique message s’afficher :
Rien de grave : en rafraîchissant la page du navigateur, on retrouve la nouvelle version.
En fait, chaque fois qu’un utilisateur enregistre une mise à jour, l’état de l’application est stocké sur les serveurs d’AppSheet, et c’est le dernier qui s’ouvre pour vous. C’est ce stockage qui permet de restaurer une version antérieure (dans certaines limites dépendant de votre licence).
Niveau 2: Utiliser un lanceur d’application
Cette option est à utiliser dans le cas où vous voulez travailler sur des versions successives d’une application et ne souhaitez pas que les primo-testeurs voient l’application évoluer au gré des modifications que vous faites. En gros, vous souhaitez ne leur présenter que les versions “approuvées par moi-même”.
Un exemple de lanceur existe sur la bibliothèque des Sample Apps d’AppSheet, sur ce lien :
App Démo : lanceur d’applications
Le principe est simple : l’utilisateur voir un nom convivial (“Ma superbe application de folie”), et en arrière-plan, on indiquera l’identifiant vers lequel chaque item pointera. Ainsi, l’utilisateur sera dirigé vers la version souhaitée.
C’est possible grâce à l’identifiant unique d’application, le GUID (“Global Unique Identification Number”, Numéro d’Identification Global Unique) que l’on retrouve dans la dernière partie de l’URL fourni pour le partage de l’application :
Je vous invite à copier l’application démo pour comprendre immédiatement de quoi il s’agit 😉
Niveau 3 : la mise à niveau de l’application
Dans ce cas de figure, qui s’applique aux applications à l’état Déployé, on va pouvoir travailler sur une copie de l’application d’origine, puis faire “ingérer” l’état de cette copie dans la version en production.
Voici les explications, pas à pas.
Faire une copie
Vous savez faire ça : dans le panneau “Manage” (Gérer), onglet “Author” (Auteur), on clique sur le bouton “Copy App” (Copier l’appli).
Modifier la copie, puis déployer celle-ci
En principe, vous savez déjà faire ça si vous êtes sur cet article 😉
Petit rappel : pour le déploiement, c’est dans le panneau “Manage” que ça se passe, avec le bouton “Run Deployment check” (Lancer la vérification pour le déploiement)
Si la vérification est validée, vous aurez ce bouton proposé : “Passer l’appli à l’état Déployé”
Le tour de magie
On va renseigner dans le Panneau “Manage” (Gérer) de l’application d’origine, c’est-à-dire celle que l’on souhaite faire évoluer, le nom de l’application copiée qui est l’état vers lequel on souhaite aller (ça va, vous suivez toujours ?).
Une fois fait, on clique sur le bouton “Upgrade app” (Mettre à niveau l’appli) qui est en-dessous.
Et là…Tadaaaam ! Le tour est joué !
Notez cependant, que la structure évolue intégralement : les utilisateurs travailleront désormais sur la base de données de l’application bis. Il sera bon de faire pointer cette copie vers la base actuelle avant mise en œuvre, ou prévoir une solution de migration des données de l’ancienne base vers la nouvelle base.
Niveau 4 : je veux revenir en arrière
Il est aussi possible de rétrograder une application.
Nous avons évoqué l’archivage des états successifs de l’application sur les serveurs d’AppSheet. Ces versions se retrouvent ici, dans le panneau “Manage” (Gérer), onglet “Versions”, section “Version History” (Historique des versions) :
En cliquant sur le bouton “Get version history” (Obtenir l’historique des versions), on obtient un inventaire détaillé du passif de l’application : qui a sauvé, quand, et le détail des modifications apportées chaque fois. Pour ce dernier point, il faudra cliquer sur “Expand” (Développer)
Après avoir cliqué sur “View” (Voir), il vous faudra cliquer sur “Restore (make this version current)” (Restaurer – Rendre cette version actuelle)
En conclusion
Le bouton Save reste bien sûr votre meilleur allié, et une gestion mesurée des mises à jour, avec les possibilités décrites, pourra permettre un développement dans de bonnes conditions.
Notez que s’il s’agit de faire des modifications d’ergonomie, le bouton Save sera la meilleure option. Pour une modification de structure en revanche (Vues ou colonnes) il sera de bon ton de prévenir vos utilisateurs par un message. Nous y reviendrons !
Vous avez un projet de réalisation d’application ou de formation sur AppSheet ? C’est par ici que ça se passe !
