あっけない距離表示

時計がひと段落付いたということで、次はラリーコンピューターのもう一つの重要機能である

トリップメーター

に着手いたします。

トリップメーター、つまり走行距離の表示ですが、App Inventorでは、位置情報を取得するための

LocationSensor

というものにかなりの動作制限があったため、トリップメーターのように1秒以内で常時位置情報を更新するというアプリを作ることはできませんでした。

今回のアプリについて、最大の懸念事項はそこだったのですが、すでにAndroidマーケット上にはスピードメーターアプリとか、GPSロガーアプリなどがたくさん出回っているため、自分が求める機能は実現できるという確証はありました。問題は、それを自分が構築できるか？ということです。

で、App Inventorのときと同様に、まずは現在地の経緯度を取得するためにはどうしたら良いか？をいろいろ調べていきます。

程なくしてなんとなく理解できてきました。

取得できる情報は

• 経緯度
• 高度
• 住所
• 速度・・・・・

？？？！！

速度！？？

そうなんです。取得できる位置情報の中に、”速度”があったのです。

てっきり2点間位置情報から距離を求めようと思っていたのですが、最初から速度を出してくれるのであれば、処理的にはかなり軽くなりそうです。

なにしろ、App Inventorの際は、経緯度計算がかなり負担になり、結果的には様々なエラー要因となってしまっていたのが、経緯度計算をしなくて済むのであれば、＋－×÷のみで済みますからね。

実際には小学生レベルの計算になりますが、時速が出るのであれば、GPS更新間隔をAndroidの最小間隔である”1秒”とすると、

時速/3600*1000

で秒速　ｍ/ｓが計算できます。これだけです。
あとは、これをひたすら積算していけばトリップメーターの基本は完成となります。

これが、もし経緯度計算ですと、経緯度を取得してから、こんな感じのことを1秒毎にやってあげる必要があります。


　　　　
　

時速を取得してくれるので、距離算出は予想よりはるかに簡単な処理で済みました。そして、App Inventor時の問題であった、時刻と距離が正常に表示されるか？ということですが、結論からいうと

問題無し

今のところ10以上の機種で利用いただいているようですが、不具合についての連絡がないということは、利用に支障をきたす問題は無しということだと理解しています。

ということで、

• 任意の基準時刻へ補正できる時計表示
• 1秒毎に更新されるトリップメーター

ができました。基本的にはこれだけでもラリーへ参加することは可能です。厳密にいうと、WRCのようなTC方式ラリー（分からないかたはごめんなさい、ルールが単純なラリーと思ってください）への参加が可能ということになります。

ここから先は、ラリーの現場で使うために必要だったり、あったら便利だなという機能の充実を図ることになります。

まずは時計表示から

App Inventorでの開発時、時計の表示は大まかにこんな感じで行っていました。

＜1秒毎に実行されるタイマースタート
↓
現在時刻取得
↓
時・分・秒分割表示
↓
タイマー終了＞

時計だけの場合は、これで概ね問題はなかったのですが、これと平行して距離の計算を行うようにしてからは、まともに1秒毎に時計表示が更新されない、というか1秒以内に更新が間に合わなくなってしまい、２～３秒おきの表示になってしまいました。これはかなり問題でしたね。

ということで、今回はJAVA＆Eclipseでまずは時計を作ってみます。

Androidには、もともと

・アナログ時計
・デジタル時計

というものが備わっています。簡単にいうと、【画面のここに”デジタル時計”を表示】と配置してあげると、勝手に端末の時計を表示してくれるというものです。

ただ、これだけでは一回表示した後に更新されません。従ってやはりApp Inventorのときと同じように、1秒毎に現在時刻を取得して表示してあげることで、時分秒が表示されるデジタル時計として使用することができます。

ここで、一つ重要な事項が後々発見しました。時系列はズレますが、時計の利用時、特にラリーのように秒単位で必要な時計を作る際には重要な問題ですので、ここで挙げておきます。

それは、

Androidは時計の秒合わせができない

いろいろ技を駆使すればできないこともないのですが、一般的ではなく、たとえば普通の時計やパソコンの時計みたいに、ワンタッチで時報と秒を合わせるということはできません。今の機種はどうだかわかりませんが、少なくとも私が持っているSH-03Cではできません。

