コンポーネントはXMLで記述され、そのルール(ifA then B
ステートメント)を記述することで、希望する動作を実装することができる。
例えば、機械の検査中にユーザーが「カメラ」ボタンを押すと、装置の内蔵カメラが起動するという要件がある。
同じルールをもう少し実装に近い形で表現するとこうなる:
ステップ
"inspect_machine "で、コマンド
"Camera "のイベントが
発生したら、アクション
"start_camera "を実行する。
コンポーネントの構造フレーム
部品の典型的な構造フレームは以下の通りである:
<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>
例を挙げる前に、XMLタグの概要を以下に示す:
- <コンテキスト>:扱う変数(データ)を定義する
- <rules>: 一連のアクションがどのような条件で実行されるかを定義する。式ともう1つのアクションで構成される
- <アクション>:ワークフローで使用する定義済みのアクション(例:デバイスカメラの起動)。
- <step>: スクリーンのデータ(コンテキスト)とロジック(ルールとアクション)を含むデバイス上のスクリーンで、ユーザーインターフェイステンプレートにリンクされている。
- <states>:ルールがいつチェックされるかを決定する(例:イベントが発生したとき、ステップに入ったとき、ステップから出たとき)。
- <マッピング>:データ(コンテキスト変数)をユーザーインターフェース(別のファイルで定義される)にマッピングする。
コンポーネントの例
コンポーネントの構造をよりよく理解するために、イメージ・チョイス・コンポーネントを例に説明します。
ユーザーは「アップル」と「ペア」の2つの選択肢から選ぶ。このトレーニングでは同じコンポーネントを使用し、今後改良していく予定です。
ダウンロード・コンポーネント
以下のUIは、このコンポーネントがFrontline Workplaceスマートグラスアプリケーション上で実行される際にどのように表示されるかを示しています。
ワークフローはこうだ:
<?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>
ワークフローの説明
1.ワークフロー・タグには、startstep="choose" という属性がある。これは、コンポーネントを初期化した後、どのステップを最初に実行するかを選択するために使用します。
2.<step id="choose"
...は、uitemplate="ChoiceScreen "
を使用して、さらに表示される選択肢を参照するために使用されます。ChoiceScreenは、このステップにいる間に画面に表示されるものを定義するファイルです。
説明したように、コンポーネントの動作はルールを使って定義される。ルールは、式(または条件)と、その条件がTrueのときにどのアクションをとるかで構成される。各ルールは、<onenter
>、<onresume
>、<onleave
>、<onevent
>、<onpause>の
いずれかの状態に割り当てられる。ルールがチェックされるのは、コンポーネントがその状態にあるときだけである(例えば、onenter - コンポーネントが最初に起動されたとき)。
3. <rule id="menu_button_selection">は
<onevent>
ステートに割り当てられている。イベントが発生するたびに、このステートに与えられたすべてのルールがチェックされる。ここでは、<expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression>は
、イベントに特定のコマンドが含まれているかどうかをチェックします。このようなイベントは、"APPLE "または "PEAR "という名前のボタンが、音声コマンドまたは画面上で押されたときに起動されます。
4.ルール式がtrueと評価された場合、ルールの<actions>
タグ内のアクションセットが実行される。この例では、finish_workflow
アクションが使用されている。これは、ユーザーが2つのオプションのうち1つを選択すると、即座にコンポーネントを離れ、<output>
パラメータでどちらの選択がなされたかを渡すので、その選択に基づいてワークフロー図に異なる遷移を作成することができます。
📌課題
選択コンポーネントを拡張して、ユーザの選択を含むメッセージをFrontline コネクタに送り返したいとします(コネクタはこの情報をバックエンドシステムに伝えることができます)。次の質問について考えてください:
- そのコンポーネントはどのステップを持つのですか?
- アクション」カタログを見てみよう:どのアクションが必要でしょうか?
ヘルプとリソース
アクションは 、私たちが使用できる基本的な構成要素です。ユーザーが見るもの(色、テキスト、通知など)の変更から、データの管理やFrontline コネクタまたは外部デバイスとの通信によるプログラムの流れ(次のステップへの移行)の制御まで、さまざまなものがあります。
ソリューション・ノート
まず第一に、Frontline コネクタとの通信は別の機能であり、それ自身のコンポーネントを持つべきであると主張するかもしれません。確かにその通りです。通信の側面を独自のコンポーネントに分離することで、両方のコンポーネントの再利用性が高まります。一方、複数の機能を1つのコンポーネントにまとめることで、Frontline Creator Interfaceに表示されるプロセスフローを簡素化したい場合もあります。ここでは、両方の機能を1つのコンポーネントにまとめるとします。
あなたのコンポーネントにはどのようなステップが考えられるか?
前回は、ステップはスクリーンと同等であると言われた。では、追加機能が単なるバックエンドのコミュニケーションであるなら、なぜ複数のステップを持つのだろうか?
その答えは、保守性と再利用性だ。保守性とは、通信面に変更を加える場合、そのステップだけを見ればよく、他のコードを読む必要はないからだ。再利用性は、コンポーネントがさらに複雑になれば、同じステップを使って別のメッセージを送ることもできるからだ。
同じように、これら2つの機能を2つの別々のコンポーネントにするのは良いアイデアだろう。1つのコンポーネントにまとめる場合は、少なくとも別々のステップを作成することをお勧めします。画面の外観を同じにするか、Connectorからの進捗通知確認を追加するだけです。例えば、"choice "と "message_connector "です。
どのアクションが必要だろうか?
この質問の主な目的は、「アクション」カタログに慣れてもらうことです。ここでは、実装プロセスで使用するアクションの例を示します:
これで最初のレッスンは終了です。次のレッスンでは、 スコープについて学び、最初の実習課題に取り組みます。