Nas lições seguintes, discutiremos os diferentes elementos de um componente. Aqui você encontrará uma breve introdução sobre a estrutura geral de um fluxo de trabalho.
Um componente é um tipo de fluxo de trabalho que pode consistir de múltiplas telas/etapas. Qualquer fluxo de trabalho que possa ser modelado usando vários componentes e passos de IU, também pode ser criado em um único componente. Muitas vezes é preferível criar componentes que são módulos reutilizáveis para cumprir uma função específica, por exemplo, um componente que só permite escolher uma data. Dessa forma, você e até mesmo os não desenvolvedores poderão usar seus componentes para modelar diferentes processos business.
Os componentes são escritos em XML. Você pode implementar o comportamento desejado anotando suas regras, que são se as declaraçõesA e B.
Por exemplo, para o seguinte requisito: Se o usuário estiver inspecionando uma máquina e pressionar o botão "Câmera", então a câmera interna do dispositivo é iniciada.
A mesma regra poderia ser expressa um pouco mais perto da implementação:
Se estivermos no passo "inspect_machine" e um evento ocorrer com o comando "Camera", então execute a ação "start_camera".
Estrutura de um componente
A moldura estrutural típica de um componente é a 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 seguir adiante com um exemplo, abaixo está uma visão geral das tags XML:
<content> Define variáveis (dados) com as quais se deve trabalhar.
<regras> Consiste em uma expressão e mais uma ação. Define sob que condição um conjunto de ações é executado.
<ações> Ações predefinidas que queremos utilizar no fluxo de trabalho (por exemplo: iniciar a câmera do dispositivo, mudar o valor de um contexto para x, ...).
<step> Tela no dispositivo: contém os dados (contexto) e a lógica (regras e ações) da tela e está ligada 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 um degrau).
<mapping> Mapeia os dados (variáveis de contexto) para a interface do usuário (que é definida em um arquivo diferente que analisaremos mais adiante).
Exemplo de um componente
A fim de melhor compreender a estrutura dos componentes, usaremos um exemplo de um componente muito básico.
O usuário seleciona entre as duas opções "Maçã" e "Pêra". O mesmo componente será usado para este treinamento e será melhorado à medida que avançamos.
A captura de tela abaixo é a tela visível no dispositivo.
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>
Componente para download
Explicação do fluxo de trabalho
1. A etiqueta de fluxo de trabalho contém um passo inicial de atributo = "escolher". Isto é 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 posteriormente 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 por meio de regras. Uma regra consiste em uma expressão (ou condição) e qual ação a ser tomada quando essa condição é Verdadeira. Cada regra é atribuída a um dos estados <entrar>, <resumir>, <soltar>, <emprego> ou <emprego>. 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 <regra id="menu_button_selection"> é atribuída ao <evento> estado. Sempre que um evento ocorrer, todas as regras dadas a este estado serão verificadas. Aqui, <expressão>#{evento:comando} == 'APPLE' || #{evento:comando} == 'PEAR'</expressão> 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 na tela.
4. Se uma expressão de regra for avaliada como verdadeira, o conjunto de ações na <ações> tag da regra é executado. Neste exemplo, é utilizada a ação fim_fluxo de trabalho. Isto deixa imediatamente o componente uma vez que o usuário tenha escolhido uma das duas opções, e passa a qual escolha foi feita em um parâmetro <output> para que possamos criar transições diferentes 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 estas informações a um sistema back end). Pense sobre as seguintes perguntas:
- Que etapa(s) seu(s) componente(s) teria?
- Dê uma olhada no catálogo de ações: De quais ações você provavelmente precisaria?
Ajuda e Recursos
As ações são os blocos básicos de construção que podemos utilizar. Elas vão desde a mudança do que o usuário vê (cores, texto, notificações,...) até o controle do fluxo do programa (transição para o próximo passo) através do gerenciamento de dados e comunicação com o Conector Frontline ou dispositivos externos.
Notas de solução
Em primeiro lugar, pode-se 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 seu próprio componente tornaria ambos os componentes mais reutilizáveis. Por outro lado, às vezes você quer simplificar o fluxo do processo mostrado no Frontline Creator Interface para seu cliente, mantendo múltiplas funcionalidades juntas em um único componente. Por enquanto, vamos supor que combinamos ambas as funcionalidades em um único componente.
Que passos seu componente poderia ter?
Anteriormente, foi-lhe dito que os passos são basicamente equivalentes a telas. Então, por que você teria mais de uma etapa se a funcionalidade adicional é apenas comunicação backend?
A resposta é manter e reusar a capacidade de manutenção. A manutenção, porque ao fazer mudanças no aspecto da comunicação, você só terá que olhar para essa etapa e não ler nenhum outro código. Reusabilidade, 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 idéia fazer dois componentes separados destas duas funcionalidades. É uma boa idéia ao menos criar etapas separadas se você as combinar em um componente. Basta fazer a tela parecer a mesma ou acrescentar um aviso de progresso do Conector. Como tal, sugerimos ter 2 passos aqui, por exemplo "escolha" e "message_connector".
De quais ações você provavelmente precisaria?
O objetivo principal desta pergunta é familiarizá-lo com o catálogo 'Ação'. Aqui estão exemplos de ações que você pode utilizar no processo de implementação:
- send_commit_message: Comunica com o Conector Frontline
- step_transition: Mude da etapa "escolha" para "message_connector" (se você tiver 2 etapas)
- ui_progress_notification: Informa ao usuário que estamos atualmente nos comunicando com o backend (no caso de esperarmos pelo reconhecimento)
- setvar: Usado para salvar uma entrada que pode posteriormente ser devolvida tanto ao conector como a um parâmetro de saída de nosso componente
Com isto, você terminou agora a primeira lição. A próxima lição será sobre os escopos e abrangerá sua primeira tarefa prática.
