Build 2013でのWindows 8.1 + 周辺デバイスコンテンツ紹介

先月(2013年6月)サンフランシスコで開催されたBuild 2013。Windows 8.1に関する様々な技術情報が発信されました。このブログでは、Windows ストアアプリで数多あるWindows対応周辺機器との連携用に追加された、Win RT API(Windows Runtime API)を紹介します。先ずはざっくり関連セッションを紹介し、その後、このブログで、各セッションの話題を深堀していこうと思っております。 先ずは、2-023 Building Apps That Connect with Devices をご覧ください。このセッションでは、Windowsに対応する様々な周辺機器とストアアプリが連携する基本事項が紹介されています。 関連セッションとしては、 3-025 Building Windows apps that use scanners いわゆる、イメージスキャナーとの連携方法 2-041 Strongauthentication: Building apps that leverage virtual smart cards in enterprise, BYOD, and consumer environmentsスマートカードを使ったストアアプリ 3-029 How to point-of-sale devies in your appバーコードや磁気カードリーダーをストアアプリで使う 2-9110 Biometrics-fingerprints for apps指紋認証 3-9034 Using Geolocation…

1

“今日から使える”アプリコンテスト – 紹介

Digi International主催の”今日から使える”アプリコンテストの紹介です。詳しくは、 http://www.digi-intl.co.jp/campaign/contest/index.html を見ていただきたいのですが、このコンテストは、Digi International様の製品を使って「これは便利、こんなのが欲しかったわ」と奥様も納得して、直に使えて役に立つ、生活に密着したアプリケーションを作って競い合う、アプリケーションコンテストです。 日頃、何だかよくわからない裸のボードを使ってゴニョゴニョやって、「やった完成!!」と見せびらかしても、奥さんには白い目で見られるそんなあなた(あれ、私のこと?)、このコンセプトでアプリを作って投稿しませんか? このコンテスト、日本マイクロソフトも協賛させていただいております。もう随分昔(といっても2年前ですが)、TechDays2010のキーノートで披露した、Windows 7 Sensor & Location Platformで、ZigBee無線付テーブルタップをPCにつなぎ、さらさらヘアーをドライヤーの熱風で靡かせて、電力見える化のデモをやりましたが、このデモも、ZigBee無線付テーブルタップがDigi International様の製品なので、一応、このコンテストの範疇になります。他にも、Digi Connectは、Windows CEをOSとして使っていたり、XBee Wi-Fiドングルは、超有名なドングルなので、私のブログの読者の中には、家に帰れば2、3個転がっていそうですね。こういった製品をWindows 7 PCや、Windows Phone 7、.NET Micro Framework等と連携させるとか、デバイスとWindows Azure上のサービスを連携させるとか・・・ 組込みGeek系突っ走りだと、いまひとつ、「奥様の納得」感を得るのは難しいので、是非、パソコンやクラウドなどの連携まで試してみてくださいね。 コンテストの募集要項をよぉっく見ると、賞品の項目に「マイクロソフト賞」とありますね。この賞は、Digi Internationalさんの製品と、日本マイクロソフトの製品とを組み合わせて活用し、「奥様も納得」するアプリを作っていただいた応募者向けの賞です。 締切は5月18日、まだまだ先です。どしどし応募してくださいね。3月22日には、関連セミナーも実施予定です。「え~組込み系は良くわからないんだよねぇ…」という開発者の方も、「え~クラウドとかスマホとかPCアプリとか、IT系は判らないんだよねぇ…」という方々どちらも、この機会にチャレンジです!!  

0

.NET Micro Framework + Windows Azure + Windows 7 + Windows Phoneでセンサークラウドプロトタイプ

