今年の総括

少々早いかもしれませんが、今年の総括を行っておきましょう。

昨年の今頃、Ａｎｄｒｏｉｄアプリの開発に興味を持って、Ａｐｐ　Ｉｎｖｅｎｔｏｒ　というツールにてアプリ開発をスタートしました。

そして年明けから、Ａｐｐ　Ｉｎｖｅｎｔｏｒ　でラリーコンピューターアプリを作る限界を感じたので、本格的にＥｃｌｉｐｓｅによる正攻法？のアプリ開発をスタートした２０１１年。

わずか１ヶ月足らずで無謀にも有料アプリとしてマーケットにリリース。

そしてその２週間後にあの地震・・・。

地震後は、ラリーに出る余裕が無くなってしまったため、アプリケーションの開発を少しずつ行いつつも、７月終わりに家庭の事情により、一旦アプリ開発を中段。

そして８月半ばより開発を再開して現在に至る。

こんな１年でした。

はっきり言ってアプリ開発が中心の１年だったといっても間違いないかと思われます。

リリース当初は出来ることも限られており、機能や操作性も今思うと申し訳ないくらいでした。今でも完璧ではありませんが、その頃に比べるとだいぶ”専用ツール”として成長してきたように思えます。

Ａｎｄｒｏｉｄアプリを開発して一番良かったこと。それは

”世界中のたくさんの方と交流を持つことができた”

有料アプリですから、当然利益が出てうれしいということもありますが、やはりアプリを開発していなければ絶対に接することが無かった方々と交流を持てて、少なからずご期待をいただけたというのは、自分の存在価値を実感できる瞬間でした。

現在、ＭａｃＢｏｏｋ　Ａｉｒを入手したことから、iphoneアプリの開発に少しだけ手をしつつありますが、出してみて改めて、Ａｎｄｒｏｉｄアプリの開発しやすさというのを実感しています。

当初は、”Ａｎｄｒｏｉｄはレイアウトが千差万別で嫌だ”とか思ってましたが、今はそんなことも大して苦にはならず、逆にイカにマルチレイアウト化するか？ということの方が楽しかったりもします。

開発や導入コストがかからず、誰でも手軽（か？）にスタートすることが出来るＡｎｄｒｏｉｄの世界。Ａｐｐｌｅのガンジガラメな世界とは違うところが魅力かもしれません。

逆にiphone開発からスタートした方は、この辺りはいい加減に感じるらしいですね。どっちから入ったか？が結構あとあとまで影響するのかな？と。

さて、今年はASE Rally Monitor100を有料アプリとしてリリースしました。

Ａｎｄｒｏｉｄの有料アプリは、８０％がダウロード数１００以下らしいです。で、現在ASE Rally Monitor100のダウンロード数は１００以上（いくつかは企業秘密ということで）なので、選ばれた２０％以内に入っているということになります。これは結構うれしいですね。

さて、来年はアプリの開発そのものよりも、アプリを利用した様々なサービスの可能性ということを重点に活動してみようと考えています。

先にも書きましたが、アプリ自体の売り上げを期待することは非常に難しいようです。ただし、ラリーモニターのようにコアなターゲットアプリは、思うよりも需要があるということが理解できました。

そこで、企業などが手をつけられないコアなジャンルを狙い撃ちしたアプリ開発というもの、そしてそれらを道具としたサービスを構築していくことがアプリ開発者の将来的可能性だと思うので、そこらへんを意識してみたいと思います。

開発日記的にスタートしたこのブログも、雑記として脈絡が無いブログになっていますが、もしお時間があれば来年もお越しいただければと思います。

以上、１年間ありがとうございました。来年もよろしくお願いいたします。

Graphical Layoutが表示されない。

AndroidをEclipseで開発する際、画面のレイアウトはxmlファイルで作成します。

基本的にコードで構成されるのですが、これを直感的に設計できるように”Graphical Layout”を使うのですが、これが最近表示されなくなってしまいました。その代わりに”設計”っていうタブに切り替わってしまい、これがまったくもって役立たずなんです。

困ったときはGoogle先生ということで、いつもどおり調べてみると、

xmlファイルを右クリックして、”アプリケーションから開く”→”Androidレイアウト・エディター”と選択

とりあえず、これで無事Graphical　Layoutが表示されました。

原因はADTのバージョンアップらしいのですが、いつもそうですが、いきなりこうなるのでその都度困るという繰り返しです。もうなれましたけどね。

ということで、着実に成長している我が身です。

一転復活！

さて、先週末は、衝動買いによるMacデビューからAndroid開発環境の構築を行っており、すでにレポしたように、従来開発していたアプリをMacの環境でインポートすると、エラーが出るという状態を改善できず、半ばあきらめてしまいました。

しかし、やっぱりこのままでは悔しいので、もう一度いろいろ調べてみました。

エラーというのは、


@Overrideなんちゃらのエラー

という、結果的にはポピュラーなエラーなんですが、原因は

JAVAコンパイルが1.6になっている必要があるところが、1.5のままだった

というものでした。実は、週末の悪戦苦闘中にもすでにこれが原因というのは容易に掴めていたのですが、ここを直しても解決しなかったので、嫌になっちゃったという次第です。

では、どうして解決したのか？

週末に直したのは、Eclipseの設定だったのですが、アプリのプロジェクト個々の設定が1.5のままだったという次第です。見直したつもりでしたが、1日あけて昨日みたら直っていませんでした。

で、これを直したら、上記エラーは出なくなりました。

本当にこれで解決したかはまだ未定ですが、とりあえずMacでビルドし直して端末にアプリを入れてみたら普通に使えたので、たぶん大丈夫なんだと思います。

ということで、一転して当初の目論見どおり、MacでもAndroid開発を継続できることになりました。

こうなると、スペック的には申し分ないMacBookAirなもんで、Eclipseの動作が非常に軽快になり、うれしい限りです。まったくいい加減なものです、人の心なんて。

この機種はSSDなので、起動や特にスリープからの目覚めがすばやすぎます。Androidタブレットも速いですが、ノートでこの速さだと、非常に快適ですね。

お騒がせしました。

当初の目論見が外れる・・・・。

Macに手を出した一番の理由。それは

「MacでもAndroid開発できるんだったら、触っておきたい」

というものでした。で、昨日・一昨日と開発環境を整えて、今まで作ったアプリを開発しようとインポートすると、Overrideエラーが発生。

ネットで同様事象を調べると、JAVAコンパイルを1.6にすると解決するとありましたが、すでに1.6なんですよねぇ。

原因が不明な現在、Macで今まで作ったアプリをいじることができません。

このまま解決しない場合は、当初目論んでいたものの半分以上がパーになってしまいます。

新しいアプリを作る分にはエラーが出ないため、Windowsで作ったアプリはMacだとこうなるのか？とか、今まで使っていたEclipseは3.6だけど、Macに入れたのが3.7だから、このあたりが要因なのか？とか、思いついたことを一つずつ潰していくしかないですね。

たぶん、途中までWindowsで開発していて、急遽Macにスイッチするという事象は稀なんでしょう。参考になるレポートが見つけられないため、下手したらMacでAndroid計画は座礁してしまうかも・・・。

気分転換にiphoneの開発環境を作ってみるものの、いろいろ制約があって、早くも撤退したくなった週末。

いじる前に売り払って、Windows機を買いなおした方がいいのかなぁ・・・。Windows７をMacに入れるという業もあるらしいが、そうすると更にお金かかるしなぁ。

少し後悔の念が沸いてきていますが、くじけずがんばりましょうか。

Mac始めました

今までAndroidアプリの開発には、

デスクトップ２機
ノート１機

の計３機を使っていました。贅沢っぽく聞こえますが、あちこちで仕事するため、それぞれの環境にあるPCを使っていただけの話です。

これらはWindowsですが、このうちノートはThinkPadX32という、もうかなりの年代機種なもので、最近では動作自体に大分ストレスを感じていました。特に開発につかっているEclipseはストレスを感じていました。もっとも、３年前に中古で格安購入したものですから、もう十分役目を果たしてくれたと思います。

そこで、新しくノートを用意したいと考えていました。

当初はThinkPadEdgeあたりを考えていました。ただ、Windows７になるものの、基本的には大して目新しいものもなく、できることも今までと変わらないというのが少し気になっていました。

そんななか、ふと考え方を変えてみて、

「MacでもAndroid開発できないのか？」

と何を血迷ったか調べてみると、特段問題もないことがわかりました。

そこで、急激にMacを入手してみたくなり、半ば勢いで昨日購入してしまいました。購入したのは

 機種名： MacBook Air

  機種 ID： MacBookAir4,1

  プロセッサ名： Intel Core i5

  プロセッサ速度： 1.6 GHz

  プロセッサの個数： 1

  コアの総数： 2

  二次キャッシュ（コア単位）： 256 KB

  三次キャッシュ： 3 MB

  メモリ： 4 GB

某量販店で定価１２万ちょいのものを９万ジャストで購入。Windows機だったら、同様のスペックでももう少し安く入手できるのでしょうけど、最大の決定打は、

”AndroidもIphoneアプリも開発できる”

につきます。Andoridはもちろんですが、今回の購入により、環境としてはほぼIphoneアプリ開発ができることになります。

以前から度々”IphoneでもARMが使いたい”というご意見をいただいていたのですが、あとは私の勉強次第でそれも実現するかもしれませんね。

ということで、現在はMacとWindowsの各種違いに悪戦苦闘しながら、乳児から幼児になれるように栄養補給中です。

”デスクトップにショートカットを作る”

これだけのことも、単語の違いからスムーズにできないのは新鮮と言っておきたいと思います。

Ａｎｄｒｏｉｄマーケットにおける端末チェック

ここ数週間で、以下のようなお問い合わせをいただくことがありました。

「ASE Rally Monitorを使いたいと思って、●●という端末を購入したのですが、Ａｎｄｒｏｉｄマーケット上で、おたく（私）のリリースするアプリが一切見つからない。もしくは”利用端末は該当アプリは対象外です”とはじかれる」

というものです。これ、一番困るパターンかもしれません。

というのは、アプリのプログラム等の不具合であれば、原因は全て自分（というわけでもないですが）のため、解決もできるのですが、この問題は一概に自分による原因ばかりではないからです。

この問題でまず最初に考えられる原因というのは、

・ＯＳバージョンの不一致

つまり、アプリ側で最低バージョンをＡｎｄｒｏｉｄ２．２としている場合、当然Ａｎｄｒｏｉｄ２．１の端末からはマーケット上でアプリを検索することができません。またインストールすることもできません。これはもっとも単純な原因です。

ただ、今回のお問い合わせについては、これは全く該当しません。ＡＲＭは２．１以上をターゲットにしていますが、いずれもこれ以上のバージョンですので。

次に考えられる原因ですが、アプリ側で実装する必須機能を端末側で実装していない。例えばＧＰＳを搭載していない端末。これもはじかれるかもしれませんね。ただ、これも今回については該当せず。いずれもＧＰＳを標準で搭載しています。

あとはスクリーンサイズですか。でもアプリ側ではsmallからxlargeまでカバーしています。

と、ここまではアプリ側の可能性による原因です。

これ以外に、開発側でないと分からないことがあります。それは、

・マーケット側で勝手に利用端末を制限している

というもの。アプリのマニフェストや内容により、自動的に利用端末一覧なるものを設定してしまい、それに記載のない端末は、対象外とする的な機能です。実はこれが原因なんだと個人的に思っています。

というのも、今回問い合わせいただいた端末というのは、

Ｌｅｎｏｖｏ　IdeaPad A1

これは最近発売された７インチタブレットで、その低価格から魅力的かな？と思っていました。問い合わせいただくまで気づかなかったのですが、その時点ではリストにありませんでした。従ってたぶんアプリが見つからなかったんだと思われます。

で、この記事を書いている現在改めて調べてみると、こんな感じで追加されていました。

A1_07というのがたぶん該当端末です。

ということで、こればかりが要因ではありませんが、こんなことでもアプリがマーケット上で見つからないということにつながるという例でした。

スマートフォンを利用したラリコンの立ち位置

スマートフォン（タブレット）を利用したラリーコンピューターアプリの立ち位置というのが1年かけてみて理解できてきました。

自分なりに理解したことは

・導入の手軽さ→車両への加工が不要かつ、費用的負担も抑えられる。

・単純な操作系→結局のところ、TCラリーに使う方は、”時計”と”トリップ（距離）メーター”があれば良いという意見が多いです。多機能にして操作を複雑化するよりも、単純な操作系の方がより実戦向きなのかもしれません。

・妥協前提だということを前面に出す→外部からの車速信号入力をしない限り、どうしても距離は多かれ少なかれズレを所持します。このことを理解してもらいやすい設計にする必要がありそうです。

こんなことでしょうか？

外部機器を開発して車速信号を入力してみたり、その他いろいろ進化することは可能なのかもしれませんが、そうすると結局のところ利用コストが上昇し、専用の機器を買うことと変わりなくなってしまい、Androidを使うメリットが薄らいでしまいます。

開発当初に自分で言っていたことですが、

”技術の追求とユーザーの使いやすさは＝になるとは限らない”

これを再度自分に言い聞かせていこうと思います。

トライアルバージョンの必要性

本日ASE Rally Monitor100のお試しバージョンである”ASE Rally Monitor Free”をアップデートしました。

これまでトライアルバージョンはだいぶ放置してしまっていましたが、そんな中でも実はもう少しで3000件に突入しようとしています。もっとも使用時間の制限をかけてあるため、アンインストールしてしまっている方もたくさんいて、現在は生存率が30％程度となっています。

もともとこのトライアルバージョンを作った目的は、まさにARM100に対する評価版でした。それが放置してしまったことで、内容に大きな差が生まれてしまいました。

これでは、せっかく興味を持ってトライアルバージョンをダウンロードしていただいた方々にほんとに申し訳ないということで、大変遅くなりましたが、トライアルバージョンも現行版と同じ機能にアップデートいたしました。

今後は大きなモディファイはARM100に関しては当面なさそうなので、これでトライアルバージョンとしての目的が復活できそうです。

有料アプリを公開している場合は、こういうトライアルバージョンを併せて公開することで、少しでも安心してご利用いただけることになるかと思いますので、今後も気をつけたいと思います。

Google+運用はじめました。

もはや開発日記ではなくなりますが、Google＋の運用をはじめました。

例にもれず、Facebookもそろっとですが使っていまして、別に不満や要求もないのですが、せっかく新しくスタートしたものを、Androidでべろっぱーとして使わんわけにはいかないだろうということでのスタートです。

で、結局どうなの？

ということになるのだと思いますが、まだまだ使い始めなもので、レビュー出来るほどのものではありませんが、とりあえずGoogle＋＆Facebook＆Twitteｒ＆Bloggerの四連コンボを組み上げ、Google＋を軸にまわしてみようと思っています。

Androidユーザーは、本人が好もうが好まざろうが、Googleのサービスを使いこなすことが、新しい世界への近道のような気がするためです。

もちろん、不便な面などもありますが、それでも”使いこなす”ということは、それら不便な面を認識して克服することが重要なんだろうと思っていますので、”とりあえず使ってみる”精神でのんびり行きたいと思います。

スマートフォンに満足するためには？

現在、世間では”スマートフォンブーム”と称して、スマートフォン推しをしています。

その際に必ず出てくるのが、自分が良いと思うものを否定されることに対するネガティブキャンペーン。

これを言うと、今からの内容もまさにネガティブキャンペーンになるので何とも難しいというか、どうでも良い話なんだとは思います。

何事も過渡期というのは、賛否両論が入り混じるものです。

開国か攘夷かという時代的なものもそうですし、考え方などもですね。

本題ですが、

スマートフォンに満足するためには？

まず最初に必要なこと。それは

向上心を持つこと


たぶんこれに尽きそうな気がします。ガラケー愛好家や、スマートフォンに移行して最初の壁を乗り越えられなかった方々のネガティブキャンペーンは概ねこんな感じではないでしょうか？

「ボタンが押しづらい」


「電池が持たない」


「電話とメールができれば良いから、多機能で使いづらいのは不要」

