いなあものPalmware開発日記 このページをアンテナに追加 RSSフィード

2005-11-22

[]愚行の尻拭い 愚行の尻拭い - いなあものPalmware開発日記 を含むブックマーク

今回はちょっと難しい話です。

さて、本日、B-CAL 1.3.0を公開しました。

今回のバージョンアップの目的は、J-OSとJaPon環境でB-CALのデータを受け渡す事です。

最近は、英語Palm日本語化する人が増えたため、今までJ-OSを使っていた人が、新しいデバイスを購入した際にJaPonに乗り換えたり、逆にJaPonからJ-OSに乗り換えたりする機会が増えています。

そんな折、B-CALユーザから

「機種を乗り換えたらアイコン状態が保存できなくなった」

とか

「B-CALに登録してある情報を読み出せなくなった」

と言った報告を聞くようになって来ました。

原因を調査すると、たいていの場合上記のようにJaPonとJ-OSの乗り換えがきっかけだと言う事も分かりましたので、それぞれの環境で色々と調べてみると、興味深い事実が発覚。

JaPonとJ-OSではB-CALの保存データの並び順が違うのです。

B-CALは、表示に使ったアイコンの種類と最後に表示した人、そしてB-CALに登録している人の氏名と生年月日を1つのデータベースでまとめて管理しています。

データベースではこれらの情報レコードごとに管理しています。

例えば太郎さん、花子さんという二人の情報を登録したデータベースがあったとして、J-OSではそれが以下のように作られます。


 1.最後に表示した人の情報

 2.最後に表示したアイコン情報

 3.花子さん情報

 4.太郎さんの情報


これは、僕がB-CALをリリースした頃に使っていたVisor Platinum(日本語版PalmOS3.5)と同じ並び順になります。

ところがJaPon環境ではこの並び順が以下のようになります。


 1.花子さん情報

 2.太郎さんの情報

 3.最後に表示した人の情報

 4.最後に表示したアイコン情報


そう、環境設定の情報が後ろに来るんですね。

実はこの並び順は、OSデータベースソート(並べ替え)機能の違いに由来しています。

B-CALは最初に設定情報を読み、その後データベースソート順に従ってデータを順番に読む仕組みになっています。

ところが環境が変わってしまうと、今まで綺麗に整列していたデータがぐちゃぐちゃのデータになってしまうので、ソートされた順番でデータを読み出す事が出来なくなってしまっていたのです。

ここで皆さんは、

「これはJ-OSやPalmOS3.5と並び順が違うJaPonの不具合ではないのか?」

と思うかもしれません。

ところがどっこい。何と僕が調べた限り、クリエPEG-NX80V(日本語版PalmOS5.0)では、JaPonと同じ並び順になるのです。

もうこれでは訳がわかりません。

今年になって何度かJaPon対応と言って行った改修作業は、全てこの問題を解決しようと試みた結果です。

ただ、小手先で対応しようとしたのが間違いで、結局JaPon環境では動作するようになったけど、J-OSへの移行ダメという状態に持っていくのが精一杯でした。

今回のVer1.3.0で追加した「情報再構築」機能とは、まさにJ-OS配列のデータをJaPon配列に変換(またはその逆)するための機能です。

一番泥臭い手法ですが、保存データを先頭から全て読み込んでOSデータベースソート順にあわせて再度保存データを作り直しをしています。

これで何とか表示のつじつまを合わせる事が出来ました。

さて、では何故B-CALでだけこんな問題が発生しているのでしょうか?

その理由は、ソートの鍵となる文字列に含まれていた特殊文字にあります。

実際には、JaPonもJ-OSもデータの整列を行う際に、それほど大きな違いがあるわけではありません。一部の特殊な文字を除いては。

実はB-CALで使われていたキー文字列に、たまたまその特殊文字が含まれていたために、こんな現象が発生してしまったのです。

当時は良かれと思って組み込んだ特殊文字が仇となってしまった訳です。

とんだ愚行のおかげで、その尻拭いに長い時間を費やす結果となってしまいました。

2005-11-08

[]デバイスの多様性とアプリ デバイスの多様性とアプリ - いなあものPalmware開発日記 を含むブックマーク

PalmOS搭載デバイスと言えば、一昔前なら4つのアプリケーションボタンと上下ボタンが当たり前でした。

でもクリエジョグダイアルを搭載した頃から多様化が始まり、本家Palmでも、Tungsten|Tに5Wayナビゲーションを搭載したかと思えばZireは思い切ったコストダウンアプリケーションボタンが2つに減ったりもしています。

これは、アプリを作る側にとっては頭の痛い問題です。

ユーザはありとあらゆるデバイスアプリを使おうとするのに対し、僕が持っているデバイスはその中の本の一握りでしかありません。

だから、「WristPDAのロッカースイッチに対応して下さい」なんて言われると、気持ちは対応してあげたいのですが、果たしてどのような作りこみをすればいいのかまるで分からないのが現状です。

一応、アプリ製作者の間でも情報をやり取りしていたりして、実機を持っていなくても作りこみの基本は分かっていることは多いのです。

でも検証環境が無い中でアプリの対応をするのは、長さ1mの箸で豆を摘む様に細心の注意を払いながら、冒険も出来ず一番確実に動作するであろう方法をおっかなびっくり採用することになります。

例えば、シューティングゲームを作ったとします。

あるデバイスでは、シュートボタンを押したときにミサイルが1発しか発射されないのに、他のデバイスではボタンを押している間ミサイルを連射するようでは、ゲームとして全く別の物になってしまいますよね。

だからミサイルの発射は、ボタンを押した直後の最初のイベントを見つけるとか、ボタンを離したときのイベントを拾って処理を行ったりしないといけない訳です。

一事が万事そんな感じになってしまうのです。

また、Zireなどボタンの数が少ないデバイスでも動作する事を前提とすると、使えるボタンが自ずと決まってきます。

さらに、クリエTJ/THシリーズだと上下ボタンが左右に配置されていたりもします。

このように、全ての機種で使いやすいよう、ボタンに機能を振り分けることがとても難しい事だとお分かりいただけると思います。

さて、一方で最近はボタンに割り振る機能をカスタマイズするようなアプリが増えています。やはり、アプリの作者としては多くの方に自分のアプリを使っていただきたいと思っているので、どうしてもそういう方向に向かわざるを得ないのでしょう。

僕も、そんなボタンキャリブレーション機能をひとつのモジュールとして作り、NS Basicアプリを作っている方向けに提供できたらと考えています。

既に現在、試行錯誤を繰り返しながら拙作LightCycleにこのモジュールを組み込む試作を行っています。

まだまだ正常に動作するまでには至っていないのですが、このモジュールを公開できたならば、アプリによっては非常に開発の助けになるのではないかと思っております。