2014年7月31日木曜日

Waypoint Navi プロジェクトほぼ完了 - Episode 2

Waypoint Navi のマニュアルも書いたので無事公開した.
欲しい人はこちら→Waypoint Navi

開発当初から公開は考えていたけど,ふと思い立って広告を入れてみることにした.
まぁ,知名度が壊滅的に無いのと,頻繁に立ち上げるアプリでもないので,ハナから収入は期待していないけど,どれだけ収入があるのか経験しておくものいいかなと.

最初は Google Play に登録しないと広告収入はないと思っていたのだけど,野良アプリでも収入が入ることを知ったので,いれてみた.もし仮に \2,500 (= Google Play 登録料) 儲かったら,Google Play にも上げてみるかな.

2014年7月27日日曜日

Waypoint Navi プロジェクトほぼ完了ヽ(´ー`)ノ

家にヒキコモったままw ナビアプリを検証する環境を構築できたので,実際にナビさせてみることにした.
前回,kml の座標データを送信するスクリプトをわざわざ書いたのは実はもうひとつ目的があって,「PC の Google マップで検索したルート (= kml に記録されているルート)」と「Android で検索したルート」が一致するかの確認も兼ねている.これが一致しないとこのアプリの前提が崩れてしまうので.

で,やってみた結果↓

経由地到達時の次経由地へのナビ起動は,割りと上手くいっているみたい.ただ,経由地毎に画面がガチャガチャ切り替わっているのがちょっとうざいw たまにナビ再起動に失敗するので,ナビ kill→ナビ起動 に wait を入れることで対応した.
また嬉しい事に,完全にナビが終わった後なら次のナビを起動してもボタンキャンセルは要らなかった.これで root 必須じゃなくなったので,公開できる可能性が一気に高まった.

また気にしていた,Google マップのAndroid/PC の違いによるルート検索の差異は,今のところ無いみたいで安心.

これで,まぁまぁ使い物になる感触を得た.
あとはツーリングに行くだけだwww

あと,恒例のコレジャナイ感たっぷりのアイコン↓

2014年7月26日土曜日

ツーリング用ナビアプリ プロジェクト(3)

ツーリング用ナビアプリのデバッグで実際にナビさせたい.
と言ってもいきなり実走試験するわけにはいかないので,GPS アプリに擬似 GPS 情報を与えるために Bluetooth GPS というアプリを使用した.
これは本来は,外部 GPS 機器のデータを Bluetooth で Android で送信して利用するためのアプリだが,普通に「PC + BT ドングル」⇔「Bluetooth GPS」でも繋がるので,PC から道路を移動する座標を送信し続ければ,所望のことは実現できる.

というわけで kml に記録されたルートの座標を連続で送出する perl スクリプトを書いた.と言ってもやることは基本的には単純で,kml の座標を NMEA に変換して仮想シリアルポートに write するだけ.

と思ったのにこんなことでハマるハマるwww 何故か PC から送信している座標が無視されてしまい,WiFi による測位とかそっちの測位結果が使用されてしまう(;´д⊂)
手持ちの GPS 機器⇔Bluetooth GPS なら正常なので,Bluetooth GPS がおかしい可能性は低い.ならば NMEA フォーマットがおかしいのかと試行錯誤してみた結果,どうやら Android は単純に NMEA の座標を使用するのではなく,NMEA データの精度・信頼性を評価した上でおかしいと判断した場合は他の測位手段を使用しているっぽい.

具体的には,日時,方位,速度,$GPGGA の捕捉衛星数・HDOP などなど.
kml には方位,速度等足りない情報があるので,それらを演算で生成して NMEA に付与したら,やっとこさ Google マップを騙すことが出来たヽ(´ー`)ノ 高度等,求めようがないデータは固定で.
NMEA パラメータの何が省略できるかまでは検証してないけど,ひとまず↓の情報だと ok だった.
$GPGGA,012345,3401.234567,N,13501.234567,E,1,12,0.5,10.0,M,,,,*1B
$GPRMC,012345,A,3401.234567,N,13501.234567,E,34.55723,121.52,250714,,,A*47

2014年7月21日月曜日

ツーリング用ナビアプリ プロジェクト(2)

プロジェクト ツーリング用ナビ の続き.

Google マップのマイマップでエクスポートした KML を Android の MapView に読み込むとこまでできた.

直接 MapView が KML をレンダリングしてくれればチョー楽だったんだけど,残念ながらそこまでは行けてなかった.
しかたがないので,XmlPullParser で KML をパースして WayPoint とルートの線をここらへんを見ながら
←表示してみた.

ウヒョヒョwww だいぶいい感じ.

ここまでできたので,次にナビの起動を実装してみた.前回書いたようにナビの起動自体はインテントを投げるだけなんだけど,ここで問題発生.
経由地に到達したら (Google ナビが起動中の状態で) 次のナビを起動することになるけど,そうすると前動いていた方のナビで「ナビを終了しますか?」というダイアログが表示されて,手動でボタンを押さないと次のナビが起動しない.経由地毎に操作するとかありえないので,これは痛い.

