11月27日開催のエスキュービズムエンジニア勉強会資料です。

1. POSとステートマシン
Windowsストアアプリとデバイスの連携

2. ステートマシンとは？
● 状態と遷移のモデル
（今回扱うのは言うまでもなく有限ですが）
● ステートマシンは状態遷移図で表現できる
● 最近は（とある界隈で）FPGAとか流行っていて
たまに耳にすることもありますね

3. POSを例にした状態遷移
POSのページ遷移を
状態遷移図として（すごく簡単に）
表現するとこんな感じ
客層選択ボタン
/会計ボタン
新規会計ボタン
メイン
ページ
会計
ページ
戻るボタン
完了ボタン
精算
ページ
戻るボタン
会計
ページ

4. POSとデバイスと状態遷移（予習）
←状態遷移がややこしくなる
http://en.wikipedia.org/wiki/File:Barcode-scanner.jpg
POS
←Windows版POSは
USBで色々繋げられる
←状態遷移が
とてつもなくややこしくなる

5. たとえば
「会計画面に遷移したら、
（POSの「読み取り開始」ボタンを押さずに）
いきなりバーコードを読みたい」
という要求
いままでは「読み取り開始」ボタンを押して、
ユーザがPOSの状態を明示的に
「バーコード読み取りモード」に遷移させてた
（↑今日の発表内容で改修済み）

6. 「会計画面に遷移したら、
いきなりバーコードを読みたい」
Windowsストアアプリでは、
Window全体へのキー入力
（CoreWindowのKeyDownイベント）
をハンドリングすれば、
アプリ起動直後でのバーコード読み取りも
ハンドリングできる

7. 「会計画面に遷移したら、
いきなりバーコードを読みたい」
（逆に言えば）
Window全体へのキー入力はすべて
CoreWindowのKeyDownイベント
によってハンドリングされてしまう

8. POSとデバイスと状態遷移（復習）
←状態遷移がややこしくなる
http://en.wikipedia.org/wiki/File:Barcode-scanner.jpg
POS
←状態遷移が
とてつもなくややこしくなる
（キー入力によるモード切り替え等々・・・）

9. デバイスからの入力例
バーコードリーダーからのバーコード入力
「4560292290245n」
ハードキーからの商品の数量変更を行う入力
ハードキーで「数量変更キー（'Q'とする）」入力
ハードキーで「1」入力
ハードキーで「0」入力
ハードキーで「確定（'Enter'とする）」入力

10. デバイスからのPOSへの入力例
「4560292290245n」
POS
CoreWindow
「Q10n」
http://en.wikipedia.org/wiki/File:Barcode-scanner.jpg

11. デバイスからのPOSへの入力例
本当はこんな感じ・・・
「4」「5」「6」「0」「2」
「9」「2」「2」「9」「0」
「2」「4」「5」「n」
CoreWindow
「Q」「1」「0」「n」
http://en.wikipedia.org/wiki/File:Barcode-scanner.jpg
POS
「まとまった文字列ではなく」
文字入力のために押される「キー」が
（VirtualKeyとして）入力されてくる

12. バーコードリーダーの入力も
ハードキーの入力も
アプリからは「キーボード入力」にしか
見えない
● アプリのユーザは別々のデバイスを操作してい
るのに、アプリからは同じ入力にしか見えない
● 入力に応じてアプリの状態を変更させ、
特定の状態で入力をハンドリングすれば
解決できる

13. 「CoreWindowへの入力」と
「POSアプリの現在の状態」で
ステートマシンを組む
（この場合、「出力」は「POSの挙動」・・・？）

14. 数量入力
初期状態
初期状態
'n'入力
数字キー
数量変更キー
Escキー
数量入力中
数量確定
C（クリア）キー
商品数量変更処理
（内部処理）
規定桁を
超える入力
数値入力
'n'入力
バーコード
読み取り中
バーコード検索
（内部処理）
バーコード
確定

15. 「」
「5」「0」
「」
数量入力
初期状態
Escキー
「」
'n'入力
数字キー
数量変更キー
初期状態
「5」「0」
「0」
数量入力中
数量確定
C（クリア）キー
商品数量変更処理
（内部処理）
規定桁を
超える入力
バーコード検索
（内部処理）
数値入力
実際には状態に応じて
'n'入力
バッファ（キュー）を切り替え、
バーコード
バーコード
読み取り中
確定
バッファの状態に応じた処理
「4」「9」・・・
（上記によるバッファのクリア
と状態遷移も存在）

16. 実際にはキーの個数（0～9などの数字キーを除く）だけ
前ページの状態遷移図が縦に（とても）長くなります
具体的には
キーボードとバーコードリーダー対応前の
コードは500行程度だったんですが、
対応後は2000行を超えて現在も増加中・・・
状態遷移図を書いたら
コードを自動生成して欲しいデース！

17. 加えて
「商品選択状態」で「割引」が押された場合には「単品割引」
「商品未選択状態」で「割引」が押された場合には「全体割引」
といった状態に遷移させる必要もあります
（商品選択はアプリのUIをタッチして選択するので、
前々ページのCoreWindowベース状態遷移図の
「外の世界」の状態が・・・）

18. 更に加えて
たとえば'%'という文字列を含むQRコードを
バーコードリーダーから読み取ると、
アプリからは'%'の該当箇所で
「Shift」と「5」が順番に入力されてくる・・・
お察し下さい
http://en.wikipedia.org/wiki/File:QWERTY_keyboard.jpg

19. まとめ1
日頃使い慣れているボタン操作だと
ユーザの操作が制限できて
（=状態遷移図の枝刈りができて）、
かつ「キーボードのAキー」という入力ではなく
「Aという独立したボタン」として入力できるので
とても素晴らしいですね
（訳:アプリのボタン以外からの操作は大変ですね）

20. まとめ2
「アプリのデザイン」という枠組みでは
「UIの振る舞い」が意識せずとも込みになっている
（経験的にそんな気がするというだけですが）
「デバイス」が絡んだ「アプリのデザイン」では
「UIの振る舞い」が「デバイスの操作」に依存するので
上記を加味した統合的なデザインが必要
（=「画面デザイン」じゃ対応しきれない）