これに気が付く、というか今までの携帯が勝手に秒まで合わせてくれていたため、てっきり秒まで合っているものだと思い込んでいてしまい、つい最近まで考えもしない問題でした。

端末で秒を合わせられないのであれば、端末から時刻を取得しても意味がなく、一瞬、

このアプリ終わった・・・・

と途方に暮れました。しかし、そうも言ってられないということで、対策をいろいろ考えます。まず

・分単位での修正は端末で可能

これにより、分より上の修正は端末で適当にやってもらうことにします。ということで、アプリ側では秒のみ
の修正を考えることにしました。

秒の修正をどうするか？

アプリのプログラミングでも対策はできるのですが、これは裏技的な話になってしまい、アプリ利用者が知らないうちに裏技をさせられている、ということになってしまいます。これはまずいですので、却下。

そこで、考えた結果の対策が

もう一個時計作っちゃいなよ

というもの。つまり、システム時計とは別にアプリ専用の時計を併走させてしまおうというものです。このアプリ専用の時計は、アプリのプログラム上でしか動いていないため、もし時計をいじっても端末そのものには何の作用もしません。

ASE Rally Monitorには設定画面があり、いくつかの設定項目についてはメモリーしておくことができます。その一つとして、基準時計との誤差を設定しておくことで、アプリ内の時計を常時補正するようにしました。

システム時計を使わずに、アプリに独自の時計を併走させることで、秒の補正ができるようになりました。ラリー競技においては、大会公式時計が必ずしも国の基準時間とぴったり合っているとは限りません。

国内だけであれば良いのですが、アプリはすでに世界各国でご利用いただいております。中には基準時計そのものがあいまいな地域があるかもしれません。そんなときに、この方式であれば、常に最初の段階で大会公式時計と合わせることができます。

いちいちスタート前に合わせる必要がありますが、下手に端末を信用するよりは、確実かな？と思いますので、我慢していただければ良いなと思います。

ということで、時計については、完成しました。あとは、距離計測をしても問題なければ良いのですが・・・。

西洋的アプローチと日本的アプローチ

プログラムを勉強するにあたり、取り組むスタンスというのは各自様々かと思います。

一般的な日本人は、おそらく

・学校で習う
・テキストなどで独学

というパターンが多いのかな？と思います。それらに共通することは、

１から順番にステップアップ

ということではないでしょうか？

何事にも基礎があっての応用ですから、至極当然といえば当然です。問題なのは、

日本人は過程の美学がある

ということです。問題といってもマイナスの意味ばかりではないのですが、少なくとも自分自身にとっては、これがマイナスに働くことが多いと感じることが多々あります。

今はどうか分かりませんが、私が学生時代の話。

中学校までの数学のテストというのは

２　＋　４　＝　？？

と出た場合、？？の答えだけを求めればよかったのです。この場合、ある人は、

２に１を４回足して６にする

かもしれませんし、別の人は、

２＋（２ｘ２）＝６

というように６を導くかもしれません。どういう風に求めても”６”を導けば正解なわけです。しかし、高校入学の最初の数学テストのときに、例として適切か分かりませんが、

2と５の最小公倍数は？？

という問題が出たとして、私は直感で

10

と記入しました。見れば分かるので、過程もへったくれも無いと思ったわけです。しかし、返ってきた解答用紙をみると、

０点

でした。なんで、１０になったかの経過が書いてないかららしいです。しかもその経過が合っていないとだめだとか。

実際はこんな問題ではなく、もっと公式をいくつか使うような問題でしたが、ニュアンスとしてはこんな感じです。公式を使わなくても、なんとなく数字をいじっていると答えが出ることってあると思います。実際にありました。そのアプローチというのは様々であって、お決まりの公式でしか回答できない人が評価されて、誰も思いつかないアルゴリズムを開発しても評価されない、日本の教育課程に幼いながらもあきれ果てた思い出が高校時代にはたくさんありました。

かなり私情に走ってしまいましたが、要は

答えを導く方法は１つではない

ということです。これは、今でも自分の柱の一つかもしれませんが、遠回りしようが、最短距離だろうが、答えを自分で出すということに価値があります。日本の教育は、

”聞くことは恥ずかしくないからバシバシ聞きなさい”

と教えてきました。そのため、ろくに自分で物事を考えたり判断することができずに、安易に人に頼ってしまう人をたくさん作ってきてしまったのでしょう。