たぶん8割くらいはこんな感じの理由な気がします。

これらの感想を抱かないためには、「新しいものへのチャレンジ」とか「自己の向上」というものが必要になってくると思います。

そうしたことを差し引いても、自分自身で使いこなす”努力”をすることで、携帯端末としての本当の進化を遂げるんだと実感しています。

身の周りでも、「どんどん使いやすくなっているよ」という人もいれば、「結局使いづらいから、ガラケーに戻りたい」という人がいます。

前者は、どんどん”こういうことやりたいけど、どうすればいい？”と聞いてきます。後者は自分自身で”出来ない”とか”そもそも使いづらい”と最初から決め付けてしまっているようです。

向上心や探究心、努力。

そんなものを持つことが、スマートフォンを使いこなす最初の壁かもしれません。

Preferenceが存続されない

今一番の悩み。それは・・・

Preferenceが存続されない

つまり、各種設定の保存が初期化されてしまうということです。

原因を色々模索しているのですが、なんとも現状では発見できず。Preferenceへの保存＆呼び出しというのは、非常に単純というか簡単なんだと私は思っていました。

しかし、現状だと30分から1時間すると、どうしても設定がリセットされてしまいます。

ここが理解できないところなのですが、一旦保存はされています。アプリをfinish()して、数分程度間をあけて、改めてアプリを起動させても設定は保持されたままです。でも、先ほど述べたように30分～1時間くらい間を空けてしまうと、リセットさえています。

保存されていないというのならわかるし、起動時に何らかの初期化をコード上でしているのであれば、アプリの再起動で初期化されるはずなんだと思っています。

それが、数十分経たないとリセットされない、というのがいかんせん意味不明です。

使用時に毎回設定すれば良いのですが、それも面倒ですよね。なんとか解決したいところです。

久々にハマッてます。

どこまでサポートするべきか？

私の主力アプリASE Rally Monitor100は、内蔵GPSを利用したラリー用アプリケーションです。

この内蔵GPSというのは、端末によって精度がバラバラで、悪いものになると正直ラリーで使うことは非常に避けたいものもあります。

そこで、このARMでは、外部GPS機器を使いたい方に向けて設定項目を追加してあるのですが、この場合は、ARM以外にも端末側の設定やGPS機器を接続するための別アプリの設定も行う必要があります。

そもそも当初は内蔵GPSのみで考えていたのですが、外部GPSを使用したいという声がいくつかあったので、少しでも使いやすくなればということで追加したのですが、正直この先というのはARM以外の問題になってきますので、ここまでフォローする必要があるのだろうか？と悩む今日この頃です。

一般的なPCのソフトウェアを見た場合、数万円するソフトウェアでもソフトウェア自体の相性や対応を完璧にフォローしているものは皆無です。それを考えると、必ずしも１００％を目指すことは様々な観点から見てみても現実的ではないのでは？と思い始めてきました。

商品に対する価値というのはそれぞれですが、ちょっと行き詰ってきたので、泣き言をいいたくなってきている今日この頃ですが、ユーザーはありがたいことに？いろいろと課題を与えてくれます。

「まっ、こんなもんだよね、できないよねぇ」

と言われると、悔しくてなんとか今までは来ましたが、そろそろムリポ！と投げ出しそうな気がしはじめています。

最大の弱点がちらほら露呈し始めてきている今日この頃です。

今後の方向性

ARMもなんとなく画期的な新機能というのが行き詰ってきた感じがしてきました。頭ではいろいろ構想や夢は広がりますが、広がるほどに自分の無力さとのギャップにがっかりすることもシバシバ。

で、今後はどのような方向で進めていこうか？と悩む今日この頃です。

１．GPSによる距離表示の精度を上げる

これは、現状ではトンネル処理などがいまいち適当というか、あまり正確ではありません。まあもっともふた昔前くらいのカーナビチックにはなっていますが。

で、この精度を端末に内蔵している各センサーを使って更に向上を目指す。

２．外部ハードウェアを製作or流用してGPS以外からの距離取得を目指す

これは、GPSにそろそろ見切りをつけて、いよいよ車速センサーなどを取り込んで、禁断の領域へ足を踏み入れるというものです。実現すれば、もはやラリーコンピューターとしての弱点は、クリック感以外はなくなるでしょう。というより、その弱点よりもメリットの方が増えそうです。

と、現状ではARMは２つの方向性を見出しています。

２の方が精度は間違いなく上で、２を実現させることは究極のAndroidラリーコンピューターに近づくことができるでしょう。問題は、２の場合、ハードウェアを開発もしくは流用する必要があり、なおかつそれらと通信をする必要があるということです。

ハードウェアについては、実はすでに汎用品として、車両診断コネクターからデータをBluetooth経由で飛ばすドングルが出回っており、先日私も入手してみました。ただ、残念なことに、このドングルは、私が乗っている日産マーチ（AK12)のプロトコルに対応していないようで、まったくデータを拾ってくれませんでした。

テスト車両がテストできない環境ではこれ以上開発を進めることはできません。できないことはないですが、テストのたびに違う車両を用意して・・・・というのは私のライフスタイル的にはちょっと無理があります。今までも毎日乗っているマーチでGPSのテストができたから、一人でもこの時間で開発できたのだと思っています。

では、車速信号をカウントしてBluetoothで飛ばすハードウェアを別途開発しては？となりますよね。

これも考えました。というか今でも捨てきれない選択肢です。ただ、単にプログラムだけではなく、ハードの設計・開発となると、何倍も大変かつリスクがあがります。Androidアプリだけであれば、最悪不具合があっても、アップデートするだけで対応できますが、ハードまで対応となると、正直一人では限界を超えることは間違いありません。

理想として将来にとっておくことは良いかと思いますが、現実これを一般にリリースすることは当面先かな？と。やりたい気持ちはとてもあるので、誰か協力してくれる方がいれば、進められるんですけどね。

ということで、今後は１のGPSを使った精度向上を計ってみようと思います。

これは正直目に見える進化は期待できず、ユーザーの方はあまり気がつかない分野なのですが、気がつかないうちに自然と違和感なく使える。これも結構重要なことだと思うので、できることから進めていくことにします。

ハードやりたいよなぁ・・・・でもコンセプトが・・・・。

アプリの開発に必要なスキルとは？

お前がスキルについて語るか！？と言われそうですが、具体的な技術スキルについては、語るに足らない者なんで、まったくのアプリ開発経験無しな人間がアプリ公開半年を過ぎて感じたことを少々偉そうに語ってみたいと思います。

アプリの開発に必要なスキル。

それは当然ながら、プログラミング言語や開発ツールの操作などのスキルということになるかと思います。これらのスキルの大小で、アプリ自体の出来はかなり左右されます。これについて、私のような素人に毛が生えた人間は語る内容もありませんので、割愛しましょう。

で、次に必要なスキル・・・・というより、上記技術的なスキルより以前に必要なスキルがあると実感しています。それは

アイデア

です。どんなに技術的なスキルを持ち合わせていても、その種となる”アイデア”が生まれてこないことには、物は出来ません。そして、アイデアが生まれたとしても、人に使ってもらえるアイデアでないと、当然ながら魅力的なアプリを作ることもできません。

このアイデアというスキルに関しては、正直勉強したり練習したりして得られるものではないのでは？と常日頃感じています。

アイデアを生むためには、日ごろの生活で

「ここはもっとこういう流れの方が・・・・」

とか、

「こうしたら、違う見方ができるかな？」

などという考え方をしていないと、なかなか面白いアイデアって生まれないんだろうなぁ・・・と。

そして、更に必要なスキルとして、

アフターケア

これが、実は最も大切なスキルのような気がしています。

今回私が提供しているARMに関しては、英語/日本語にて専用のサイトを作って公開しています。なぜこうしたか？というのは色々理由があるのですが、一番は

”アプリについての説明を十分にするため”

です。ARMはラリーコンピューターの代用ということで、一般的なアプリではないこともあり、必ずしも全員がすぐに使いこなせるというものではないと思っています。現在も申し訳ないことに、分かりづらいところが多々あるかと思います。

そんなアプリを少しでも使いこなしていただき、便利なアプリとして愛用していただくためには、アプリ自体に説明書的なものをつけるだけでは絶対的に足りないことは最初からわかっていました。

そこで、専用サイトを作り、尚且つ説明書を英語/日本語それぞれで別途専用にPDFにて作成することで、常に最新状態で情報をお届けしたいという気持ちがあります。

おかげさまで、現在殆どの方にアプリを削除することなくインストールしていただいた状態でおります。具体的な数値は控えますが、ほぼ全員という感じです。

これはユーザーの方の寛大な姿勢と、専用サイトを常に更新することで、”今はダメでもそのうち良くなるだろう”という期待の現れなんだろうと勝手に思っています。

その期待に応えたい！

それも必要なスキルかもしれませんね。

ふとしたことでスタートしたラリーアプリの開発ですが、今では20カ国以上の方々にご利用いただいており、これほどうれしいことはありません。

まだまだ未熟ではありますが、ご要望や指摘事項は小回りの効く開発環境を最大限に生かして対応していきますので、暖かく見守っていただければと思います。

時刻の補正に悩む

現在、GPSによる時刻の補正機能の精度向上を目指して無い知恵絞って試行錯誤しています。

今までは、GPSに頼らず、あくまでも手動で基準時計との差を入力することで補正していました。これがラリーにおいては一番確実な方法です。

その際には、あらかじめ端末による時刻の自動同期機能をOFFにしておく必要があります。というのも、ある段階で5秒の差があって、それを補正しても、端末側で自動同期されると、差が5秒で無くなってしまうことが多々あるためです。

で、今回GPSによる時刻同期を追加したのですが、今度は端末の時刻同期がOFFになっていると、アプリ側でGPSを使った同期ができなくなりました。

考えた結果として、端末側で時刻の自動更新がOFFになっていると、端末内蔵のGPSが時刻を取得しないのではないか？ということです。つまり、時刻に関してはGPSがOFFになっている状態と同じような状態になってしまうということです。

ということで、GPSによる時刻同期をしたい場合は、あらかじめ端末の自動同期をONにして、マニュアルの場合は逆にOFFにする必要があるということが分かりました。

これらを全てのユーザーが理解していただくことは非常に困難かもしれません。アプリ側で、GPSによる同期のON/OFFにより端末側を設定できるようにできれば良いのですが、果たしてそれができるのか？

また新たな課題です。

デベロッパーコンソールがまたおかしなことに・・・

Androidマーケットにアプリを公開するのが

デベロッパーコンソール

です。

前にも書きましたが、ここでは、トータルでどれだけダウンロードされて、今どれだけ生き残っているか？という”有効なインストール数”というのを確認することができます。

以前に”更新のタイムラグがある”と書き、これは未だに直ることはないのですが、それに加えてここ数日、新たな現象が発生してきました。

インストール数：トータルでダウンロードされた数
有効なインストール数：アンインストールされていないで、生き残っている数

なはずで、理論上は

インストール数＞有効なインストール数

なはずですよね？それが、ありがたいことにコンスタントにご新規様にご利用いただけているため、数が増えているのですが、ここ数日にあり

インストール数＜有効なインストール数

になっています。しかも1割近くも”有効な・・・”が上回る始末。つまり、トータルなはずのインストール数だけが更新されていないのです。

これだけならあまり気にしないのですが、インストール数というのは、マーケット上でユーザーがアプリを探す際に、そのアプリがどれだけインストールされているか？を表示するための元になるデータです。

で、今私のASE Rally Monitorが、ある大台の直前まで来たまま上記の通り更新がとまっているために大台に乗れずに足踏み状態になってしまっています。更新されれば間違いなく大台に乗るはずです。

これが実は重要な要素で、マーケット上に表示されるインストール数は

1～10

10～50

50～100

100～500

・・・・

などと、ある程度の間隔で区分けされます（区分け数値は適当です）。例えば999インストールの場合は”500～1000”と表示されますが、1001インストールの場合は、”1000～5000”と表示されます。

アプリをインストールする際、特に有料アプリの場合は、決断する基準として、この”インストール数”を少なからず参考にする方もおられるかと思います。自分が買おうとしているアプリが、10件しか過去にインストールされていなければ正直不安ですし、10000件も有料アプリとしてインストールされていてれば、とりあえず良く分からないけど少し安心するのでないでしょうか？

もちろん評価などの方が参考になるでしょうけど、この数値も開発側は軽視できないと思っています。


長くなりましたが、私もあとちょっとで大台に乗れて次のステージ区分に進めるので、早いところ更新してほしいものです。

広告表示について

最近のアプリケーションには結構広告が表示されるものが増えているかと思います。

私もアプリケーションを有料で公開しており、ありがたいことに沢山の方にご利用いただけています。また、無料アプリもいくつか提供しており、それらも沢山の方にご利用いただけていることはありがたい話であります。

そんな中ですが、今後の自身の勉強とモチベーション維持のために、無料アプリのいくつかに広告を入れてみることにしました。

やり方は・・・・・説明するほどの技量がないものでGoogle先生に聞いてください。

最初は”AdMob”というのを利用していましたが、これは国内ではいまいち弱いため、”Adlantis”という方に切り替えてみました。

なぜこちらを選択したか？というと、私が個人的に利用しているいくつかのアプリに表示される広告が、皆この”Adlantis”という記載があったから・・・・それだけです。

ということで、Adlantisでどれくらい収益が上がるのか？を今後見てみたいと思います。

有料アプリは色々大変なので、無料アプリ＋広告でモチベーションを維持したいと思う今日この頃です。

App Inventor 年内で一旦終了

Googleから提供されていたAndroidアプリをJAVA知識無しでも作ることができるツール

App Inventor

が、年内でGoogleからの提供が終了されることが先月発表されました。

思い起こせば、私がAndroidアプリ開発をスタートしたきっかけは、まさにこのApp Inventorを偶々ネットで見つけて、

「これなら自分でもできそうだ・・・」

と思ったのが全てでした。

今もそうですが、その頃はもっと知識が皆無だったため、App Inventorの扱い方からアプリの公開まで非常に頭を悩ませながら一歩一歩進んでいました。

その頃の開発中の画面はこんな感じです。

わずか１０ヶ月前の話ですが、非常に懐かしい画面です。画面も今のARMの礎といった感じですね。

このツールがあったからこそ今に至る勢いをつけることができたわけで、非常に感謝すると共に、
惜しい感じもします。

ただ、Googleからの提供は終わりますが、某教育機関が受け継ぐらしいので、今後ともAndroidアプリの開発入門ツールとしてより進化することでしょう。

もし身の回りの開発が一段落したら、またApp Inventorを弄ってみようかな？と思います。

地域限定アプリの可能性

たまには違うことがしたくなり、ラリーとはまったく関係ないアプリを作り始めてみました。

つくば市内は地域を４分割してゴミだしの曜日が決定されています。通常、各家庭に上記のようなカレンダーが配布され、市のホームページからもダウンロードできますので、特に不自由はないのかもしれません。

でも、ちょっとした時、例えば外出先にて「あれ？明日って何の日だっけ」とか思うことが少なからずあるかもしれません。

そんなときに、スマートフォンを持っていれば簡単に分かりやすく確認できる。そんな狙いで作ってみました。

機能はホントに単純です。

まずカレンダー画像を取得します。これが一番面倒です。当初は、今日は第何曜日かを取得し、計算上からテキストで表示しようと思いました。その方が楽そうだったためです。

ただ、何か間違いがあると面倒なので、結局は市のホームページの画像を表示することにしました。やり方は企業秘密ということで・・・・・・という大したものでもないですが、面倒なので。

で、Spinnerで地区を選択し、今日の”月”と組み合わせて表示させる。ただそれだけです。

まあ、月の最後とかでは来月のカレンダーも見たいかな？ということで、前月・翌月ボタンを追加。最初は地区とかもPreferenceで設定しようと思いましたが、より使いやすいUIと思った時には、もうこの程度が逆に良いかな？ということで、現在の所は設定はありません。

今後は、このように地区限定アプリをいくつか使い、つくば市アプリ群みたいなものを作ってみようかな？と思う今日この頃です。

