.NET FrameworkのSocketクラスでUDP Multicast Group Socket通信を行う - データ受信編

ずっと前に、Windows Phone 7とWindows PCをUDP Multicast Group Socket通信で連携させる方法をポストしました。このポストでは、Windows PC→Windows Phone 7のデータの流れのみ説明していました。このポストでは、Windows Phone 7がMulticast Groupに送信したデータをWindows PCで受信する方法を解説します。Windows PC側で使うのは.NET FrameworkのSocketクラスです。 Multicast Group通信を、おさらいしておくと、Wi-Fiなどで同じローカルネットに接続されたデバイス間で、アドホックに1 to Manyで通信するためのプロトコルです。グループIPアドレス(224.0.0.1~239.255.255.255が利用可能。一部WS-*で予約されているものもあり)とグループポート番号をあらかじめ決めておいて、そのアドレス、ポートにデータをUDPで送信すると、そのグループにJoinしているデバイスだけに、一括してデータを送信できます。このプロトコルを使えば、Ad-Hocにネットにつながったデバイスを発見して、Peer-To-Peerでつないだりすることが出来ます。例えばどこかのWi-Fiスポットで、そのネットにつながっているデバイス間でチャットしたり、家庭のWi-Fiに家電をつないで、即、家のHEMSやPC,スマホと連携、AV機器連携などにも使えます。1度の送信でグループにJoinしている全てのデバイスにデータが送信できるので、プログラムもシンプルです。このプロトコルは、Wi-Fiルータのローカルネット内で閉じているので、インターネット上にデータは出て行きません。ローカルネット内のデバイスをグループ化してローカルで済む通信に対してはこのプロトコルを使い、必要なデータ送受信・サービスの利用のときのみクラウドと連携といったシナリオも可能です。 能書きはこれぐらいにして、早速Socketを使った受信方法を解説します。通信相手として、Windows Phone 7をご用意ください(シミュレーターでもOKです)。そして、Windows Phone 7側は、http://msdn.microsoft.com/ja-jp/library/ff431744(v=vs.92).aspx から公開されている”マルチキャストソケットのサンプル”の、左側のアイコンの右横にあるリンクからC#/VBのサンプルをダウンロードして動かしておいてください。グループアドレス、グループポートは、このサンプルで使われている、224.0.0.1と52274を使います。 Windows側のコードを解説していきます。 まず、Multicast GroupにJoinするためのコードですが、     IPAddress groupAddress = IPAddress.Parse(“224.0.1.1”);    int groupPort = 52274;     Socket receiveSocket = new Socket(                AddressFamily.InterNetwork,                SocketType.Dgram,                ProtocolType.Udp);     receiveSocket.SetSocketOption(               SocketOptionLevel.Socket,               SocketOptionName.ReuseAddress,              1);     IPEndPoint ipep…

0

“.NET Gadgeteerで電動モーターカーを作る”プロジェクト始動

非常に多忙の中、.NET Gadgeteer(.NET Micro Framework)で電動モータカーを動かすプロジェクトを始めました。 .NET Gadgeteerでモーターをドライブし、ついでに、WiFiでWindows Phoneとつないで、リモコンで動かします。3/21のUX-TVで完成品をお見せする予定です。 使うものは、以下の通り。 Fez Spider Fez Spider用WiFiモジュール Fez Spider用モーター駆動モジュール タミヤ模型のツインモーターギヤーボックス タイヤ4本 電池ボックス ユニバーサルプレート そして、IS12T ※ギヤーボックス、タイヤ、ユニバーサルプレートなど、街の模型屋さんで普通に売られている、タミヤ模型の部品を使っています。シングルスレッドな脳みそをタイムスライスして擬似マルチタスクで動かしながら、作っていきます。作っていく過程は都度、ブログにアップしますね。乞うご期待  

2

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

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

ページ遷移を考慮した、時間のかかる複数データダウンロード処理 – Windows Phone 7+Twitterを例に