最近、電力見える化や農業クラウドなど、センサークラウドが実用化の時期を迎えつつあります。タイトルに挙げたテクノロジーを使えば、センサークラウドのプロトタイプが廉価で手軽に実現できるのでは、ということで投稿してみました。想定としては、 このポストで説明した方法でプロトタイプを作成し実証実験 結果をもとに本格稼動に向けて、デバイスやサービス、アプリを構築 といった流れを考えています。 センサークラウドの基本構成要素は、 センサーデバイス+小型組込み機器   センサーノードとしてフィールドにばら撒かれる データ収集用ネットワークストレージ    ネットワーク上で稼動 データ分析・活用ネットワークサービス   ネットワーク上で稼動 システム管理者向けアプリ          PC等で稼動 ユーザー向けデータ活用アプリ       PC、タブレット、スマートフォンなどで稼動 になるかと思います。最初に挙げたセンサー機器で測定対象の各種データ(電力や温度、湿度、大気圧、照度、などなど)を収集し、2番目のストレージに格納、3番目のサービスで活用し、4番目でシステムを管理、5番目でユーザーが見たり指示したり、といった構成です。あい これらとタイトルに挙げた技術をそれぞれマップしていくと、 センサーデバイス+小型組込み機器 プロトタイプを作るなら、.NET Micro Frameworkデバイスが利用可能です。.NET Micro Frameworkが動く市販のデバイスは、GHI Electronics社のFezシリーズやNetduinoがあります。これらは、ボードだけなら4000円~1万円程度、接続可能なセンサーデバイスも多数売られている(数百円から数千円)ので、プロトタイプのレベルなら多額の投資がなくても利用可能です。アプリケーションはC#やVBを使って、.NET Framework系のネットワーク機能が豊富に揃ったライブラリを使えるので、デバイス上のプログラムも容易に作成できます。.NET Micro FrameworkはApache V2ライセンスで提供されるオープンソースなので、ライセンスフィーもいりません。 データ収集用ネットワークストレージ ネットワークストレージには、Windows Azureのストレージサービスや、SQL Azureが利用可能です。Webから申し込み手続きをしてすぐ使え、実験中だけ稼動し、終わったら、契約を終了可能です。実験環境としては最適でしょう。 データ分析・活用ネットワークサービス こちらは、Windows Azureが、データ分析・活用サービスのホスティングサイトとして利用可能です。こちらもSQL Azureと同様、使いたい時だけ使えるので、プロトタイプ向きといえるでしょう。また、Windows Azure上で作成したサービス向けクライアントアプリはWindows系アプリだけでなく、アンドロイドやiPhone向けのものが作成可能です。 システム管理者向けアプリ こちらは、Windows 7 PCが利用できます。Windows Azure上にRIAとして構築しても構いませんし、ネットワークサービスと連携するPC上で動くアプリを用意するのも良いでしょう。特に専用のPCを用意する必要もなく、通常のPCで十分です。もしゲートウェイや専用デバイスが必要であれば、Windows 7の組込み版OSであるWES7や、Windows Embedded Compact 7 デバイスが利用可能です。 ユーザー向けデータ活用アプリ こちらは、Windows 7 PC、Windows Phone 7を使って、RIAサービスや、それぞれのOS上で動くクライアントアプリを作るこことも出来ます。ブラウザ内で動くアプリだけでよいのではと思う方もいるかもしれませんが、画面の大きさや操作性、各デバイスが装備している機能との連携を考えると、今後はむしろネットワークサービスとして連携してデバイス二インストールされて動くアプリのほうが主流になるのではないかと私は予想してます。デバイス側もどんどん進化しますからね。 以上、ざっと紹介しました。上の組合せであれば、開発環境はVisual Studio 2010で全て開発可能ですし、同じ言語、同じ流儀のライブラリーを使える、つまり同一スキルセットでプロトタイプ作成が可能です。本格システムの場合は、認証や暗号化などセキュリティが必要になりますが、App Fabricを使えば、何とかなりそうです。 図にするとこんな感じ 以上、簡単ですが、今後も方々でこの話題は話したり、ブログ書いたりする予定なのでよろしくお願いします。ではまた…

0

ETロボコン計測システムクラウド化トライ

