windows consumer preview / 開発環境の入っていないPCにMetrostyle appsをデプロイする

twitterである方が「metroAppsを開発環境のない複数のPCへ配置してテストする場合どうするの？」的なことを呟いてるのを見かけたので、

wdpの頃から飛んだ記憶を呼び覚ましcunsumer previewでちょっとやってみましたという記録になります。

そもそもdeveloper previewのときは二台ともvisual studio入れてしまっていた気がするので…

結論から書くとこの通りやるだけです。

０）AppPackage内のAdd-AppxDevPackage.batを実行すると、developer license か enterprise sideloading configurationが必要とエラーが出てしまいます。

１）PowerShellを管理者権限で起動、Show-WindowsDeveloperLicenseRegistrationと入力すると開発者用ライセンスの取得ダイアログが表示されます。

２）画面に従いLiveIdのパスワード入力等を行うだけでライセンス取得ができました。

３）ライセンス取得後は、AppPackage内のAdd-AppxDevPackage.batで普通にデプロイできます（管理者権限が必要）

 スタートスクリーンを確認するとこの通り

クリックすると先ほどデプロイしたMetrostyleAppsが起動します（残念ながらこれはgrid applicationのプロジェクトテンプレートそのままのものです）

以上で開発環境の入っていないPCへのMetrostyle Appsのデプロイは終わりです。

この作業をしながらtwitterにキャプチャ投げてたのですが、

”開発者ライセンス”って言葉もdeveloper previewでアプリ動かしたときに見ているはずなのに完全に忘れてしまっていて

windows storeの開発者登録に関連するものかと勘違いしたりして恥ずかしいtweetを投げたりもしています。

まぁ、久しぶりにmetrostyle appsのプロジェクトを触った日でした。

デスクトップPCのDeveloper PreviewをConsumer Preview入れ替えたことで、Consumer previewも二台体制（X220Tのほうは常用）になり、

またWindows Developer Daysにも参加できることになったので、これをきっかけにここへの記載も含めてもう少し何かしていきたいと思います。

WOA（Windows on ARM）

年末から、忙しかったり不調だったりでだいぶ空いてしまいました。

微妙な記事ストック（未完）はあるのですが、今回はタイムリーなニュースに関して…

http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx

Building Windows 8にて、ARM版についての概要が記載されました。

ざっと見ですが、

• ARMにもデスクトップ環境が提供される
• デスクトップ版Officeが標準搭載される
• デスクトップ環境にはエクスプローラ、IE10等が提供される
• ARM版はプリインストールのみ

と予想通りな点もあるのですが、

"WOA only supports running code that has been distributed through Windows Update along with the full spectrum of Windows Store applications."  

ということで、ARM版に置いても.Netアプリは動くであろうという甘い期待が打ち砕かれました。

前後を読むと、バッテリライフやパフォーマンス、セキュリティ的な観点での事由のようですが、

Officeが使えるiPadという扱いになってしまわないか心配でもあり、それってCEでもいいんじゃね？って思いもあり

クライアントアプリも開発してる人間としては、セキュリティという言葉とフルバージョン（？）Windowsという言葉に惹かれて顧客の環境に入ってくると厳しいなぁとは思います（まぁ、日本企業は未だにXPが多いので暫くの時間はあるでしょう）

ただ現時点ではドメインへ参加できるか等のビジネスユースでの扱いの説明はないため、WOA端末の位置づけについては今後の情報に注視したいところです。

またdesktop version OfficeのリストにOutlookがないのですが、

スケジューラやメールに関してはMetrostyle Appsのバックグラウンドタスク（の多彩なトリガ）やタイル通知等の機能を活かす場面が多々あるからではないだろうかと思います。

個人としては、事由に納得はするがなんのためのcli？という気分が残る発表でした。

Metro style Apps : アプリケーションパッケージ、デプロイ、ＶＳ１１の嘘

    また少し空いてしまったが、今回はこんなの最後で良いんじゃないか？というアプリケーションパッケージについて

アプリケーションパッケージ（Appx Package）って何？

    OPCをベースにしたWindows Store用のソフトウェアパッケージ
    Microsoft Windows Installer（MSIファイル）の代わりと思えばいいのだろうか。
    Metro style appsが制約たくさんなためか、今までのげんなりするインストーラ作成とは異なり、簡単だが何もカスタムは出来ないように見える。
    また、パッケージファイルの実体はOpenXMLと同様にZipファイルになっているので拡張子を変更すると簡単に中身を見るとこが出来る。
    ※展開した中身に既視感があったのはそのためらしい。
   