一つ前の投稿で、時間のかかるデータダウンロード一発こっきりのケースを説明しましたが、その続きです。 Twitterでは、膨大な量の項目を”カーソル”を利用してダウンロードしていくAPIを持っています。             var friendsUri = new Uri(“http://api.twitter.com/1/statuses/followers/” + targetUsername + “.xml?cursor=” + cursor);            var twitter = new WebClient();            twitter.DownloadStringCompleted += new DownloadStringCompletedEventHandler(twitter_FollowersDownloadCompleted);            twitter.DownloadStringAsync(friendsUri); 前回の投稿でも似たようなコードが出てきましたが、DownloadStringAsync()メソッドの引数のUriにカーソルの値を追加すると、最大100項目ずつダウンロードが可能です。cursorを”-1”と指定すると最初の100個が取得できます。そして、イベントハンドラのコードで、e.ResultをXElementでParseした結果に対し、             string cursor = message.Descendants(“next_cursor”).First().Value; で、次に続く百項目を取り出す為のカーソルを取得できます。この値を使って逐次非同期ダウンロードを繰り返していくと、全ての項目がきちんと(Twitter APIは単位時間当たりの使用制限があるのでそれを超えなければの話ですが)ダウンロードできます。次に続く項目はない場合、カーソルは”0”になります。 更に、毎度ダウンロードが終わった時点で、各時点のカーソル値とひも付けてダウンロードした内容をファイル化しておけば、逐次ダウンロードの途中で、アプリが終了され、再開した時にも、保存したファイルを辿っていって、ファイル化されていないところからダウンロードを始めれば、処理に無駄がありません。まとめたコードを以下に紹介します。     string targetUsername;                // 調査対象のユーザーアカウント名は事前に代入しておく     GetFollowersData(string cursor)  // OnNavigatedToや、ボタン、タップのハンドラーで、cursorを””にしてコール    {        string fileName = “followers” + targetUsername + cursor + “.xml”;        var storage = IsolatedStorageFile.GetUserStorageForApplication();        if…

0

ページ遷移を考慮した、時間がかかるデータダウンロード処理 – Windows Phone 7+Twitterを例に

Windows Phone 7では下に並んだ3つのボタンでいつでもページ遷移ができます。Twitterなどネットからデータをダウンロードするのに時間がかかる場合、当然、ダウンロード処理中にページ遷移が起こり得ます。TwitterのREST APIでデータをロードする場合、WebClientというクラスを使います。例えば、あるユーザーアカウントのフォロワーのリストを取得する場合には、             var friendsUri = new Uri(“http://api.twitter.com/1/statuses/followers/” + targetUsername + “.xml” );            var twitter = new WebClient();            twitter.DownloadStringCompleted +=                    new DownloadStringCompletedEventHandler(twitter_FollowersDownloadCompleted);            twitter.DownloadStringAsync(friendsUri); というコードでWebClientクラスのDownloadStringCompletedイベントにハンドラを登録し、DownloadStringAsync()メソッドでデータロードを開始して、データロードが終わったらtwitter_FollowersDownloadComplatedメソッドがコールされるというように、非同期APIを使います。ちなみにハンドラ側では、         void twitter_FollowersDownloadCompleted(object sender, DownloadStringCompletedEventArgs e)        {            XElement message = XElement.Parse(e.Result);            var query = from m in message.Descendants(“user”)                        select new TwitterUser                        {                            Id = m.Element(“id”).Value,                            UserName = m.Element(“name”).Value,                            ScreenName…

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

Windows PhoneからSkyDriveにファイルをアップロードする方法

既にMarketplaceから公開されているSensor Checkerを見ながら思った。計測結果をファイル化したいと。都合よくLive SDK v5.0が公開され思った。SkyDriveに計測結果をアップしたら便利だよなと、無料で25GBだし…ということで、計測結果をファイル化してSkyDriveにアップする機能拡張を行いました。既に機能追加版はMarketplaceにアップロードしたので、Rejectされなければ直ぐアップデートされるはずです。 SkyDriveへのファイルアップロードは、意外と簡単。方法を順番に説明していきます。 1. 最新版のLive SDKをダウンロード&インストール http://www.microsoft.com/download/en/confirmation.aspx?id=28195 からファイルをダウンロードして、ダブルクリック&インストールします。 2. Windows Phone向けのアプリケーションプロジェクトを作成し、参照設定にLiveのコンポーネントを追加 Microsoft.Live Microsoft.Live.Controls を追加します。 3. Appクラスに、LiveConnectSession型のスタティックなプロパティを追加する Appクラスは、App.xaml.csにあります。 using Microsoft.Live; を先頭に加え、     public LiveConnectSession LiveSession { get; set; } を定義しておきます。 これで準備は万端です。 4. Windows Liveへのサイン用ページを作成 プロジェクトにページを一枚追加します。そのページの先頭のほうに、名前空間を以下の様に追加します。 <phone:PhoneApplicationPage     …    xmlns:mc=”http://schemas.openxmlformats.org/markup-compatibility/2006″    xmlns:live=”clr-namespace:Microsoft.Live.Controls;assembly=Microsoft.Live.Controls”    FontFamily=”{StaticResource PhoneFontFamilyNormal}”    … そして、Windows Liveのサインインページにナビゲートする為のボタンを追加します。             <StackPanel Name=”SigninPanel” Grid.Row=”0″>                <TextBlock Text=”Signin to SkyDrive” FontSize=”24″ HorizontalAlignment=”Center”/>               …

0

Windows Phone FMラジオを操作するアプリの注意点(バックグラウンドの音楽演奏)

というわけで、またFM Radio Wave Level CheckerがRejectされてしまいました。「音楽を演奏した状態でこのアプリを起動して、端末のボリュームスイッチ(IS12Tの場合は、電源ボタンの下)を押し、表示されたPlayerメニューバーで音楽を止めると、例外発生するよ」と、フィードバックには英語で書いてあり、実際やってみると、あ本当だ!!。 発生したExceptionをじっと見ると、どうやらXna FrameworkのFrameworkDispatcherのUpdate()がコールされていないのが原因と判明。前に、マイクロフォンからの音を録音する方法をこのブログで紹介した時紹介した、FrameworkDispatcher、どうもアプリでPlayer系を弄る時には、回さないと駄目らしい。 ということで、ページのクラスに、OnNavigatedTo()メソッドを加え、         private DispatcherTimer loopTimer;        protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)        {            loopTimer = new DispatcherTimer();            loopTimer.Interval = TimeSpan.FromMilliseconds(50);            loopTimer.Tick += delegate { try { Microsoft.Xna.Framework.FrameworkDispatcher.Update(); } catch { } };            loopTimer.Start();             base.OnNavigatedTo(e);        } とコーディングし、OnNavigatedFrom()メソッドで、このloopTimerのStop()メソッドをコールするルーチンを追加しました。 これでやってみると、音楽の演奏を止めた時の例外が発生しなくなったので、これでOKなのだろうなぁ…ということで、また懲りずにMarketplaceに登録。幾らなんでももう大丈夫かな?結果は多分クリスマスイブ辺り。プレゼントになるかどうか、お楽しみ。 教訓:Microsoft.Xna.Framework.Media.MediaPlayerを弄るアプリを作る場合は、FrameworkDispatcherのUpdate()コールループを入れるべし!! …SilverlightプロジェクトよりXnaプロジェクトで最初からやったほうが良いかも。 FM Radio Wave Level Checkerに関する過去の投稿は以下のとおり FM Radio Wave Level Checkerの最初の投稿…

0

Windows Phoneページ遷移には色々あるよね

Sensor Checkerのダウンロードがもう直ぐ400を超えそうな勢いで、非常に嬉しいな…ということで、機能追加アップデートを開始しました。グラフ化された計測値のデータを、別のアプリで活用できるように、 E-Mailで送る SkyDriveにアップロードする の二つを予定していてE-Mail送付の機能は既に完成済み。このポストでは、先ずはE-Mail送付の機能を追加した時に気がついた、ページ遷移ロジックを作る時の注意点をメモります。 E-Mailを送付する画面としては、こんな感じのものをよういしました。 測定したデータをContentに表示し、一番上のテキストボックスにE-Mailアドレスを入力します。Memo欄に、測った時の状況(例えば、「100メートルダッシュ!」とか「素振り100本!」とか「力いっぱいトゥ!」とか)を入力、Sendボタンをタッチすれば、E-Mailアドレス送付タスクが起動して、メールの本文にXML形式で記述された計測値が格納されて送付される寸法。E-Mail送信は、 var task = new Microsoft.Phone.Tasks.EmailComposeTask();task.To = address;task.Subject = “sensor”;task.Body = “…”;task.Show(); で、Windows Phoneが提供するE-Mail送信機構が起動して簡単に送付できる。ここまではよかった。だが、しかし… このページの色々な表示は、OnNavigateTo()メソッドの中で作っています。で、E-Mail送信用ページが表示されて、送信が終わると、このページに戻ってくるわけですね。で、当然OnNavigatedTo()メソッドがまたコールされるわけです。まぁ当たり前だね。しかし、センサーページでやっていることをひっくるめた処理の流れを書くと、 センサーページでStartボタンをタッチ→Stopボタンがタッチされるまでセンサーで計測した値をメモリに保持 センサーページでSendボタンをタッチ→メモリに保持した内容をXML形式でIsolatedStorageにファイルとして保存 保存したファイル名を付加して、このページに遷移 ※ここまでがセンサー計測ページ側の処理 このページのOnNavigatedTo()メソッドがコールされる センサーページから渡されたデータのファイル名を、NavigationContextから取り出す ファイルを開き、Contentに書き込む ファイルはもういらないので、IsolatedStorageから削除 となっていて、センサーページからこのページに遷移した時は全く問題ないけれど、E-Mail送信ページから戻ってきた時にOnNavigatedTo()メソッドを実行しようとすると、4番のステップから実行されるので、既に削除してしまったファイルを開く破目になる。当然エラー発生。センサー計測のページからの遷移の時と、E-Mail送信ページからの戻りの時は区別するコードが必要って訳です。 まぁ、「単なる設計不足醬!!」といわれればそれまでですが、人間、あるページから能動的に遷移を書いているときは注意が向いても、終わって自動的に戻ってくる時は案外抜けがちなので、設計時にご注意。   ついでに、メールアドレスを手入力するのはとっても面倒なので、Microsoft.Phone.Tasks名前空間のEmailAddressChooserTaskを使って、アドレス帳から選択可能にする機能を加え多野で紹介しておく。 var task = new Microsoft.Phone.Tasks.EmailAddressChooserTask();task.Completed += new EventHandler<Microsoft.Phone.Tasks.EmailResult>(task_EMailAddrSelectCompleted);task.Show(); とやればこちらも簡単にアドレス選択用のデフォルト機能を使え、登録したハンドラがコールされると、選択結果が返ってくるので、それをアドレス用テキストボックスに代入すればよろし。 更に、センサー計測値なんてものは、多分自分にしか送信しない(筈)なので、ころころ変えるもんじゃない。だから、Sendボタンをタッチした時のハンドラで、 var appSettings = System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings;appSettings[“address”] = textBoxAddres.Text; と書いておけば、アプリの設定として保存される。それで、OnNavigatedTo()内で、 var appSettings = System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings;if (!appSettings.Contains(“address”)){    appSettings.Add(“address”,””);}textBoxAddress.Tex…

0

Windows Phone FM Radio Level CheckerがMarketplaceでまたReject?

あ~あ、またRejectされちまったい…て事で、現在Windows Phone 7のMarketplaceに申請中のFM Radio Wave Level Checker(まぁ…なんちゃってアプリ系ですが)、2回目のRejectを食らいました。前回は、「フレームカウンター表示されとんでぇ」でしたが、今回は、何でRejectされたか紹介しておきます。多分Radio系をいぢるアプリを作る時の参考ぐらいにはなるでしょう。 アプリケーションへのRequirementsに、「ユーザーがバックグラウンドで音楽聞いてるとき、邪魔しちゃ駄目ん」という項目があります。FM Radio Wave Level Checkerは、ラジオをONにしてある周波数の電波の強度を測る為、バックグラウンドで演奏されている音楽が必然的に止まってしまいます。そこんとこ意識してなかったので、2度目のRejectを食らったわけですわ。 音楽がPlay中かどうかは、次のコードで簡単にわかります。 if (Microsoft.Xna.Framework.Media.MediaPlayer.State == Microsoft.Xna.Framework.Media.MediaState.Playing){    … この条件式がtrueなら、ユーザーに「You 止める?」というメッセージを出して、ユーザーの同意を得て止める操作が必要なんですね。演奏終了は、MediaPlayer.Stop()をコールすれば良いのですが、MediaPlayerの状態を変えるメソッドをコールするには、マイクの使い方で説明した、処理ループを用意しないといけないらしいので、今回は時間もなく、「止めてん」という表示を出すに留めました。 これで、Marketplace通るといいなぁ・・・

0