ETロボコン2011チャンピオンシップ大会では、スタンドアロンシステムが稼動している横で、実は、クラウド化したシステムの実験をやっていました。ETロボコン計測システムの概要は、一つ前のポストhttp://blogs.msdn.com/b/hirosho/archive/2011/11/17/etroboconracetrackingsystempart1.aspx を見てもらうこととして、この実験では、隣でスタンドアロンシステムに対して行っている操作とまるっと同じ操作をして、ちゃんと動くか、応答性能は問題ないか、一大会あたり幾ら位かかるか、について検証を行いました。 実験システムは、図のように構成しました。 IISで動いているWCFサービスをWindows Azureにそのままポーティング DBをSQL Azure上に作成(スキーマはEFから生成したSQL文を使用) WCFサービスのDB参照先の接続文を一行SQL Azure用に修正 PC側のETRoboConTrackingSystem、ETRoboConResultEditorExcelのHTTP/SOAPの参照URLを修正 以上、これだけで、結果としてはちゃんと動きました。私は方々でデバイスとクラウド連携というお題で講演していますが、私の講演をお聞きいただいた皆さんの中には、「同じコードで直ぐ動きます、Azureでクラウドをはじめることは簡単です」と言っていたのを記憶に留めている方も多いと思います。言っているとおりに動いています(嘘つきにならなくてよかったです)。 移植作業は、梶原さんという技術者が協力してくれました。Twitterで協力者募集したところ、申し出てくれた方です。私は酷いので、「Codeplex上にアップしているプロジェクト群のうち、ETRoboConTrackingServerプロジェクトをAzureに挙げればよいですよ。お願いします」の二言で丸投げ。でも、動きましたね。梶原さんありがとう。 まぁ、大会当日の朝、さぁ動かそうとして、何故かDBの定義が一箇所だけ古く、最初動かなかったのですが、程なく解決。その後は、正式本番システムの横で、同じオペレーションを行って問題なく動きました。携帯電話のディザリングでPCをネットにつないだ場合は、転送速度の問題で応答性能悪すぎで、タイムアウト連発。ワイヤードでLANにつなげば特に問題はありません。むしろVista PCのスタンドアロンより、Win7+Azureのほうが体感的に早い気がしました。 実稼動に向けては、セキュリティやアクセス権、ローカルで持てばよい情報もあるのでDBのスキーマ変更とそれに伴うロジック変更が必要ですが、まぁなんとかるでしょう。クラウド側もクライアント側も、C#、.NET Frameworkと同じスキルを活用できるのも魅力ポイント。 気を良くした太田は、あ、そういえば、WCFサービスをWindows Phone 7アプリで接続するのも簡単だっけと思い出し、準備の傍ら、WP7アプリもちょこっと作って、WCFサービスによるHTTP/SOAPにアクセスして、大会情報の取り出しと順位結果表示のサンプルアプリも作っていた次第。こちらも後でブログにポストの予定です。

0

Windows Phone 7.1 アプリ Sensor Checker 更新

MSC2011 D1-401セッションで披露した、センサーデモアプリを公開しているサイト、http://mangosensorchecker.codeplex.com に最新のコードをチェックインしました。 アニメーションに関するコードなど、関連する一連のブログで紹介したものが全て入っています。コンパスのVisual表示では、BingMapとも組み合わせてみました。現在Sensor Checkerという名前でMarketplaceに登録しているものとほぼ同じです。ただし、BingMapは各アプリ用に必要なキーがあり、それを公開するわけにはいかないので、省略しています。Bingまpとの連動を試したい方は、http://www.bingmapsportal.com/ で開発者登録とアプリ登録をして自分のキーを取得してPageCompassVisual.xamlのmap要素にCredentialProvider属性を追加してください。 このデモアプリに関するほかのポストは、http://blogs.msdn.com/b/hirosho/archive/2011/09/30/windows-phone-sensor-checker.aspx から辿ってくださいまっせぇ。  

0

Windows Phone 7.1 簡単なメーター表示