ラリーアプリについては、ASE Rally Monitor100をより充実させることに集中し、気分転換にこうしたものを摘んでみる。

そんなスタイルで当面は行こうかな？と考えております。

もはや何屋だか分からないですね。まったくこの業界とは関係ない仕事をしております・・・。

画面の明るさ調整

タブレットを車内でラリーコンピューターとして使用するにあたり、最も気をつけるべきことの一つが、

視認性

ということになります。

ARMでは、画面の配色を2種類設定することで、ある程度はこの辺りの対策をしてきました。配色以外について、Androidでは、OSの設定で画面の明るさを調整できるので、今までは特段気にはしていませんでした。

で、昨日タブレットを夜にテストしてみた際、スマートフォンでは気にならなかったのですが、タブレットの場合は、画面の配色に加えて明るさも調整できた方が良いことに気がつきました。

そりゃそうです。画面サイズが大きくなった分、発光量も増えるわけで、標準状態では眩しいのも当然です。

そこで、せっかくならと、簡単に調整できるようにスクリーン上に”SeekBar”を追加して、随時調整できるようにしてみました。

右上にあるバーが明るさ調整で、画像はシンプル画面ですが、メイン画面上にも同様に設定しています。

設定の際に気をつけること・・・・というか、少々ハマッたことがいくつかありますので、ご報告。

１．端末の照度設定を”自動”にしていると、SeekBarに照度を設定した際、全幅にて調整できない。

　これは、今まで自分の端末が自動調整になっていたのですが、そのまま開発していたら、どうやってもSeekBar全幅に対して調整幅が設定されず、ものすごく狭い幅でのみ有効になってしまいました。ということで、注意が必要です。

２．調整幅の下限を１０％くらい残しておく。

　これは、通常明るさの数値幅が0.0～1.0（上限）で設定できるのですが、下限の0.0で設定すると、画面そのものが真っ黒になると同時に、フォーカスが効かなくなり、アプリに戻ることができなくなります。そこで、10％くらい残すようにして、それ以下にならないようにしてあげる必要があります。

ということで、照度調整機能追加完了です。

Bluetooth GPS と Bluetooth GPS provider

まず、タイトルの２つ。これは紛らわしいですが、それぞれ別のアプリケーションの名前です。

共に、外部GPSをBluetooth接続から内部GPSに置き換えるというアプリケーションで、ASE Rally Monitor でもこれらを使うと、より精度が高い使用をすることが可能となります。

Bluetooth GPS providerは、従来私の方でお勧めしていたアプリでした。ASE Rally Monitorは、つい最近までは時刻はマニュアル補正のみを使用する方式を採用していました。これは各国の標準時刻の精度に差があることと、結局のところラリーの場合は、主催者が提供する公式時計が基準になるというもののためです。

しかし、少しずつ開発を進めていくうちに、やはりせっかくGPSを使用しているのであれば、GPSの時刻から自動で補正した方が楽では？と思い始め、先日GPSによる時刻補正機能を追加しました。

そこで判明したのが、先に出ていた”Bluetooth GPS provider”の時計は6～10秒程度ズレてデータを吸い出してしまうようで、どうしてもGPS時刻補正をすると時計があいません。

そこで、他に同様のアプリが無いか？といろいろ探してみつけたのが、タイトルのあるもう一方の

”Bluetooth GPS”

というアプリです。紛らわしいですね。

で、このアプリを机上でテストしてみたところ、時計はバッチリ！GPSロガーどおりの時刻を表示してくれました。これはもう推奨をこちらにする必要あり！！と焦って報告をしてしまいました。

そして、いざ実走テストをしてみると・・・・・

”更新レートが１HZ・・・”

このアプリの何を設定しても、私にはこれを切り替えることはできません。アプリ自体のステータスビューでは、GPSロガーの設定である４Hｚで取得しているようですが、吐き出しが１Hｚになっているようです。

結局私にはこれを変える設定を見つけ出すことができず、再度HPやマニュアルの記載を変更。

Bluetooth GPS provider
→GPSロガーどおりのレートで更新排出するものの、時刻がおかしい・・・。

Bluetooth GPS
→時刻は正しいものの、更新レートが１Hzのみ排出・・・・。

誰か上記を両立させたアプリ知りませんか？・・・て、本当は自分で作るなり、ASE Rally Monitorに組み込むなりすればよいのでしょうけど、いかんせん技術不足なもので、ご迷惑をおかけいたしまくりです。

＜外部GPSを使用する場合のとりあえずの結論＞

Bluetooth GPS providerを使用して、ARMの時刻設定方法を”マニュアル補正”にして使用する。その際に端末の時刻自動更新をOFFにしておく。

これが完璧かと。

なんか悔しいです。

外部GPSロガーを接続するアプリ

これまで、ASE Rally Monitorを外部GPSと一緒に利用する際には、「Bluetooth GPS provider」というアプリケーションをお勧めしていました。

ところが、ARM100にGPSによる時刻自動補正機能を追加した後に判明したのですが、このアプリはGPSの時刻を正しく横取りしてくれないようで、どうしても6秒くらいずれてしまいます。

いろいろ試しましたが、他人様のアプリなので、これ以上は追及することはやめ、時刻を正しく取得してくれるアプリを別に探すことにしました。

現状ではこれがお勧めかな？と思われます。

Bluetooth GPS
https://market.android.com/details?id=googoo.android.btgps&feature=related_apps&rdid=googoo.android.btgps&rdot=1&pli=1

なんだか似たような名前ですが、とりあえずGPSViewに表示された時刻と端末で表示する時刻はほぼ一緒なので、問題ないレベルのようです。

しばらくはこれに切り替えることをお勧めしながら、最終的には私自信がBluetoothを勉強する必要がありそうですね。

Bluetoothはよくわからん・・・・です。

Optimus Pad L06CのGPS

最近、Optimus Pad　を車載してテストをするケースが増えてきましたが、ここで気になったのが、この端末のGPS捕捉精度です。

それまでは、SHARPのSH-03Cのみで実機テストをしており、このSH-03Cは比較的安定してGPSを捕捉してくれます。で、巷では銀河系などはGPS精度が悪いなどとレポートされており、そんなもんかぁ～と他所事で考えていましたが、Optimus Padをテストするようになって、ようやくスマートフォン・タブレッドのGPS精度を実感しました。

SH-03Cは、無障害の屋外ですと、長くても1分程度でGPSをキャッチしてくれます（端末により違うかもしれませんが）が、Optimus PadはGPSを最初にキャッチするまでに5分くらいかかります。シチュエーションにより異なるかもしれませんが、今のところ安定して？5分くらいかかります。そして、キャッチしたあとも、安定（Accuracyで５以下）するまでにやたら時間がかかったり、途中で突然ロストしてしまったりすることも珍しくありません。

今のところ、この2台のみ実機テスト済みなので、他の端末ではもっとひどいかもしれませんが、少なくとも、Optimus PadでGPSを使用する際は、その辺りを十分意識する必要がありそうです。できれば外部GPSをBluetooth接続してそちらを使う方が格段に利用しやすくなるかと思います。

準備と開始のブレークポイント

Androidアプリを公開し始めて半年が経ちました。

最初は思いつきで手を出してしまったアプリ開発ですが、進めていくうちに、少しずつではありますが、自分にできることが増えていくのが楽しいと思える今日この頃。

それに伴い、いろいろ悩みが出てくることがしばしばあります。それは

「もっとこういうレイアウトにしておけばよかった」

「こういう操作系の方が機能的だった」

などなど。

なにしろ、思いつき人間で行き当たりばったりなもので、思い立つと設計図も何も描かないまま、頭の中だけでスタートしてしまいます。当然その時点で予測されるものは組み込んでいくのですが、スタート段階で自分にできないことは組み込めません・・・・というか頭に浮かびません。

でも、進めていくうちに、あることができるようになると、そこから枝分かれして、いろんな方向が見えてきたりします。その際に今までの仕様で対応できる場合とできない場合があり、対応できない場合により面白い方向があったりします。

では、そこまでできるようになるまで開発を進めない方が良いのか？というと、タダでさえ自分は素人で出来ることも限られているわけで、技術が追いつくまで待っていると、あっという間に出来る方に先を越されてしまいます。できない人間はがんばって出来るようになったところで、既に出来る人には届かないというのは当然です。

ある程度はできないと進めないですが、ある程度まできたら待っていないで進んでしまう。

このラインの見極めが難しいなぁといつも感じながら物事を進めています。

と、ちょっと心情的なお話でした。

Optimus Pad L06C用USB充電ケーブル

Optimus Padユーザーの悩みの一つとして皆が少なからず残念に思うのが、

「充電ケーブル」

かと思います。私も例に漏れず、どうしたものか？と悩んでおりました。

なぜ悩むか？といいますと、通常のスマートフォンなどは、MicroUSB接続で充電ができます。これは、家庭用１００VコンセントからACアダプタを利用しても可能ですし、PCなどのUSBと接続しても充電することができます。端末側がMicroUSBなので、最終的にそこに導いてやればよいのです。

それに対してOptimus Padはというと、端末にデータ通信用としてMicroUSBジャックがあるのですが、ここに接続しても充電はされません。厳密にはほんの少しずつはされるようですが、あくまでもデータ通信をして余ったカスみないなものが流れるようです。実際、端末自体も充電状態にはなりません。

では充電はどうするのか？というと、専用のACアダプタが付属してまして、これを端末のジャックに指して100Vから充電します。そしてこのジャックがものすごく小さく細い仕様で、汎用品というのが皆無に等しいという感じです。

通常、自宅内で使用する分にはこれでよいのですが、私の場合、車載での利用がかなり高く、GPSを使用する機会も多いため、いくらバッテリーに余裕があるといっても、GPSを連続使用するとさすがに半日は持ちません。

そこで、車の12Vから電源を取れる方法を考えていましたが、いかんせん最終的にプラグが特殊なためなやんでおりました。

そんな折、以下のようなものを発見。

http://pocketgames.jp/blog/?p=14892

USBと充電ジャックを接続するケーブルです。

価格も送料・代引手数料全て込みで1000を切る価格と、手ごろだったため、早速注文。翌日には到着しました。

Optimus　Padの電源は5V2Aとなっていますが、通常PCのUSB出力は5V500ｍA程度。そして、一般的に販売されているシガーライターから取得するUSB電源アダプタも5V500ｍA程度です。

そこで、実験ということで、PCのUSBにケーブルを接続して、端末に接続してみました。

結果、しっかり充電モードになりましたので、まずは充電状態には成れたようです。

充電時間については、現在実験中ですが、大体

20分で8％上昇

といった感じ。明らかに充電は進んでいるようです。電流が1/4程度ですから、通常よりも充電には時間がかかるのは当然ですが、それでも上記の感じから、満充電には4時間半程度で完了しそうです。

当初は2Aアダプタを別途ようして、車載時にはそこから電源を取得することも考えましたが、この分なら安い500ｍA程度のアダプタで十分のようです。

使用するシチュエーションとしても基本的に車載時には常時接続することになりますから、

”減らなきゃいい”

自分にとっては、このケーブルはぜひお勧めできる一品です。

車載利用メインの方は一本いかが？

ストップウォッチ・・・・愚かな自分

前回、Timerの精度がウンチャラと書きましたが、そもそも論として、ストップウォッチの作り方の基本を間違っていました。

あまりに情けないので、書きたくないのですが、誰かの参考にでもなればということで、恥を忍んで報告してみます。

最初のダメ野郎な作り方は、Timerを使って、更新間隔ごとに、カウントを＋＋していたんです。だから、Timerが正確に1秒ごとに更新されなければ、当然カウントも1秒ごとに増えていきませんよね？で、そこで

”Timerの精度が・・・・”

となったわけですが、そもそもこの作り方が間違いの元。

Timerは使うのですが、問題は経過時間の出し方。

スタート処理時に　System.currentTimeMillis()　でミリ秒単位で取得。そして、Timerの処理内で、現在のミリ秒を同様に取得し、スタート時刻との差を算出。そしてsetText。


これで全て解決です。

あまりに基本的なところを間違えていたため、ガッカリすぎます。


本業の方がみたら、実は上記の解決も解決にはなっていないかもしれませんが、少なくとも現在ストップウォッチが20分以上作動していますが、見た目ではGPS時刻とのズレは把握できませんので、まあ良しとしましょう。


また一つ勉強になりました。これで近々公開できそうです。

Timerの精度が出せない・・・・

現在新たに開発を進めている、ASE Rally Monitorのライト版には、ストップウォッチを装備します。ストップウォッチ自体を作ることは難しくない・・・・・はずでした。

通常、ストップウォッチアプリなんかを見てみると、殆どがストップウォッチそのもののみを表示したりしています。

それに対して、今開発しているものは、GPSで時刻を自動補正した時計とストップウォッチを同時に表示します。ラリーにおいてはやはり時計というのは、最も欠かせないツールの一つですからね。

初めに、1/100秒単位のストップウォッチを作ってみました。

動作そのものは問題なく進んでいったのですが、ふと時計と比べてみると、経過時間がおかしなことに気がついてしまいました。

Timerを使ってストップウォッチを表示しているのですが、そのTimerの更新間隔がどうも時刻とずれているようです。Timerそのものの誤差といったところでしょうか？

きっとプロな方々はこんなことは当たり前で対処方法も知っているのかもしれませんが、私の力ではどうしても誤差を取り除く方法を見つけることができません。

そこで、試しに1/10秒単位に変更してみました。

すると、とりあえず時計表示と違和感はなくなりました。長い目でみればずれるのでしょうけど、何時間もストップウォッチを作動させておくことも非現実的なので、まあ良いかな？と。

ということで、ストップウォッチといいながら、1/10秒単位というなんか微妙なストップウォッチになりました。

アイデアばかりが浮かんでは消え・・・・

先日のMapViewの勉強も進まぬうちに、またまた別のものを試したくなってしまい、試作。

こういうアプリを作っていると、どうしてもいろいろ機能を盛りたくなってきてしまうものです。ただ、どうしても技術を追求すると、大多数のユーザーが使いづらいものになってしまうことが多いような気がしてなりません。

ASE Rally Monitor100 も既に開発はいったんストップさせています。不具合や細かい修正は続けていますが、新しい機能の追加は余程のものではない限り、先に述べた理由により意図的にストップさせています。

そんなわけで、先日のMapを表示する新感覚ラリーコンピューターに着手したわけですが、さらに原点回帰ということで、今一度基本からやり直してみることにしました。

ARM100を開発スタートした当初は、まったく手探り（今もですが）で進めていましたが、あの当時より多少は・・・・というかほんとに少しだけ理解できてきたので、もっと効率的な作り方があったんだ・・・とかが少し気付くときがあります。こんな私でも成長したんだ・・・・なんてね。

もちろん、このアプリについてもターゲットはあって、実際に狙い通りのものができたらマーケットにリリースする予定で進めています。

今回は、ARM100とは少し狙いをずらしたもので、よりシンプルなものかつ、ARM100に無かった機能を付加していく予定です。

詳しくはまた後日レポートしてみます。

Eclipseのアップデートでmain.xmlが開けないエラー

タイトルの通りのエラーが出て、”おいおい”状態になりました。

とりあえず、こんな感じで対処。

１．Eclipseを一旦終了

２．Eclipseフォルダにある【eclipse.exe -clean】を実行

３．Eclipseを起動

これで元に戻りました。専門家ではないので、これ以上突っ込まないでいただけると助かります。

ホント、綱渡りな開発者です・・・。

MapViewを組み込んだラリーアプリの開発スタート

しばらくアプリ開発を停滞させていましたが、先週あたりからチラホラ再開しだしまして、このお盆休みの機会に、新しくアプリを作ることにしました。

従来のASE Rally Monitor100と同様にラリーコンピューターアプリなのですが、今度はターゲットを

Android3.0～

に限定した、タブレット用ラリーアプリにしてみることにしました。

