あいてぃーとふぼふ

WindowsPhone7アプリケーション開発入門!

マイクロソフトが実施している「WindowsPhone7アプリケーション開発入門」セミナーに参加してきました!森博之さんが講師を務めるこのセミナーでは、WP7アプリ開発の概要から実装までを網羅する内容となっています。さすがに概要から学ぶのは退屈かな~…とも思いましたが、わたし自身もWP7に関する情報を色々と発信していきたいと考えていますので、イチから学ぶいい機会と思い仕事をサボって参加してきました。

迷った!

セミナーは大手町にある大手センタービルという会場で開催されました。普段なら前もって会場までの行き方を調べておく性質なのですが、今回は前日のゴタゴタであいにく下調べを忘れてしまいました。仕方がないので、東京駅からセミナー会場のある大手センタービルまではWP7に搭載されているGPSを頼りに向かったのですが、ものの見事に迷いました!しかもわたし、WP7以外のスマートフォンなんて持っておらず、通常の携帯もパケットし放題ではないという鬼仕様!街中でエルシャダイに会ったら間違いなく「そんな装備で大丈夫か?」と尋ねられるくらい貧弱な装備です。パンツ一枚のアーサー@魔界村みたいなものですよ。しかもWP7ってまだ日本語が打てませんので、住所を調べたくてもなかなか検索にヒットせず…。この日ほどWP7に腹を立てたことはありません!おかげで1時間近く歩き回って堂々の遅刻…。ホント、東京はよくわからんですばい。

一部の層には意外な人気!

平日ということもあり参加者は少ないかな~なんて思っていましたが…意外や意外!30名くらい入れそうなセミナールームがほぼ満席状態でした。やっぱりWP7の人気はスゴイですね~(一部の層で)!ちなみに、実機持ちはわたしを含めて数人程度でした。でもこれが普通。むしろ今まで参加した勉強会のように実機持ち9割とかが異常なわけで。

セミナーの内容は?

今回のセミナーが対象とする技術者レベルはSilverlightの修得者を前提としています。このため、XAMLやデータバインド等の基礎知識は一切省略して、WP7のアプリ開発に重点を置いた内容となっていました。しかし、あらためて概要から聞いてみると気付かされることの何と多いことか!WP7の実行モデルや各コントロールの特性など、じつは漠然と理解したまま放置していたものがすべてクリアになった感じです。ちなみにアジェンダは以下の通りとなっており、10時から17時まで一日中WP7づくし!といっても座学だけではなく、HandsOnLabな実習も含めた内容で退屈しません。

  1. WindowsPhone7開発概要
  2. WindowsPhone7開発入門
  3. 画面操作
  4. WindowsPhone7 FeatureAPIs
  5. MVVM・非同期処理

なおHandsOnLabでは、ターゲットを「Device」に指定しているためにエミュレータでのデバッグ実行ができずに悩んでいる方も多数おられました。最新のWPDT7.1では「Emulator」が既定値となりますのでこのようなことはなくなるのですが…。なるほど確かに、WP7開発ならではのあるあるですよね~。

今後の予定!

本セミナーと同じ内容のセミナーが6月末日にも開催されます。森さんにお聞きしたところ、現状では今回と同様の内容で実施しますが、WPDT7.1のRTMがリリースされているようであれば、それをベースにした内容にするかもしれないとのこと!セミナーは無償ですので、興味がおありの方は是非ともどうぞ~。

Windows Phone 7 アプリケーション開発入門

明日の自分に期待したい

今日は帰宅が遅くて更新する時間が取れなかったので、落書きメトロちゃんでお茶濁しです~(;≧Д≦)明日こそは…トゥモローこそは頑張って更新したいっ!

どうでもいいですけど、トゥモローっていうと「生きもの地球紀行」のエンディングテーマだった杉本竜一さんの「Tomorrow」って曲を思い出します。わたし結構好きだったんですよ、生きもの地球紀行!あの曲を聴くとなぜだか無性に涙腺が緩くなるんですよね~。まぁどうでもいいですけどね。

生き物地球紀行

WP7のゲームループはUIスレッド?(後編)