あっ、また私情が・・・・。

ということで、私の場合、１から順を追って学んだり取り組むことにかなりの抵抗感があるため、アプリ開発をスタートすると決めても、いきなり

”GPSの使い方は・・？”

とかが知りたくて、そこから少しずつ戻りながら、必要な情報だけを手に入れていくという流れになってしまいます。

そんなわけで、正攻法によるアプリ開発をスタートすることになりました。まずは、開発環境を整えるということで、”Eclipse"なるソフトをインストールしました。いちいち理論を勉強する時間もないので、”Eclipse"をインストールするもんなんだ、と言い聞かせて、さっさと設定したため、詳細については理解できていません。Androidアプリを開発するために必要な操作の最低限しか理解していませんが、まあ良いでしょう。

なんだか、精神論ばかりのようになってしまい、

”アプリ　開発”

なんかのキーワードでお越しいただいた方には大変申し訳なく思っておりますが、ご勘弁ください。所詮素人なもので、お教えできるほどの技量はございません。

いい加減、アプリについて少しは話を進めないといけないかな？と思いますので、次からはアプリの内容についての試行錯誤を進めたいと思います。

アプリ開発再スタート

”App Inventorでラリコンアプリを作って見る”

当初の目的を実現していく中で、どうやらラリコンアプリを作ることは、App Inventorには荷が重過ぎるということが分かってきました。

前回も書きましたが、”App Inventorを使ってみる”という目的からすると、この段階で決着しても良かったのだと思うのですが、

”Androidで動く、実戦で使えるラリーアプリ”

というものに対して、ラリー界でも少なからず期待と興味を持っている方々がいるということを実感してしまったため、時間がかかるかもしれないけど、自分の勉強もかねて、正攻法でのアプリ開発をスタートすることにしました。

まず、ネットでアプリ開発について書かれたサイトを探すと、App Inventorのときとは違い、かなりたくさんのサイトを見つけることが容易にできました。

しかし、どこを見ても共通することは、

”JAVAを理解していることが前提”

となていることです。

？？？

JAVAって何だ？

普通にパソコンを利用している方は、たまに画面右下あたりから

”JAVAをアップデートしますか？”

的なメッセージを差し出されることがあるかと思います。従って、”JAVA"という文字そのものは見たことがあるという方も少なくないかと思います。私も”JAVA"という文字は知っていました。でも、それが”プログラム”であることは認識していませんでした。

調べていくうちに、”JAVA"はプログラム言語であるようなことが分かってきました。

この段階で、私のスキルとしては

”エクセルでマクロがちょっと組める”

くらいで、そのベースが小学生時代に触った

”BASIC”

です。ファミリーコンピューターが出たころ、キーボードをつけてファミコンベーシックとものがあり、それで円を書いたりすることができるという程度ですね。

その程度の人間がアプリの開発することにしたのでした。

ちなみに、私はゲームを始め、様々なものについてくる”取扱説明書”というものは基本的に読まない人間です。決して自惚れているとかではなく、

”早く遊びたい！触りたい！”

という欲望の方が強くなってしまうため、とにかくスタートしてしまったり、分解してしまったりします。そして後で後悔することも多々あります。石橋を叩く棒を探すのが面倒な人間です。

そんな人間ですから、”JAVAを知っていることが前提”というのを受け入れることができずに、本屋に行って、”Androidアプリ開発入門”みたいな本を開いてみちゃうのです。しかしそこには、みたことも無いような記述のオンパレード。

私が知っているプログラムは、

変数を宣言
↓
処理
↓
表示

みたいな単純なものだったので、この段階でJAVA的内容はまったくもって理解すらできずに、かなり

”やめようかなぁ・・・”

が莫大に増えてきました。今でも理解はできてるとは到底いえませんけどね。

しかし、とにかく”アプリを作る”という使命感というか、強迫観念により、何かしらかた手をつけてみようという決心をしました。

あせらず一歩一歩

最も苦手な言葉です。

次から次へと訪れる壁に限界を感じる

App InventorのLocationSensorを常時生かしておくためには、MyTracksなどの別アプリをバックグラウンドで動かしておき、そちらから位置情報を横取りする必要があるというのは前回お知らせしたとおりです。

