Os componentes são escritos em XML e você pode implementar o comportamento desejado anotando suas regras, que são instruções Se A e B .
Por exemplo, o requisito é que, ao inspecionar uma máquina, se o usuário pressionar o botão "Câmera", a câmera interna do dispositivo será iniciada.
A mesma regra poderia ser expressa um pouco mais próxima da implementação como:
Se estivermos no step "inspect_machine" e ocorrerevent um com a command "Câmera", então execute action "start_camera".
Quadro estrutural de um componente
A estrutura estrutural típica de um componente é a seguinte:
<fluxo de trabalho [ATRIBUTOS]>
<contexto> [...] </contexto> // Variáveis de dados, opcional
<regras> [...] </regras> // Se [Expressão] então [ações]; opcional
<ações> [...] </ações> // opcional
<passos>
<passo [ATRIBUTOS]>
<estados>
<onresume> [...] </onresume> // opcional
<onevent> [...] </onevent> // opcional
[...]
</estados>
<mapeamento> [...] </mapeamento>
</passo>
[...]
</passos>
</fluxo de trabalho>
Antes de avançar com um exemplo, abaixo está uma visão geral das marcas XML:
- <contexto>: define variáveis (dados) com as quais trabalhar
- <regras>: define sob qual condição um conjunto de ações é executado. Consiste em uma expressão e mais uma ação
- <ações>: ações predefinidas que queremos usar no fluxo de trabalho (por exemplo, iniciar a câmera do dispositivo).
- <passo>: tela no dispositivo que contém os dados (contexto) e a lógica (regras e ações) da tela e está vinculada a um modelo de interface do usuário
- <estados>: determina quando uma regra será verificada (por exemplo, quando um evento ocorre, ao entrar ou sair de uma etapa)
- <mapeamento>: mapeia os dados (variáveis de contexto) para a interface do usuário (que é definida em um arquivo diferente)
Exemplo de um componente
Para entender melhor a estrutura dos componentes, usaremos um exemplo de um componente de Escolha de Imagem .
O usuário seleciona entre as duas opções "Apple" e "Pear". O mesmo componente será usado para este treinamento e será aprimorado à medida que avançamos.
A interface do usuário abaixo exibe como esse componente apareceria durante a execução no aplicativo de vidro inteligente Frontline Workplace.
O fluxo de trabalho é:
<?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="o usuário seleciona entre duas opções" 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>
Explicação do fluxo de trabalho
1. A tag de fluxo de trabalho contém um atributo startstep="choose". Isso é usado para selecionar qual etapa será executada primeiro após a inicialização do componente.
2. <step id="choose"... é usado para se referir a uma escolha que será exibida usando uitemplate="ChoiceScreen". ChoiceScreen é um arquivo que define o que é exibido na tela enquanto estamos nesta etapa.
Como explicado, o comportamento de um componente é definido usando regras. Uma regra consiste em uma expressão (ou condição) e qual ação tomar quando essa condição for True. Cada regra é atribuída a um dos estados <onenter>, <onresume>, <onleave> <onevent> , ou <onpause> . As regras só serão verificadas quando o componente estiver nesse estado (por exemplo, onenter - quando o componente for iniciado pela primeira vez).
3. O <rule id="menu_button_selection"> é atribuído ao <onevent> Estado. Sempre que ocorrer um evento, todas as regras dadas a esse estado serão verificadas. Aqui, <expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression> verifica se o evento contém um comando específico. Tal evento seria ativado quando um botão com o nome "APPLE" ou "PEAR" é acionado por comando de voz ou pressionando-o na tela.
4. Se uma expressão de regra for avaliada como verdadeira, o conjunto de ações na tag da <actions> regra será executado. Neste exemplo, a finish_workflow ação é usada. Isso sai imediatamente do componente depois que o usuário escolhe uma das duas opções e passa qual escolha foi feita em um <output> parâmetro para que possamos criar transições diferentes no diagrama de fluxo de trabalho com base nessa escolha.
📌Designação
Suponha que você queira estender nosso componente de escolha para enviar uma mensagem contendo a escolha do usuário de volta para o Frontline Connector (que por sua vez poderia comunicar essas informações a um sistema de back-end). Pense nas seguintes perguntas:
- Qual(is) etapa(s) seu componente teria?
- Dê uma olhada no ': Quais ações você provavelmente precisaria?
Ajuda e Recursos
As ações são os blocos de construção básicos que podemos usar. Eles vão desde alterar o que o usuário vê (cores, texto, notificações,...) até controlar o fluxo do programa (transição para a próxima etapa) gerenciando dados e se comunicando com o Frontline Connector ou dispositivos externos.
Notas da solução
Em primeiro lugar, você pode argumentar que a comunicação com o Frontline Connector é uma funcionalidade separada e deve ter seu próprio componente. Você estaria absolutamente certo: separar o aspecto de comunicação em seus próprios componentes tornaria ambos os componentes mais reutilizáveis. Por outro lado, às vezes você deseja simplificar o fluxo de processo mostrado na Frontline Creator Interface para seu cliente, mantendo várias funcionalidades juntas em um único componente. Por enquanto, vamos supor que combinamos as duas funcionalidades em um componente.
Quais etapas seu componente poderia ter?
Anteriormente, você foi informado de que as etapas são equivalentes a telas. Então, por que você teria mais de uma etapa se a funcionalidade adicional é apenas comunicação de back-end?
A resposta é manutenibilidade e reutilização. Manutenção, pois ao fazer alterações no aspecto de comunicação, você só terá que olhar para essa etapa e não ler nenhum dos outros códigos. Reutilização, porque você também pode enviar mensagens diferentes usando a mesma etapa se o componente se tornar ainda mais complexo.
Da mesma forma, seria uma boa ideia fazer dois componentes separados dessas duas funcionalidades. É uma boa ideia pelo menos criar etapas separadas se você combiná-las em um componente. Basta fazer a tela parecer a mesma ou adicionar uma confirmação de notificação de progresso do conector. Como tal, sugerimos ter 2 passos aqui, por exemplo, "escolha" e "message_connector".
Quais ações você provavelmente precisaria?
O principal objetivo desta pergunta é familiarizá-lo com o catálogo 'Ações'. Aqui estão exemplos de ações que você pode usar no processo de implementação:
- send_commit_message: Comunica-se com o Frontline Connector
- ui_progress_notification: Informa ao usuário que estamos nos comunicando com o back-end (caso aguardemos a confirmação)
- setvar: Usado para salvar uma entrada que pode ser retornada posteriormente ao conector e a um parâmetro de saída do nosso componente
Com isso, você já terminou a primeira lição. A próxima lição será sobre escopos e abrangerá sua primeira tarefa prática.