Dans les leçons suivantes, nous aborderons les différents éléments d'un composant. Vous trouverez ici une brève introduction à la structure générale d'un flux de travail.
Un composant est un type de flux de travail qui peut se composer de plusieurs écrans/étapes. Tout flux de travail qui peut être modélisé à l'aide de divers composants et étapes de l'interface utilisateur peut également être créé dans un seul composant. Il est souvent préférable de créer des composants qui sont des modules réutilisables pour remplir une fonction spécifique, par exemple, un composant qui vous permet uniquement de choisir une date. De cette façon, vous, et même les non-développeurs, serez en mesure d'utiliser vos composants pour modéliser différents processus business.
Les composants sont écrits en XML. Vous pouvez mettre en œuvre le comportement souhaité en écrivant ses règles, qui sont des instructions ifA then B.
Par exemple, pour l'exigence suivante : Si l'utilisateur inspecte une machine et appuie sur le bouton "Caméra", la caméra interne de l'appareil se met en marche.
La même règle pourrait être exprimée d'une manière un peu plus proche de la mise en œuvre comme :
Si nous sommes dans l'étape "inspecter_machine" et qu'un événement se produit avec la commande "Caméra", alors l'action "démarrer_caméra" est exécutée.
Cadre structurel d'un composant
Le cadre structurel typique d'un composant est le suivant :
<workflow [ATTRIBUTES]>
<context> [...] </context> // Data variables, optional
<rules> [...] </rules> // If [Expression] then [actions]; optional
<actions> [...] </actions> // optional
<steps>
<step [ATTRIBUTES]>
<states>
<onresume> [...] </onresume> // optional
<onevent> [...] </onevent> // optional
[...]
</states>
<mapping> [...] </mapping>
</step>
[...]
</steps>
</workflow>
Avant de poursuivre avec un exemple, voici un aperçu des balises XML :
<content> Définit les variables (données) avec lesquelles travailler.
<règles> Se compose d'une expression et d'une action supplémentaire. Elle définit sous quelle condition un ensemble d'actions est exécuté.
<actions> Actions prédéfinies que nous voulons utiliser dans le flux de travail (par exemple : démarrer la caméra du dispositif, changer la valeur d'un contexte en x, ...).
<step> Écran sur l'appareil : il contient les données (contexte) et la logique (règles et actions) de l'écran et est lié à un modèle d'interface utilisateur.
<states> Détermine quand une règle sera vérifiée (par exemple : lorsqu'un événement se produit, lors de l'entrée ou de la sortie d'une étape).
<mapping> Fait correspondre les données (variables contextuelles) à l'interface utilisateur (qui est définie dans un autre fichier que nous examinerons plus tard).
Exemple d'un composant
Afin de mieux comprendre la structure des composants, nous allons utiliser un exemple de composant très basique.
L'utilisateur choisit entre les deux options "pomme" et "poire". Le même composant sera utilisé pour cette formation et sera amélioré au fur et à mesure.
La capture d'écran ci-dessous est l'écran visible sur l'appareil.
Le flux de travail est :
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<workflow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" wfd_version="1.0" reporting="false"
id="choice" name="choice" descriptor="Choice component" startstep="choose"
xsi:noNamespaceSchemaLocation="../../../configuration/workflow.xsd">
<steps>
<step id="choose" descriptor="the user selects between two options" uitemplate="ChoiceScreen">
<states>
<onevent>
<rule id="menu_button_selection">
<expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression>
<actions>
<finish_workflow id="finish_workflow">
<output>
<param name="selected_button" type="string">#{event:command}</param>
</output>
</finish_workflow>
</actions>
</rule>
</onevent>
</states>
</step>
</steps>
</workflow>
Télécharger le composant
Explication du flux de travail
1. La balise workflow contient un attribut startstep = "choose". Il permet de sélectionner l'étape qui sera exécutée en premier après l'initialisation du composant.
2. <step id="choose"... est utilisé pour faire référence à un choix qui sera ensuite affiché en utilisant uitemplate="ChoiceScreen". ChoiceScreen est un fichier qui définit ce qui est affiché à l'écran pendant que nous sommes sur cette étape.
Comme expliqué, le comportement d'un composant est défini à l'aide de règles. Une règle se compose d'une expression (ou condition) et de l'action à entreprendre lorsque cette condition est vraie. Chaque règle est affectée à l'un des états <onenter>, <onresume>, <onleave>, <onevent> ou <onpause>. Les règles ne seront vérifiées que lorsque le composant se trouve dans cet état (par exemple onenter, lorsque le composant est démarré pour la première fois).
3. La <règle id="menu_button_selection"> est affectée à l'état <onevent>. Chaque fois qu'un événement se produit, toutes les règles données à cet état seront vérifiées. Ici, <expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression> vérifie si l'événement contient une commande spécifique. Un tel événement serait activé, lorsqu'un bouton portant le nom "APPLE" ou "PEAR" est déclenché soit par une commande vocale, soit en appuyant dessus sur l'écran.
4. Si une expression de règle est évaluée à true, l'ensemble des actions de la balise <actions> de la règle est exécuté. Dans cet exemple, l'action finish_workflow est utilisée. Celle-ci quitte immédiatement le composant une fois que l'utilisateur a choisi l'une des deux options, et transmet le choix effectué dans un paramètre <output> afin que nous puissions créer différentes transitions dans le diagramme de flux de travail en fonction de ce choix.
Affectation
Supposons que vous souhaitiez étendre notre composant de choix pour renvoyer un message contenant le choix de l'utilisateur au connecteur Frontline (qui pourrait à son tour communiquer ces informations à un système dorsal). Réfléchissez aux questions suivantes :
- Quelle(s) étape(s) aurait votre composant ?
- Jetez un coup d'œil au catalogue d'actions : De quelles actions auriez-vous probablement besoin ?
Aide et ressources
Les actions sont les blocs de construction de base que nous pouvons utiliser. Elles vont de la modification de ce que l'utilisateur voit (couleurs, texte, notifications,...) au contrôle du déroulement du programme (passage à l'étape suivante) en passant par la gestion des données et la communication avec le connecteur Frontline ou des dispositifs externes.
Notes de solution
Tout d'abord, vous pourriez faire valoir que la communication avec le connecteur Frontline est une fonctionnalité distincte et devrait avoir son propre composant. Vous auriez tout à fait raison : séparer l'aspect communication dans son propre composant rendrait les deux composants plus réutilisables. D'un autre côté, il arrive que vous souhaitiez simplifier le flux de processus présenté dans l'interface du créateur Frontline pour votre client en conservant plusieurs fonctionnalités dans un seul composant. Pour l'instant, supposons que nous combinions les deux fonctionnalités dans un seul composant.
Quelles étapes votre composante pourrait-elle franchir ?
Auparavant, il vous a été dit que les étapes sont fondamentalement équivalentes aux écrans. Alors pourquoi avoir plus d'une étape si la fonctionnalité supplémentaire n'est qu'une communication en arrière-plan ?
La réponse est la maintenabilité et la réutilisabilité. La maintenabilité, parce que lorsque vous apportez des modifications à l'aspect de la communication, vous n'aurez qu'à regarder cette étape et à ne pas lire le reste du code. Réutilisabilité, car vous pouvez également envoyer différents messages en utilisant la même étape si le composant devient encore plus complexe.
De même, ce serait une bonne idée de faire deux composants distincts de ces deux fonctionnalités. Il est bon de créer au moins des étapes distinctes si vous les combinez dans un seul composant. Il suffit de donner le même aspect à l'écran ou d'ajouter un accusé de réception de la notification de progression à partir du connecteur. En tant que tel, nous suggérons d'avoir 2 étapes ici, par exemple "choix" et "connecteur_message".
De quelles actions auriez-vous probablement besoin ?
L'objectif principal de cette question est de vous familiariser avec le catalogue "Action". Voici des exemples d'actions que vous pourriez utiliser dans le cadre du processus de mise en œuvre :
- send_commit_message: Communique avec le connecteur Frontline
- step_transition: Passage de l'étape "choix" à "message_connector" (si vous avez 2 étapes)
- ui_progress_notification: Informe l'utilisateur que nous sommes en train de communiquer avec le backend (dans le cas où nous attendons un accusé de réception).
- setvar: Utilisé pour sauvegarder une entrée qui peut ensuite être renvoyée à la fois au connecteur et à un paramètre de sortie de notre composant.
Vous avez ainsi terminé la première leçon. La prochaine leçon portera sur les lunettes de visée et comprendra votre premier travail pratique.