前回の検証結果(左記の画像)より、XNAのゲームループ(GameTimerクラスのイベントハンドラ)はUIスレッド上で動作することがわかりました。でも、これには大きな危険が潜んでいます。

UIスレッドの占有はダメ!

お気づきの方も多いと思いますが、この事実から読み取れる危険…、それはUIスレッドの占有には今まで以上に注意しなくてはならないということです。何を当たり前のことを…と思うかもしれませんが、ちょっと待ってください!たとえば、SilverlightのUIコントロールのイベントハンドラにおいて長時間処理を実行した場合、そのぶん、同様にUIスレッドを利用するGameTimerクラスのイベント発行が遅延してしまいます。このため、ゲームループのFPS(1秒間に処理する回数)が低下しますよね。この際に厄介なのは、OnUpdateイベントまでもがUIスレッドで動作するという事実です。これはつまり、UIスレッドの占有による弊害は、描画のコマ落ちなんて生易しいものではなく、ゲームの処理落ちに直結するということです。

XNAのみを利用する場合、処理に時間を喰ってしまった際は、意図的に描画処理をスキップして更新処理を優先させたりします。こうすることにより、描画のコマ落ちは発生しますが、ロジックの処理落ち(ボタンを押したのに認識されない等)を回避させることは可能です。ただしSilverlightと相互運用させる場合、こういう危険性を理解しないまま使用してしまうと後々厄介なことになりそうです。

まとめ!

後編に引っ張りましたけど、いいたいことはこれだけです。う~…ん、個人的にはOnUpdateイベントがUIスレッドである必要性が理解できません。Silverlightコントロールから値を取得するだけならば別段UIスレッドである必要はないわけですし…。でも、UpdateとDrawの実行順序を保証させたいがためだとすれば…なんとなく理解できるかも?いやでも…なんでかなー…。

ということで、全体的な完成度は少し残念な感じの「WPDT 7.1β」ではありますが、ことSilverlightとXNAの相互運用に関してはホント素晴らしいと思います。 SilverlightとXNAの共存なんて、まるで夢物語のようですね~♪いうなれば、仮面ライダーBLACKとシャドームーンが共闘するくらいアツイ 展開!…かな?かな?

WP7のゲームループはUIスレッド?(前編)

「WPDT 7.1β」では、SilverlightとXNAを相互運用することが可能となりました。この機能を利用することにより、例えばSilverlightのコントロールとXNAのゲームロジックを同一の画面内で共存させることが可能となります。個人的にイチ押しの機能です。

ちなみにこの機能は、Silverlight5のDrawingSurfaceクラスにおいて、より洗練された形で実装されています。ですがそれでも、利用する際にはXNAに関する知識が少なからず必要となります。また、WP7も将来的にはSilverlight5ベースになるでしょうし、今のうちからXNAの使い方を理解しておくのも良いと思います。

話が少しそれましたが、左記画像のアプリではこの機能を利用して、UIコントロールをSilverlightで制御し、ローザさんの3DモデルをXNAで制御しています。メッシュデータの利用方法など、XNAの基礎知識に関してはまた別の機会にご紹介するとして、今日の本題はXNAのゲームループからSilverlightのUIコントロールを操作することは可能か?という内容です。たとえば、3Dモデルのアニメーションが終わったらUIコントロールの状態を変更する、みたいなことが可能かどうかということですね。

まずはおさらい!

SilverlightとXNAを相互運用する場合、WP7.1ではGameTimerクラスを利用します。早い話、このタイマーがOnUpdateイベントとOnDrawイベントを交互に発行…つまりゲームループを発生してくれるので、これらのイベント内でXNAの更新処理と描画処理をしてあげればよいわけです。概略は右記画像のとおりです。仕組みは単純ですね~!このため、当然ではありますが、SilverlightのUIコントロールをXNAのゲームループから参照しても、別にビルドエラーにはなりません。でもじゃあ実行時に、XNAのゲームループ内からSilverlightのUIコントロールを操作した場合は…一体どうなるのでしょう?

やってみよう!

ということで、やってみました!結論から先に申しますと、XNAのゲームループからSilverlightのUIコントロールを操作することは可能です!やったね、たえちゃん!…ん?でも待てよ。たしかSilverlightのUIコントロールはUIスレッド以外から操作することはできないはず…。なのにうまく動くのは…なぜ?