位置情報取得間隔が１分以上あれば、こんなことをする必要も無いのですが、ラリーコンピューターに必須の距離算出には１秒程度の間隔が必要になります。

ということでの横取り作戦だったわけですが、横取りというくらいなので、常に正しく取得できるわけではありません。何かのタイミングによっては、”Null"となってしまう瞬間があり、そのタイミングでラリコンアプリから横取りをすると、その後の２点間距離計算時に、数値ではないということでエラーとなり、強制終了してしまうということが頻発しました。

正直AppInventorの限界を感じつつも、

「自分が工夫・勉強していないだけで、解決方法があるのではないか？」

という捨てきれない思いがあったので、まずは”Null"だったときに計算等をスキップしては？という分岐を作ってみます。

しばらくの間はこれで回避できていたのですが、やはりタイミングが合うとアウト！・・・・

ということで、根本的な解決案ではありませんでした。

その後もいろいろ試してみましたが、自分の技量ではどうしても解決にはいたりませんでした。しかも、早い段階で完成したと思われた時計表示についても、距離計算を実装したあたりから、正しく１秒毎に表示できなくなり、２秒おきとか３秒おきなど、とてもラリーに使える代物ではなくなってきてしまいました。

「ここらがApp Inventorの限界か！？」

ひょっとしたら、もっと根本的なところが間違っていたのかもしれません。また、今のApp Inventorは今後、このあたりは進化するのかもしれません。でも昨年末の段階では、私の中では

”App Inventorで作るラリコンアプリ”

は、このあたりが限界かな？と着地することにしました。

当初の目的が”App Inventor”を勉強する、使ってみるということだったので、個人的にはこれでラリコンアプリプロジェクトは終わっても良かったのですが、この頃すでに他のラリー関係者からご連絡をいただき、”駄作です”という前提でこの状態のアプリをお送りしていたのです。

おそらくかなり期待をしていただいていたのかと思いますが、作った本人が”駄作”というくらいなので、今思うと、かなり申し訳無かったものだったはずです。

その”申し訳ない”という気持ちと、何より

”こんなもんか・・・・”

と思われているであろうことが自分としてはめちゃくちゃ悔しかったので、ならばということで、禁断の

JAVA

へ手をつけてみる決心をしたのでした。

ASE Rally Monitorの本当のスタートは、ここからです。やっぱり人間

”悔しい”

という思いから始まるのかな？と今回も実感しました。

ラリーでも”あいつより遅い”といわれることが悔しいと思える人は、きっと速くなれます。でも、”あいつはあれを使ってるから仕方ない”とか”あの車はあ～だから・・・”と自分で勝手に線を引いてしまう人は成長が止まってしまうでしょう。それと一緒ですね。

ということで、いよいよJAVAによる正攻法のアプリ開発がスタートです。

※App Inventorのことでお困りの方は、以下のサイトでいろいろ探すと答えが見つかるかもしれません。私も大分助けられました。ただし全部英語です・・・。

App Inventor Coffee Shop

LocationSensorの弱点 Part2

Googleマップや他のGPS系アプリ、たとえばスピードメーターアプリなどでは、しっかり１秒毎にデータが更新されているのに、App Inventorで私が作ったものは、何回試してみてもなかなか位置情報が更新されません。

忘れた頃に、ピロッと更新されるので、まったく検討違いなことをやっているのではなさそうですが、そんなに難しい仕組みでもないはずなため、まったくもって原因不明でした。

ちなみに（ちなんでばかりですが・・）、App Inventorは、世の中に登場してまだ１年未満のツールで、しかもAndroidがまだ普及していない国内にいたっては、App Inventorを使っている方というのも昨年末の段階では殆ど稀だったような気がします。試しに使ったという情報は見つかりますが、詳しく解説しているのは２～３箇所くらいだったかな？と。

そんな状態のため、LocationSensorのことについて解説している国内のサイトも無く、情報やフォーラムはすべて海外サイトを参照するしかありません。

つたない語学力を駆使して、いろいろ調べていくうちに、ようやく答えが見つかりました。

それは、

「App Inventorに備わるLocationSensorは、位置情報取得後、次の取得まで60秒お休みする」

というものです。

まさに想定外の理由でした。これで今までの事象がすべて納得できました。そりゃぁ、元からそういう仕様だったら、いくら駆使してもできないはずだよなぁ・・・と。