理由はいくつかあるのですが、その一つとして、私も開発用としてAndroid3.0タブレットを手にしてみて、確かにネットブラウジングなどはスマートフォンよりも見やすいですし、ノートPC(Windows）よりもすばやく起動するという利点があります。

ただ、それ以外になかなか”タブレットでなくっちゃ！”という場面に出会うことは正直少ないような気がしていました。

それは、ひとえに

タブレット用に考えられたアプリが皆無

ということだと勝手に思っています。スマートフォン用アプリもほぼ問題なく使えるのですが、レイアウトが崩れたり、そもそもスマートフォン用だからスマートフォンで使えばよい・・・・・みたいになって、どうしても中途半端になってしまいます。

そこで、少しでも”タブレットでなくちゃ！”という、タブレットユーザーに日の目を浴びていただきたいということで、スタートしてみることにしました。

そして、Android3.0～としたのは、そうしないと、スマートフォンでも使われてしまうことになり、その場合、考えているアプリはスマートフォンでは適さないと想定しているからです。

ただし、この”Android3.0～”というコンセプトは撤回することになるのですが、それはまた次の機会に。

ちなみに、開発を始めたアプリの試作画面はこんな感じです。

スマートフォンのCMは時代が止まってる？

この夏モデルから、各携帯キャリアではAndroidスマートフォンを大量にリリースしていて、いよいよキャリアもスマートフォンへのシフトを加速させてきたように感じます。

ただ、CMを見る限り、どのキャリアにおいても、結局”スマートフォン”の利点や特徴を理解させるようなCMではなく、単に今までのガラケー同様、見た目やらの宣伝しかしていないような気がします。

スマートフォンは、見た目もそこそこ大事かもしれませんが、一番はカスタマイズ性の高さや広さなんだと思います。

「こんなアプリを入れればこうなる」

みたいな宣伝をサクッとしたほうがはるかに理解されやすいと思うんですけどねぇ。

例えば、

「スマートフォンなら、こんなカーナビになるよ」

って画面見せてGoogleマップナビでも動かせば、”スゲーっ！”って思う人は少なくないような気もするんですよね。

もう少し頭使いましょうよ、広告代理店さん。高い給料貰ってるんですからね？

初エラーレポート

ASE Rally Monitor100は、公開から5ヶ月目に突入しました。

少しずつですがアップデートを繰り返してきましたが、果たして皆様問題なく使えているのかな？と不安はつきませんでした。

Androidアプリ公開者は、デベロッパーコンソールという管理サイトにより、アップデートや統計を管理していますが、その中にユーザーの端末で発生したエラーのレポートというのがあります。

これまで、他のアプリでは2件くらいエラーレポートがありましたが、現状で唯一有料で公開しているアプリASE Rally Monitor100に関しては、エラーレポートはありませんでした。

しかし、今朝、ついにエラーレポートが届いてしまいました。内容は

ArithmeticException




調べたところ、これは”0の除算”で登場していただくらしい。

大体想像できました。ラストアップデートで、ゴーストカーモードに追加した機能の中で、たぶんある条件になると、０で除算してしまうのだろうということです。

一応事前テストで、０で除算しないようにしたつもりだったのですが、気がつかないパターンで出たようです。まだまだ低脳なもので・・・。

ということで、もう少し様子を見てみてエラーレポートが増えてくるようでしたら、対策してみたいと思います。

エラー０は素人ながら結構誇りに思っていたので、かなりガッカリしていますが、ユーザーの方がこのエラーと出くわしたら、もっとガッカリだとおもうので、今のうちに予防を考えておきましょう。


※追記：予測されるエラー原因を対策してみました。これでたぶん大丈夫・・・・・なはず？

タクシーメーターアプリ

アプリ開発再開宣言から、わずか1日。

いろいろな練習を兼ねてアプリを作っていますが、そのうちの一つがこんなものです。

見てをお分かりと思いますが、「タクシーメーター」アプリです。

iphoneでは立派なものがあるようですが、Androidでは見つけ方が悪いのか、見つけることができなかったので、練習がてら作ってみようと思いました。

基本的な”距離＆時間併用”加算システムは完成して、テストをしてみました。地域によって違いますが、初乗りは２ｋｍ程度まで一定料金でそれ以後は距離により加算されます。またこれにあわせて時速１０ｋｍ未満の時間が100秒前後で累積されると1回加算されます。

テストの結果、概ねそれらしく動きました。ラリーモニターとは違い、距離を表示していないで、しばらくすると料金が上がる様子は、まさにタクシーメーターっぽいですね。

UIがショボイのは今後の課題として、まずは基本機能をつくり、その後で付加機能（割増・割引）を追加して公開しようと思います。

100円だったら買ってくれるかなぁ？無料じゃなきゃだめかなぁ？

ASE Rally Monitor開発再開！

ここのところ、少しいろいろ落ち着いてきましたので、ここらでしばらくご無沙汰していた

ASE Rally Monitor

の開発を再開させることにしました。

実際には落ち着いたといっても、解決そのものはしていないのですが、少し気晴らし（といったらユーザー様に失礼なんですが）でもしたく、それなら楽しいことをしたいということで、アプリ開発に戻ってみることにしました。

手始めに、現在実装しているGhostCarモードのバージョンアップをしようと思います。

現在のバージョンでは、ターゲット（GhostCar)に対する早遅を”距離”のみで表示しています。これは、一般のモニターの方（ラリーに関わらない方）が早遅を把握するのは、距離でどのくらい先にいるかの方が分かりやすいという声を反映させてみたものです。

しかしながら、従来の実戦ラリーの中では、距離よりも”時間”の方が理解しやすいことと、後どれくらいの余裕があるのか？例えば、タイヤの空気圧をチェックしたり、ヘルメットをかぶったりする時間にどれくらい余裕があるか？を意識するためには、やはり時間の方が都合が良いのも事実です。

そこで、距離による表示と時間による表示を切り替えられるようにします。

現在チェック中で、まもなくアップデートできるかと思いますので、しばらくお待ちください。

それにしても、少し間が空いただけで、ちょっと抜けてしまっている部分が出始めています。

基礎からみっちりトレーニングしたプログラミング技術ではないだけに、走り始めたら止まってはいけないようです。

お久しぶりです。

大変ご無沙汰しております。

いろいろ忙しくしており、現在アプリ開発まで気が回らないため、開発日記もストップしております。
せっかくお越しいただいたのに、いつまで経っても変化が無く、大変申し訳ございません。

まだもう少し続きそうなので、開発は涼しくなったころにできれば良いなぁとは思っていますが、手が空いたときは気分転換がてらに、弄っています。

アプリ開発をココでやめてしまうわけにもいかないので、落ち着いたら再スタートします。それまでは、たまにこうして謝罪の登場いたしますので、それまではご勘弁いただければ助かります。

現在ASE Rally Monitor100は有効なインストール率が９０％を超えています。これは100人いたら90人以上の方が、捨てないで取っておいていただけているということです。実際には使っていないのかもしれませんが、開発者としては、この数字は感謝させていただく数字だと思っております。

そんなアプリをこのまま放置するわけにも行きませんので、必ず進化させるなり、新しいものを作るなりはしていきますので、もう少しだけお待ちください。

ということで、またしばらくしたら定期謝罪？記事をあげたいと思います。

多角的視点は重要です。

ちょっと専門的（といってもプログラムではなく、車遊びの話です）になり、わかりづらいかもしれませんが、現在、ASE LapTimer開発に伴いモニターの方にテストをしていただいております。

その中で、ジムカーナという舗装のミニサーキットや広場にパイロンを立ててタイムを競うカテゴリーで活動されている方々が何名かおられますが、その方々から、こちら側がまったく想定していなかった指摘をいただきました。

私はラリーという、一般公道を閉鎖してタイムを競うモータースポーツをしておりますが、それはスタートからゴールまでが結構離れた場所にあり、基本的には一方通行なはずです。

しかし、ジムカーナという競技では実はスタートとゴールが近接している場合があるだけではなく、場合によっては一旦フィニッシュラインを通過することもあります。以下のコース図は先週末に実際に行われたコース図です。

ちょっとイメージがつかみにくいかもしれませが、スタートしてすぐフィニッシュラインを通過しています。でもこの時点では当然計測は終了してはいけません。

ところが、最初のバージョンでは、こういうシチュエーションを想定していなかったため、このまま使った結果、当然ながらいきなり計測が止まってしまう結果になったようです。

言われてみれば当然の結果ですが、自分が関わっていないカテゴリーなだけに、想定の範囲外ということで、改めて多角的な視点の重要性を認識させていただきました。

現在は概ね改良は完了して、次のバージョンのテストに進みます。

GPS時刻更新追加のその後

先週、GPS時刻更新機能を追加しました。

とりあえず様子見ということで、1分間隔で更新するようにしてみましたが、この場合だと、更新のタイミングで時計表示が1秒程度抜けてしまうことがあるようです。

Androidのバージョンや端末によりマチマチだとは思いますが、現状で私のAndroid2.2　SH-03Cではたまに抜けてしまうことがあります。

抜けるといっても、５２　～　５４　みたいに表示するだけで、致命傷にはならないとは思うのですが、やはりあまり気持ちがいいものではありませんよね？

ということで、今後はこの更新タイミングを考えてみると同時に、肥大化してきたコードを少し整理してみて、少しでも負荷を減らすことを考える必要がありそうです。

Androidスマートフォンは100完璧な性能を追求することは最初から見当違いだとは思っていますので、なるべく妥協点を見つけつつ及第点を挙げていくような工夫が必要です。これは開発者にも利用者にも言えることではないでしょうかね？

デベロッパーコンソールの統計情報

Androidアプリ公開は、マーケットの”デベロッパーコンソール”というところで管理・公開していきます。ここではアップデートや有料アプリの売上確認など、様々なことを行うのですが、その中の一つとして、統計情報なんてのもあります。

メイン画面では、アプリのインストール数等を確認でき、詳細ではインストールしていただいた方の増減や国・端末機種など大まかではありますが、把握することができ、参考にすることで今後の方向性などを分析することも可能です。

で、この集計結果の更新というのが、実に”適当”というか、信じがたいというか。

というのは、インストール総数と有効なインストール数というのがあって、インストール数はまさに今までインストールされた数。AndroidアプリはGoogleアカウントで管理しており、同一アプリであれば有料・無料問わず１アカウントで１インストールとなります。有料アプリなどを一回削除しても、再びインストールする際に料金がかからないのは、このアカウントで紐付けられているからですね。

で、有効なインストール数というのは、現在端末にインストールされているリアルタイムな数・・・・・なはずなんです。

アプリを利用している方は、概ね一度や二度はアプリを削除したりしているかと思います。削除されると、この有効なインストール数が減り、インストールされていれば減らないということになります。

総数は、今まで減ったことはありません。まあ当然ですよね？で、有効なインストール数というのは当然増減します。１回削除されれば１つ減りますし、その人が気が変わって再度インストールすれば１つ増えますから。

しかし、この数の更新頻度が実に適当で、決まった周期では更新されません。しかもここで厄介なことは、アプリがインストールされていないから数値が変わらないのか、更新されていないだけなのかが、判断しづらいということです。特に無料アプリしか公開していない方は、ここ以外で確認する手段は今のところないでしょうから、この数を気にする方は非常にやきもきすることでしょう。

では、なぜ”特に無料アプリしか・・・”なのか？

それは、有料アプリの場合、この統計とは別に、GoogleCheckoutという、Googleの各種サービスの決済をするところがあり、ここで売上等を確認することができます。このGoogleCheckoutの更新頻度は、少なくともデベロッパーコンソールの統計情報よりはリアルタイム性は上で、ほぼ売上と同時に状態を確認することができます。

したがって、実際の数などは、こちらで確認しながらの方がより現状を把握でき、その詳細をのんびり統計情報の更新を待つという流れになっています。

最近だと、あるアプリが、先週まで有効なインストール数が９０％を超えていました。しかし、今週に入って、インストール総数だけが一気に３０％も増えてしまい、有効なインストール数が更新されていないため、結果として現在の有効なインストール数が６０％程度に落ちています。ひょっとしたら、３０％の新規利用があったけど、それとまったく同じだけ手放した方がいたということなのかもしれませんけど、数から考えるとちょっと現実的ではないような気がするので、大丈夫だとは思いますが、不安にはなりますよね？

こうした統計はしっかりとした信頼性がないと、信じないだけではなく、不安材料になってしまい、あらぬ行動をしてしまうことにもつながりかねないので、しっかりと更新するならする、しないならしないと決めて欲しいものです。

プロに負けないためのアプリ開発

私の本業は、プログラマーでも、システムエンジニアでもなく、どちらかというとアナログ的な仕事がメインです。

そんな私が昨年末のAndroidスマートフォンを入手したことから、勢いでスタートしてしまったアプリ開発。

今では、有料版アプリを公開して、自分の中では沢山の方々にご購入いただいて感謝するばかりです。

有料版を公開した瞬間から、極力自分のことを”素人”と呼ぶことはやめています。３００円のアプリ、実質自分に入ってくるのは７０％で２００円程度ですが、お金をもらっている以上は外から見れば立派な”プロ”ですからね。

でも、ここからの話の都合、あえて自分を”素人”として、本業の方を”プロ”と区分けさせていただきますが、現在世の中には、同じようにAndroidoスマートフォンにガラケーから乗り換えたタイミングで、

”アプリを作りたい！”

と思っている方は沢山おられるかと思います。そうした中には自分と同じく、プログラマーでもなんでもないまったくの”素人”な方もおられるでしょう。

そんな素人にとって、もっとも二の足を踏むきっかけの一つが

”プロの存在”

ではないでしょうか？自分のことをいえば、”どうせ作ってもプロがちょろっと関われば数倍以上の出来のものを作られて終わりだ”という空虚感です。今でもそうです。

最近で言えば、私はラリーコンピューターの代用アプリをリリースし、今でも勉強できたことから改良に生かしながらユーザーの方々と二人三脚で成長していますが、ことあるごとにネットでラリーアプリなどを調べると、あちこちで”プロ”的な技術力を持つ方が同様のアプリ開発を進めていることを目にします。そんなときは、焦りとともに、”一気に追い抜かれるんだろうなぁ”という空虚感に襲われます。

では、そうした方との差別化を図るためにはどうすれば良いか？

技術力が圧倒的に劣る自分が考える答えは

・考えるより動く

技術があったり、学校で勉強したり、参考書を見ることに慣れている方は、とかく準備や手順というものを重視します。これはごく当然のことです。でも、自分も同じようにしていたのでは、技術力がない分、準備の時間は数倍以上必要になり、準備の段階で挫折することは間違いありません。

そこで、プロな方が準備している前に、動いちゃってどうせ追いつかれるにしても一歩でも二歩でも先に行っていた方が追いつかれるまでは自分のやりたいようにできます。

・素人ならではの、使う方の立場に立てる開発

これも私が重視することですが、技術者は技術に溺れる。これは定説のような気がします。そして、技術者というのはとかく自分の知識をユーザーに披露したがるものです。最初は受け側も付き合ってくれるのですが、あるところからは、ついて行けずに離れてしまうことが多々あるような気がします。私もユーザーとしてはそんなことを感じたことは多々ありました。

それに対して、開発者も素人ならば出来ることは限られている。そしてユーザーの技術力と近いレベルで物事を考えられるので、自分が上にいるだなんて間違っても考えることができません。技術の自慢もできませんからね。

自分でどんどん技術の投入ができない分、ユーザーから意見を聞いて”こうしたい”ということに対して自分なりに勉強して、ユーザーの意見中心から反映させていく。自分発信ではなくユーザー発信のアプリ開発は、素人でもプロに負けない要素の一つだと思います。

・自分に出来ることを全力投入する

プログラミングに劣るのであれば、広報活動やメール対応の素早さなど、プログラミング以外の部分で出来ることをとにかく重点的に行う。もちろんプログラムの勉強も並行していくのですが、素人ならではの視点で、”アプリの説明サイトを英語と日本語で作ったら？”とか、”素人ちっくな開発日記は？”とか思いついたことと出来ることを深く考える前にやる。人間勢いが無いとできないことって沢山ありますからね。