調べてみよう!

これを検証するために、左記のようなコードにおいて、SilverlightのイベントハンドラとXNAのゲームループのスレッドIDを取得し比較してみました。すると面白いことに、上記のスレッドIDは完全に一致します。このことから、XNAのゲームループはUIスレッド上で実行されていることがお分かりいただけると思います。GameTimerクラスは、普通のTimerというよりはむしろDispatcherTimerに近い感じなんですね。ともあれこれで、XNAのゲームループ内からSilverlightコントロールをガンガン更新しても何ら問題ないことがわかりました。実際に、最大FPSで回しているゲームループからテキストボックスのテキストを(1秒間に数十回)変更しても、問題なく更新されます。

潜む危険…

…でも、この事実に喜んでばかりもいられません。なぜなら、この事実にはある重大な危険性が潜んでいるからです。ということで、続きは次回の投稿で!

WPDT 7.1 β リリース!

ということで、Mangoイベントも無事に終了です。イベント終了後に間もなく、日本語入力に対応した開発環境『Windows Phone Developer Tools 7.1 Beta』が公開されました!バージョンが7.1で…しかもβ?という謎仕様!このタイミングでそんな悠長にバージョン刻んで大丈夫なのか心配にはなりますが、なにはともあれ最新版のWPDT公開です!今日はその簡単なレビューをお届けします。

とその前に!当たり前のことではありますが、今回公開された最新の『WPDT7.1』はあくまでβ版です。このため、アプリケーションの開発には可能な限り従来のWPDTを利用することを強く推奨致します!これホント!

日本語入力に…対応!

WP7のエミュレータが日本語入力に対応しました!もちろんフリック入力も可能です。さらに「カーブフリック」と「確定フリック」をマスターすれば、すべての文字を1フリックで連続入力することが可能になります!これはスゴイ!ちなみに、日本語入力パネルから英語入力パネルを呼び出すことも可能なのですが、英語入力パネルから日本語をローマ字入力することはできないようです。せっかく呼び出せるんだから、これはできるようにしてほしいなぁ~。

日本語UIは…微妙@私的見解。

うまく言葉にできませんが…、個人的な日本語UIの第一印象はとにかく微妙!何が悪いって、たぶんUIのフォントだと思います。ただでさえ日本語は、英語と比べて文字数が多くなりがちなのに、このフォントではピボット等の次世代的なコントロールとミスマッチな気がしてなりません。もちろん、UIは未だ開発途中であるということは重々承知していますが…。せめてタイトルは太字にするとか、カーニングを調整するとか、いっそ明朝体にした方がよっぽどオシャレな気がします。でも一説によると、このフォントはWP7用に開発された素晴らしいフォントであるとのこと。えーと…マジですか。わたしにはもう国内で成功しているビジョンが見えないんですが…。でもでも、人の感性は千差万別ですものね。

SilverlightとXNAの相互運用は…最高!

SilverlightとXNAの橋渡しを実現するために、UIElementRendererというクラスが追加されました。簡単な話、要はこのUIElementRendererクラスを利用して、スプライトにSilverlightのUIパーツを描画し、XNAで描画したゲーム画面とセル画のように重ねることにより、SilverlightとXNAの共存を実現しています。また、従来のXNAと同様にコンテンツパイプラインも利用できるみたいです(ここはまだ未検証)。これでSilverlightエンジニアに対するゲーム開発の敷居がグッと低くなりそうですね!ちなみに、アプリケーションバーを不透明状態で利用するとコントロールの位置と入力座標がズレるので要注意です!個人的にはこの機能が「WPDT7.1」イチ押しかもです~!

BackgroundAgentは…期待通り!