パッケージの作り方

    １）SolutionExplorerからStore->Create App Package

　　

    ２）"Build a package to use locally only"を選択（※Windows Storeはまだアプリケーションを受け付けていないため）

　　

    ３）出力先とバージョン情報の設定

　　

    ４）確認。OKならBuildを押すと指定フォルダにパッケージが作られる

　　

パッケージの使い方

    １）出力先に指定したフォルダに、アプリ名_バージョン番号_ターゲット名_Testというフォルダがあるので開くとbat/appx/appxsym/cerの４ファイルが入っている。

　　

    ２）batファイルを右クリックし、Run as administratorでインストール実行     

　　※緑字が出れば成功

　　※赤字は失敗（別バージョンが既に入っている）

    ３）スタートスクリーンでアプリ名を入力すればすぐに確認が出来る

　　※たくさん作ってると検索のが早いので

    ４）アンインストール方法は、アイコンを右クリック または アイコンを上下どちらかにフリックして下部表示されるメニューからアンインストールを選択する。

　　 ※キーボードではアプリケーションキー（MenuKey）

何処に展開される？

　インストール後の展開先は、インストール方法により異なる。

    VS11からだと　C:\Users\{ユーザ名}\AppxLayouts
    .batからだと 　C:\Program Files\Applications   ※アクセス不可のフォルダ
   
　複数ユーザで各々インストールを行った場合、同一バージョンならば同じ展開先を使用するためApplications下のファイルが増えることはない。
　ユーザ⇔単一バージョンのアプリケーションで結びつきを管理しているようで、下記のように複数ユーザで別バージョンを並行インストールすることは可能となっている。

　　 ※Applicationsフォルダ、上２行が同一アプリ別バージョン

    また、ＶＳ１１からインストールされている場合（する場合）、他のユーザが同一アプリ（バージョン問わず）を.batからインストールする（している）とエラーになる場合がある。その場合には、他のユーザ側でアンインストールを行わなければならない。

VS11の嘘

    上記に書いたようにVS11から実行された場合は通常と異なるフォルダにアプリケーションは展開される。
    当然このフォルダに設定された権限は、”C:\Program Files\Applications”と異なるため、本来実行できない下記のようなコードが動いてしまう。

　　

　　※xdr.txtはパッケージに含まれるコンテンツファイル

    通常はこのようなことをすることもないだろうし、Metro style Appsではフルパスのファイルアクセスを行うようなメソッドが使用できなくなっているため、ファイル権限が問題になるケースは限られるが、ＶＳ１１から配置した場合には、通常とは異なる状態であることは認識しておくべきだろう。
   

現状と問題点

    現状のアプリケーションパッケージは、他のＰＣに自分の作ったアプリケーションを展開するための機能でしかない。
    問題点としては、Metro style AppsがインストールされるApplicationsフォルダが管理者実行のコマンドプロンプトで閲覧できてしまう点があげられる。
    権限設定があるためか、書換・削除は失敗するが、ファイルを外部へコピーすることは可能であり、Windows Developer Previewに含まれているサンプルアプリケーション内の画像ファイル等を取り出すことが出来てしまった。
    この件については、Windows Storeが提供されるWindows 8 ベータ版が配布された後に追試しようと思うが、Developer Previewと変わらない状態であれば必要に応じてパッケージに含まれるファイルの暗号化等を検討しなければならないだろう。
   

Metro style apps : 画面について（Layout & Orientation）

様々な記事で目にしていることと思うが、Metro style appsはiPad、WP7、Android等のように１アプリが全画面占有する動作が基本となる。

ホームボタン（WP7はWindowsボタン）の代わりがWindowsキー、ホーム画面の代わりがスタートスクリーン、アプリは起動すると全画面を使用してユーザと向き合う。

画面という観点で、Metro style appsが前に挙げたプラットホームと異なる点は、全画面表示以外の表示パターンを持つことである。

タッチパネルがあるデバイスでは下記の図のような指の動きを、ないデバイスではキーボードショートカット（Windows Key+.）を実行してみてほしい。

開いていたアプリが端により、画面の残り４分の３程度が緑色の状態になっただろうか

この状態で、Windowsキーを押しスタートスクリーンに戻り、IEを起動すると下記のような画面になる。

これがドキュメントではMultiple viewsと表現されるMetro style Appsの異なる表示モード（Snapped view／Filled view）である。

基本的には表面にあるアプリしか実行状態（Running）にならないMetro style appsであるが、この状態では同時に二つのアプリが実行状態（Running）となる。

開発者として注意しなければならないのは、基本的にどのアプリもユーザ操作でSnapped viewにすることが可能ということである（試したところDirectX Applicationも同様にスナップ出来るし、二画面ともにDirectX Applicationを並べることも出来る）