となんだか、ブツブツつぶやきみたいになちゃいましたが、要は素人がプロに”勝てる”要素というのは、同じ土俵上にはまず転がっていません。ならば同じ国技館の中に別の土俵を作って、そっちに観客を注目していただく努力をした方が、良い結果が得られる可能性は上でありそうだという勝手な思いです。

毎日が”プロによる追い越し”にドキドキでございますが、

「自分にできることはプロに無いいくつかのことだ！」

と自信を持って、自分の気が済むまでユーザーのために時間を費やしたいと自分自身に言い聞かせるための記事でした。

フライングスタートしたからには追いつかれる前にフィニッシュへ到着して、後でペナルティをもらいましょうか。

ASE LapTimerというストップウォッチ

今後の勉強と、自分のモータースポーツライフのツール作成を兼ねて、現在

ASE LapTimer

というタイム計測アプリを開発中です。

今更ラップタイマーかということは無しにして、一応自分がこれまでラリーというモータースポーツをしてきた経験を生かして、よりシンプルで自分達の利用シーンにマッチしたアプリを作っているところです。

ASE Rally Monitorに使われていない機能の勉強も兼ねており、その機能は

・GPSを使った目的地までの距離測定

・Timerを使ったストップウォッチ

・ImageViewを使った画像表示及び切り替え

主にこんなところでしょうか？この中で、”Timer"を使った・・・というのは、実はASE Rally Monitorでは今のところ、Timerは使っていません。機能の一部に所要時間を表示する部分がありますが、これは時計表示を利用しており、秒単位での表示にしてあります。

今回Timerを使ったのは、ストップウォッチということで、より詳細な計測をしてみようということで、1/1000秒まで計測するためです。

にわかデベロッパーなので、正しくないかもしれませんが、1秒ごとの繰り返しをする場合、Timerを使うよりも、DigitalClocｋのTextChangeを利用した方が簡単な気がしています。ASE Rally Monitorではこれを応用していろんな部分のタイミングを取得しています。

ただ、欠点は1秒以上のタイミングでしか取得できないということです。

今回は1/1000秒ごとに取得したいということだったので、新しくTimerを使うことにしました。

で、実際に1/1000秒まで使うか？というと、今回は1/100秒までにしました。これは、まずGPSによるスタート＆ストップタイミング取得にする都合、1/1000秒単位の精度が得られないこと。といって1/100秒では？やはり同じなんですが、1/10秒にすると、なんかストップウォッチの雰囲気がでないので、ビジュアル的な意味あいもこめて1/100秒にしてみました。

あとは、1/1000秒にすると、表示桁が１つ増えてしまい、テキストサイズが小さくなってしまうからという単純な理由です。

そんなこんなでTimerを試行錯誤しながらも無事使用することができて、ストップウォッチらしくなりました。

当初はこれで満足的な感じだったのですが、やっぱりいつものごとく、いろいろ欲が出てきております。

既に最初の段階とはレイアウトから違ってますから・・・・（＾＾；

接近アラートの練習

GPSによる位置情報の取得については、最低限のことは理解できてきました。ここで、次の段階・・・・というわけでもないのですが、今度はある地点に近づくとアラートを発するというアプリの勉強をしてみることにしました。

Androidでは、

"distanceBetween"

"distanceTo”

などを使用することで、2点間の距離を返してくれます。これを使ってある地点からある地点までの距離を計測することが第一歩になるかと思います。

ちなみに、"distanceBetween"は2点間の経緯度を指定すると、その直線距離を返してくれ、"distanceTo"は、ある地点の経緯度を指定すると、現在地との距離を返してくれます。

今回の勉強は、ある地点に近づくとアラートということなので、ある地点は固定点です。そして、近づくのは自分ですから、自分の現在地からある地点までの距離が必要ということで、後者の"distanceTo"を利用して距離を求めることにします。

これだけ書けば、後は単純ですよね？

一定時間ごとに、

距離取得

↓

アラート発生の判定

の繰り返しです。

このアラートを使うといろんなアプリの開発に役立ちそうです。自分の中でもいくつかアプリの構想があり、その中でも結構重要な役割をしそうなので、今回勉強してみました。

ASE Rally Monitorにこの機能を組み込むことでも、いろいろな役立ち機能になりそうです。その中でも、ペースノートのロスト防止のお手伝いができそうですので、もう少し煮詰めていきたいと思います。

GPSによるトンネル内走行２

出入口の経緯度による2点間距離算出は、トンネル走行等には適さないということで却下というのが前回までのこと。

で、結局採用したのが、トンネル内に入ってGPSが遮断される直前の距離を保持して、遮断中はその速度で走行していると仮定しトリップを進める方法です。

この方法だと、道路が曲がりくねってようが、遮断されている時間に比例して距離を進めるため、前回の懸念材料は考えなくてよくなります。

ただし、問題が無いわけではありません。

仮定速度で走行していることにするわけですから、実際の走行はその仮定速度からずれないように走る必要があります。極端な加減速をすると、出口で実距離と帳尻が合わなくなります。

ただ、車を運転する方ならわかるかと思いますが、余程都心部などで無い限り、トンネル内で停車したり加減速することはなく、殆どの方は、トンネル内は一定速度で走るのではないでしょうか？人間の心理として、トンネルのような狭く見づらい空間ではなるべく危険な行動はとらないようにするようです。

ということで、この方法を採用してテストをスタートしました。

近くにたまたま１ｋｍくらいのアンダーパスがあったので、そこを行っては直しを繰り返してとりあえず、大体の形にはなりました。まだ条件によっては距離が止まりますが、まあ、最初からまったく計測しないよりはマシだとは思われます。いずれにせよ次の交差点でリセットすれば良いですからね。

トンネル内走行処理はこんな感じでまもなく完了です。

GPSによるトンネル内走行

Androidに限らず、カーナビなどGPS機器でのトンネル内走行というのは、天敵の一つではないでしょうか？

通常のカーナビは、GPSの他に車速信号及びジャイロセンサーを併用するため、GPSが遮断された際も、どのくらいの速度でどの方向に向いて走るかをある程度算出し、その結果と道路のデータをリンクさせて地図上にプロットしていきます。

それに引き換え、現状スマートフォンにはジャイロセンサーは搭載されている端末もありますが、車速信号の取り込みは単体ではできません。ある機器を使うと、ECUからBluetooth経由で飛ばすことができますが、単体では無理ですね。

ということで、GPSのみでトリップメーターを使うと、トンネルに入ってGPS信号が無くなった瞬間に距離のカウントがストップします。もちろんトンネルを出れば復活するのですが、トンネル分抜けてしまう状態になります。

GPSだから仕方が無い

のですが、やはり少しでも使っている方が困らないようにしたいということで、この部分の処理をテストすることにしました。

一番簡単なのは、出入口の経緯度を取得し、2点間の距離を出すことです。しかし、この方法の場合、長いトンネルにおいて屈折している場合、距離がずれてしまいます。極端に言うと、螺旋状態のトンネルなどで、出入口が上下関係で重なっている（最近首都高にできましたね）場合、距離は殆ど進まなかったことになってしまいます。

直線のトンネルなら良いのですが、長いトンネルは結構屈折していることが多いので、この案はパスします。

別に実際に計測していないのだから、距離がずれても良いのだとは思うのですが、先にあげたような例の場合は、さすがに困りますからね。

ということで、別の案を採用することにしました。それは、また後日。

Android3.0タブレット生活を始めてみて

先週、急遽Android3.0搭載のタブレット「Optimus Pad L-06C」を入手し、Androidタブレット生活を並行スタートさせました。

まず、利点から。

・起動が圧倒的に早い

Windowsノートとの最大の違いはまさにこれだと断言できるかな？スマートフォン同様、起動待ちという概念は無くなります。ちょっとネットを見たいとかにはまさに最大限有効な利点でしょう。私が使っているWindowsノート「ThinkPad X32」（随分古いな！とかは言わないでください）は起動まで3分くらいかかるので、それに比べれば雲泥の差です。

・電源の持ちが長い

先週末は金曜の夜から日曜夜までラリーのため持ち歩いていましたが、帰ってきたときにバッテリー残量が８１％だったときは驚きました。これは端末のバッテリー容量にもよるので、一概には言えないのですが、電源が確保できないラリー会場などではかなり有効な部分ですね。

利点ばかりではなく、弱点も当然あるかと思います。

・入力がしづらい

スマートフォンよりはスクリーンが大きい分、まだマシですが、やはりキーボードには圧倒的に劣ります。特に私は一般的な方よりは多少入力速度が速いと思うので、余計その点が辛いですが、はっきり言ってこれは買う前から十分理解はしていたので、がっかり感はありません。近々キーボードをつないで使える環境を作りますので、そうすれば大分改善されるでしょう。

自宅などでは、キーボードを使った方が絶対に良いと思います。そうすれば弱点の一つは問題なくなるでしょう。

・Android3.0を”携帯端末”と認識されてしまう

これは、予想外というか頭にありませんでした。例えばYahooメールなどをブラウザから見ようとすると、モバイルページになってしまい、自分でPCページへと変更しなくてはなりません。Amebloとかのブログサイトなども結構これで二度手間になります。別にモバイルページで見ればいいのでは？と思われるでしょうけど、画像などが表示されなかったり、PCページにあるはずのリンクがなかったりと、結構戸惑うことがあります。これは結構不便ですね。

まあ、まだ初めて数日なんで、あんまりいきなり決め付けてしまうのも発展の妨げになりますから、あまり急がずにいろいろ把握してみようと思います。

よく、iphoneユーザーがAndroidをけなしたり、逆のパターンも同様だったりと、自分が使っているもの以外を否定することを目にしますが、これは自分の発展や視野を著しく狭める残念な考え方ではないかな？といつも思います。

それぞれの環境で得意・不得意分野があるのをしっかり認識して、その有利な点を上手くつまみ食いすると、それぞれにしか無かった見え方から新たな視界が広がることは間違いありませんから、それぞれを自分のライフスタイルに上手くマッチさせることが重要かな？とOptimus Padを入手して改めて実感している毎日です。

ASE Rally Monitorの実戦導入を終えて

この週末に開催されたラリーにてASE Rally Monitorの開発版実戦テストを行いました。

基本機能は問題ないようですが、先入観なく使っていただいた感想として、問題点としてあげていただいたのが

「トンネル内での欠測」

です。GPSを使った距離表示のため、当初からわかっていることですが、実戦で指摘されてしまうと、やはり何とか少しでもプラス方向へ改良したいという思いが出てきます。

GPSだから仕方ないんですでは、やはり許されないというか、自分の中で納得できないので、今後はこのあたりを少しでもマシになるように試行錯誤してみようと思います。

スマートフォンだからこんなもんか

という感想を

スマートフォンなのにこんなにできるの！？

に変えることが今の楽しみかもしれませんね。

先週末の問題について

先週末、突如として私がマーケットに公開しているすべてのアプリについて、

「このアプリケーションは0台以上の端末で・・・」

と表示されてしまっていた件について、実は以前5月はじめ頃にも同じ状態になり、そのためか、公開しているアプリがマーケット上で表示されなくなってしまうことがありました。その際は、マニュフェスト上で、スクリーンやキーボードを細かく指定してしまったためと予測し、それらを未指定にしてアップデートした結果、無事復活しました。

今回も同じ状態かな？と思っていたものの、今まで1度もアップデートしていないアプリまで0台状態になってしまったため、一応スクリーンなどのマニュフェストを再度確認してアップデートしてみるものの、改善されません。そこで、まったく素のテストアプリを一つ作ってマーケットに上げてみます。やはりこのテストアプリもだめでした。

もはや原因がわからない状態となり、土曜の2：30過ぎ。ラリーのサポートに出発するギリギリとなってしまったため、一旦原因追求は保留とし、最後にマーケットで自分のアプリが出てくるかをチェックしてみると・・・・

なんと、すべてのアプリが出ていることが判明！

でもデベロッパーコンソール上では未だに0台状態には変わりありませんでした。

タイムリミットを越えてしまったため、原因は帰ってから見ようと思い昨日夜帰宅後にチェックしてみると、

・・・・

425台！

もうわけがわかりません。デベロッパーコンソールの更新や数値の表示は、結構適当だったので結局のところはデベロッパーコンソール側の問題だったのかな？と。というのも、上記のテストやアップデートを行っていない放置アプリについても、土曜早朝までは0台だったものが、昨晩は400台以上になっていました。何もしていないアプリが変化しているということは、デベロッパーコンソール側としか思えない、思いたくないという感じです。

とりあえず、昨日もアプリをご購入いただけているので、問題は解決したのかな？と素人ながら期待しつつ、iphoneよりはかなり低価格とはいえ、マーケット公開にお金を取ってる以上、もう少し正確なコンソールを運営して欲しいものです。

ASE Rally Monitor300（仮）開発スタート

Android3.0実機を入手して従来のASE Rally Monitor100をテストしてみたところ

動作的には問題は無いのですが、スクリーンサイズが大きくなったことで、数字や入力が快適に操作できる反面、ちょっとテキストサイズが大きすぎるような気がしてきました。

個人の趣向によるので難しいところですが、せっかくの大画面（という表現が違和感ありますが）なので、単に見やすいというよりも、より操作性が高いものにしたいということで、こんな感じで試作し始めました。

従来のバージョンは、数値の入力を”タイムピッカー”と”オリジナルテンキー”の２つで実施しています。タイムピッカーダイアログは、メイン画面にオーバーラップして表示されますが、オリジナルテンキーは別画面へ遷移して行うため、入力完了までが長くなってしまいます。

そこで、メイン画面にテンキーを配置して、直接ここで入力できるようにしてみることにします。また、従来は端末のメニューボタンを押すことで各種モードを呼び出して処理をしていましたが、これもメイン画面に専用ボタンを配置して、直接モード操作ができるようにします。

これにより、ラリースタートからフィニッシュまでほぼ1画面で操作できると予測しています。

最初から従来バージョンもこうすればいいじゃん！って突っ込まれそうですが、従来バージョンは３～４インチのスマートフォンを対象に開発をしています。スマートフォンでこのレイアウトにしてしまうと、時計や距離が小さくなりすぎて現実的ではなくなってしまいます。そこでスマートフォンは見易さを最大限に追求するかわりに、若干操作ステップが多くなってしまいました。

今回のASE Rally Monitor300（仮）が上手くいけば、スマートフォン・タブレットそれぞれの利点を最大限に生かすアプリ開発のきっかけになりそうですので、引き続き両方共に進めていきたいと思います。

スマートフォンを使ったトラッキングシステム

今週末以下のサイトで、無料サービスを使ったトラッキングシステムの

テストを実施します。

http://team-ase.blogspot.com/p/live-tracking.html

本来は、ASE Rally Monitorを含めたシステムを開発してみたいのですが、いかんせん素人プログラマーもどきなので、なかなかそこまで追いつけません。

仕組みはわかります。

バックグラウンド上でメールにて位置情報を送信

↓

位置情報を受信

↓

データをGoogleMap上にプロット

↓

プロットされたらGoogleMapを更新

↓

1分後に振り出しに戻る

技術力が無い私の場合は、技術力を身につけるよりも、横着して無料サービスを探す努力をしてしまいました。

将来的には自分ですべて出きればいいんでしょうけど、さすがに仕事じゃないので厳しいところですね。

ちなみに上記サービスはiphoneでもできます。ただし、ラリーの場合は山で開催されるため、本番中はなかなか厳しそうな気もしますが、将来の可能性としてはありかもしれません。

Optimus Pad運用スタートは早くも効果あり

昨日Optimus Padが到着し、いよいよAndroid3.0の実機運用がスタートしました。

初期設定は既にスマートフォンで一度やっているため、はじめてAndroidに触れるよりは大分スムーズに行き、K-9メールアプリの設定をはじめ、特別に問題なく設定は完了しました。

WEBブラウザは、殆どGoogle Chromeなので、普段Google ChromeをPCで使っていれば、お気に入りなどのインポートは簡単すぎるほどあっという間です。

で、早速Android3.0の実機の恩恵を受けることになりました。

