現状
http://wantech.ikuto.com/software/CameraDS.apk

iPhoneの不便なところの一つとして、写真をフォルダ管理できないことがあったわけだが、
某カメラアプリが便利だと感じた点は、撮った写真をアプリの専用フォルダに一時保存するから、
ともかくどんどん撮りまくり、その大量に撮った写真の中で残したいって物だけを標準のフォルダに移動し、
いらない写真は一時保存なのでまとめて消すっていう作業まで、一つのアプリで出来た事だ。
そういう動作をAndroidアプリでも実現したいと思っている。

だので、カメデスで撮った写真はまずカメデス専用フォルダに入り、
カメデスからそれぞれの環境にインストールされたギャラリーなりファイラなりを起動出来る様にし、
ユーザーがそれぞれでやりやすい方法でファイルの管理をするような感じになればいいなと思ってた。
ところが、カメラアプリからギャラリーを起動してファイルを選ばせるって言うことは出来るが、
フォルダを指定してギャラリーをただ起動するっていうのが出来ない。
ブラウザならURLを指定してただ起動することは出来るが、
ギャラリーだとファイルを選ばせた時点で終了するっていう動作しか出来ない。
世の中には優秀なギャラリー的アプリがいっぱいあるのに、
それを利用して自分の望む動作をさせることは出来ないので、ギャラリーは独自実装しなきゃいけない。

そういうわけで、ともかくギャラリー起動ボタンを付けて、独自ギャラリーを実装してる途中なんだが、
写真のプレビューを作って一覧表示するのに時間がかかりすぎる感じ。
ボタンを押してからちょっと待たないと一覧が出ないので、その間にアプリが固まってるかと思っちゃう。
しかもいざ一覧を表示しても、それをスクロールさせるのにまたカクカクしちゃう。
おそらくそこいらのギャラリーアプリは、キャッシュ的な物を作って高速化してるんだろうな。
それをやらずに5メガピクセルの画像をそのまま並べようとすると、性能的に追いつかないんだろう。
まぁ、ギャラリーが必要ならキャッシュもやらなきゃいけないなってところ。

まだ一覧表示が出来て良かったよの状態でしかなく、必要な写真を仕分けるとか、
いらない写真を消すとか言うところまでは出来てないが、
それをやるにあたってぜひとも実装したいのはCROPと呼ばれる切り抜きだ。
ほとんどのギャラリーアプリに切り抜き機能はあるけど、4:3で固定して切ることが出来ない。
カメラアプリにサイズ固定の切り抜きが付いてれば、ズーム機能を使わずにあとから切ればいい。
そして、切り抜いた完成写真を標準フォルダに移動し、ズームなしで撮った写真を破棄する。
それをやるために無駄に画素数を最高にして撮る。

とりあえずそこまで出来れば便利だと思って、当初は撮るだけのつもりが大がかりになりつつある。
見た目はいたってシンプルだが。

中国から通販の車載アームが来たので、StreakでGoogle製ナビを試してみたが、あまりよくなかった。
携帯に付いてるナビなんてこんなもんだろうとあきらめなきゃならないレベル。
しかしnavicoはこんなもんじゃない。
知らなきゃこれはこれで、この程度の物として便利かも知れないが、知ってたら比べものにならない。
せっかく5インチの画面で見やすいから、ナビはぜひStreakを使いたかったが、アプリがダメじゃ意味がない。
画面が小さくてもiPhoneの方が使い物になっちゃう。
これはAndroidでnavicoが発売されたら即買っちゃうな。
ダメだこれ。

まず、両方に対して似たような方法で、どういう反応を示すかって感じで裏切った動きをしてみた。
旧道の方が近いけど渋滞するからいつもバイパスを通ってるって所で、
当然ナビは近い旧道を提案し、それを裏切ってバイパスに向かったんだけど、
navicoはバイパスに入った瞬間にあきらめて、バイパスを使った最短ルートを示した。
ところがGoogleは、車では入っていけない道を使ってUターンするように示した。
さらにその問題のポイントをすぎても、Googleは旧道に戻るための最短ルートを探した。
もはや、目的地に着くことよりも、最初に提案した旧道ルートに戻ることを優先し、
そのためには遠回りになろうが関係ないという頑固さが、いかにも昔のナビらしくて賢くない。

また別の目的地へ行く際は、提案を裏切って知る人ぞ知るようなところを通ったのだが、
navicoは途中からそのルートを使った正しい最短ルートを示してくれたのに、
Googleはどうにかして細い道を通ってでもUターンさせることに必死だった。
つまりね、Googleは細い道も知ってるけれども、あえてそういう所は使わずに提案するように出来てて、
そこまでは良いんだけど、いざ裏切られたら、正しいルートに戻るために細い道も使ってしまう。
その細い道を車が通れるかどうかの判別が不完全なので、
あえて最初の探索では除外してるのに、再検索では除外してないっていう仕様なんだな。
それに比べてnavicoは、ちゃんと車が通れるかどうかを判別してるのか、
それとも既に通った道の太さを参考にしてるのか、最初は安全ルートしか提案しなくても、
あとから通好みの道に入ったときちゃんと通好みの提案に切り替えてくれる。
たぶん。
まだ少ししか使ってないけど、使った分に関しては歴然の差が生まれている。

また、十文字だけどちょっと左向きに直進って所で、分岐を右という音声案内をしやがった。
交差点ではなく分岐と表現したことも意味不明だし、やや左なのに右と表現したことも不明。
画面上はちゃんと表示されてるので、音声だけおかしかった。
備え付けのナビがバカだから、ナビという物はバカなんだという覚悟が多少あったけれども、
Googleのはまだまだ全然実用レベルじゃないほどバカだ。
たぶん都心部とかではもうちょっと賢く、こっちは田舎だからダメなんだろうな。
で、おそらくこれは開発途中で、今はダメでもそのうちもっと使いやすくなるんだろう。

帰りはパケット通信なしじゃ探索も出来ない事を教えられた。
ということは、これってパケットオフにしてるから有効な再検索が出来なくて、
しかたなく目的地到着より初期提案ルートへの復帰を促してただけなんじゃなかろうか。
もしかしたらパケットオンにしてれば、いつでもうまいルートを検索する賢いナビになるかも知れない。
まぁそれでもパケットは使わないけれども。
そんなわけなので、やはり完全オフラインで使えるかどうかも重要だって事だ。
地図だけダウンロードしたからオフで使えるってもんじゃないね。