さて、原因は分かったものの、引き続き海外サイトで対策などを調べていくうちに、ある対策を見つけました。それは、

「他の１秒毎に位置情報を取得するアプリを起動しておくと、App InventorのLocationSensorが休まず働く」

というものです。ホントか？と半信半疑でしたが、とりあえず適当なアプリは無いかな？ということで、とりあえずGoogleのオープンソースGPSロガーである

MyTracks

をインストールして起動。ログ取得をスタートします。

当然ですが、MyTracksはしっかりとログを取得し、軌跡をGoogleマップ上にトレースしていきます。

この状態のまま、MyTracksはバックグラウンドで動かしておき、いよいよ我がラリコンアプリもどきを起動。すると・・・・

なんと、しっかりと位置情報を数秒単位で更新するではないですか。今までの悩みがあったため、かなりこのときは感激した記憶があります。

しかし、間もなくまた壁にぶつかります。それは、

”位置情報が取得できずにアプリが強制終了”

次から次へと参ったものです。

どうするか？それはまた次回。

App InventorのLocationSensorの弱点

App Inventorで位置情報を取得できることは分かりました。

ちなみに、App Inventorで取得できる情報は

・緯度
・経度
・高度
・住所

などです。

以前にも書いたような気がしますが、ラリーコンピューターの機能は大別すると

距離と時計

になります。位置情報のうち、緯度と経度（厳密に言うと高度も必要なのですが）が分かるということは、移動している際に、一定間隔（１秒毎）に経緯度を取得することで２点間の長さ、つまり距離を計算することが可能になります。計算式などはいろいろあり、どこまで精度を求めるかによって大きく変わってきますので、この際割愛させていただきますが、とにかく経緯度を一定間隔で取得すれば距離が分かるということになります。

別に１秒毎でなくても良いのですが、２点間の距離を計算する際は直線距離になります。従ってあまり間隔が長くなると、道路形状と著しく異なる直線距離として計算してしまうため、１秒毎くらいが精度的には限界かな？と思っています。

ちなみに、時速３６ｋｍでは秒速１０ｍになり、時速６０ｋｍでは秒速16.6・・・ｍになります。

さて、計算式をブロックで作り上げて、１秒毎に処理を実行するタイマー（Clock）を使い、

１秒毎に経緯度取得
↓
２点間の距離計算
↓
トリップに距離積算

という流れを組み上げます。そして、いざ実行してみると、

「１回目の経緯度は取得するけど、なかなか経緯度が変化しない」

？？

しばらくすると、経緯度が変化して一応２点間の距離は表示されました。

いきなり表示された距離は”３００ｍ”を越えるもの。

ちなみに、Googleマップなどで現在地を表示する際は、カーナビのごとく１秒毎に移動していました。それに対して、いきなりの距離が３００ｍとは、いったいどういうことなのか？タイマーは１秒毎にしているし、この時点ではまったくもって謎ばかりでした。

実は、これがApp Inventorに備わるLocationSensorの最大の弱点といっても過言ではないでしょう。

弱点の話は次回。

App Inventorで位置情報を取得

時計の表示はとりあえず、”Timer"と”Clock"ブロックを使うとイメージどおりの時計を表示することができました。この段階では・・・・。

ちなみに、今更ながらですが、App Inventorのコーディング画面はこんな感じです。



この画面でいうと、左上の緑のブロックが処理の単位になります。

”LocationSensor1.LocationChanged”

という名前のブロックです。

App Inventorは位置情報を取得するために、”LocationSensor"というものが用意されています。これをアプリ内にセットすることで、位置情報を取得することができます。

で、ブロックの意味ですが”LocationSensor1”という名前のLocationSensorが”LoationChange"したとき、つまり位置情報が変化したときに、ブロック内の処理を実行するということになります。

ブロック内の処理の内容についてまで説明すると、まさにApp Inventor講習になってしまうので、簡単にいうと、

「LocationSensor1のLocationがChangeしたときに、住所・経緯度を表示して、ボタンを有効にせよ」

という内容が組まれています。

こうして、処理単位でブロックを組んでいき、それらをまとめて一つのアプリを作っていくというのが、App Inventorでのアプリ開発になります。

App Inventorでの位置情報の取得は、こんな感じで一応は可能です。

”今どこだか分からなくなったから、確認したい”