開発/公開中のASE Rally Monitorは既にAndroid3.0に一応対応しています。早速インストールしてみると、特別に問題はなく動いています。

次に、開発バージョンも同様にインストールしてみます。すると、インストールは完了しましたが、アプリが立ち上がると同時にエラーになってしまい、強制終了してしまいます。

？？？

特別に何かを変えたつもりはなかったので、非常に悩みました。マニュフェストを公開版と比べても問題なく、まったく原因がわからないこと小一時間。

で、EclipseのDDMSで確認してみると、どうも”Clock Lavel"が見つからない的な感じ。しかし該当テキストはあるし・・・・・・とよくよく見てみると、ようやく原因が判明！

原因は、時計表示のIDがあり、そのカラー等を設定する際に”TextView00"としてコード上で宣言しているのですが、レイアウト上のIDが”TextView"となっていたため、レイアウト構築時にエラーとなってしまったというものでした。

なぜか開発版のxlargeスクリーンだけここが変わってしまっていたため、公開版では問題なくて開発版でエラーになっていたんですね。あまりにも単純すぎる原因でしたが、いかんせん今までのエミュレーターがあまりにも激重だったため、デバックできなかったのですが、実機でのデバックはあまりにもスムーズなため、頻繁なチェックの末発見できた次第です。

やっぱり実機に敵うものはありませんね。

今後もデバッグ用として大いに活躍していただくと共に、普段のネットライフもコチラ中心で運用できそうなので、投資価値としては十分期待できそうです。

Android3.0ポチッた

Android3.0が国内で流通しだして３ヶ月くらい経ちますが、ASE Rally Monitorも流通当初からAndroid3.0への対応ということで微力ながら動いてきました。

で至るところで言われているのが

”Android3.0のエミュレーターが遅すぎる”

ということです。例に漏れず、私の開発環境でも重過ぎてストレスを感じていました。

そんな中、今後のことも考えて、勢いで

Optimus Pad　L-06C

をポチッちゃいました・・・。

メール・HP作成・ネットブラウジングのすべてを現在Google様に頼りきっている自分としては、普段の生活では、Androidタブレットの方がストレスなく過ごせるかな？というのが一番の理由です。そのほか、曲がりなりにも開発する人間としては、自分で頻繁に動作を試せないAndroid3.0エミュレーターにどうしても納得がいかなかったというのも理由の一つですね。

自分のためにも使いますが、いろんな人にASE Rally Monitorをはじめ自分のアプリを説明する際、スマートフォンよりもタブレットの方が説明しやすいとか、お客様に写真を見せる時に、印刷したものよりも画像の方が管理がしやすいとか、まあいろいろこれから使い道を考えてみます。

自分の勉強に対する投資だと思って、勢いに任せてポチることも時には重要なんだと、自分に言いきかせてみます。

WebViewの勉強

ホント、順番がめちゃくちゃで参考にならないと思いますが、WebViewの勉強のために、一つアプリを付くて見ました。

現在の全日本ラリー選手権では、タイムの速報を公開する主催者がほとんどとなっておりますが、スマートフォンの場合、携帯サイトが使えないためPCサイトでこの速報を確認することになるかと思います。その場合、見たいページに行くまでに数ステップかかってしまうことと、いちいちサイトを探さないといけません。

そこで、アプリ側で見たいページ（STAGE番号）を選択すれば、ブラウザで表示するというアプリです。

アプリ起動後に、ListViewからSTAGE番号を選択すれば勝手に表示しますので、アプリ起動と選択の２STEPで行けるはずです。

WebViewはGoogleマップをはじめアプリでは必ず使うものの一つなので、今回初歩を勉強してみました。今後も引き続き勉強してみようと思います。

次なる課題

ASE Rally Monitorの開発を通じて、常時課題をいただいているような感じで過ごしておりますが、画面遷移の基礎を覚えた次の課題は

”データベース”

です。具体的には、SSのタイムを記憶しておく機能を作りたいということになります。

現在は、STAGEモードの終了時に所要時間（STAGEタイム）をToastにより表示していますが、これをデータベースに保存するという機能を作りたいと思います。

ユーザーの方から、この機能についての希望をいただきました。本番のタイムは実際には公式記録として残りますので、あえて保存しなくても良いとは思いますが、練習などではいちいちタイムを覚えておけません。そこで、ASE Rally MonitorのSTAGEモードを利用し、スタート～フィニッシュを行うだけで記録できたらなぁというご希望です。

基本的には

ステージフィニッシュ処理

↓

SQLiteで保存

↓

設定画面かメニューに呼び出し＆クリアを配置

そんな流れかなぁ？と。

こんなのも今更言う話でもないのですが、素人プログラマーもどきなもので、ちょっとずつです。

スイスからの問い合わせ

アプリ公開から、グローバル化が始まった我が人生？

昨日、スイスのユーザーからASE Rally Monitorについて問い合わせがありました。

どうも数値入力が上手くいかない様子。HTC　Desireで入力したけど反映されないということで、わざわざ動画を送っていただきました。ありがとうございます。

で、理由については、現在不明ですが、端末とアプリの関連かな？と想定されます。他にも同様の方がおられましたらご連絡ください。

この方は先月３０日に購入いただき、２日後の一昨日から不具合が出たということ。それまでは正常らしいです。

この間にアプリをアップデートしたならば、アップデート部分に問題があると予測できるのですが、最終アップデートが５月２６日なので、

アップデート→購入→２日間は正常→２日後から不具合

ということを考えると、アプリ側の問題というよりは、端末やその他利用環境がこの２日間で変わったためによる不具合の方が可能性があるかなぁ？と予測しています。

とりあえず、現在開発中のバージョンを送ってみて様子を見ます。というのは、開発バージョンは先にお知らせしたとおり、数値の入力方式を端末に依存しないようにしたので、もしこれで数値が入力できるようだと、予測通り端末側の問題かな？となると思われます。

まずは様子を見てみます。

簡易AVEモード試作中

さて、テンキー入力の試作が完了し、現在テスト中ですが、テンキー入力（画面遷移）のレベル１を取得したため、いよいよ禁断のエリアに足を踏み入れることにしました。それは

「アベレージモード」

簡単にいうと、ある区間の平均時速（指示速度）がわかっている場合、その平均時速に対する早遅を表示するというモードです。

実際のラリーコンピューターでは、リアルタイムに、指示速度に対して何秒遅れて走行しているとかを正確に表示してくれます。

このモードは、早い段階から要望があったのですが、いつかは実装したい程度で考えていました。

で、今回ようやく着手することにしたのですが、いくつか前提項目があります。それは

・GPSの距離計測は１秒単位での早遅表示は無理・・・というか無意味

・表示部分に限界がある。

GPSの件については、どうしても常時計測することが難しいGPSで、１秒単位の精度を求めることは当初から無理だと認識しています。そのため、着手にいたらなかったわけですが。

したがって、あくまでも”参考”程度の表示を前提とする必要があります。

次に、表示部の限界ということですが、せっかく画面遷移を覚えたのだから、AVEモード用に画面を移せば良いじゃん、っていう考え方もありますが、あまり画面が行ったりきたりすることはAndroidの性格上よろしくなさそうです。実際のラリー中も、なるべく表示は動かない方が疲れないかな？と認識しています。

これらを念頭において、とりあえずAVEモードの開発に着手したわけですが、従来のラリーコンピューターの早遅表示は、

「指示速度に対して”何秒”ずれているか？」

ということで、○○秒遅れ！とかで表示されます。この場合、当然１分以上ずれていると、表示は

「○○：XX:**」

というフォーマットにしないといけませんが、ここで先に述べた前提項目の”表示部の限界”というのが効いてきます。

