Les composants sont écrits en XML et vous pouvez implémenter le comportement souhaité en écrivant ses règles, qui sont des instructions if A puis B .

Par exemple, lors de l’inspection d’une machine, si l’utilisateur appuie sur le bouton « Caméra », la caméra interne de l’appareil démarre.

La même règle pourrait être exprimée un peu plus près de la mise en œuvre comme suit :

Si nous sommes dans le  step« inspect_machine » et qu’unevent  se produit avec la command « Caméra », alors exécutez action « start_camera ».

Cadre structurel d’un composant

L’ossature structurelle typique d’un composant est la suivante :

<workflow [ATTRIBUTS]>
    <context> [...] </context> // Variables de données, <règles facultatives
    > [...] </rules> // Si [Expression] alors [actions] ; optional
    <actions> [...] </actions> // optional
    <steps> 
        <step [ATTRIBUTS]>
            <states>
                <onresume> [...] </onresume> // optional
                <onevent> [...] </onevent> // facultatif
                [...]
            </states>
            <mapping> [...] </mapping>
        </step>
        [...] 
    </steps>
</workflow>

Avant d’aller plus loin avec un exemple, vous trouverez ci-dessous un aperçu des balises XML :

  • <context> : définit les variables (données) avec lesquelles travailler
  • <règles> : définit la condition dans laquelle un ensemble d’actions est exécuté. Se compose d’une expression et d’une action supplémentaire
  • <actions> : actions prédéfinies que nous voulons utiliser dans le flux de travail (par exemple, démarrer la caméra de l’appareil).
  • <étape> : Écran de l’appareil qui contient les données (contexte) et la logique (règles et actions) de l’écran et qui 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, à l’entrée ou à la sortie d’une étape)
  • <mapping> : mappe les données (variables de contexte) à l’interface utilisateur (qui est définie dans un fichier différent)

Exemple d’un composant

Pour mieux comprendre la structure des composants, nous allons utiliser un exemple de composant Image Choice .

L’utilisateur choisit entre les deux options « Apple » et « Pear ». Le même volet sera utilisé pour cette formation et sera amélioré au fur et à mesure que nous avancerons.

Télécharger le composant

L’interface utilisateur ci-dessous montre comment ce composant s’affiche lors de l’exécution sur l’application Frontline Workplace Smart Glass.

Le flux de travail est le suivant :

< ?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="Composant de choix » startstep="choose"
          xsi :noNamespaceSchemaLocation= ».. /.. /.. /configuration/workflow.xsd">

    <steps>
        <step id="choose » descriptor="l’utilisateur choisit entre deux 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>

Explication du flux de travail

1. La balise de workflow contient un attribut startstep="choose ». Ceci est utilisé pour sélectionner l’étape qui sera effectuée en premier après l’initialisation du composant.

2. <step id="choose"... est utilisé pour faire référence à un choix qui sera affiché ultérieurement à l’aide de uitemplate="ChoiceScreen". ChoiceScreen est un fichier qui définit ce qui est affiché à l’écran pendant que nous sommes dans 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 d’une condition) et de l’action à effectuer lorsque cette condition est True. 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 est dans cet état (par exemple, onenter - lorsque le composant est démarré pour la première fois).

3. Le <rule id="menu_button_selection"> est attribué à 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 commande vocale, soit en appuyant dessus sur l’écran.

4. Si une expression de règle a la valeur true, l’ensemble des actions de la balise de <actions> la règle est exécuté. Dans cet exemple, l’action finish_workflow est utilisée. Cela quitte immédiatement le composant une fois que l’utilisateur a choisi l’une des deux options, et transmet quel choix a été fait dans un <output> paramètre afin que nous puissions créer différentes transitions dans le diagramme de flux de travail en fonction de ce choix.

📌Mission

Supposons que vous souhaitiez étendre notre composant de choix pour renvoyer un message contenant le choix de l’utilisateur au connecteur de première ligne (qui pourrait à son tour communiquer cette information à un système principal). Posez-vous les questions suivantes :

  • Quelle(s) étape(s) votre composant aurait-il ?
  • Jetez un coup d’œil à la question ' : De quelles actions auriez-vous probablement besoin ?

Aide et ressources

Les actions sont les éléments de base que nous pouvons utiliser. Ils vont de la modification de ce que l’utilisateur voit (couleurs, texte, notifications,...) au contrôle du flux du programme (transition vers l’étape suivante) en gérant les données et en communiquant avec le connecteur de première ligne ou des périphériques externes.

Solution Notes

Tout d’abord, vous pourriez faire valoir que la communication avec le connecteur de première ligne est une fonctionnalité distincte et doit avoir son propre composant. Vous avez tout à fait raison : séparer l’aspect communication en ses propres composantes rendrait les deux composants plus réutilisables. D’autre part, vous souhaitez parfois simplifier le flux de processus affiché dans l’interface Frontline Creator pour votre client en regroupant plusieurs fonctionnalités dans un seul composant. Pour l’instant, supposons que nous combinions les deux fonctionnalités en un seul composant.

Quelles sont les étapes à suivre pour votre composant ?

Auparavant, on vous disait que les étapes étaient équivalentes à des écrans. Alors, pourquoi auriez-vous plus d’une étape si la fonctionnalité supplémentaire n’est qu’une communication backend ?

La réponse est la maintenabilité et la réutilisabilité. Maintenabilité, car lorsque vous apportez des modifications à l’aspect communication, vous n’aurez qu’à regarder cette étape et ne lire aucun autre code. Réutilisation, car vous pouvez également envoyer des messages différents en utilisant la même étape si le composant devient encore plus complexe.

De la même manière, il serait judicieux de faire deux composants distincts de ces deux fonctionnalités. C’est une bonne idée de créer au moins des étapes distinctes si vous les combinez en un seul composant. Il suffit de faire en sorte que l’écran ait la même apparence ou d’ajouter un accusé de réception de notification de progression à partir du connecteur. En tant que tel, nous suggérons d’avoir 2 étapes ici, par exemple, « choix » et « message_connector ».

De quelles actions auriez-vous probablement besoin ?

L’objectif principal de cette question est de vous familiariser avec le catalogue 'Actions'. Voici des exemples d’actions que vous pouvez utiliser dans le processus d’implémentation :

  • send_commit_message : Communique avec le connecteur de première ligne
  • ui_progress_notification : Informe l’utilisateur que nous sommes en train de communiquer avec le backend (au cas où nous attendrions un accusé de réception)
  • setvar : Permet d’enregistrer une entrée qui peut ensuite être renvoyée à la fois au connecteur et à un paramètre de sortie de notre composant

Avec cela, vous avez maintenant terminé la première leçon. La prochaine leçon portera sur les champs d’application et englobera votre premier devoir pratique.