MSC2011 D1-401セッションのセンサー系フォロー最終投稿です。ここではデモでお見せしたコンパス(Visual系)を紹介します。 コードは、http://mangosensorchecker.codeplex.com/SourceControl/list/changesets のPageCompassVisual.xamlと、PageCompassVisual.xaml.csを見てください。 図のコンパスみたいな絵がCompassセンサーのTrueHeadingの値に従って回転します。 ファイル名は、Compass.pngとしておきます。 この画像はPowerPointを使ってちょろっと作って、PNGファイルとして保存したものです。これをWindows Phone 7 Silverlightアプリケーションプロジェクトのフォルダーにコピーして、ソリューションエクスプローラーで既存のファイルの追加を使って、プロジェクトに追加します。 そして、この画像を、以下のXAMLコードでPageに貼り付けます。             <Canvas Grid.Row=”1″ Width=”400″ Height=”400″>                <Image x:Name=”imageCompass” Canvas.Left=”20″ Canvas.Top=”20″ Source=”Compass.png”>                    <Image.RenderTransform>                        <TransformGroup>                            <RotateTransform x:Name=”compassRotation” CenterX=”180″ CenterY=”180″ Angle=”0″/>                        </TransformGroup>                    </Image.RenderTransform>                </Image>            </Canvas> 太文字で示した部分が、Imageをはめ込む為の定義。図を描くためのキャンバスを用意して、図を置く左と上の位置を指定して、ソースファイルを指定すればOK。そして、後でこの図を回転するために、赤字で示したRotateTransformを定義しておきます。図は360×360ピクセルで作ってあるので、CenterX/CenterYをその中心に指定してAngleの値を変えていけばこの図画回転するという寸法。 コードビハインド(PageCompassVisual.xaml.cs)側では、センサーの使い方基礎で説明したようにCompassクラスのインスタンス(名前はmySensorとしておきます)を使うために必要なコードを書いておいて、CurrentValueChangedイベントのハンドラーの中で、             Deployment.Current.Dispatcher.BeginInvoke(delegate()            {                double trueHeading = e.SensorReading.TrueHeading;                tbTrueHeading.Text = String.Format(“{0:0.000}”, trueHeading);                compassRotation.Angle = trueHeading;            }); XAMLで用意しておいたRotateTransform要素(名前はcompassRotation)のAngleに値をぶち込めば、図のNは計測された真の北極の方向に合わせて、図が回転します。 以上、これだけで回転しちゃうのですが、これだと、Compassセンサーの値が変わるたびにカクカク動いてしまいあまり格好良くないんです。 で、単に値を更新するのではなく、BeginInvokeブロックの中身を、以下のようなコードにすると、                 double durationUnit…

0

Windows Phone 7.1 ページ遷移とセンサー管理

Windows Phone 7.1のSilverlightアプリケーションはPage単位で作成されています。このポストではページの遷移とセンサーのライフサイクル管理を結びつける一例を解説します。 注意点でも説明したように、センサーを無駄に動かすと無駄に電池を消費するので、センサーのライフをきちんと管理しなければなりません。アプリケーションの設計上、センサー計測を止めるための何がしかのトリガーが入っているはずですが、例えば戻るボタンを押されればセンサーを使うロジックが含まれたページは消えて前に表示されていたページが表示されるので、戻るボタンが押されたタイミングでセンサーを停止する必要もあります。このことを考えると、センサーのライフサイクルの大枠の管理はページの遷移に紐付けておいたほうがすっきりするし、確実にセンサーのライフサイクル管理ができます。 ページの遷移は、ApplicationPageクラスを継承する各ページクラスのメソッドをオーバーライドすることによってハンドリングが可能です。 protected override void OnNavigateTo(System.Windows.Navigation.NavigationEventArgs e)対象ページが表示される時にコールされる protected override void OnNavigateFrom(System.Windows.Navigation.NavigationEventArgs e)対象ページから別のページに遷移する時にコールされる 先ず、ページが表示されている間センサーインスタンスを保持するためのクラスメンバーをページクラスに追加します。 private Motion motion; そして、対象ページが表示される時にコールされるOnNavigateToメソッドに以下のようなコードを書きます。 protected override void OnNavigateTo(System.Windows.Navigation.NavigationEventArgs e){    if (Motion.IsSupported)    {        motion = new Motion();        motion.CurrentValueChanged += new EventHandler<SensorReadingEventArgs<MotionReading>(motion_CurrentValueChanged);    }} ここで、センサーのインスタンスを作っておきます。これで、ページが表示された後に実行されるコードが動く時には、必ずセンサーインスタンスが存在していることになります。また、センサーはデバイスと一対一のものなので、インスタンスはただ一つだけあればよいので、これで十分です。それから計測データを非同期的に受け取るためのハンドラーもここで登録しておきます。そうしておけば、別の場所でStartをかけるだけで計測が開始されます。 次に、対象ページから別のページに遷移する際にコールされるOnNavigateFromには以下のようなコードを書きます。 protected override void OnNavigateFrom(System.Windows.Navigation.NavigationEventArgs e){     if (motion != null)    {        motion.Stop();                motion.Dispose();    }} ここでは、センサーの計測停止と、リソースの解放処理を行います。センサークラスにはセンサーの状態を保持するプロパティは無く、計測中かどうかを判断することはできないので、念のためStop()をコールしています。もちろん、Stop()メソッドのコールは、ページ表示中ずっとセンサーを使い続けるアプリを除いては、本筋のロジックのほうできちんとコーディングすることを忘れないでください。センサー4クラスは、IDisposableインターフェイスを実装しています。センサーに限らず、IDisposableインターフェイスを実装しているクラスは、システム内部でリソースを食っているものが多いので、Dispose()メソッドをコールして使い終わったらリソースを解放しておきましょう。 はい、これでおしまい。こんな感じでプログラムを書いておけば、ページの表示開始・終了に合わせてセンサーの生成・消滅を行うことができます。…