この辺りは情報があふれているので割愛します。概ね予想通りのことができますね!…ていうか、タスク切り替えってどうやるの?戻るボタン長押しじゃないの?う~ん、わからない(汗

IE9は…使いづらい。

エミュレータ上ではIE9のパフォーマンスを実感することができませんので、ここではあくまで操作性のお話です。IE9では、アドレスバーが下に移った(アプリケーションバーに組み込まれた)ことにより、タイピングがしやすくなりました。でもこれにより、結果的にアプリケーションバーの「ボタン」と「メニュー」という統一されたUIデザインを自らブチ壊している気がしてなりません。現に、使用頻度の高いタブの切り替え機能がアプリケーションバーメニューに降格されてしまったため、タブ切り替えという機能を一目で認識できないですし、操作にかかる手間も1クリック増えてしまいました。慣れれば問題ないのかもしれませんが、慣れなきゃわからないUIなんてメトロなデザインじゃないのでわ…(汗?

タイルは…おもしろい!

WPDT7.1では、NotificationServiceを利用しなくてもタイルの更新が可能になりました!しかも、タイルを登録する際には画面のURL(パラメタ含む)を指定するようになっているので、アプリケーションのあらゆる画面(パラメタ含む)にリンクするタイルを登録することが可能です!さらに、登録したタイルは定期的に裏表を切り替えることもできるんです!これはおもしろいですね~!ちなみに、無限にパタパタするタイルを作ろうと思ってShellTileDataクラスの拡張を試みましたが無理でした。ちょっぴり残念。

データベースは…大歓迎!

これはホント、スゴク便利~!WPDT7.1では、そのものズバリなSqlClientクラスは存在していません。このため、従来のSQLをガリガリ記述するような感じではなく、DataContextを利用した、あくまで今風のデータベースアクセスが可能になってます!うーん、これは素晴らしい!

コマンド対応は…中途半端。

ボタンコントロールで普通にコマンドが使えることを確認しました!でも、相変わらずApplicationBarIconButtonはコマンドに対応していません(そもそもButtonBaseじゃないし)。あとMSDNにはUIElementのEffectが利用できるって書いてあるのに利用できない。…なんか中途半端?

エミュレータは…やばい。

エミュレータ上で動作させた場合、アプリケーションの起動が劇的に早くなりました!ただし、エミュレータ全体の動作としては何かもっさりした感じにグレードダウン。他にも、パノラマのスクロール時に画面が固まったり、IE9が稀にオート無限スクロール状態に陥ったり、DatePickerから日付を選択した際に画面がバグったり、…とにかくエミュレータのバグらしき現象が目立ちます。

特にひどいのは、既存のアプリケーションの挙動がいろいろと変わってしまうこと。例えば、パノラマ内に水平スクロール可能なリストボックスを配置したアプリケーションにおいて、リストボックスを水平フリックした場合、従来のWPDTではきちんとパノラマが遷移してくれました。しかしWPDT7.1では、上記の場合にパノラマが遷移しなくなってしまいました。子のイベントが親に飛んで行かないイメージです。これがSilverlight4ベースになったことによる弊害なのか、それともエミュレータがまだβ版だからなのか、非常に判断に苦しみます…。なお、実機の挙動は従来のWPDTと同様です。

まとめ。

う~…ん、全体的にもう少し完成度の高いリリースを期待していたのですが…ちょっと残念かもです。期待を膨らませすぎたのか、テンション&モチベーションが降下気味…。しかも今回はβ版ということを確認せずにうっかりメインPCにインストールしてしまったのが痛かった!やはり現状のアプリケーション開発は従来のWPDTで行ったほうが無難だと思います…いやホント。とにかく、開発用に従来のWPDTを再構築しよう。

The junior high school 2nd grade syndrome!

クラウドガールの第一話が公開されましたね~!これで日本のマイクロソフトさんも、やっと何かがはじまった気がします!(*≧∀≦)ノ

がんばれメトロ!

メトロちゃんも、非公式ながらがんばって告知しますよー!どこかで見たことのある告知な気もしますが、そこはみなさん立派な大人。そっと目を瞑っていただけると幸いです。といいますか、要は日本でWP7が盛り上がってくれれば何も言うことはありませんので、願わくばクラウディアさんのようにWP7の公式な擬人化が登場してくれることを切に願います~(*´∀`*)

Mangoイベント!

そして今日はMangoイベントの日!といっても、海外で開催されるイベントですので、日本時間に換算すると24日の深夜に開始となります。このMangoイベントにおいて、WP7に関する最新情報が発表されると見てまず間違いありません!ちなみに『Mango』というのはWP7における次期アップデートのコードネームです。おそらく一般的には『Windows Phone 7.5』として発売されることになるであろうこのバージョンは、日本語に正式対応した初の大規模アップデートとなっています。このため、国内のWP7技術者は固唾を呑んでこの瞬間を待ち詫びていたわけです!どんな情報が発表されるのか、今から楽しみで仕方がありませんね!『WPDT for Mango』が公開されたら、しばらくはイラストなんて描いてる暇はないだろうなぁ…(´∇`*)ワクワク

Mangoが意味するもの…それは!

もしや『Mango』とは、その形状と色から暗に『覇王の卵』を比喩したものであり、ともするとこのMangoイベントとはまさにIT業界における『蝕』そのものである可能性があーだこーだ… ←楽しみすぎて中二病が発症中@ベルセルクを知らない人はごめんなさいです。

Microsoft Developer Forum 2011!

『Microsoft Developer Forum 2011』に参加してきましたー!MDFは、マイクロソフトさんが自社の展望と最新の技術情報を開発者の方々に公開するイベントです。今年はマイクロソフトさんの本社が品川に移ったため、会場は品川のインターシティホールを利用して開催されました。

基調講演!

まずはバルマーさんの基調講演からスタートです!生バルマーは今回はじめて見ましたが、やはりストリーミングでは味わえない迫力がありました!マイクなしでも十分声おっきいし…。講演の内容は技術的な情報というよりも、今後の動向や展開などの概略に焦点を置いた内容となっていました。残念ながら、特に新しい情報はなかったです。そしてやっぱり最後は「デベロッパー!デベロッパー!デベロッパー!デベロッパー!」(4回言った)。

メインセッション!

メインセッションでは、大場さんを筆頭にエバンジェリストの方々が最新技術に関する概要を紹介しました。ただし、MIXのストリーミング配信などを見た人にとっては、やはり目新しい情報はありませんでした。WP7に関しても、Mangoに関する最新情報は明日のMangoイベントまで秘密のようです。う~ん、ちょっと残念。そして最後は、巷で話題のクラウドガールが大々的に紹介されました!MSさん的には今後クラウディアさんにかなりの注力をしていくとのことですので、日本のMSもやっとこさ始まった感じです!ただ残念ながら、会場の反応はイマ一つだった気がします。もちろん、わたし的には大興奮でしたけども。

交流会!

そして、交流会では何とまさかの生クラウディアさん撮影会!実写版クラウディアさん登場ですよぅ~!(*´д`*)メインセッションで成りを潜めていた隠れクラウディアファンも、ここぞとばかりに長蛇の列!もちろん、わたしも一緒に写真を撮らせてもらいました!ほかにも、いろいろな技術者の方々とお話しできてホックホクです!こういうイベントの醍醐味は、やはり交流会にアリですね~!(≧∀≦)そんなこんなのMDFでした!

WP7の非公式イメージキャラクター(改善編)

先日、あまり深く考えずにWP7の擬人化キャラクターとして「メトロ」ちゃんを描いたわけですが、さっそく知人からダメ出しを喰らいました(ノ∀`;)…。いわく、「萌えキャラ界隈はすでに飽和状態だから、ロリ女の子キャラよりショタ男の子キャラの方が断然プリキュアいいよ!」とのこと。なるほど、確かに一理…あるのか? ∑(´゚Д゚`;)まぁでも、せっかくいただいたご意見ですので、今回は「メトロ」ちゃんの設定をもう少し掘り下げてみたいと思います。

WP7のテーマは2通り!

WP7には、「ライト」と「ダーク」という2通りのテーマ(背景色)が用意されています。左記の画像のうち、左が「ライト」で右が「ダーク」のテーマですね。ということは、これを利用して「メトロ」には「2つの人格(というか性別)が共存している」みたいな設定にすればいいじゃない!しかも、例えば「くしゃみをしたら性別が入れ替わる」なんて設定にすれば、これはもうスゴク新しいんじゃないですかねー!…どこの1/2だよ。

ふたりはひとり!

ということで、マジメに考えるのがもう面倒くさいので、WP7の非公式イメージキャラクター「メトロ」は、「メトロくん(ライト)」と「メトロちゃん(ダーク)」の二人から成るキャラクターってことにしようと思います。要するに、ロリとショタでオールレンジをカバーする感じ。メトロくんのコスチュームがかなりヤッツケな感じですが、この辺りのディテールは追々煮詰めていこうと思います。自分のデザインセンスのなさにヘコむ…。

WP7の画面遷移時に指定するパスを短縮

WP7のSilverlightアプリでは、画面を遷移する際にUriを指定します。たとえば左記のような感じですね。でも、この際に指定するUriのパスは文字列なので、どうしてもリファクタリングに弱かったりします。また、異なるモジュールの画面に遷移する場合、モジュールの名称まで含めたパスを記述する必要があるため、パスが冗長になりがちです。そこで今回は、画面遷移時に指定するUriのパスを短縮する方法をご紹介します。

どうやって実現する?

正確には、パスを短縮するというよりは、パスを別の文字列にマッピングします。そして、画面遷移時にこのマッピング情報を利用し、指定した文字列に対応する画面に遷移できるようにします。これにより、例えば、”Page1″と指定するだけで”/View/Page1.xaml”画面に遷移できるようになります。

実装方法はどうするの?

パスと文字列をマッピングするためにはUriMapperクラスを利用します。このクラスのインスタンスをApp.xamlのリソースとして作成し、パスと文字列のマッピング情報を定義します。なおこの際、文字列はパターンマッチングな感じで記述できるのがミソです。その後、上記クラスのインスタンスをApp.xaml.csのルートフレームのUriMapperプロパティに設定します。なんと手順はたったのこれだけ!詳細は上記を参照してください。

使い方はどんな感じ?

NavigationServiceを利用して画面を遷移する際に、定義したマッピング情報に基づいて、文字列とパスのマッチング&変換が自動的に実施されます!具体例は左記のとおり。この方法を知っていると、いろいろと潰しが効くので便利ですよ~!(≧∀≦)ノ

サンプルプログラム!

サンプルプログラムはこちらからダウンロードすることが可能です。
UriMapperSample

WP7のバリデーション(改良編)

前回のサンプルプログラムでは、テキストを変更したタイミングでOKボタンの活性状態が変化しないことが問題でした。今回はこれを解決してみましょう。

なんでこうなるの?

この問題は、WP7ではない普通のSilverlightでも同様に起こります。なぜなら、Textプロパティにバインドしたソースの更新タイミングは LostFocusが既定値となっているためです。このタイミングは、Bindingクラスの『UpdateSourceTrigger』を利用することにより指定することが可能であり、既定値である『Default』値の振る舞いはコントロールごとに異なります。たとえばIsCheckedなどの依存関係プロパティでは、更新タイミングが『PropertyChanged』であるのに対し、Textプロパティだけは、パフォーマンスを考慮して更新タイミングが『LostFocus』となっているのです。この辺りの詳細はMSDNをご覧くださいね。

つまり、テキストが変更されるたびに検証処理を実施(OKボタンの活性状態を更新)するためには、TextプロパティのBindingのUpdateSourceTriggerをPropertyChangedに指定すれば解決できそうですね。以下のような感じです。さっそくやってみましょう!

でもね、できません(´・ω・`)!だってね、Silverlightで指定できるUpdateSourceTriggerの値はDefaultとExplicitだけなんです!って、なんじゃそらー!(`Д´)

ならどうするの?

ということで、毎度おなじみBehaviorを使用して解決しましょう!やるべきことはいたってシンプルで、テキストボックスのTextChangedイベントが発生したときに、Textプロパティのバインディングソースを更新します。これにより、UpdateSourceTriggerにPropertyChanged値を指定した場合と同様の効果を得ることができます。

Behaviorの実装方法とXAMLはこんな感じになります。なお、このBehaviorを利用した場合はバインディングソースがBehavior内で更新されるため、TextプロパティのUpdateSourceTriggerには『Explicit』を指定してあげると尚良しです。これで納得の挙動になりました!

サンプルプログラム!

改良版のサンプルプログラムは以下からダウンロードすることが可能です。
ValidationSample(v2)