この点を考慮しておかないと狭い画面に無理やりスケーリングを行ったような酷い画面をユーザに見せることになってしまう。

アプリケーション側から見た場合、Metro style appsの表示モードは以下の４種である。

※注・スナップできる条件として、horizontal resolution (> 1366 px)との記載があるので、条件を満たせばPortraitでもスナップできるのかもしれない。

それではプログラム側で画面状態を検出する方法を確認してみる。

回転検出は以下のイベント

　DisplayProperties.OrientationChanged

レイアウト変更は以下のイベントで検出することが出来る。

　FrameworkElement.LayoutUpdated

上記イベント内で表示状態を取得するには下記プロパティを参照する。

　DisplayProperties.CurrentOrientation（画面の回転方向の取得）

　※筆者環境（lenovo Thinkpad X220 tablet）では自動回転しないため画面のプロパティから回転を設定し確認を行った。

　ApplicationLayout.Value（画面の表示状態の取得）

　※SnappedViewに関しては常に横幅320pxとなる。FilledViewの横幅は、全画面の横幅から320pxとボーダー幅22pxを引いた値となる。

また、SnappedViewについては下記メソッドで解除を試みることが出来る。

　ApplicationLayout.TryUnsnap();

しかし、試した範囲ではFilledViewのほうに別アプリを開いているとこのメソッドは失敗してしまうため、IEやDesktopの挙動のようにSnapped view側でアクションを起こした際にアプリをSnapped viewからFilled viewに切り替えるという動作が自作アプリで実装できるのかは不明である。

今回は画面についての基本的な事柄を確認してみた。

特徴的なのはSnapped view／Filled viewであり、特にSnapped viewの方は横幅の制約もあるためどのようなに利用するのかが悩むところである。

ガイドラインにはレイアウトを切り替えた際も機能の連続性を保つように書かれているが、Snapped viewになると横幅が極端に小さくなるため、操作の継続という観点は外して考えるしかないだろう。

また利用者としてはSnapped viewの横幅が任意には変えられないので、使うのであればそれなりの意味（機能）が欲しいのでないか、そこをどうアプリに組み込んでいくか、活かしていくかが開発者の課題になると思う。

　※ TryUnsnapメソッドが意図通りに動けばSnapped viewになることを無理やり回避できそうな気はするが…

PS. ブラウザがハングして書いてたものが消えてしまったのもあるがまた時間があいてしまった。そして上の文に出てることよりも色々試したり調べたりしている気もするのだが整理して書こうと思うと消えてしまう部分が多いのも確かで、もう少しスコープを小さくしてコードや試行錯誤や気になった箇所を深く書くほうがいいのかもしれないと書き方悩み中

Metro style apps : アプリケーションライフサイクルについて

前から少し空いてしまったが少しづつ。

Metrostyle appsの今までと大きく異なる挙動としてあげられるのが、バックグラウンドに回ったアプリは停止するという動作である。
この動作についてはWindows Phone 7やiOSのアプリと似たようなものだといえばざっとしたイメージは出来ると思う。
WP7では状態遷移図（http://msdn.microsoft.com/en-us/library/ff817008(v=vs.92).aspx）があったのだが、Metro style appsでは用意されていないようなので（比較するという意味でも）少し整理をしていきたいと思う。

まず状態パターンを洗い出すのに参考になるのがApplicatoin.OnLaunchedメソッドの引数LaunchActivatedEventArgs.PreviousExecutionStateの値である。
列挙型ApplicationExecutionState（http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.activation.applicationexecutionstate）をみると以下の４状態が定義されている。

（表１．アプリケーション状態）

まずこの関係性を明確にするために、各イベントハンドラにコードを仕込み実際の動作を確認したいと思う。

…が、大苦戦。
苦戦した箇所は大きく以下の通りである。

（１）ファイル出力の制約

 Metro style appsとDesktop appsでは同じクラスでも使える機能が異なる。そしてまた全く触れないクラスもある。
 今回はTrace、StreamWriterといった機能が上記にあたったため、File access sampleを参考にファイル出力を書いてみた。
 また、Documentsフォルダの取得やファイルの読み書きにはマニフェストへの権限設定が必要となる。
 もしうまくいかない場合には、File access sampleのPackage.appxmanifestを自身のプロジェクトのものと比較してみるとよいだろう。

