Los componentes se escriben en XML y puede implementar el comportamiento deseado anotando sus reglas, que son instrucciones si A y B .
Por ejemplo, el requisito es que durante la inspección de una máquina, si el usuario presiona el botón "Cámara", se inicia la cámara interna del dispositivo.
La misma regla podría expresarse un poco más cerca de la implementación como:
Si estamos en el step "inspect_machine" yevent ocurre con la command "Cámara" entonces ejecutamos action "start_camera".
Estructura estructural de un componente
El marco estructural típico de un componente es el siguiente:
<workflow [ATTRIBUTES]>
<context> [...] </context> // Variables de datos, optional
<rules> [...] </rules> // Si [Expresión] entonces [acciones]; opcional
<acciones> [...] </acciones> // opcional
<pasos>
<paso [ATTRIBUTES]><estados>
<encurrículum> [...] </onresume> // opcional
<onevent> [...] </onevent> // opcional[...]
</estados>
<mapeo> [...] </mapping><
/paso>
[...]
</pasos>
</flujo de trabajo>
Antes de seguir adelante con un ejemplo, a continuación se muestra una descripción general de las etiquetas XML:
- <context>: Define las variables (datos) con las que se va a trabajar
- <rules>: Define bajo qué condición se ejecuta un conjunto de acciones. Consta de una expresión y una acción más
- <actions>: Acciones predefinidas que queremos usar en el flujo de trabajo (por ejemplo, iniciar la cámara del dispositivo).
- <paso>: Pantalla en el dispositivo que contiene los datos (contexto) y la lógica (reglas y acciones) de la pantalla y está vinculada a una plantilla de interfaz de usuario
- <estados>: Determina cuándo se comprobará una regla (por ejemplo, cuándo se produce un evento, al entrar o salir de un paso)
- <mapping>: Asigna los datos (variables de contexto) a la interfaz de usuario (que se define en un archivo diferente)
Ejemplo de un componente
Para comprender mejor la estructura de los componentes, usaremos un ejemplo de un componente de elección de imagen .
El usuario selecciona entre las dos opciones "Manzana" y "Pera". El mismo componente se utilizará para esta capacitación y se mejorará a medida que avancemos.
La siguiente interfaz de usuario muestra cómo se vería este componente mientras se ejecuta en la aplicación de vidrio inteligente Frontline Workplace.
El flujo de trabajo es:
<?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="Componente de elección" startstep="choose"
xsi:noNamespaceSchemaLocation=".. /.. /.. /configuration/workflow.xsd">
<steps>
<step id="choose" descriptor="el usuario selecciona entre dos opciones" 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>
Explicación del flujo de trabajo
1. La etiqueta de flujo de trabajo contiene un atributo startstep="choose". Esto se utiliza para seleccionar qué paso se realizará primero después de inicializar el componente.
2. <step id="choose"... se utiliza para hacer referencia a una opción que se mostrará uitemplate="ChoiceScreen"con . ChoiceScreen es un archivo que define lo que se muestra en la pantalla mientras estamos en este paso.
Como se ha explicado, el comportamiento de un componente se define mediante reglas. Una regla consta de una expresión (o condición) y de la acción que se debe realizar cuando esa condición es True. Cada regla se asigna a uno de los estados <onenter>, <onresume>, <onleave> <onevent> , o <onpause> . Las reglas solo se comprobarán cuando el componente esté en ese estado (por ejemplo, onenter, cuando el componente se inicia por primera vez).
3. El <rule id="menu_button_selection"> se asigna al <onevent> estado. Cada vez que ocurra un evento, se comprobarán todas las reglas dadas a este estado. Aquí, <expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression> comprueba si el evento contiene un comando específico. Tal evento se activaría cuando un botón con el nombre "APPLE" o "PEAR" se activa mediante un comando de voz o presionándolo en la pantalla.
4. Si una expresión de regla se evalúa como verdadera, se ejecuta el conjunto de acciones de la etiqueta de <actions> la regla. En este ejemplo, se utiliza la finish_workflow acción. Esto abandona inmediatamente el componente una vez que el usuario ha elegido una de las dos opciones, y pasa la elección que se hizo en un <output> parámetro para que podamos crear diferentes transiciones en el diagrama de flujo de trabajo basadas en esa elección.
📌Asignación
Supongamos que desea ampliar nuestro componente de elección para enviar un mensaje que contenga la elección del usuario al conector de primera línea (que a su vez podría comunicar esta información a un sistema backend). Piensa en las siguientes preguntas:
- ¿Qué paso/s tendría su componente?
- Echa un vistazo a la sección ': ¿Qué acciones necesitarías?
Ayuda y recursos
Las acciones son los bloques de construcción básicos que podemos usar. Van desde cambiar lo que ve el usuario (colores, texto, notificaciones,...) hasta controlar el flujo del programa (pasar al siguiente paso) mediante la gestión de datos y la comunicación con el conector de primera línea o dispositivos externos.
Notas de la solución
En primer lugar, se podría argumentar que la comunicación con el conector de primera línea es una funcionalidad independiente y debe tener su propio componente. Tendrías toda la razón: separar el aspecto de la comunicación en sus propios componentes haría que ambos componentes fueran más reutilizables. Por otro lado, a veces desea simplificar el flujo de procesos que se muestra en la interfaz de Frontline Creator para su cliente manteniendo varias funcionalidades juntas en un solo componente. Por ahora, supongamos que combinamos ambas funcionalidades en un solo componente.
¿Qué pasos podría tener su componente?
Anteriormente, se le dijo que los pasos son equivalentes a las pantallas. Entonces, ¿por qué tendría más de un paso si la funcionalidad adicional es solo la comunicación de backend?
La respuesta es la mantenibilidad y la reutilización. Mantenibilidad, porque al realizar cambios en el aspecto de la comunicación, solo tendrás que mirar ese paso y no leer nada del otro código. Reutilización, porque también podría enviar mensajes diferentes utilizando el mismo paso si el componente se vuelve aún más complejo.
De la misma manera, sería una buena idea hacer dos componentes separados de estas dos funcionalidades. Es una buena idea crear al menos pasos separados si los combina en un solo componente. Simplemente haga que la pantalla se vea igual o agregue un acuse de recibo de notificación de progreso desde el conector. Como tal, sugerimos tener 2 pasos aquí, por ejemplo, "elección" y "message_connector".
¿Qué acciones necesitarías probablemente?
El objetivo principal de esta pregunta es familiarizarte con el catálogo de 'Acciones'. Estos son algunos ejemplos de acciones que puede utilizar en el proceso de implementación:
- send_commit_message: Se comunica con el conector de primera línea
- ui_progress_notification: Informa al usuario que actualmente nos estamos comunicando con el backend (en caso de que esperemos el acuse de recibo)
- setvar: Se utiliza para guardar una entrada que luego se puede devolver tanto al conector como a un parámetro de salida de nuestro componente
Con esto, ya has terminado la primera lección. La siguiente lección tratará sobre los alcances y abarcará su primera tarea práctica.