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

前回、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)に対する早遅を”距離”のみで表示しています。これは、一般のモニターの方（ラリーに関わらない方）が早遅を把握するのは、距離でどのくらい先にいるかの方が分かりやすいという声を反映させてみたものです。

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

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

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

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

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