（２）async/await、非同期API

 ここは自身の理解不足だとは思うが、例えばApplication.Exitingイベントの処理
 待つようにログ出力を書いているつもりであるがファイルに出力を行わずにメソッドが終了してしまう（Debug.Writeでの出力は出ている）
 この関係だと思われるが、Suspended→Resumeとなった場合にも、ResumingのタイミングでSuspendingのログ出力が同時に出るという事象も発生している。
 マルチスレッドプログラミングの経験がある身としては、ブラックボックスの非同期を強要されたあげく思うように動かないのはとても歯がゆい思いになる。 

（３）デバッガではSuspendedにならない？

 挙動をみる限り表題の通りのようだ。プロセスをアタッチした場合も同様（リモートデバッグについては後日確認したいと思う） VisualStudioで実行する際にDeployは行われているため、スタートスクリーンから実行することでSuspended状態をみることは出来る。
 しかし、２との関係で確信が持てない挙動が残るのも事実である。

以上より、ライフサイクルについてまとめると言ったものの思ったほど思うようには動いていないが、PreviousExecutionStateをキーとして現在確認できた項目を以下に記す。

• NotRunningステータスになるのは新規のDeploy直後もしくは電源投入直後（それ以外の場合は一度動いたときの状態を前状態として保持している）
• Alt+F4もしくはタスクマネージャから終了した場合、前状態はTerminatedではなくSuspended/Runningとなる
• Suspended→Terminatedはメモリ使用率を８５％～９０％程度まで高めたときに発生した（本当に使用率で判定しているかは不明）
• Suspendingイベントが五秒以上応答がなかった場合、terminateになる記載があるが現象は確認できていない。

ここから状態遷移図を作成すると以下のようになる。

（図１．アプリケーション状態遷移図[簡易]）

簡易と書いてあるのはこれ以外にAsociation Launchingと称されるファイルやＵＲＩとの関連付けで起動するケース、Windows Storeが絡むであろうアプリケーションのアップデートという機能、Background Taskについてはこの図には含まれていないためである。
またPreviousExecutionStateを軸にみたが、アプリケーションライフサイクルとして考えるのであればNotRuning状態・プロセスの無い状態（紫のライン）は図に含まなくてもよかったのかもしれない。
その状態でWP7の図と比べて見るとRunning-Suspended-Terminatedの関係はWP7のRunning-Dormant-Tombstonedの関係と似通っており、基本的な部分においてのコンセプトは（外見だけでなく）共通していることが現れているのではないかと思う。

以降、より詳細をみることでわかったことがあれば適宜フィードバックしていきたいと思うが、MSDNに図が出てきたらそれが正解なのでそれまでのイメージとなれば幸いかなと

次回は、全体像が見えない状態で体系だてて書こうとすると進まない・纏まらないのははっきりしているのでガイドラインをベースにライフサイクルを個別に見ていくか、サンプルをベースに気になる機能について書きたいと思う。
また、もっと欲張らないでもっと短く狭い範囲をみて行ったほうが良いのかなと書き方悩み中

何故Metro style appsを選ぶのか？

BUILDでの発表資料みるとWindows Developer PreviewにもDesktop Appsはあり、発表でも従来のアプリとの互換を保つとも明言されている。

何よりも開発者は今まで開発スタイルに対しての知識と経験を持っている。

企画する方だって普通は今と変わらない環境で動くものをまず求めるはずである。

その状況下で何故Metro style appsを選ぶのか

まず初めにこの点をWindows Developer Preview/Metro style apps双方の特徴から少し考えてみたいと思う。

●タブレットデバイス（タッチインターフェース＆フルスクリーン）

2012年には世界で1億台の出荷が見込まれるというタブレットデバイス

現状のWindowsタブレットはiPadに比べて残念すぎるとよく評されるが、Windows Developer Previewをぜひタッチ可能なＰＣで動かしてみて欲しいと思う。

スタートスクリーンやそこに並ぶアプリを触りだすと如何にこのシステムがタッチインタフェースを意識して作られているかがわかる筈だ。

従来も全画面アプリやタッチインタフェースを使用するアプリを開発することは出来た。

しかしフルスクリーン＆タッチファーストというコンセプトのアプリケーションフレームワークがあればより容易に機能を実装出来るとともに、この世界観に溶け込むアプリケーションを作成できる。

Windows Developer Previewを触りWindowsタブレットに希望を感じることが出来たのなら、それがMetro style appsを選ぶ理由になる。

ARM版については色々と噂されているが、個人的にはデスクトップ環境は提供されると思う。（つかなければ某社の圧力でないかと…）

ただし、ARM版デバイスの大半はタブレットデバイス（もしくはウルトラポータブルデバイス）になると思われることと

