2011年6月28日火曜日

多角的視点は重要です。

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

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

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

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

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

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

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


GPS時刻更新追加のその後

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

とりあえず様子見ということで、1分間隔で更新するようにしてみましたが、この場合だと、更新のタイミングで時計表示が1秒程度抜けてしまうことがあるようです。
Androidのバージョンや端末によりマチマチだとは思いますが、現状で私のAndroid2.2 SH-03Cではたまに抜けてしまうことがあります。

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

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

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

2011年6月26日日曜日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2011年6月24日金曜日

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

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

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

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

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

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

”アプリを作りたい!”

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

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

”プロの存在”

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

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

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

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

・考えるより動く

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

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

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

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

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

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

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

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

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

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

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

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

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


2011年6月21日火曜日

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

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

ASE LapTimer

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

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

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

・GPSを使った目的地までの距離測定
・Timerを使ったストップウォッチ
・ImageViewを使った画像表示及び切り替え

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

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

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

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

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

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

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

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

当初はこれで満足的な感じだったのですが、やっぱりいつものごとく、いろいろ欲が出てきております。
既に最初の段階とはレイアウトから違ってますから・・・・(^^;

2011年6月20日月曜日

接近アラートの練習

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

Androidでは、

"distanceBetween"
"distanceTo”

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

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

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

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

一定時間ごとに、

距離取得
アラート発生の判定

の繰り返しです。

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

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

2011年6月17日金曜日

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

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

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

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

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

仮定速度で走行していることにするわけですから、実際の走行はその仮定速度からずれないように走る必要があります。極端な加減速をすると、出口で実距離と帳尻が合わなくなります。
ただ、車を運転する方ならわかるかと思いますが、余程都心部などで無い限り、トンネル内で停車したり加減速することはなく、殆どの方は、トンネル内は一定速度で走るのではないでしょうか?人間の心理として、トンネルのような狭く見づらい空間ではなるべく危険な行動はとらないようにするようです。

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

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

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

2011年6月16日木曜日

GPSによるトンネル内走行

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

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

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

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

GPSだから仕方が無い

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

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

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

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

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

2011年6月14日火曜日

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

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

まず、利点から。

・起動が圧倒的に早い

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

・電源の持ちが長い

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

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

・入力がしづらい

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

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

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

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

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

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

2011年6月13日月曜日

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

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

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

「トンネル内での欠測」

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

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

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

という感想を

スマートフォンなのにこんなにできるの!?

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

先週末の問題について

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

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

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

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

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

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

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

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

・・・・

425台!

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

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

2011年6月10日金曜日

ASE Rally Monitor300(仮)開発スタート

Android3.0実機を入手して従来のASE Rally Monitor100をテストしてみたところ
動作的には問題は無いのですが、スクリーンサイズが大きくなったことで、数字や入力が快適に操作できる反面、ちょっとテキストサイズが大きすぎるような気がしてきました。

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

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

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

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

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

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


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

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

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

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

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

2011年6月8日水曜日

Android3.0ポチッた

Android3.0が国内で流通しだして3ヶ月くらい経ちますが、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番号を選択すれば勝手に表示しますので、アプリ起動と選択の2STEPで行けるはずです。

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


2011年6月6日月曜日

次なる課題

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

”データベース”

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

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

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

基本的には

ステージフィニッシュ処理
SQLiteで保存
設定画面かメニューに呼び出し&クリアを配置

そんな流れかなぁ?と。

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


2011年6月3日金曜日

スイスからの問い合わせ

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

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

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

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

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

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

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

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

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

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

2011年6月2日木曜日

簡易AVEモード試作中

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

「アベレージモード」

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

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

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

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

・GPSの距離計測は1秒単位での早遅表示は無理・・・というか無意味
・表示部分に限界がある。

GPSの件については、どうしても常時計測することが難しいGPSで、1秒単位の精度を求めることは当初から無理だと認識しています。そのため、着手にいたらなかったわけですが。
したがって、あくまでも”参考”程度の表示を前提とする必要があります。

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

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

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

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

「○○:XX:**」

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

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

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

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

つまり、

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

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

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

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

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

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

2011年6月1日水曜日

テンキー画面試作中

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

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

それがこれ。

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

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

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

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