新築瓦葺二階建てブログ

新築瓦葺二階建てブログ

もともとは為替と株ネタが中心でしたが、最近では、Android, Silverlight, GoogleAppEngine(GAE)も話題にしてます。自転車ネタも最近では少なくなっちゃいました。。一部でも共感持てるひとがいたら、どしどしコメントしてくださいね。基本、寂しがりやさんなので。

Amebaでブログを始めよう!

ちょっとまじめな話。。。


Android + Windows(サーバー)という組み合わせで、いろいろな方法を模索しています。


この所、GPSから受信した経緯度を使って、MapViewにピンを打ってみたりしていましたが、

ただ、これでは、自分が移動しないとピンも移動してくれないんですよね。。。


そこで今回は、直接、Android とつなげる訳ではありませんが、MapViewに自動的に移動する物体を表示させる事を、最終目標としています。


方法としては、


 1) Google Maps API WebService を利用して、移動物の経路情報を取得する。

 2) 経路情報をデコードし、SQL Server に保存する。

 3) 移動物用のテーブルを用意し、一時間に50km進む移動物を、2秒間隔で更新する。


という方法をとりたいと思います。


で、第一回目の今回は、


 1) Google Maps API WebService を利用して、移動物の経路情報を取得する。


を実施してみようと思います。


まずは、Google Maps API WebService を呼び出す所です。



string origin = System.Web.HttpUtility.UrlEncode(textBox1.Text, Encoding.UTF8);
string destination = System.Web.HttpUtility.UrlEncode(textBox2.Text, Encoding.UTF8);
string mode = "driving";
string url = "http://maps.googleapis.com/maps/api/directions/xml?"
            + "origin=" + origin + "&destination=" + destination + "&mode=" + mode + "&sensor=false";



※textBox1, textBox2 にはそれぞれ、出発地・目的地を入れます。


Google Maps API WebService を呼び出すときに注意する点としては、、、


 ・C#で扱いやすいように、xmlで返るようにしています。

 ・検索条件(出発地・目的地)には、住所やランドマークなどを日本語で入力すると思いますので、URL Encode しています。

 ・URLの一番最後の「sensor」は必須オプションです。※おまじないだと思ってください。


これを、 XmlDocument を使って呼び出します。


XmlDocument doc = new XmlDocument();
doc.Load(url);

取得した doc を確認すると、返信されたxmlが返ってきます。


あとは、XPath を使って、データを取得しましょう。

私は直接、要素をしていする方法を取りました。


string status = doc.DocumentElement.SelectSingleNode("/DirectionsResponse/status").InnerText;
if (status != "OK")
{
    textBox3.Text = status;
}
else
{
    string polyline = doc.DocumentElement.SelectSingleNode("/DirectionsResponse/route/overview_polyline", nmr).InnerText;
}

経路検索が行えなかった場合には、「status」に OK 以外が返ってきますので、必ずハンドリングするようにしましょう。

サンプルは、今後使用する、「overview_polyline」を取得する方法を記載しています。


次回は、overview_polyline をデコードします。
アプリケーションの開発で、DB を使用するのは普通にある出来事になったが、今までを振り替えってみると、DB にどのような処理をさせるか、これといって定まっていない。

もちろん、要件として違いが出るとは思うが、これだけDBサーバーが高機能化したのだから、もっとDB に仕事を任せたらいいのだと、最近では思うようになった。

DB にまつわる用語として、マルチDB なる考えがあるが、この考え方に少し疑問も持っている。
この考え方、極端な考え方かもしれないが、DB に仕事をさせないと言った構造を目指さざるを得なくなる。
結局のところ、いかに効率のいい関数やSQLの書き方あったとしても、そこにDB 依存があった時点で切り捨てられる。
結果、AP によるキャッシュやコミット処理の段組が発生し、効率化の為に無理な構造を強いられる。

これは無駄ではないのか?

そもそも、マルチDB の恩恵は誰がうけるのか?
アプリにDBがバンドルされてると思えば、大したことではないのではないか?

無闇な宣伝文句に左右されず、無駄だと気づいてほしい。

そういう意味でも、GAPやAzureはいい。何せ、考えなくて良いのだから!



Android携帯からの投稿
社内のとあるweb システムのスマホ対応を検討するようにと、指示があったらしい。

別に悪い話じゃないのですが、担当者曰は、スマホでも見れるように大きく表示されるように対応するようです。

なんかちょっと違うと感じるのは、私だけ、、、なんでしょうか?

スマホ対応っていうんだから、てっきりアプリを作るんだ!と思ってました!

そういえば、なんかのアプリでも、明らかにwebの画面を内部で表示しているものがあったけど、それ以来、使ってないなー。
表示も遅いし、なんか、パケットを無駄に使われてるかと思うと腹がたった!

なんでアプリにしないんだろうか?
ひょっとして、やり方知らないからだとか?

いつも言われるのが配布の問題だけど、バージョンチェックと配布先へのリンクを貼るだけなんだけどなー。
自動配布も出来るんかな?


Android携帯からの投稿