みたいなアプリでしたら、この内容で十分アプリを作ることはできるかと思います。

問題は、ラリコンアプリの場合ですが、長くなりましたのでまた次回ということで。

App Inventorでラリコンアプリはできるか？

ということで、App Inventorでラリーコンピューターアプリケーションを作り始めました。

最初に作ったのがこれです。



すでにいろいろ配置されていますが、この段階で自分ができたことは

• 時計の表示
• LIST選択
• GPSの取得

のみです。従って距離の表示などはまだできません。

時計については、AppInventorの場合、システム内蔵時計の時刻を取得することができますが、ラリーで使う場合、以下の内容を重視します。

●数字は時分秒で、それぞれ00時１１分22秒というように、２桁ずつ表示する必要がある。

これは、時計を表示する場合、時分秒をそれぞれ分けて取得することができますが、これだと、１桁のときは１桁で表示され、０時１分１１秒というようになります。内容としては特に問題ないのですが、この場合、桁が変わると、表示部の長さが変わってしまいます。

ラリーの場合、車内の振動というのはかなり激しく、内容もさることながら見易さや間違いにくさというものが重要になってきます。そのため、桁は常に２桁であった方が見やすさは格段に上がります。

ということで、表示をする場合、それぞれ条件分岐をしてあげて、１桁の場合は頭に０をつけて表示するようにします。

これで時計については、常に２桁で表示することができました。

また、時計は常に進みます。そのため、タイマーを使って時計を変化させます。

１秒ごとに今の時刻を取得
↓
表示桁を揃える
↓
表示
↓
・・・・・

簡単には、こんな流れです。

今にしては、結構いい加減なものでしたが、今でも基本はこの流れを汲んでいるといっても良いでしょう。

App Inventorって何？

アプリ開発当初は、本家のブログにて何度か出てきた

”App Inventor"

ですが、これっていったい何なの？

まずはこれをご覧ください。


ということです。

といっても分かりづらいかと思いますが、要は文字をツラツラ記述していく代わりに、動きや名前が決まっているブロックを組み合わせていき、結果としてプログラムを作るというものです。

このブロックには、ジグソーパズルのように、凹凸があって、論理的に不適合なもの同士は接続できないようになっています。合体するこきに

”お前、こいつらはつながんねぇって言ってんだろ！！”

的な感じです。

結果的にラリーアプリもどきを、このApp Inventorで一通り作ってみたのですが、一般的なアプリであれば、十分対応することができるかと思います。

ただ、このツールの謳い文句

”小学生でも作れる・・・”

というのは、いささか疑問かと。というのは、結局、文章を書くところをブロックにしただけで、スタートの前提として

”プログラムの基礎の基礎を知っている”

という条件がつくと思います。

・変数
・条件分岐
・処理

等など。そして、このプログラムの作り方は、”BASIC"に近いのかな？と思います。なぜなら、私が唯一最低限レベルで知っているのが、”BASIC"だからです。

”おいおい、ゼロから始めるんじゃなかったのか！？”

すみません。そういう方は、”こっちこそ、ゼロから始めるんだアプリ開発！”というブログをスタートしていただければと思います。

ということで、このApp Inventorというのは、

小学生でも作れる

のではなく、

プログラムの基礎を理解した小学生なら作れる

とした方が良いような気がします。

このApp Inventorをスタートしたことが、結局のところ今に至るわけですから、十分アプリ開発の入門としては利用価値があるかと思います。まずはアプリを作って公開する楽しみを知って、より便利なものを作りたいと思った場合、再スタートするというのも手かな？と思いますので、ぜひ興味を持った方は一度試してみてはいかがでしょうか？

ちなみに、App Inventorは、昨年夏に公開されたため、まだまだ使い方や機能などの情報元が少なく、日本語での説明サイトは、数えるほどしかありませんので、ブロックの使い方や意味を理解するまでが結構大変かもしれませんので、がんばってください。

まずはGoogle App Inventorから

Androidアプリ開発どころか、前提である”JAVA"すら、まったく触れたことすらない私にとって、さてどこから手をつけてよいものやら・・・・と途方に暮れていた12月の暮れも押し迫ったころ。

とりあえずネットで

「アプリ　開発　ツール」

的に検索をしていたところ、

”App Inventor"

というツールに引っかかりました。

