Ce retour d’expériences (REX) sur les développements Power Apps est simple et direct, sans fioritures, ni considérations philosophiques :). C’est celui que j’aurais aimé trouvé quand j’ai débuté sur Power Apps.
Bien évidemment, et comme toujours, vous avez le droit d’avoir une expérience différente, voire opposée. Et c’est tant mieux !
Dernière précision : il est loin d’être exhaustif. Evidemment.
Ne pas se lancer directement dans le développement !
Créez une maquette 1:1 (« mock-up ») du résultat attendu.
Faites la maquette avec un crayon, PowerPoint, Visio, Balsamiq, etc. : peu importe. Les capacités époustouflantes de Microsoft PowerPoint m’ont convaincu depuis bien longtemps. Désolé Jeff !
La maquette doit être complète, détaillée et précise. Les enchaînements doivent être clairement définis : quand l’utilisateur clique sur ce bouton, il se passe ceci, etc.
Méfiez-vous car les changements coutent chers, une fois le développement démarré. En effet, les changements sont simples à faire mais très fastidieux. Cela dépend évidemment du nombre d’écrans concernés.
Définir les valeurs de base
Les valeurs de base sont les principales couleurs : le thème principal et le sous-thème associé (RGBA(62;96;170;1), AliceBlue, etc.)
C’est aussi la police choisie (Arial, etc.), ainsi que la taille par défaut qui sera utilisée pour la police (14pt, etc.).
Définissez aussi la taille par défaut des icônes, en prenant en compte qu’il y aura des grandes icones (64x64px, etc.) et des petites icones (30x30px, etc.).
Eventuellement, vous pouvez aussi définir la couleur des entêtes de galeries (GALLERY) pour le remplissage (FILL) et la couleur du texte (Color). Vous pouvez aussi définir la hauteur par défaut du modèle (TEMPLATE) de la galerie. Ainsi, vous aurez une présentation uniforme des contenus.
Toutes ces valeurs par défaut doivent être stockées dans des variables globales. Ça n’arrive probablement jamais chez vous, mais parfois les utilisateurs changent d’avis :).
Définir un plan de nommage
Nommez vos contrôles, variables et collections selon un plan de nommage.
En effet, il n’y a pas de fonction Rechercher / Remplacer : renommer manuellement une variable est fastidieux et long. Il est donc important d’adopter un plan de nommage dès le début.
Par exemple, les variables globales débutent par GLB, les variables locales par LOC.
Sachez aussi, que contrairement aux contrôles, les collections et les variables ne se renomment pas automatiquement.
Vous pouvez vous inspirer du document de Microsoft « PowerApps canvas app coding standards and guidelines.pdf« . Ce document propose des règles de nommage simples (extrait) :
- Bouton (button): btn
- Etiquette (label): lbl
- Entrée de texte (text input): txt
- Collection (collection): col
- Galerie (gallery): gal
- Zone de liste déroulante (combo box): cmb
- Formes (rectangle, cercle, …): shp
- Listes déroulantes (drop down): drp
- Date (date): dte
- Icône (icon): ico
- Image (image): img
- Minuteur (timer): tim
- Texte html (html text): htm
- etc.
Dans la liste ci-dessus, la première valeur est le nom du contrôle en français (et en anglais entre parenthèses), suivi du suffixe proposé. Le suffixe se met devant le nom du contrôle.
Définir ses propres conventions de nommage
Evidemment, vous pouvez définir votre propre convention. Dans tous les cas, il est extrêmement important, et utile, de rester consistant sur tous les écrans. Par exemple, le contrôle qui affiche le message doit porter un nom similaire sur tous les écrans. Rappelez-vous que Power Apps n’autorise pas d’avoir deux contrôles avec deux noms identiques dans une application.
Dans mes applications, tous les contrôles sont préfixés par un code que j’attribue à chaque écran: IDENS01, IDENS02, etc.
Exemple de nommage d’un contrôle de type icône :
ico10aIDENS01
Le nombre (10) et la lettre (a) n’ont pas de sens précis. En effet, contrairement à tout ce vous pouvez lire sur le web, et y compris dans le document PDF de Microsoft, ce n’est pas une bonne idée de donner un nom significatif aux contrôles dans Power Apps.
Cela ne sert pas à grand ‘choses, c’est une source de confusion, voire d’erreur quand le nom est trop long (dans Power Automate). Source : https://powerusers.microsoft.com/t5/General-Power-Automate/The-datetime-string-must-match-ISO-8601-format/m-p/603496#M52598.
Inversement, avoir des noms standardisés, permet de gagner beaucoup de temps dans la zone de recherche du volet arborescence. Notamment, cela permet de trouver tous les contrôles identiques sur tous les écrans.
C’est utile quand vous avez 20 ou 30 écrans Power Apps à modifier.
Écrire les règles de gestion et les événements de l’application
Écrire noir sur blanc les règles de gestion et les événements dans un document.
Exemples de règles de gestion et d’événements:
- Si la date est changée, la valeur résiduelle est recalculée.
- La saisie du champ Libellé est obligatoire pour enregistrer.
- Le montant à rembourser est égal au montant total moins la somme à déduire et moins les frais, etc.
Vérifier les valeurs et vos raisonnements
Développer, c’est faire des hypothèses.
Aussi, ajoutez des étiquettes temporaires pour vérifier la validité des hypothèses et contrôler les résultats intermédiaires.
Puis, tracez le déroulement d’une application (si autorisé), notamment avec la fonction Patch().
En complément, lisez aussi En cas de problèmes avec PowerApps.
Laisser un commentaire