レガシーアプリに対しての関係者の微妙な発言があるため、ネイティブアプリは当然として、.NetもPInvokeしてるものは一部修正とリコンパイル必須、CLR4のみのサポートになる等の制約が付くのではないかとは思っている。

●Live tiles

Windows Developer PreviewにはWindows Phone 7と同じようにライブタイルがある。

この機能、実はすごい便利でWP7を開いたときに、

次のスケジュールが表示されている、天気予報が表示されている→詳細を見たければタイルをクリック

という情報の確認とアプリへの導線が自然に感じられるような素敵な作りになっている。

つまり、目立つ位置に置いてもらえるアプリ＝稼働率が高くなる

Windows 8世代のアプリはライブタイルでアピールしてこそ勝ち組になれるのである。

ライブタイルを使用するにはmetro style appsを選択しなければならない。（だよね？）

●HTML5/CSS3/Javascript+WinRTアプリケーション

自分は今でもJavascriptでコード書いてるとムキーってなる方だが好きな人は大好きだろう。

デバイスでHTML/JSアプリってwebOSを彷彿とさせるのだが

サンプル見てるとJavascriptからWinRTコンポーネントをすごい自然に呼べてるので、

フロントだけHTML/JSでバックはC#/C++とかって組み方も出来そうであるし、Promise.thenでの非同期処理も素敵にみえる。

 HTML大好きっ子がデザインからロジックまで全部やるのもよし、

xamlは知らないけどHTML/CSSはばっちりというデザイナさんと組んでアプリを作る場合にも、Metrostyle appsは良い選択肢にはなるのではないだろうか

●Windows Store

アプリを配布するのにもう自前でインフラを整備しなくてもよい。

Metro style appsを選べば、（多少のお金はかかるが）Windows Storeが使える。

購読課金モデル、（コード側の対応なしで）期間指定での体験版、自動アップデート等にも対応するようで、

これらの機能を容易に使用出来るだけでもMetro style appsを選択する意味はあるだろう。

ちなみにMetro style appsは今までのようにexplorerからexeキックでは動かすことが出来ない。

当然、ビルド成果物を丸ごとコピーしても他のPCで動かすことは出来ない。

vs11でappxパッケージを作成することは出来るが、開発者登録がまだ始まっていないせいもあるだろうが他のPCに入れようとすると開発者証明書のエラー的メッセージをだしてインストールも出来ないので、他のPCで動かしたければソースを渡すかリモートデバッガで配置するしか手段がないのではないかと思われる。

●環境の引き上げ

何故これから新しく作るアプリの制約にWindows XP、.Net2.0、ie6…といったものを負わねばならないのか

いつの日も開発者がまず悩まされるのがレガシーサポートではないだろうか？

Metro style appsはWindows 8以降のものである＝レガシーサポートを切る理由になる。

開発者はMetro style appsを選ぶことにより何の制約も無く最新のテクノロジを使い開発するこことが出来るようになる。

それで顧客がいなくなっても筆者は責任はとれないが…

 

と、Windows Developer Preview/Metro style appsの特徴からMetro style appsを選ぶべき理由を考えてみた。

筆者的には、末尾が許されるのであれば、Live tiles・Windows Store等の機能はとても魅力的に感じるがどうだろうか

 

次からは、Metro style appsのアプリケーションライフサイクルについて整理していきたいと思う。

 

 

 

 

序

２０１１年９月のBUILDイベントでWindows Developer Previewがリリースされて３カ月

そして先日（12月6日）のWindows Storeの発表に付随してWindows 8 β版リリースが２０１２年２月となることが公式に発表された。

このスケジュールから大きなトラブルがなければ２０１２年内に正式版のリリースとなるであろうWindows 8

当ブログではこれに関連する事柄を開発者の視点から綴っていこうと思う。

当面はMetrostyle Appsを主題としていきたいと思う。

 筆者は、SNSの普及により様々な場面で目に入る趣味グラマやスペシャリストの発言をみて、心中穏やかじゃない状況に追い込まれつつある30代駄目グラマ

21世紀初頭にJ2EEから仕事に入り、Javaフレームワーク作ったり、Solarisでマルチスレッド（C）やったり、大規模DBやったり、DSPがやるようなことをPCでやるためにx86 SIMDやったりと色んな下請け経験をしたあげく、今はC#＆HTML/CSS/JSあたりをメインにレガシー環境縛りに泣く日々を過ごしている。

 当ブログの個人的な目的は以下

• 本業とあまり関係ないライン？の技術・知識を積み重ねる
• 他人に読まれることを意識した文章を書く
• 継続

一朝一夕に目指すレベルにはなれなのでまずは一歩ずつ