ストアアプリの構想:::::::::::ストアアプリを初めて作ります。いうアプリにするかイメージを膨らませ、要求文章を記述してみます。(自分は思うのですが、この世界で最も難しい仕事は「企画」だと思います。視線より次の画像に切り替わります。声に反応できますが、声による入力は必須ではありません。ヒアリング要望元は自分ですが、その自分にヒアリングを行っていきます。上記の要求についてお聞きします。アプリを使用する場面を教えて下さい。<問1>いつ・どこで・誰が・何のために・何を・どうする...場面ですか?<答1>寝る前に、ベッドで、私が、電子書籍を読むため、電子書籍のページを、めくる場面です。(画像ビューアの仕事かそれ?電子書籍のデータを解析すれば画像を表示できると考えるが、その辺確認入れてみるか)<問2>ビューアの作成ではなく、電子書籍の閲覧アプリの拡張に聞こえます。<答2>...そうかもね、その場合は電子書籍の閲覧アプリの拡張って可能なのですか?...情報不足で答えられません。要望元は画像ビューアがほしいと言っていましたが、要望の意図を確認した所、電子書籍の閲覧アプリの機能拡張として視線からページをめくれさえすれば良いことがわかりました。ストアアプリの拡張が可能かは、現段階では判断する材料が無いので調査が必要になります。入ったタブレットで閲覧できて拡張できるならアプリはどれでも良い。ファイルの解析などを行なうライブラリが提供されているならば一から作るでも良いという意向を示しました。電子書籍の閲覧アプリの作り方といった体で、既存アプリの拡張などが行えるか市場にはどういった閲覧アプリが出回っているか調査することになりました。電子書籍のデータ形式ですが、次のページで紹介されている通りいくつか存在します。こちらを読み込んで表示するアプリが多数存在することから、読み込みライブラリなどが公開されているのだと思います。有料なのか無料なのか調べます。読み込みは行えないようです。(2014.03現在)バイナリデータ作成元の会社の意見としては、ブックリーダーを個人で作らせたくないとのことです。戦争しているようです。機能を拡張する方法で考えてみます。アローキーなどでめくれました。持ってくるとその他のストアアプリは中断状態に入りますのでマウスやキー入力操作に介入が出来ないように思えますが、どうなんでしょう?前回学んだストアアプリの基礎にバックグラウンドタスクというものがあります。フォアグラウンドからストアアプリが移動しても、プロセスが残り続けてダウンロードやメディアの再生を続けることができました。こちら、キー入力イベントをバックグラウンドから投げ続けることカメラの動画を入力として処理を継続できるか調べます。(バックグラウンドタスクは制約が多いからダメっぽい気がするけど...確認します。)...もう少し電子辞書のフォーマットについて調べてみました。ウェブブラウザで読み込めば、内容を表示できるみたいですね。ファイルを展開して中身を読み込んでみたいと思います。展開することは出来たのですが、コンテンツファイルが暗号化されている様子。読み込んで表示できるのか確認してみます。コンテンツが暗号化されたままです。同メールアドレスでオーソライズして開けると思っていた書籍までも、確認できませんでした。お店が配っているリーダーのみでしか閲覧できないという制約がはっきりしてきました。私達はお金を払っても、ダウンロードしたコンテンツをどうこうして良い権利は受け取っておらず作品をある制約の下で閲覧するだけの権利しか得ていなかったのです。(何を今更...)はやくキー入力イベントを起こしてページがめくれるのか試してみます。使ってストアアプリ作ったことなかったですね。知識はそれなりに用意出来ているので、軽く練習してみます。アカウントでサインインするように言われました。新しいプロジェクトより、[Windowsストア]→[グリッドアプリケーション]と選択します。開発者用ライセンスが求められました。1ヶ月で期限切れとなる模様、更新はメニューより[ストア]→[開発者ライセンスの取得]で更新します。無料でいつでもいくつでもライセンス取得が可能だそうです。(わざわざライセンス取得するのは不正なアプリ開発を防ぐための安全対策でしょうか?)どきっとしたけど、なんだストアアプリをC++で用意していただけでした。ストアアプリのビルド、実行を確認しました。(頂点カラーを使ったボックスの回転アニメーションを確認しました。)実行は作ったアプリのインストール+実行という扱いのようですが、普通にアプリを終了させる操作ではデバッグ実行が終了しません。デスクトップに戻り、明示的にデバッグを中止することで、デバッグ実行が止まりました。(なるほど、なるほど)気を取り直して、グリッドアプリケーションを触ります。して作業していたからでした。このグリッドアプリにて、キーイベントを取得して何かしらの反応をするように書き直します。キーが押されたら別ページヘナビゲートする機構を入れてみました。キーを押下すると別ページヘナビゲートすることを確認しました。これとは別にバックグラウンドタスクを実行するストアアプリを見てみましょう。マシンからマイネットワークを選択するとエクスプローラーがフリーズします。(ひどいバグだ)おや?単にエクスプローラーにて右クリックするだけでもハングしますね。ハングしてしまいました。サインアウトできました。月曜日になったので、また来週!さて、バックグラウンドアプリのサンプルはしっかりトリガーに反応してブレークしますが、まったく同じように作った自分のアプリでブレークポイントを同じ場所に設置してもシンボルが読み込まれていないため?ブレークしませんでした。ー!?どうなっているの。おや?今度はさっきまでブレークできたサンプルプロジェクトまで、ブレークポイントでブレークしなくなってしまいました。バックグラウンドタスクも裏でずっと走る処理というわけではありませんでした。(トリガーを得て15分以上スリープした後1秒だけCPUを使えるとかその程度しかリソースをもらえません。)中断状態に移行する処理にてずっとループして処理を実行するアプリも想像しましたが、これも現実的ではないですね。外部アプリからストアアプリを操作するという方法は、簡単には見つからないことがはっきりしてきました。アプリに限り出来ないようにしているとのことです。セキュリティ上の問題らしいですね。視線操作でめくるというバックグラウンドアプリは諦めましょう。作る方法が無いことの調べがつきました(2014.03現在)ので、この世の誰にも実現は不可能です。ピクチャービューア出鼻をくじられた感が強いですが、要望元には調査結果を突きつけて要望を取り下げてもらいました。(自分なんですけどね...)最初に誤って口にした画像ビューアを作る件で合意しました。(これも自分なんですけどね...)ということで画像ビューアを用意し、これを視線で操作する方向に作業を持って行きたいと思います。視線をカメラから捉えるという処理が可能なのか調べてみましょう。使い方を確認してみます。Gazegroup.orgフォーラムにあるのはAPIドキュメントはなし、コード見ろとのことですね。使ってみましたが思ったより精度が悪いです。実際にどのように視線を検出しているか確認できたので面白かったですが画像処理の部分がまだまだチューニングの余地を残す作りでした。自分でも作れそうなので作ってみます。お、ではここから視線検出プログラムを設計していきましょう。使えることSobelフィルタ、ハフ変換、領域分割などが高速に行えること画像処理を拡張できるプラグイン機能を持つこと...とまぁ思いつきであれやりたい、これやりたいを列挙してそこからユースケースを書いてユースケースの記述に登場する名詞句、オブジェクトをドメインモデルに配置、整頓していきます。リンクを貼りたかったのですがIEからアクセス拒否されるので出力の一部の画像ファイルを表示します。要約すると「画像処理したい→開発者は入力画像をフォルダにおいて、サンプルプラグインの一部の画像処理コードを作る」です。矢印は先行を意味し、ユースケースが実行される前にそのユースケースが実行されることを示しています。入力画像を表示するためには、まず入力画像が読み込まれていないと始まらないといった具合です。要求から派生した要求ということで汎化を使っていますが、表記としてはまったくのデタラメです。派生した要求なのでこのままとします。教科書もユースケースは記述が大事で、線引きはどうでもよいとか何とか書いてあった気がします。(たぶん)やりたいことには全て実現の矢印がユースケースから伸びているので、要求を漏れ無く実現できます。(たぶん)ドメインモデルはこんな感じになりました。最初の2時間の作業の結果がこれです。分析を行って、ここに書かれている間違いをどんどん修正していきましょう。いう、これが参考にした教科書とまったく異なることに気付きました。ここからは本当にケースバイケースで、とにかくロバストネス分析の目的である属性やオブジェクトの抽出を行っていきます。ユースケースのリンクを貼り付けて、アクターからバウンダリに通信線を伸ばし、ユースケースの通りにコントロール、エンティティを配置していきます。ここでうまく配置作業がはかどらない場合はユースケースの記述がおかしいことに気づけるというものでした。順番にユースケースに対応するロバストネス図を作っていきましょう。ドライブに割り当てました。置き換わるので、ファイルパス管理が楽になります。ファイルをサーバーに提出します。これで一安心、いつでもこの状態に戻すことが出来ます。確かにユースケースから簡単に描き起こせましたが、これであっているのかわかりません。新しいオブジェクトは登場しませんのでこの図は無かったことにして良いと思います。(これを描いてみて思ったことは、これは描くまでもなかったということですね。)プラグインの編集これも正しい図かどうかは置いておいて、プラグインを最初に作る際、まず骨組みとなるサンプルが必要であることに気付きます。新しく登場したサンプルプラグインをユースケース、ドメインモデルに追加しました。加えて、プラグインを識別するためにはユニーク値が必要なことに気付きます。コントロールに「このユニークなプラグインIDを編集する」というものを追加し、インタフェースクラス(→プラグイン基底クラス)にプラグインIDが必要であることがわかってきました。これをドメインモデルに反映させます。こんな感じでロバストネス図を描く、足りないものをユースケースとドメインモデルに追加するという作業を繰り返していきます。一通りロバストネス分析を行った後のドメインモデルを次に示します。ドメインモデルしまった、本当は属性だけ埋めるのですが、先走って操作を書いてしまいました。ここまで記述して途中色々とシステムに対して要求が出てきました。複数カメラの入力を同時に処理したい。複数処理結果を同時に表示したい。シークして巻き戻しなどして結果を確認したい。これらの要求を取り入れて、ユースケースを追加、ドメインモデルの修正、ロバストネス分析を行います。追加要求これはプラグイン開発者ではなく、出来上がったプラグインをテストするテスターの操作となります。設計の教科書に似た状況なのでだいぶユースケースが書きやすくなりました。ロバストネス分析を行います。使って3Dモデルを出力結果に表示したいという要求が出たのでちょっと最新版でサンプルが動くか調べてみました。0x8007007E)みたいなエラーダイアログとともにクラッシュしたので、解決を図るため次のランタイム更新を実行しました。インストーラ結果は...大成功、上記の問題は解決しました。環境で動作することを確認。どちらでも同じアセンブリを利用して同じ結果を得られるかどうかなのですがこの画像処理開発環境が完成したあとで確認してみましょう。ロバストネス分析に戻ります。追加要求のロバストネス分析後のドメインモデルひとまず分析はここまで、画像入力ストリームの作成をプラグイン化することで任意のデバイスを認識できるようになります。(たぶん)つぎにやるのは「テクニカルアーキテクチャ」です。いまのところ抽象的すぎて本当にプラグイン拡張できるのかとか、不明な点が多いです。実装調査し、要素技術を確定させます。引き続き設計を行いますが一旦話を切ります。