どこに表示するかですが、時計・残り時間・到着予定時刻は常時表示させておきたい。あくまでも参考なのだから、優先度はそれらに比べて低い。と考えると、残りの表示の中で更に優先度が低そうなものと切り替えることになり、結果として”REFUEL(燃料給油までの距離）”を使うことにします。

そうすると、先のフォーマットにした場合、桁がたりないということになります。

そこで、このREFUELと同じ距離で早遅を表示すれば良いのでは？と考えます。

つまり、

「指示速度どおりに走っていると仮定する車と実際の自車の位置との距離差」

を表示したらどうでしょうか？ということです。

指示速度どおりならば、ずれは”0ｍ”になり、遅れていれば”５５０ｍ遅れてますよ”ということです。

最初は慣れが必要かもしれませんが、参考にする程度であれば、これでも目的としては同じことなのでは？と淡い期待をしています。

ということで、試作がまもなく完成しますので、AVEモードを要望していただいていた方にテストバージョンをお送りしてみようと思います。

どこまで行くんだろう、ASE Rally Monitor・・・。

テンキー画面試作中

ASE Rally Monitorの数値入力、具体的には”距離の入力”について、現状のバージョンでは、Androidのソフトキーを使って入力する形になっています。

これは、必ずしも便利とは言い切れないのは当初からの課題でしたが、現在テンキーを別途制作中です。

それがこれ。

入力するときに、別途この画面を呼び出して、入力して元に戻るという流れです。

Androidアプリ開発の超基本である”画面遷移”に、今頃ながら着手したという情けなさですが、結構四苦八苦しながら、ようやくゴールが見えてきました。

やはり格段に入力のしやすさがあがります。もう少し自分でテストをしてみたら、モニターの方にご協力いただき、最終テストに移りたいと思います。

テンキーが実装されると、アプリの魅力が上がりそうなので、もう少しがんばってみます。

今更ながら画面遷移

ASE Rally Monitorの中で、距離を入力する項目がいくつか出てきます。

現在この入力については、Andorid内のキーボードを使用するようにしていますが、横スクリーンで使用すると、数字以外のキーも表示されてしまい、結構入力はしにくいという理解をしています。

縦スクリーンの場合、入力を数値規制していれば、電話と同じように数字のみがキーボードとして表示されるのですが、アプリの性質上そうもいかないため、頭を悩ます材料のひとつになっていました。

で、早い段階で、

「別画面でキーボードを作れば」

という構想はもっていたのですが、いかんせん、にわかデベロッパーの思い込みとは怖いもので、

「画面遷移をすると、距離計測が止まる」

と勝手に決め付けていました。この思い込みがあったため、別画面でキーボードを作ることをプランから外してしまい、その代替策として、

「ダイアログでキーボードを作る」

ということをひたすら考えていました。

ダイアログというのは、時刻入力とかするあのポップアップメニューみたいなやつですが、あれが表示されているときはActivityが動いているというのを既に認識していたため、この方法を考えたと次第です。

Android3.0には、標準で”Number Picker"というものがあるため、レイアウトなどは非常に簡単なのですが、Android2.ｘでは、簡単にはいかないようで、散々悩んでおります。

そして、気分転換というわけでもないのですが、今更ながら画面遷移でもやってみようかな？と試しにキーボードを作って画面を遷移させてみると・・・・

「裏で距離動いてんじゃん！！」

ということで、素直にキーボード画面を作ってみることにします。

タブレット入手するかなぁ・・・。

現在自宅で使用しているノートPCは

ThinkPad X32

です。年代物ですが、昨年HDを交換＆容量アップして、まだまだ活躍していただくつもり満々なのですが、結構いろいろと疲れている感じは否めません。

このPCでは、WEBブラウジング、ホームページ・ブログ管理をはじめ、メールやアプリ開発・画像編集までさまざまに使っていますが、殆どの割合としては、

WEBブラウジング・ホームページ・ブログ・メール

になるかと思います。

ココで、ふと考えてみると

WEBブラウジング：Google Chrome

ホームページ管理：Googleサイト

ブログ管理：Blogger(Google）

メール：Gmail（Yahooメールもコチラで使用中）

と、実はGoogleラーであることに改めて気がつきます。

で、これらのサービスはWindows環境でなくても、Androidで十分使えるのは言うまでもありません。

だったら、起動の早さやThinkPadへの過負荷を防ぐ意味もこめて、Androidタブレットがあれば困らないのではないかい？と思い始めております。

にわかではありますが、Androidでべろっぱーを表記するのであれば、やはりタブレットを持っていなくてはいけないような気もしますし、近々タブレットを入手してみようかな？と思う今日この頃です。

かなり今更感は否めませんが、せっかくの機会なので、手を出してみようと思います。

マーケットに出てこなかった原因

昨日お送りしたように、ここ１ヶ月近くASE Rally Monitor100はAndroid Marketに表示されていませんでした。で、昨日アプリ側を見直してアップデートしてみた結果、無事に表示されるようになり、早速ご購入いただくことができました。

購入いただいた方は、ここか本家のブログを見て、きっとわざわざご購入いただいたんだと思います。この場をお借りして感謝申し上げます。ありがとうございました。

さて、原因ですが、予想通りアプリ内の”マニュフェスト”に余計な設定をしてしまっていたためのようです。

このアプリを使用できるスクリーンやキーボードなどの指定を意味を理解せずに設定してしまっていたため、それらの条件を満たす端末が世の中になくなってしまい、結果としてマーケットに表示されなくなったというのが原因だと思われます。

世の常として

”余計なことはするな”

というのはまさにこのことですね。

デベロッパーコンソールの”対応デバイス”が・・・・

ASE Rally Monitor100は、ありがたいことに、ほぼ毎日ご購入いただいておりました・・・・・・・５月頭までは。

それから、パタッと止まってしまい、ニーズを満たして止まったんだろうと思っていましたが、今まで毎日だったものが１ヶ月ちかくも無くなってしまうと、いろいろ不安になったりもします。

しかし、単にアプリの魅力が低いのか？とも思えるし、なんともなここ最近でしたが、ふと今日マーケットの管理サイト”デベロッパーコンソール”を見ていたら、見慣れない項目がありました。それは

このアプリケーションは､アプリケーションのマニフェストで定義されているように、これらの機能を備えた端末でのみ使用できます。

画面レイアウト: SMALL NORMAL LARGE XLARGE

必要な端末の機能

android.hardware.location

android.hardware.location.gps

android.hardware.touchscreen

このアプリケーションは 0 台以上の端末でご利用いただけます。

？？？対応端末が０台？

試しに他のアプリで確認してみると、４００台程度の端末に対応と表示されています。

これは何だ！？？

といろいろネットで情報を探してみても、いまいち原因がわかりません。とりあえず、マニュフェストが関係ありそうということで、マニュフェストをアプリ同士で比べてみると、どうやらいくつか原因らしきものが見えてきました。

とりあえず、それを直してみてマーケットにアップデートしてみたら、

”403台”

にレベルアップしました。

これでまたしばらく様子を見てみて、原因であれば、申し訳ないことをしてしまったということになります。

Android Marketはしょっちゅう変更されているようですので、今後はちょくちょくチェックしなくてはなりませんね。

縮尺自動計算ツール

昨日は、息抜きを兼ねて、これまでとは違うアプリを作ってみるという話でしたが、早速作ってマーケットに公開いたしました。

縮尺自動計算ツール

たいしたものではないですが、地図などを見ているときに、

「この地図で○○ｃｍか。これって、実際に何mくらいなんだろう？」

って思うときって、少なからずあるかと思います。

また、

「この地図の縮尺ってどのくらい？」

なんてことも。

そんな時に、わかっている2つの数値を入力することで、残りの答えを導いてくれます。

たいしたものではないといったのは、これは計算自体は掛け算か割り算だけだからです。でも、とっさのときに、

「どっちが分母だっけ？掛けるんだっけ？割るんだっけ？」

っていうときに迷わないで済むかと思います。

実は、1年くらい前に、フラッシュ版を作っていました。意外にアクセスがあったので、Android端末でも需要があるかな？と期待しています。

息抜きアプリ製作中

1月後半から、Java～Androidと、０からアプリ開発を勉強してきて、その間にほぼASE Rally Monitorオンリー（Rally Signalというのも作りましたが）で来たためか、少し頭が硬くなってきてしまったと感じています。

同じアプリに向き合ってばかりでは、新しい発見や技術の向上に支障がきたしそうな気がしてきたので、今週はまったく違うアプリの開発息抜きがてらしてみることにしました。

既に概ね完成しており、特段珍しいアプリでもないのですが、あると少し便利かな？というものを作っています。今週末までには公開できるかな？と。

ちなみに、今回の息抜きアプリのテーマは

”多国語化入門”

と今更ながらですが、いろいろやってみてます。

中華PADでのASE Rally Monitorテスト

中華PADでのレポートが届きました。抜粋させていただくと以下のようなレポートです。

「Dropad A8という7インチ静電式のTabのGPS対応CFWが出ましたので試してみました。この機種にはGPSは内臓されていないので、USBドングルによるGPSになります。問題なくたちあがり測位もできています。」

その様子はこちらです。

いろいろ精力的にテストしていただいており、感謝するしかありません。

ASE Rally Monitorの開発について、最近は少し停滞気味です。というのも、自分のスキルでできることがそろそろ壁に差し掛かってきており、ココから先はじっくり勉強していく必要がありそうな気がしています。

同じアプリ開発で勉強していると、時に嫌気がさしてきてしまうため、気分転換にまた違うアプリでも作ってみようと思います。

複数チェックの重要性

マーケットでのダウンロードもココのところ落ち着いてきたようで、一旦休憩といったところでしょうか？

そのような状況ですが、現在何名かの方々にお手伝いいただきまして、精力的にテストなどを行っていただいております。

2月末の段階で、早々にマーケットに公開した当初は、実際のラリー競技に最低限使えて、距離＆時計が誤作動無く使えれば良いかな？程度に考えておりました。というのも、実際にこういうものに対して、どのような方からどのような使い方を希望するのかが未知数だったため、自分基準で作っていたからでしょう。

公開してしばらくするうちに、自分が関わるラリー競技に近い方から、まったくラリー競技に接していない方まで、さまざまな立場にてアプリを利用いただくようになりました。

そうすると、自分が想定していない使い方や利便性の優劣など、新しい基準などが生まれてくるようになります。

ココで必要になってくるのが、さまざまな目線からテストを繰り返すということですね。

今まで自分が気づかなかったことはもちろん、気づいていてもあえて重要視していなかったことまで、いろいろな問題や発展に出会うことができます。

こればかりは、自分ひとりではクリアしていくことができませんが、幸いかなり献身的にご協力いただける方が沢山おられるおかげで、少しずつバージョンアップを繰り返していくことができます。

既に3ヶ月前を振り返るとかなり発展をさせていただいておりますが、まだ大きな課題をいくつか残しているので、皆さんに忘れられないうちに勉強していきたいと思います。

開発協力いただいている方はもちろん、ご利用いただいているすべての方々に毎日感謝です。

デイ＆ナイトモード検討

ちょっとご無沙汰しておりました。公私共に忙しかったもので。

さて、現在モニターの方やユーザーの方から、多種にわたるアイデアをいただいており、うれしくも悩ましい日々を過ごしております。すべてに対応することは難しいですが、ご要望が多いものについては、少しずつでも対応していきたいと考えております。

そんな中で、当初から検討しているうちのひとつが

デイ＆ナイトモード

です。カーナビなどでは、昼夜で白黒が逆転した感じの配色に変わるかと思います。要はあれです。

結構最初の段階からこれは検討していましたが、まずは機能をある程度まとめたかったということで、一時保留していました。

最近またこのご要望があるということで、再度テストを開始しようと思っているのですが、実はスマートフォン（に限らずですが）のディスプレイはハード的にかなり反射しやすいので、配色うんぬん以前の問題だったりします。以前一度テストした際も、正直見やすくなったのか？という程度しか影響がなく、それよりも表面に反射防止シートなどを貼った方が効果があるのでは？と思っています。

ただ、アプリ側でデイ＆ナイトモードを搭載することで、少しでもお役に立てればとは思っていますので、近々テストをしてもらい、アップデートしていきたいと思います。

GPSスイッチ追加中

iOSでの開発は一旦・・・というか、当面置いておいて、本筋に戻りましょう。

ASE Rally Monitorもバージョン２へとアップデートし、引き続きいろいろ試してみたいと思っていますが、簡単なところから徐々にということで、現在テスト中なのは、

”ＧＰＳ起動メニューの追加”

今までのものは、先に端末自体のメニューからＧＰＳを起動させておいてからアプリを起動するという流れでした。慣れてしまえば、これでも際立って面倒ということもなく、ホーム画面に、ASE Rally MonitorとＧＰＳスイッチの２つを配置しておけば、まあ問題は無いかな？というレベルではありました。

でも、やはりたまに、ＧＰＳ起動を忘れてアプリを立ち上げてしまい、一旦戻って・・・・なんてことがあるのも事実です。

ということで、今更ながらシリーズですが、メニューにＧＰＳ起動を追加してみました。

Ａｎｄｒｏｉｄの仕様で、例えばアプリを起動したら、自動でＧＰＳが起動するということは基本的にはできないというか、してはいけないようなので、こんな流れになります。

ASE Rally MonitorのメニューからＧＰＳ起動を選択

↓

端末（ＯＳ）の設定画面に遷移

↓

ＧＰＳ起動にチェックで端末の”戻る”を選択

↓

ASE Rally Monitorに戻って、ＧＰＳ捕捉待ち

こんな感じです。ダイレクトでＯＮにできないのは、例えばＧｏｏｇｌｅマップなどで、特別に現在位置を知る必要が無い場合は、ＧＰＳは使いませんが、もしここでユーザーの認識外の状態にて自動でＧＰＳが起動してしまうと、知らないうちにバッテリーが消費されてしまったりするからなんだと思います。

ということで、ASE Rally MonitorのメニューにＧＰＳ起動を追加してみました。

当面の目標は、Ｂｌｕｅｔｏｏｔｈ制御の勉強かな？と。

やはりiphoneは恐るべしか

昨日、ASE Rally Monitorについて、初めてドイツから問い合わせがありました。その内容は、

「iphoneバージョンは無いの？」

というもの。

既に以前、日本の方から同じお問い合わせは何度かいただいておりましたが、海外からも同じような問い合わせをいただいたことで、改めてiphoneのシェアというものを実感いたしました。

残念ながら、現在のところiphone版の開発は予定していません。ご存知のとおり、iphone(iOS)のアプリを開発するためには、以下の2点が最大のネックです。

• MACが必要
• 毎年2万近くの登録料がかかる

その他にもプログラムを勉強する必要がありますが、これはAndroidの時と条件は一緒なので、受け入れることができますが、上記2点はどうやっても15万くらいの初期投資が必要になりますので、そこに参入することができません。そんなお金があれば、ラリーに出たいし。

もちろんiOSのアプリの方が売り上げとしては期待できると思います。でも、同じ価格で元をとるためには少なくとも500以上売らないといけません。iphone/ipadで５００は、どうなんでしょう？まったく予測がつかないですね。

ユーザーとしてはまだまだiOSの方がかなり多いと思うので、その方々にぜひASE Rally Monitorを使用していただきたいのは山々なのですが、誰かがMacを買ってくれるまでは当面お預けというのが現状です。

せめて登録料がもっと安ければ・・・。

アップデートその後の失態

昨日は、ASE Rally Monitorのちょっと大きなアップデートを行いました。

記事の中で、”機能は毎日テストをしていた”と書いていながら、大失態をしてしまいました。原因を追究することが重要なので、大失態にいたる原因を追究します。

まず、大失態の内容というのは

”キャリブレーションモードが正しく機能しない”

というもの。操作系は正常なのですが、キャリブレーション終了処理をしても、計算結果が”０”になってしまうというものです。

キャリブレーションモードを開発したのは4月半ば。その際には当然繰り返しテストをして思うように動作するようになりました。その後、外部GPSロガーを使用するためのテストに移行します。結論はここで根本的な原因が発生します。

まず、距離の算出を簡単にいうと

GPSから取得する秒速　ｘ　キャリブレーション比率　＝　表示する秒速

となります。スマートフォンの最小更新間隔が”１秒”なので、GPSは1秒ごとに位置情報を取得します。したがって、1秒ごとに秒速を加算していけば、そのまま距離として使えるという内容です。

ところが、ここで外部GPSを使用するということは、この”1秒ごとの更新”が違ってくるということになります。

そこで、その対策をするために、テスト用にAとBという2系統の追加トリップをプログラム上で走らせてどちらが良いかを試して、最終的にAという系統を使うことにしたのですが、テスト中、最初はAにしていたものを後半からBにしていました。

AでもBでもトリップは表示するので、気づかなかったのですが、キャリブレーションモードの計算にはAしか使っていなかった。そのため、Bのままだった状態ではキャリブレーションモード内で距離を計算できずに、結果として”０”になったというわけです。

なぜこういうことがおきたのか？

理由は簡単。それは

頭の中でしかプログラムを考えない

から。本職の方からしたらお叱りを受けるかもしれません。

フローチャートとかを絵に描いて、流れや動きを把握するべきなんでしょうが、それをすべて頭の中でしかやらないため、たまに全体像を把握しきれなくなる。これが根本的な原因ですね。

幸い頭の中でしか考えないため、自分の頭で考えて理解できたことしか頭の中で組みあがらず、自分の技量以上のことはできません。従って原因は自分の頭で考えたこと以外には無く、発見は比較的簡単に行えました。

ということで、大失態発覚から10分程度で再アップデート完了しましたが、大失態ですね。

ASE Rally Monitor 100 アップデート

本日ASE Rally Monitor100のアップデートを行いました。

具体的にはキャリブレーションモード・GPS設定・トリップクリアの設定の追加という、機能の追加がひとつと、マルチスクリーン対応です。

機能の追加は機能自体の不具合だけをチェックすれば良いので、比較的簡単・・・・いうと語弊がありますが、要は自分の端末で毎日テストをしていればチェックできるので、楽なんです。

それに引き換え、マルチスクリーン対応については、アップデートを行った今が一番不安です。

これまでは、あえて対応させていなかったので、マッチしない端末があることを前提としたリリースだったのですが、今回は一応エミュレーターやいくつかの実機では確認したものの、世に流通しているすべてに対してチェックができないため、マルチレイアウト化したが故にレイアウトがおかしくなる端末が出てくるかもしれないという新たな不安が発生しています。

コレばかりは、いつまでも不安がってアップデートを遅らせてしまうと、せっかくのアイデアが新鮮味を失ってしまうかもしれない。でも、なるべく不具合は減らしたいというジレンマを今回初めて体験しております。

とりあえず、主要な端末はある程度テストできたので、今回アップデートいたしました。

この先の機能追加等については、かなり行き詰っているというか、いくつか追加機能の候補はあり、既にテストをしてみたりしているのですが、これ以上いろんな機能を追加していくと、タダでさえ分かりづらいマニュアルが更に分かりづらくなるような気がしています。

ラリーという競技の特殊性は、単に狭い道をありえない速度で競う特殊性だけではなく、ペナルティーや進行過程の特殊性というのがあります。

基本的にはASE Rally Monitor100は現在のバージョンで、WRCや全日本ラリー選手権には参加できると考えています。もちろんもっとお金を出せばより正確だったり、操作性・多機能なコンピューターは沢山あります。しかし、それらの高性能コンピューターに対して、唯一最大のメリットというのが、

手軽さ

です。Androidタブレットで使用していただいている方も沢山おられますが、やはり開発当初は

スマートフォンで使用できる

ということが最大の特徴であると考えていました。そこの手軽さからラリーに触れてもらうというコンセプトは今でも変わってはおらず、この”手軽さ”というのは、端末や入手の手軽さだけをいうのではなく、

操作の手軽さ

も当てはまると思っています。そのため、これ以上多機能になるということは、操作系がどんどん複雑になる印象をご利用いただく方々に与えてしまうんだろうなぁと。

コンセプトを頑なに貫くことも良いことばかりではなく、柔軟な進行というのが重要だということもあるので、難しい選択ではありますが、まずは現バージョンの対応を中心に進めていくことにしたいと思います。

沢山の方から、いろいろアイデアをいただくことは、悩ましくもありますが、やはりうれしいものですし、感謝いたしたいと思います。

中華Pad M7010レポート2

前回に続きまして、中華Pad「M7010」での報告が届きましたので、お送りします。

まず、前回試していただいていたのは、現在公開されているASE Rally Monitor100のフリーバージョンですが、前回も書いたように、このバージョンはマルチスクリーンに対応させていないため、レイアウトとしては中央に寄ってしまい、せっかくの７inchスクリーンが生きない状態でした。

そして、現在開発を進めている試作版では、このマルチレイアウトに対応させるべくトライ＆エラーを繰り返していますが、その試作版をM7010で動かしてみてもらいました。それがこれです。



かなり良い感じに近づきました。良くを言えば、もう少しだけ外周の余白を減らしたいところですが、これ以上特定の端末に対してしっかり合わせてしまうと、他の端末で表示切れなどが予想されることから、この程度であればクリアにしようと思います。

ちなみに前回のがこれ↓



情けない話ですが、ようやくマルチスクリーンの概念が分かってきたので、急ピッチで進めております。

機能のアップデートも重要ですが、それと同じく、レイアウトがなるべく有効になることも重要ですので、もう少しがんばってみましょう。

中華Padでの動作確認中

先日お知らせした中華Padでの動作確認について、開発協力モニターの方からフリー版の動作状況について報告いただきました。


Android端末　M7010　7inch

上記のとおり、まずアプリ自体の動作はしているようで一安心です。レイアウトについて、かなり中央に寄ってしまっていますが、これは現在公開しているバージョンでは、高解像度・大画面等、推奨サイズ以外の端末にはレイアウト自体が対応していないため、想定していたとおりでした。

マルチスクリーン対応は今度のアップデート版で実施する予定で、現在GalaxyTabでもマッチを確認いたしました。Android3.0の大画面端末でもマッチ予定です。逆に小さい画面のものをどうするか？と、一番厄介なのがauの”IS03"ですね。専用画面は出来ているのですが、同じアプリで対応させることができるか？が実機が無いため何とも微妙なところです。IS03で開発協力いただける方を引き続き募集中ですので、よろしくお願いいたします。

と話はそれましたが、中華Padでも動作は確認できました。但し中華Padは機種によりGPSが無かったり、タッチパネルの方式が当アプリに向いていなかったり、個体差により同じ機種でも不具合があったりと、様々なリスクを背負うことは否めません。また、故障時の保障は？などと、不安な部分もあります。

お奨めすることはいたしませんが、中華Padに興味を持っている方の参考になればと思いますので、今後ともレポートできることがあればお送りしていきたいと思います。

お問い合わせフォーム

今更で恐縮ですが、サイドバーにASE Rally Monitorのお問い合わせフォームへのリンクを作成いたしました。

Blogerのコメント欄が見づらいため、コメントでお問い合わせいただいた方にご回答をしても、確認していただけてないかもしれない？という不安がありましたので、直接フォームからお問い合わせいただけるようにリンクを作りました。

以前IS03に関するお問い合わせなどをいただいた方や、その他いろいろコメントをいただいている方で、まだ返答等が確認できていないという方は、その都度ご返答はしておりますが、もしよろしければ再度お問い合わせいただければと思います。

お手数をおかけいたしますが、よろしくお願いいたします。

内蔵GPSと外部GPSの差

近いうちにASE Rally Monitorのちょっと大きなアップデートを控えており、最終テストを繰り返しております。具体的にはいくつかの機能の追加と細かいところの修正などですが、その中のひとつとして、すでに何度か出てきている

外部GPSの使用

をチェック中です。

いろいろ考えてどうしたらよいものか？と悩んだ末に、

１．内蔵か外部を選択

２．内蔵の場合は、GPS更新レートを自動で１Hzに設定。外部を使用するときは、１～５Hzまで選択できるようにする。

まず、内蔵GPSの場合、基本的にはMAXで１Hzです。プログラム上では、とにかく最小スパンで更新としてあるので、内蔵GPSを選択した場合は、１Hzにしておけば良いのかな？ということで設定してあります。もし１Hz以外になるようだったら、最悪キャリブレーションで調整可能なので、大丈夫かな？と。

で、外部GPSの場合、一応１～５Hzの5段階で設定できるようにしてみました。GPSロガーによっては、”１０Hｚ”というのもありますが、１０Hzでのテスト環境が私に無いため、もし１０Hzにした場合、ディスプレイ表示等にエラーがでるとまずいので、当面は５Hzまでとしておくことにしました。

設定画面からレートを選択できるため、GPSロガーを好きなレートで設定したあとは、アプリの設定を同じにすれば帳尻があうはずです。

では、内蔵GPSを使った場合と、外部GPSを使った場合で、どのくらいの誤差があるのか？

そういう疑問が生じたため、同じ区間を内蔵GPS（１Hz)と、外部GPS（５Hz）で比べてみました。その結果は、

内蔵GPS：17900ｍ

外部GPS：17860ｍ

ちょっとびっくりしましたが、誤差は１％未満でした。同じGPSで2回計ってももう少しずれそうなものですが、たまたまとは言え、GPSのくせに？と思う結果でした。

ただし、内蔵GPSの精度というのは、メーカーや世代により大きく違いがあります。私がテストに使っているDocomo　SH-０３C（SHARP製）は、比較的精度が良いみたいなので、GPSを捕まえる速さなども外部GPSと遜色は無いくらいですが、某メーカーのは明らかにGPS精度が劣るようです。そういう比較的精度が低い端末を使用する際の選択肢として、外部GPSを使えば、精度も向上できるので、良いのではないでしょうか？

ちなみに、現在のところ、外部ＧＰＳをASE Rally Monitorで使用する場合、アプリ自体では外部ＧＰＳにバイパスできないため、

Bluetooth GPS Provider

というアプリをインストールする必要があります。

Sharp IS01エミュレータースタート

Sharp IS０１はちょっと・・・・というかかなり特殊なサイズのAndroid端末です。しかもAndroid1.6ということで、今まで開発していたASE Rally Monitor100だと、そもそもアプリが対象外となってしまい、インストールできません。

ということで、IS01で使えるように、別バージョンとして開発をスタートしますが、いかんせん端末がないため、エミュレーター頼みということになります。

ところが、IS01のエミュレーターがまた微妙に起動が面倒。直接AVDマネージャーからは起動できず、コマンドラインからでないと起動できないということらしいです。ということで、以下のサイトを参考に起動してみました。

https://sh-dev.sharp.co.jp/android/modules/sdk/index.php?/sdk

ちょっと手間取りましたが無事起動して、早速テスト。

IS01の起動画面を始めて見ましたが、画面右サイドに、ハードキー代わりのタッチメニューがあるんですね。これなら押しやすいかも。何せ、同じシャープでもDocomoのSH-０３Cのハードキーは、小さくて押しにくいものですから・・・。

IS０１でうまく動けば、かなり使いやすいかな？と改めて期待してみました。テストバージョンを使っていただいている方からの報告を待ちたいと思います。

中華PADへの対応

ここのところ、沢山の方々からASE Rally Monitorに対して興味をいただいており、大変ありがたく思っております。

これまで、

・Galaxy Tab
・Optimus Pad
・IS03
・IS01

と、一般的なスマートフォン以外での利用希望をいただいており、順次対応をしていますが、最近新たなご連絡をいただきました。それは

中国産の格安Androidタブレット

です。

ご存知のとおり、Androidタブレットは、現在国内メーカーのものは殆ど無く、携帯各社からリリースされているものもほぼ１００％が海外メーカーのものです。

したがって、海外メーカーのタブレットというのは特別なものではなく、むしろ海外メーカーの方が積極的と言えるでしょう。奇しくも今日発売される”iPad2”などは、Androidではありませんが、その典型ですね。

さて、そんな中、ネットではよく目にする”中国産の格安Androidタブレット”、通称

中華PAD

ですが、少なからず興味を持っている方もおられるのではないでしょうか？

上はそれなりの値段から、下は１万を切るものまで、サイズも１０インチオーバーのものから、なぜか正方形のものまで、もうそれは多種多様なものがあります。

この中華PADを利用してASE Rally Monitorを利用できないかな？と私自身も思っておりましたが、実は中華PADの多数は、”GPS"を搭載していません。

ASE Rally Monitorでもっとも重要なのが、この”GPS"ですから、GPSを搭載していない端末は当然ながら利用することができません。また、なぜか”Android5.0搭載”などという謳い文句だったり、絶対これは？？というものも結構目につきます。

従いまして、中華PADの場合、まず機種選定からかなり慎重に行う必要があり、且つスペックだけでは読めない部分もあるため、かなりギャンブル的な選択は避けられないかな？と思います。

しかし、そんな過酷な選択条件である中華PADにてASE Rally Monitorの動作テストをしていただける方が現れましたので、ご協力をいただくことにいたしました。

早速、アプリのインストール段階でストップしてしまったようで、どうなるかわかりませんが、お楽しみに。

AndroidスマートフォンのGPS更新レート

先週、外部GPSロガーを入手して、早速更新レート５Hz(1秒間に5回更新）にてテストをしたら、処理が追いつかないようで、表示が引っかかるようになってしまいました。

そこで、少しレートを落として3Hzにて再チャレンジ。

結果は、５Hzよりはマシになったものの、まだ引っかかりはなくなりません。

ちなみに、Androidスマートフォンの更新レートは最短で”1Hｚ”です。

どうやら、この1Hzというのを最短レートにしている意味が分かってきたような気がしないでもないですね。通常、スマートフォンを使ったGPS関連アプリで、もっとも考えられる一般的なものといえば

Googleマップ

だと思います。GPSをオンにした状態でGoogleマップを起動すれば、常に現在地が表示され、カーナビのように表示します。さらに、

Googleマップナビ

を使うことで、まったく普通のカーナビとして道案内してくれます。もはやポータブルナビの時代は終わったと思うことでしょう。

で、これらのアプリでGPSを使う場合、正直1Hzもあれば使用に問題はない感じです。前にも述べましたが、時速60ｋｍ/hの際の秒速は約16.5mです。つまり、直前の案内から16.5m前後に交差点がある可能性があるということになります。これって、よほど街中で込み入っていない限りは走行上の問題にはならないでしょう。

ましては、他のGPS関連アプリも一般的にはこれ以上の更新レートは不要でしょうし、今回のテストのように、更新レートをあげれば、次の処理までの余裕がなくなるため、いろいろ弊害が出ることも想定されます。

ということで、余裕を持ってAndroidスマートフォンのGPS更新レートは1Hzなんだろう、と都合の良い解釈をしてみました。

スマートフォンは携帯電話ではなく、小型PCに通話機能がプラスされている端末だという認識でいますが、物には限界があるということで、過度な期待をすることなく、適材適所の役割を求めていく必要がありますし、そうした認識を持ってアプリを開発することが必要なのかもしれませんね。

Androidスマートフォンに外部GPSを接続

昨日到着した外部GPSロガー「Trip Recorder747pro」を早速設定してみます。

更新レートは1Hz~5Hzまで5段階で設定可能で、付属のソフトをインストールすると簡単に設定できます。更新レートは”Fix Update-Rate"にて選択します。




とりあえず、せっかく5Hzまで設定できるので、5Hzにて設定します。

ちなみに、現在のGPSの各種データは同じソフトにて確認することができます。



室内でもしっかり衛星を捕捉している様子が分かります。Speedが0ｋｍ/ｈでないのは、室内により精度が落ちているため、仕方が無いでしょう。

GPSロガーの設定はこれだけでとりあえず終了。

ただし、ASE Rally Monitor側でプログラムの修正が必要になってきます。というのは、今までの端末内蔵GPSを利用する際には、AndroidスマートフォンのGPS更新レートがMaxで1Hz、つまり1秒に1回でした。で、取得できる速度データというのが、”秒速”。つまり、更新レートが1秒に1回ならば、そのときの秒速をそのまま距離に加えてあげればよかったのです。

で、今回は1秒間に5回のデータ取得になります。つまり0.2秒ごとに取得するわけですが、その際に取得する速度も先ほどと同じように”秒速”になりますので、単純に加算してしまうと、1秒間に5秒速分の距離が加算されてしまいます。

ということで、取得した秒速の1/5を加算すれば良いのですが、実際には浮動小数点から整数へのキャストの際に、ちょっとした問題も発生します。まあ、この辺はそのうち機会があればということで。

早速プログラムを修正していよいよテストをスタート。

まずは、GPSロガーとスマートフォンをBluetooth接続します。一度設定してしまえば、あっけないくらい簡単に接続完了します。

いよいよASE Rally Monitorを起動。この際、スマートフォンのGPSをONにする必要はありません。
既にGPSロガーが接続されていれば、すぐにASE Rally Monitorもスタンバイ完了します。

実際に走行してみると、今までのこま切れ状態から、やたら目まぐるしく距離が動き始めました。

ただ、あまりに一生懸命更新するためか、スマートフォン側の処理が追いつかないような感じで、ある程度追いつかなくなってくると、表示がひっかっかるようになりました。一定間隔でひっかっかるので、処理速度の問題だと思われます。

ということで、今度は３Hzに落としてみてテストをしてみようと思います。

外部GPSテストに向けて

既に何度か報告しているとおり、Androidスマートフォンに内蔵されているGPSは、最短で更新スパンが1秒/1回が仕様となっています。中には違う端末があるかもしれませんので、その場合はご勘弁を。

で、この状態では、トリップメーター及びスピードメーターの更新も1秒毎となるため、

パッ　　パッ　　パッ

という感じで表示され、結構違和感を感じます。慣れてしまえば”こんなもんだ”と思えるのですが、それだけではつまらないので、テストを兼ねて外部GPSを利用してみることにしました。

外部GPSとスマートフォンはBluetoothで接続しますので、まず条件としては

・Bluetooth装備

のGPSロガーである必要があります。GPSロガーは各種ありますが、同じ格好をしていてもバージョンによってBluetoothが装備されていないものもあるので、注意が必要です。

そして、次の条件としては

・更新レートが２Hｚ以上

つまり、2秒に一回以上位置情報を更新するGPSロガーである必要があります。というか、それ以下だとわざわざ外部GPSを使うメリットがあまりないですからね。

中には１０Hz以上というものもありますが、後でも記載しますけど、あまり意味がないです。というのも、仮に時速６０ｋｍで走行しているときの秒速は16.7ｍ程度。1/10秒速は1.67ｍ。1/5秒速は3.34ｍ。ちなみにGPSの位置精度が１ｍ前後。つまり大雑把に言えば、1/10秒測でも誤差によっては2.67ｍになり、1/5秒速でも誤差によっては2.34ｍになるということです。この誤差が時速60ｋｍで走行しているときに許されるか否か？が問題ですが、ASE Rally Monitorのターゲットでは全く問題無しと考えています。

もちろん更新レートが高いほどより正確になる”可能性がある”のですが、処理速度が落ちたり、ｍ単位が切り替わりすぎて読みにくくなったりと、デメリットもあると考えます。また、GPSロガー自体も5Hzと10Hzで倍の仕事をするために、バッテリーの持ちにも影響が出るはずです。

ということで、長くなりましたが、更新レートは2Hz以上で5Hzまでのもので十分かな？と考えます。実際に現在の流通では

・1Hzまで
・5Hzまで
・10Hzまで（かそれ以上）

の3区分ぐらいに分かれますので、今回は5Hzまで対応するものを選択します。

最後に、実売価格ですが、高いものは数十万円以上までありますが、それではスマートフォンでやる意味がなくなります。実際には1万円というのが一つのボーダーラインではないでしょうか？

最終的に私が今回選んだものはこれです。

Transystem社　
Trip Recorder 747pro





Amazonで、急がなくてもよければ、送料無料・代引き手数料込みで1万円をギリギリですがきってます。その他にも同じメーカーのこんなのもあります。

PhotoMate 887


こちらの方が1000円くらい安いです。

なぜ、PhotoMate887にしなかったか？というのは、

・標準で付いてくるソフトで1～5Hzの5段階を簡単に切り替えられる
・アンテナ精度が良い（らしい）
・自動でON/OFF
・稼動時間が倍以上

など、1000円の差以上の価値があると思ったためです。なお、画像でみると同じ大きさのようですが、実際には倍以上違います。PhotoMateは小さめな消しゴムくらいですが、747proは、ちょっと小さなマウスくらいあります。

ということで、GPSロガーを入手し、テストをスタートしました。その様子は次回以降にお送りします。

キャリブレーションモード追加中

ラリーは主催者から提供される”ロードブック”という地図により走行いたします。

このロードブックには、次の交差点までの距離が記載されていますが、これは主催者があらかじめ任意の車両にて計測した距離です。車の距離というのは、ある程度の統一化がされてはいますが、標準状態からタイヤ外形を変えたりすると、距離というのは異なってきます。

よって、ロードブックに記載された距離と自分の車（ラリーコンピューター表示）の距離というものには、必ず誤差が生じてしまいます。

この誤差を補正するために、ラリーコンピューターには距離補正モードがあります。

ASE Rally Monitorにも当初から距離補正を設定できる項目がありましたが、暫定仕様ということで、今までは補正係数を手計算であらかじめ出しておき、この数値を登録するという、かなり面倒な仕様でご迷惑をおかけいたしております。

やはり、なるべく簡単に操作するために、このたび

キャリブレーションモード

を実装してみました。

これは、ロードブックなどで特定区間を走行し、その区間のロードブック記載距離を入力するだけで、補正係数を自動計算し、登録してくれるモードです。

従来のラリーコンピューターでは特別珍しいモードでもないのですが、ASE Rally Monitorでどのように実装するかを試行錯誤していました。

とりあえず、計測開始・終了処理で登録できるので、大分簡単になったかと思います。近々他のアップデートと共に公開予定です。

GPS更新レートを上げたい

レイアウトの対応も少しずつではありますが、進めております。リクエストがございましたら、まずはご相談ください。

さて、これからテストを予定しているのが、

外部GPSによるログ精度の向上

です。

スマートフォンに搭載されているGPSは、現状ではどの端末も

更新レート：1Hz

かと思います（もっと良いものがあったらゴメンなさい）。

1Hzというのは、1秒間に1回位置情報を取得するというものです。Androidアプリの中でも、一般的な位置情報を使うものに関しては、1秒間に1回取得すれば十分なのかもしれません。TC方式のラリーについても、正直1Hzで必要十分かな？と思っています。言い方が悪いですが、所詮GPSです。精度的にもこれ以上頻繁に更新をしたところで、特別なメリットがあるかというと、微妙な感じはします。

私が以前テストしていた海外のとあるラリーコンピューターについては、車速センサーから取得しているにもかかわらず、ディスプレイが液晶だったため、液晶表示が追いつかないためリアルタイムに表示されていませんでした。確か1秒近くスパンがあったような気がします。それでも某WRCワークスなどでも一時期使っていましたからね。

さて、そうは言っても、スムーズに動いた方が少なからずメリットはあります。

そこで、外部GPSロガーを使って、内蔵GPSの代わりにしようという試みをすることにします。

結果などは後日報告できるかと思いますので、今しばらくお待ちください。

昼用配色をテスト

レイアウトについては、確定しているのですが、実際のシチュエーションとしては昼間の車内というのがかなり割合としては大きいと思われます。その場合、スマートフォンならではなのかもしれませんが、ガラス面に入射光が映りこんでしまい、時として視認性が大きく落ちるということがあります。

そこで、カーナビを参考に、昼用の配色を現在テスト中です。

最初は背景すべてを”白”にしたのですが、そうすると真ん中の”緑”がよく見えなくなってしまいます。今回のアプリはこの色に重要な意味があるため、昼用だからといって色を変えることは望ましくありません。

そこで、この部分のみグレーにしてみました。

また、右上の箇所も時間によって色が変わり、これも意味があるため、このような感じになっています。

とりあえず、この状態である程度テストはしてみますが、そもそもハード的に入射光に弱いというのはいかんともし難いので、最終的には日よけ等を作る必要があります。ただ、自動車のメーターやカーナビなどでも、結局は日よけがあるから昼間でも見えるということには違いないため、スマートフォンだけの問題でもなく、あまり極端に考えこむ必要はないかな？と。

ちなみに、昼用⇔夜用は、設定で常時変更できるので、昼でも夜用で使うことは可能です。