あいてぃーとふぼふ

「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秒間に数十回）変更しても、問題なく更新されます。

潜む危険…

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

ということで、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を再構築しよう。

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

がんばれメトロ！

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

Mangoイベント！

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

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

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

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

WP7のテーマは2通り！

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

ふたりはひとり！

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

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

どうやって実現する？

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

実装方法はどうするの？

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

使い方はどんな感じ？

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

サンプルプログラム！

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

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

なんでこうなるの？

この問題は、WP７ではない普通の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)

バリデーションとは入力値の検証処理のことです。ところで、WP7におけるバリデーションってどうするのが正しいのでしょうか╹ω╹)？

標準の画面ではどうなってるの？

ちょっと調べた限りだと、WP7のBindingクラスにもValidatesOnExceptionsやNotifyOnValidationErrorプロパティは存在しています。しかし、DataAnnotationsの検証属性やIDataErrorInfo、INotifyDataErrorInfoといったクラスは存在していません。この時点で、従来のSilverlightのように赤いToolTipが表示されるようなことは期待できそうにありませんね…(´・ω・`)

なので、WP7のMS謹製な画面でバリデーションが必要そうな項目を探してみたところ、メールアドレスを入力するテキストボックスにおいて、必須項目やアドレスの形式を判定してました！で、結論から申しますと上記の画面では、入力値が正しくない場合に画面内の入力内容を確定するボタンが押せなくなる仕様となっていました。このため、ユーザさんが不意にアドレスの形式を誤ってしまったとしても、なぜボタンが押せないのかを即座に理解することができません。このシンプルさがメトロなのだといわれると…もうなにも言い返せませんよね~！ (>ω<、)

実装するとこんな感じ！

ということで、WP7アプリでバリデーションを実施する場合、MVVMライクに行くならICommnadのCanExecuteメソッドで実施するのがよさそうですね。さっそく簡単なサンプルプログラムを作成してみました。このサンプルでは、テキストボックスに値が入力されていない場合にOKボタンが非活性状態となり、ついでにOKボタンを押下したときにメッセージボックスを表示する仕様とします。上段がView、下段がViewModelの実装例です。

ICommnadのCanExecuteメソッドを利用すると、コントロールのIsEnabledプロパティなどを明示的に設定していなくても、CanExecuteメソッドの戻り値に応じてコントロールの活性状態を自動的に変更してくれますので便利です。ほかにも、MvvmLightのButtonBaseExtensionsクラスやPrismのIInteractionRequestを利用することにより、上記の仕様を簡潔に実装してみました。

サンプルプログラム！

詳細な内容は以下のサンプルプログラムをご覧ください。
ValidationSample

ちょっとまって！

でも、実はこのサンプルプログラムにはちょっとした問題があります。実行してもらえればわかると思いますが、テキストボックスからロストフォーカスしたタイミングで検証が実行されるのです。つまり、テキストを変更してもそのタイミングでは検証処理が実行されない（ボタンの活性状態が変化しない）ため、テキストを空にしてもなんかOKボタンが押せそうな気になります（実際は押せませんが）。できれば１文字入力するごとにOKボタンの活性状態を変化させたいですよね。ということで、これを解決する方法は次回の投稿でご紹介します！…でもやっぱり一筋縄じゃいきません（汗

はじめてお披露目する左記のキャラクターは、Windows Phone 7 の非公式イメージキャラクター『メトロ』ちゃんです。今年は日本におけるWindowsPhone７元年ともいえる年（になる予定）！WP7が日本でコケない成功するために、メトロちゃんには微力ながらWP7界隈を盛り上げていってもらいたいと願っています。…というか、マイクロソフトさんはそろそろWP7をメディアに露出していかないと、気付いた時には手遅れになってそうで心配です。ともあれ、今後、当サイトでプッシュしていきたい擬人化キャラクターNo.１のメトロちゃんを、どうぞよろしくお願い致します。

どのへんがWP7？

それを聞くのは野暮というものです。でも、強いて言うなら手に持っている『Windows Foam 7』くん。ね、Windows Phone 7っぽいでしょう？他にも『配色』はWP7のメトロを参考にしていますし、『アホ毛』もなんとなく”7”っぽくしてみました。また、ローザさんと同じマイクロソフトさん謹製の姉妹製品という位置付けなので、年齢設定をロリ低めにデザインしています。決して他意はありません。あと、何故か『コスチューム』がメイド服ベースですが、決して他意はありません。

夢はスマートに！

『Windows Phone 7のことをいろいろなひとがすきになってくれるよう、いっしょうけんめいがんばりたい』。それがメトロちゃんの夢です。どうですか？なんか応援してあげたくなりませんか？さぁ、みなさんもメトロちゃんと一緒にWP7を大いに盛り上げていきましょう！…たとえそれが負け戦になろうとも。

そんなこんなで、新たなマスコットキャラクターの『メトロ』ちゃんともども、今後ともモトスクウェアソリューションをよろしくお願い致します！

前回に引き続き、今回はLoopingSelectorコントロールをデータバインドで使用する方法をご紹介します。

どうやって実現する？

今回の方法では、LoopingSelectorとDataSourceを『Behavior』クラスにより間接的にデータバインドさせます。つまり、両者の間にBehaviorクラスを仲介させることにより、データバインドを橋渡しさせるわけです。この方法であれば、前回作成した『ILoopingSelectorDataSource』実装クラスを再利用できますし、少ない工数で実現することができそうですね！

こんな感じのXAMLになる！

先に、完成形となるXAMLの配置方法を左記に記載します。前回投稿したXMALと比較してもらえるとわかると思いますが、パッと見はほとんど同じように見えますね。大きな違いとしては、前回はDataSourceを直接設定していたのに対し、今回はBehaviorを設定してデータバインドを定義しています。設定されたBehaivorの内部では、バインドされた情報をもとにLoopingSelectorのDataSourceを初期化して、バインドされたプロパティとDataSourceを相互に関連付けます。

Behaviorを実装しよう！

では肝心のビヘイビアを実装しましょう。ソースコードは左記のとおりです。一見するとかなりのコード量に見えますが、前半は依存関係プロパティの定義が占めていますので、実際の処理はそんなに多くありません。重要なポイントは、依存関係プロパティの型がBindingクラスであるという点です。通常はIEnumerable型だったりint型だったりするわけですが、そんなことをしようものならたちまち『XamlParseException』が発生します。ですので、依存関係プロパティをBinding型とすることにより、バインド情報そのものを受け取るようにします。この対処方法は、WP7版のMvvmLightやPrismにおいても採用されていますね。

ただしこのままでは、Bindingクラスから値を取得することができないため、バインドされたプロパティとDataSourceの橋渡しが行えません。そこで活躍するのが、PrismやMvvmLight に含まれている『BindingListener』クラスです。このクラスを利用することにより、バインドされたプロパティの値を取得することができるようになり、晴れて双方向のデータバインドを実現することが可能となります！ヽ(ﾟ´Д｀)ﾉﾟ

サンプルコードはこちらから！

LoopingSelectorに関するサンプルコードは以下のリンクからダウンロードすることが可能です。なお実行には『Silverlight for Windows Phone Toolkit』がインストールされている必要がありますのであらかじめご了承ください。
LoopingSelectorSample

さいごに！

ということで、最終的にはだいぶ簡潔にデータバインドを実現することができました。工数などに応じて適材適所だとは思いますが、BehaviorやTriggerActionは、ある程度使いこなせると非常に便利な機能ですね！それにしても、なんか最近イラストばかり描いていたから、久しぶりにシステムエンジニアらしい更新をした気がする…（;￣ー￣

WP7には『LoopingSelector』というコントロールが存在するのですが、知らない人も結構多いみたいです。それもそのはず、LoopingSelectorは『Silverlight for Windows Phone Toolkit』に含まれているコントロールであり、かつ『Microsoft.Phone.Controls.Primitives』というマイナーな名前空間に属しています。しかもToolkitのサンプルプログラムにも載っていません。

コントロールの機能としては、一覧が無限にループするアイテムリストのようなものと考えてもらえれば問題ないと思います。DatePickerやTimePickerコントロールでも利用されているため、目にしたことのある人は多いハズ。今回はこれを単体で利用する方法をご紹介します。

ちょっと実装しづらい

このコントロール、実はちょっと実装しづらいです。たとえばListBoxやComboBoxといったコントロールで一覧を設定する場合、ItemsSourceプロパティにIEnumelableコレクションを設定すればOKです。同様に、LoopingSelectorにもDataSourceというプロパティが存在していますが、設定できる型が『ILoopingSelectorDataSource』となっています。このため、IEnumelableコレクションを設定すれば利用できるという代物ではありません。しかも、上記のインタフェイスを実装したクラスは標準で用意されていないため、自前で実装しなければなりません。ちょっと面倒ですが仕方ありませんね。

ILoopingSelectorDataSourceを汎用的に実装しよう

ILoopingSelectorDataSourceの実装はそれほど難しくありません。今回は汎用的なコレクションを指定できるように実装してみたいと思います。実装内容は右記画像の通りです。意外と簡単ですね！肝は『GetNext』と『GetPrevious』の２つのメソッドです。GetNextメソッドでは、コレクションの次のオブジェクトを返却するように実装するわけですが、コレクションの末尾に到達した場合は再度先頭のオブジェクトを返却するようにします。こうすることにより、コレクションを無限にループさせているわけですね～。GetPreviousメソッドはGetPrevメソッドの逆回りです。

XAMLに配置しよう

では実際にLoopingSelectorをXAMLに配置してみましょう。左記のような感じになります。LoopingSelectorのDataSourceプロパティに先程実装したクラスを指定し、適当なコレクションを指定します。なお余談ですが、LoopingSelectorのItemSizeプロパティを指定し忘れると何も表示されないのでごっそい焦ります。う～ん…でもこうなってくるとItemsSourceやSelectedItemにデータバインドができればいろいろと便利そうですよね～。よし、やってみましょう！(≧∀≦)/

データバインドで利用しよう

できません(´・ω・`)！なぜなら上記クラスはFrameworkElementの派生クラスではないので、データバインドのソースとして親のDataContextを利用することができません。となると、先程作成したクラスにFrameworkElementを継承させればよいのでは？と思いますが、そう簡単な話でもありません。しかもWP7では、Silverlight3の制約に輪をかけて制限が厳しいで、何かするとすぐさま『XamlParseException：AG_E_PARSER_BAD_PROPERTY_VALUE』エラーが発生します。にんともかんとも。

データバインドで利用したい！

それでも、どうしてもデータバインドで利用したい(>ω<、)！という人は、BehaviorとBindingListenerによる実装方法を次回の投稿でご紹介します。サンプルプログラムもその際に公開しますね！