仕方がないので,次のナビを起動する前に Google マップのプロセスを強制終了させることにした.普通は ActivityManager.killBackgroundProcesses() で kill できるはずなんだけど,どうやってもうまくいかない.で Automatic Task Killer とか他のタスクキラーアプリの挙動を観察していると,どうもナビ起動中の Google マップは killBackgroundProcesses() 出来なさそうなことがわかった(;´д⊂)
android.os.Process.killProcess() なら kill できるけど root 権限必須だし.

別の切り口で,ここによると
FLAG_ACTIVITY_CLEAR_TOP を設定することでタスクに積まれたアクティビティを再開させることができる(タスクに積まれていなければ新しく開始される)。
このとき、再開されたアクティビティより上に詰まれた(新しい)アクティビティはすべてが破棄される。
つまり、アプリ実行時に最初に起動されるアクティビティを呼び出すことで最初の状態に戻すことができる。
これだ!(`・ω・´) シャキーン と思ってやってみたけど,状況変わらず(´・ω・`) ショボーン

んー,困った.

2014年7月20日日曜日

ツーリング用ナビアプリ プロジェクト開始

ツーリング用の Android カーナビアプリを作るプロジェクトをおもむろに開始.

ツーリングでは特定の道を通ることが重要なので,経由地指定機能は必須なんだけど,Google マップのナビにはその機能はない.他の有料ナビアプリだと経由地を指定できるものもあるが,PC との連携が皆無なのでルート作成もスマフォ上で作らないといけないのでやってられない.

というわけで昔なつかしの gpshook テクノロジw で上記のことを実現することにした.
要は,次の経由地までのナビを起動して,経由地に到達したらまた次の経由地のナビを起動する,ということを繰り返すだけなんだけどw

ルート作成は PC の Google マップの「マイマップ」で作成して kml にエクスポートすればよさげ.
肝心のナビの起動はここにあるように,インテントを投げるだけなんで超簡単.

単に経由地に到達したら次のナビを起動,だけなら UI も何もいらないレベルなのだが,
・kml を読み込んだ時にルート全体を地図に表示する
・ある経由地をスキップして別の経由地を目指す機能.これも地図上の経由地マーカーをタップするとか,そんな感じの UI
を実現したいので,手始めに Google マップをアプリ内に表示させるようにしてみた.

これがハマルハマル(;´д⊂)
まず MapView についてググると API V1 についてのサンプルが多く,現在 API V2 しかサポートされてないので,どっちの記事かをわかっていないと,コードをコピペしても地図が真っ白とか,中途半端に動かない.更に API の仕様? も事細かに更新されているらしく,Google 公式サンプルですらコンパイルエラーとか(;´д⊂)

ぬるぽで死ぬたびにエラーメッセージググって修正,とういうのを繰り返して,やっと Google マップを表示できたよヽ(゜ーÅ)ノ

自分用メモ:
AndroVM で MapView が表示されない時は,AndroidManifest.xml の android:hardwareAccelerated="false" にする

2014年7月17日木曜日

DD-WRT につぶやかせてみる

DD-WRT は素の Linux に近いとはいえ,/var/log 系があまり充実していない.また出先から DD-WRT の状態を知ろうにも,Android で PPTP セッション張ってブラウザ立ち上げて…,とか面倒なので,DD-WRT に自発的に自分の状態をつぶやかせてみることにした.

最初は Basic Auth とかで wget で適当な URL + Query String を指定すれば ok だろうと軽く考えていたのだが,なんか Twitter は OAuth を採用していて (今更気づいた),wget + スクリプトで対応できる範疇を超えている.

んー,と思って色々探してみたら,StewGate-U というサービス発見!!
これは OAuth の認証を肩代わりしてくれるプロキシで,StewGate に対し簡単な http アクセスをするだけであとは StewGate⇔Twitter 間で OAuth 認証をやってくれる.

というわけで,DD-WRT からつぶやいてみたのが上の画像.
DD-WRT 内蔵の wget コマンドは POST データを送信するオプションが省かれていたので,curl をクロスコンパイルしてやってみた.

これで色々面白いことができそうヽ(´ー`)ノ

2014年7月2日水曜日

クラウドのトラブルを食らうど!

ここに次世代ブロードバンド時代の新たなギャグが誕生した.

いやね,アマゾンでは日替わりで有料アプリをタダで配っているので,有用なアプリはゲットしていた.
で,それらはアマゾンシステム的には ¥0 で「買った」ことになっているのでライセンス管理的なものがきっちりなされているっぽいのだが,ある日端末上で (¥0 で) 購入したアプリが Amazon Apps の購入リストから消え去っていたwww (左の画像)
でその状態で,買ってない扱いになったアプリを立ち上げると「コンテンツは所有されていません」というメッセージとともに強制終了されると(;´д⊂)

で結果から言ってアマゾンシステム側の問題っぽいのだが,アマゾン側も原因を掴みあぐねているのか解決に 1月程かかった.
今回はタダで貰ったものばかりだしアマゾン側もちゃんと対応してくれたから良かったけど,突然アカウントを消されたりする事例もあるし,メールなんか 100% Google に預けてるし,最近は写真も全部 Picasa に UP してローカルのは消してるし.

クラウド危険性にちょっとだけ触れた今日このごろ.