このApp Inventorというのは、Googleが提供する、ブラウザ上でAndroid用アプリケーションが開発できるというツールで、謳い文句は

小学生でもアプリが作れる

というものらしいです。

小学生でも作れるのであれば、いい大人の私でも作れるだろう。そんな安直なきっかけから、App Inventorというものに手を出してみることになりました。

思い込みによる盲点の見過ごし

回顧録ばかりでは、なかなか話が進まないので、開発中の気がついたことなどはその場であげていくようにしてみます。

で、今回はごく最近気がついたことについてです。

今まで使っていた携帯電話というのが、時刻あわせが不要で、３G回線を使って携帯が勝手に秒まであわせてくれていました。気持ち誤差はあるものの、1秒以上ずれているということはあまり記憶にありません。

これがそもそも重大な盲点の見過ごしの原因です。

数日前、アプリを開発しながらテレビをふと見てみると、ちょうど次の番組が始まる瞬間でした。つまり18時00分丁度でした。そのタイミングで、開発中のアプリを見てみると、表示されているのは

17時59分５６秒

？？
？？

まあ、地デジだから、秒は正確ではないしなぁ・・・・・と一瞬現実逃避をしましたが、地デジのズレといったって、4秒もずれることは無いはず・・・・。

一瞬なんのこっちゃ？と思いましたが、次の瞬間

”これ、ひょっとして秒をあわせてくれてないのか？”

と現実の戻ってきて、すぐに調べてみました。結果として

”３G回線で一応自動更新はされるが、秒単位の誤差はある”

というもののようです。で、これだけならば、端末で手動で00秒あわせを行えばよいのですが、いくら調べても秒あわせまでは正攻法ではできない模様。裏技はあるけど、それではアプリとして成り立たないしなぁ・・・・。

さらに調べていくと

”この4秒の誤差はメーカーの仕様によるもので、他メーカーのものはこの誤差の量が違う”

ということが判明！これは尋常ではない問題になりました。

そもそも、なぜこんなに00秒にこだわるかというと、私が開発中のアプリが”ラリー”という競技に使うコンピューターの代用品を目指しているもので、ラリーでは00秒のズレは結構問題になる場合があります。よって、これが解決できない場合は、”ラリーコンピューターもどき”で終わってしまいます。

ここで、解決案１としてまず浮かんだのが、

GPSによる時刻取得

すぐに試作してみました。すると、時刻は無事取得できました。これならば、どの端末でも同じ時間で管理することができます。ただしこの場合には問題点があります。

【GPSが受信できない場合は、時計が止まる】

GPSの時刻から端末のシステム時計を調整すればいいじゃん！と思うかもしれませんが、Androidのシステム時計は、アプリ側からは修正できないようになっています、正攻法では・・・。裏技をプログラムに組むことも考えましたが、これではアプリ利用者に迷惑がかかる場合があるので、却下。つまりGPSでの時刻取得は保留としました。

で、誤差がバラバラで、端末自体では秒合わせができない（できる端末があるかもしれませんが）、この状況で考えた苦肉の策が、

”時計を独自で走らせてそいつの誤差を与える”

今までの時計は、Androidのプログラムに実装されている”DigitalClock"をそのまま表示していました。この方がプログラムが単純になるためです。ただし、この”DigitalClock"は、システム時計をそのまま表示するだけのため、修正等はできません。そこで、これとは別系統の時計を内部で作って、自由に誤差を増減できるようにしました。

これにより、端末ごとに異なる秒のズレは一応解決できました。またNTTの時報ともぴったり合ってます。端末で時刻の自動更新をしている場合、ある時点からまた秒のズレが生じてしまいますが、ラリー開始時に自動更新をオフにしてから誤差を修正してあげれば問題にはならないかな？と思います。

また、この方式にすれば、もし大会公式時計がNTTの時報や電波時計と1秒単位でずれていた場合、
大会公式時計に合わせることができますので、融通は利くかな？とも考えています。大会公式時計が必ずしも正確といえる場面ばかりではありませんので。

ということで、一瞬

終わった・・・

と思った問題もとりあえず最悪の事態は脱したかな？と思いつつ、何事も

思い込みは致命傷になりかねない

ということを改めて実感いたしました。

開発のきっかけ

まず、どうして私がAndroidと出会ったのか？

これ、たぶんほとんどの人が”どうでも良い”ことなのかもしれませんが、あえて言わせてください。