0

Windows Phone 7.1 センサー利用時の注意

Windows Phone 7.1センサー利用時の注意点を幾つか挙げておきます。センサープログラミングに関しては、センサープログラミングの基礎を見てください。 その1) いつでもあると思わないでね Windows Phoneのハードウェア仕様を見ると、CompassとGyroは、オプションであると明記されています。製品によってはCompassとGyroscopeは使えない場合があるということです。この二つのセンサーが搭載されているかは、両方のクラスのスタティックプロパティのIsSupportedを参照すればわかります。このプロパティがfalseならば、残念ながらそのデバイスにはセンサーが搭載されていないことになります。アプリケーションを設計する時には、必要なセンサーが無い場合の対策を入れておきましょう。例えば、 搭載されていない場合は提供機能を縮小する 代替策がある場合は、別のセンサーやエミュレーションで機能ロジックを補完する 必要なセンサーが搭載されていないことを表示する Marketplaceのアプリ概要説明で、必要なセンサーを明記 などです。 if (!Compass.IsSupported){    MessageBox.Show(“王舞我”);    … その2) 必要な時だけ使う 繰り返しになりますが、センサーデバイスを使っているとそれなりに電池を食います。無駄にセンサーであたうぃを取得し続けると、他のいざという時電池切れ・・・なんてことになりかねないので、センサーが必要になるタイミングと必要なくなるタイミングをきちんと設計して、Start()、Stop()メソッドをコールしましょうね その3) その値、本当に正しい? 4つのセンサークラスには、IsDataValidというプロパティが用意されています。特にCurrentValueを使って同期的に値を取得する場合、この値がtrueの時だけ正しい値を取得可能です。センサーはセンサーデバイスなどハードウェア的な仕掛けを使うので、そのハードウェアの初期化やら何やらの手続きが必要でStartメソッドをコールしてから、実際に値が取得できるまで時間がかかる場合もあります。例えばMSC2011のD1-401でお見せしたARデモでは、Compassが直ぐには計測できなかったので、以下のようなコードを書きました。 var compass = new Compass();compass.Start();while (!compass.IsValid){    System.Threading.Thread.Sleep(100);  // この秒数が妥当かどうかは現時点では不明。無限ループの可能性があるので、何回かトライしたらExceptionを発生するなどの対策が必要} デバッガーでのステップ実行では人間がF10を押す間にIsValidがtrueになってしまうので、このコードを入れなくても、ちゃんと動いてしまいます。知らないとなかなか見つけられない問題なので、ステップ実行では動作するのにするっと動かすと正常に値が取れていないような場合は、IsValidを疑ってみましょう。 その4) その値、本当に正しい? Again 物理的事象を精密に計測する場合、精度と誤差を必ずきちんと考える必要があります。大雑把な動きや方向などをアプリに取り込む場合は問題ありませんが、ある程度正確な値が必要な場合は、例えば平均をとって慣らすなどの処理を入れましょう。(まぁもともとコンシューマーデバイスのセンサーなので、あまり厳密な計測には向かないかも…です)Compassには、Calibrateというイベントが用意されています。これはTrueHeadingの値が±20度以上違うとシステムが認識した時に発火するイベントです。ナビゲーションアプリケーションなど、ある程度正確な方位が必要なアプリを作る場合には、このイベントにもきちんと対応しましょう。キャリブレーションの方法はまた別途ポストしますね。 その5) なるべくMotionセンサーを使いましょ Motionセンサーはアプリケーションが利用しやすい形にセンサーデバイスの計測値を加工してくれるので、出来る限りMotionセンサーを使いましょう。 その6) 実行スレッド 非同期的に計測データを取得するには、CurrentValueChangedイベントにハンドラーを登録して、システムから通知を受けますが、ハンドラーをコールするスレッドは、アプリのメインスレッドとは異なるので、そのままSilverlightのコントロールを操作しようとするとExceptionが発生します。しばらくぶりにプログラミングすると、大抵忘れているので、Exception発生した時には思い出してください。 Deployment.Current.Dispatcher.BeginInvoke(()=>{    var accel = e.Accelaration; このブロックの中での処理は、メインスレッドのディスパッチャーキューに入って順番に実行されているので問題ないですが、コントロールアクセスがなく単にクラスのメンバー変数を更新する場合など処理を委譲せずにそのままハンドラーをコールしたスレッドで処理を行うような場合は、lockやMutexなどを活用してきちんとスレッド間の排他処理を入れましょう。   と、まぁ、こんなところでしょうか。 センサーとは、デバイスを取り巻く実世界の様々な事象を数値化して取り込んでくれるものです。その類のフィーチャーは、Accelerometer、Gyroscope、Compass、Motionの4クラス以外にも、位置情報やカメラ、マイク、FM電波の強度、電池の残りなど、他にも沢山あります。これまであまり活用されていなかったフィーチャーを使い倒して、魅力的なアプリケーションを是非、開発してくださいね。

0

Windows Phone 7.1 Locationの使い方

Location、Location…過去のブログのポストを見ていたら、まとまって説明しているものが無いので、改めて通して紹介します。D1-401のセミナーでも紹介したことだし。 地図やナビゲーション、自分の周辺に関わる何かを扱うアプリケーションでは、位置情報取得は必須です。Windows Phone 7.1にはSystem.Device.Locaiton名前空間に、GeoCoordinateWatcherクラスが用意されていて、デバイスの現在位置の取得が可能です。位置情報というとGPS?って思う人も沢山いらっしゃるでしょう。しかしこのクラス名にはGPSのジの字もありませんね。位置情報は、GPSで取得できるだけでなく、携帯基地局やWifiのルーター等、色々なソースから取得が可能です。純粋に位置情報を取得することを考えると、GPSは位置を取得するための単なる手段であることに気がつくでしょう。 Windows Phoneの位置情報取得機能は、GPSやその他の位置情報取得をひっくるめて位置情報を提供するように作られています。と、能書きはこれぐらいにして、早速使い方を説明していきます。 先ずは、プロジェクトの参照設定に、System.Deviceコンポーネントを追加します。 プログラムの適切な場所に、 using System.Device; を書いておきます。http://blogs.msdn.com/b/hirosho/archive/2011/10/11/windowsphone71sensorprogramingbasis.aspx で説明したセンサーと処理の流れは似ています。同期的な位置情報取得と非同期的な位置情報取得方法をTPOに合わせて選択可能です。 先ずは、同期的な処理から。 var watcher = new GeoCoordinateWatcher(GeoPosiitonAccuracy.Default);watcher.Start();var position = watcher.Position;watcher.Stop(); 基本はこれだけ。ただし、watcherのStartメソッドをコールしてから、位置情報が取れるまでは初期化や情報収集などで時間がかかる場合があるので、実際にはStatusプロパティがReadyになるまで待つ必要はあります。Positionは、Locationというプロパティが用意されていて、その中にLatitude(緯度)、Longitude(経度)が格納されています。他にもいくつかプロパティは用意されているのですが、まx、Altitudeという高度を示すプロパティだけあると、このポストでは行っておくことにします。 さて、非同期処理はといえば、センサーの時と同様、GeoCoordinateWatcherのインスタンスはクラスのメンバー変数として定義しておきます。 private GeoCoordinateWatcher watcher; 初期化フェーズの時に、インスタンスを作成し、位置情報が更新した時にコールされるハンドラーを登録します。 watcher = new GeoCoordinateWatcher(GeoPositionAccuracy.Default);watcher.StatusChanged += new EventHandler<GeoPositionStatusChangedEventArgs>(watcher_StatusChanged);watcher.PositionChanged += new EventHandler<GeoPositionChanged<GeoCoordinate>>(watcher_PositionChanged); そして、いよいよ位置情報が必要になるタイミングで、 watcher.Start(); をコールして、位置取得処理を開始します。すると、watcherは、”Initializing”→”Ready”に状態変更(watcher_StatusChangedがコールされ、引数でStatusが渡される)しつつ、”Ready”になって位置情報が取得できたら、watcher_PositionChangedがコールされます。ハンドラーのコードは以下のようになります。 private void watcher_PositionChanged(object sender, GeoPositionChangedEventArgs<GeoCoordinate> e){    Deployment.Current.Dispatcher.BeginInvoke(() =>    {        var timestamp = e.Position.Timestamp;        var location =…

0

Windows Phone 7.1 Sensor プログラミング基礎

MSC D1-401セッションのフォローアップ第一弾です。 この投稿では、Windows Phone 7.1 Mangoに搭載されているSensorの使い方を解説します。 Windows Phone 7.1のアプリケーションで利用可能なセンサーは以下の4種類です。 Accelerometer加速度センサー Gyroscopeジャイロセンサー Compassコンパス Motionモーション それぞれMicrosoft.Devices.Sensorsという名前空間の下に対応する同じ名前のクラスが用意されています。これらのクラスはすべて主要なメンバーとして、以下が用意されています。 メソッド: Start()値の計測開始 Stop()値の計測終了 Dispose()センサーのDispose。もう使わなくなったらお方付け プロパティ: CurrentValueセンサー計測値の現在の値 IsDataValid計測データの妥当性 IsSupportedセンサーサポート状況 Stateセンサーデバイスの状態 TimeBetweenUpdatesCurrentValueChangedイベントを発生する時間間隔 イベント: CurrentValueChangedセンサー計測値を受信するためのイベント 4つのセンサークラスは全て上のリストにあるメンバーを持っています。CurrentValueだけ名前は一緒でも、Accelerometerは、AccelerometerReading、GyroscopeはGyroscopeReading、CompassはCompassReading、MotionはMotionReadingという異なる型になっていて、それぞれのセンサーの種別に応じた値群を保持しています。 センサーにアクセスするプログラムは非常に簡単です。先ずは、プロジェクトの参照設定に、Microsoft.Devices.SensorsとMicrosoft.Xna.Frameworkという2つのコンポーネントを追加します。前者はAccelerometerをはじめとする4つのクラスが入ったコンポーネントです。後者は、センサーの計測値がXNA FrameworkのVector3をはじめとするクラスを使っているので、必要です。 センサーの値の取得は、同期的な取得と、非同期的な取得の二つが用意されています。同期的なスタイルは、処理の流れの中でセンサーの計測値が直ぐ必要な時に使い、非同期的なスタイルは、センサーの値が計測されるたびに、それをトリガーにして処理を行う時に使います。 先ず、同期的なスタイルを説明します。流れは以下のようになります。 using (var sensor = new Accelerometer()){    sensor.Start();    var currentValue = sensor.CurrentValue;    … 処理    sensor.Stop();} 最後にDispose()メソッドをコールする必要があることから、usingブロックで囲んでいます。コードの中のAccelerometerの部分をGyroscopeやCompass、Motionに変えても問題なく動作します。currentValueのプロパティは、それぞれのセンサー種別で異なりますが、基本骨格はまったく同じです。 次に、非同期的なスタイルを説明します。この場合は、同一のセンサーインスタンスが方々のメソッドでアクセスされるので、センサーインスタンスは、クラスメソッドとして定義しておきます。 private Accelerometer sensor; // クラスのメンバー変数として定義しておく そして、PageのコンストラクタやPageのLoadやNavigationで開かれるタイミング、もしくはセンサーからのイベントを受ける必要のあるロジックの初期化処理で、インスタンスを生成し、イベントハンドラーを登録します。 sensor =…

0