Os componentes são escritos em XML e você pode implementar o comportamento desejado escrevendo suas regras, que são instruçõesifA then B
.
Por exemplo, o requisito é que, ao inspecionar uma máquina, se o usuário pressionar o botão "Camera", 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 na etapa
"inspect_machine" e ocorrer um evento
com o comando
"Camera", execute a ação
"start_camera".
Estrutura de um componente
O quadro estrutural típico de um componente é o seguinte:
<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>
Antes de prosseguir com um exemplo, veja abaixo uma visão geral das tags XML:
- <context>: Define variáveis (dados) com as quais trabalhar
- <rules>: Define sob qual condição um conjunto de ações é executado. Consiste em uma expressão e mais uma ação
- <actions>: Ações predefinidas que queremos usar no fluxo de trabalho (por exemplo, iniciar a câmera do dispositivo).
- <step>: 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 ocorre um evento, ao entrar ou sair de uma etapa)
- <mapping>: 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 o exemplo de um componente Image Choice.
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çarmos.
Componente de download
A interface do usuário abaixo mostra 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="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>
Explicação do fluxo de trabalho
1. A tag de fluxo de trabalho contém um atributo startstep="choose". Ele é 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 opção que será exibida posteriormente usando uitemplate="ChoiceScreen".
ChoiceScreen é um arquivo que define o que será exibido na tela enquanto estivermos nessa etapa.
Conforme explicado, o comportamento de um componente é definido por meio de regras. Uma regra consiste em uma expressão (ou condição) e em uma ação a ser executada quando essa condição for verdadeira. 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. A <rule id="menu_button_selection">
é atribuída ao estado <onevent>
. Sempre que ocorrer um evento, todas as regras atribuídas a esse estado serão verificadas. Aqui, <expressão>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expressão>
verifica se o evento contém um comando específico. Esse evento seria ativado quando um botão com o nome "APPLE" ou "PEAR" fosse acionado por comando de voz ou pressionado na tela.
4. Se uma expressão de regra for avaliada como verdadeira, o conjunto de ações na tag <actions>
da regra será executado. Neste exemplo, é usada a ação finish_workflow
. Isso deixa o componente imediatamente depois que o usuário escolhe uma das duas opções e transmite a escolha feita em um parâmetro <output>
para que possamos criar diferentes transições no diagrama de fluxo de trabalho com base nessa escolha.
📌Atribuição
Suponha que você queira estender nosso componente de escolha para enviar uma mensagem contendo a escolha do usuário de volta ao conector Frontline (que, por sua vez, poderia comunicar essas informações a um sistema de backend). Reflita sobre as seguintes questões:
- Quais etapas o seu componente teria?
- Dê uma olhada no catálogo "Actions" (Ações): De quais ações você provavelmente precisaria?
Ajuda e recursos
As ações são os blocos de construção básicos que podemos usar. Elas vão desde a alteração do que o usuário vê (cores, texto, notificações...) até o controle do fluxo do programa (transição para a próxima etapa) por meio do gerenciamento de dados e da comunicação com o conector Frontline ou com dispositivos externos.
Notas de solução
Em primeiro lugar, você pode argumentar que a comunicação com o conector Frontline é uma funcionalidade separada e deve ter seu próprio componente. Você estaria absolutamente certo: separar o aspecto da comunicação em seus próprios componentes tornaria ambos os componentes mais reutilizáveis. Por outro lado, às vezes você deseja simplificar o fluxo do processo mostrado na Frontline Creator Interface para o seu cliente, mantendo várias funcionalidades juntas em um único componente. Por enquanto, vamos supor que combinamos as duas funcionalidades em um único componente.
Quais etapas seu componente poderia ter?
Anteriormente, você foi informado de que as etapas são equivalentes às telas. Então, por que você teria mais de uma etapa se a funcionalidade adicional é apenas uma comunicação de backend?
A resposta é a capacidade de manutenção e reutilização. Manutenibilidade, porque ao fazer alterações no aspecto da comunicação, você só precisará olhar para essa etapa e não ler nenhum outro código. 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 criar dois componentes separados para essas duas funcionalidades. É uma boa ideia pelo menos criar etapas separadas se você as combinar em um único componente. Basta fazer com que a tela tenha a mesma aparência ou adicionar uma confirmação de notificação de progresso do Conector. Por isso, sugerimos ter duas etapas aqui, por exemplo, "choice" e "message_connector".
De quais ações você provavelmente precisaria?
O principal objetivo desta pergunta é fazer com que você se familiarize 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 conector Frontline
- step_transition: Mude da etapa "choice" para "message_connector" (se você tiver 2 etapas)
- ui_progress_notification: Informa ao usuário que estamos nos comunicando com o back-end (caso esperemos pela confirmação)
- setvar: Usado para salvar uma entrada que pode ser retornada posteriormente para o conector e para um parâmetro de saída de nosso componente
Com isso, você terminou a primeira lição. A próxima lição será sobre escopos e abrangerá sua primeira tarefa prática.