まず、私はauの携帯を7年くらい使っていました。それが今年の7月にauの周波数帯の変更により使用することができなくなるということを昨年の夏あたりで知りました。その時点では、まだスマートフォンなどには興味も無く、ただ次の携帯は何にしようかなぁ？くらいでした。

同感する方もいるかと思いますが、auの端末というのは、非常に残念なものばかりのような気がしていました。そのため、中々買うに至るものが無く秋～冬へと移り変わります。

そんな折、auから”IS０３"のリリースが決定！

15年もauを使っていたし、ポイントもやたら溜まっていたので、いい機会ということで、これはスマートフォンデビューしようと、ちょっと期待していました。

しかし発売日近づくにつれ、どうも”バッテリー容量不足”が指摘されだします。ちょうどそのころauからも、”予約特典でバッテリーもう一個プレゼント”キャンペーンが始まりました。

・・・・

これは、自首か？

ここから、IS０３に抱いていた期待が不安へと移り、ついにはいったん保留か？ということになりました。

しかし、機を同じくして、我が家の財務大臣が

”時代についていってみたい！”

という鶴の一声がかかります。

auはなぁ・・・・・とかいろいろごちゃごちゃ言っている私をよそに、家電量販店の携帯コーナーで、

”これがいい！”

と手にしたもの。それが”Docomo　LYNX3D”でした。しかも、

”使い方説明してもらうのに、同じ端末がいい”

”同じのだったら買ってあ・げ・る・・・・・。”

買ってくれののならば・・・・・

と、天の一声により、めでたくスマートフォンユーザーへ仲間入りすることになりました。

これが私のAndroidとの出会いです。この出会いが無ければアプリ開発も始まらなかったということで、どうでも良い話ではありますが、お許しください。

次回からは、回顧録にはなりますが、アプリ開発雑記をお送りしていきます。

開発日記を始めるにあたり

皆様はじめまして。

こちらの開発日記を始めるにあたり、どういうスタンスで進めていこうと思っているかを簡単にお知らせさせていただこうと思います。

詳細は追々お送りしていきますが、あるきっかけと筆者の性格の問題から、昨年末にAndroidアプリを開発してみたいという思いが沸いてきました。

それからいろいろあり、現在そのアプリが形になってきて第二段階へと進もうかという近況でございます。

私は、プログラミングとは無縁の仕事をしており、アプリ開発などの経験も皆無です。よく雑誌やインターネットで

ゼロから始めるアプリ開発

なんていうキャッチコピーを目にする機会があるかと思います。実際私も開発を始めるにあたり、何度このキーワードを使ったことでしょう。

でも、そういう雑誌やサイトを見ると、大方

最低限JAVAを理解していることが前提

というキーワードが載っています。では、最低限必要な”JAVA"とは・・・・・と調べてみると、はっきりいってチンプンカンプン・・・。

ゼロから始めるんではなかったのか！？

で、おそらくこの段階で、”やっぱりダメかな？”と思う方々も多いのではないでしょうか？実際私もあきらめようかな？と思いました。

別な仕事をしている人間にとって、JAVAなどというプログラムを一から勉強している時間があるのか？勉強したところで、プロがちょこっと出てきてしまったら、結局あっという間に追い抜かれてしまうし・・・。ということを思うこともありました。

しかし、最初に挙げた私の性格というのが、”やりたいことはいまやりたい”という、よく言えば行動力がある、悪く言えば”行き当たりばったり”なもので、やっぱりアプリを作ってみたいという欲望が消えることはなく、とりあえず手を出してみようという決断になりました。

今後お送りしていく中で、私が知っていることも実は知らないという方も当然出てくるでしょう。その場合、やっぱり”ゼロから始まってないじゃんかよ！！”とお叱りを受けるかもしれません。

でも、少なくとも、今良く見る”ゼロから始める”よりはマイナス側に近いのではないかな？と思っていますので、もし私よりも更にマイナス側の方がいましたら、ぜひその立場で”さらに真！！ゼロから始める・・・”をスタートしてみてください。そちらの方が参考になるでしょう。

ということで、ゼロよりもマイナス側な人間が見た、やわらかいアプリ開発心境をお届けできるように、がんばって・・・・しまうと硬くなるので、のんびり続けてみようと思います。