2005-09-21-01-ハードボタン狂想曲
>> Site top >> weblog >> 月別アーカイブ >> 2005年09月のlog >> 2005-09-21-01-ハードボタン狂想曲
最終更新日付：2005/09/21 01:00:00
ハードボタン狂想曲
2005 年 09 月 21 日
多様性は一般には良いことだ。その中から１つを選ぶ立場から見れば、それは選択肢が豊富であることを意味するから。しかし、その多様性全体を守備範囲に収めたいという立場から見ると、それは時として重荷になってしまう。今回は開発者の観点から、Palm OS搭載デバイスのハードウェアボタンの多様性について中途半端に書いてみよう。
話を簡単にするために、まずはいわゆる「アプリケーションボタン」から始めよう。Palm デバイスの伝統として、多くのデバイスにはアプリケーションボタンが４つ付いている。普通は横一列に並んでいて、左から右に向かってボタン１〜ボタン４だ。そのどれかを押すと、特定のキーコードが Palm OS で処理され、通常は設定されたアプリケーションが起動する。古典的な代表例は予定表、メモ帳、アドレス帳、ToDo の４つだ。しかし、実行中のアプリが「システムイベントをフック（hook）」することによって、アプリ側でそのボタンを使うことができるようになる。フックというのは、要するに横取りということである。横取りしてしまえば、本来そのボタンに割り当てられていたアプリが起動されることはない。
このおかげでアプリケーションはハードボタンを自由に使用することができる。開発者としては、これはありがたい話だ。こういったフックは OS 側が意図的に用意してくれなければ容易に実現できるものではない。事実、Palm OS プログラミングでは、ほとんど全てのイベントをフックできるようだ。人間で言えば内臓の中まで触らせてくれるようなものである。いや、例が悪かった。そんなもの触りたい人はあんまりいないね。
しかし、残念なことにアプリケーションボタンの数は指定されていない。現実にZire21 などはアプリケーションボタンが２つしかない（ように見える）。僕は実機を触っていないから、その２つがボタン１＆２なのか、はたまたそれ以外なのかはわからない。ボタンがないデバイスもあるかもしれないし、どのボタンが「何番目のボタン」なのか、実際に試すまでわからないかもしれない。現に、Zire72 などは左上、左下、右下、右上の順にボタン１〜４が並んでいた。ひょっとしたらマニュアルに書いてあったのかもしれないが、僕は実際に試してみるまではわからなかった。Treo650 に至ってはアプリボタンを探すのにも苦労した。5Way の両側にあるカレンダーボタンとメールボタンがそれっぽいが、調べてみるとそれらはボタン２＆３だった。その結果、さらにその両側にある通話ボタンと電源ボタンがボタン１＆４であることに気づいたのだ．．．Treo650 ではボタン４をトラップするアプリの実行中は電源を切ることができない。
ボタンの数が決まっておらず、どのボタンが何番かもわからないというのは開発者側としては頭の痛いところである。たとえば、上下左右方向をボタンで処理したければ、スクロールボタンの上下と、その両端にある（ことが多い）ボタン２＆３を使うのがもっとも自然だろう。しかし、それで固定してしまうと、ボタンが２つしかないデバイスでは上手く使えなくなる。多様性が直感的なデザインの邪魔をすることになってしまうのだ。
スクロールボタンの話がでたので、そっちに話を持っていこう。伝統的な Palm デバイスには上下のスクロールボタンが付いていた。しかし、最近の Palm 社のデバイスのいくつかには 5Way ナビゲータがかわりに付くようになった。これもまた多様性のひとつであり、開発者としては悩みの種だ。さらにはジョグダイヤルのような特殊なコントローラが付いたデバイスもある。さぁ、もうお腹一杯だ。いったいどんなデザインならみんなが満足するっていうんだ？
そもそも、多様性が認められているのであれば、普遍的に直感的なデザインを提供するのは本質的に不可能だ。となれば次善の策を探すしかない。それは、（１）代表的なデバイスを優先したデザインで行く、（２）徹底的にカスタマイズ可能にする．．．のいずれかだ。しかし、（１）はいわゆる「個性的」なデバイスを無視することになってしまうし、（２）は画面の数に比例して苦労が増す．．．特に、ハードボタンだけで操作可能なアプリを提供しようとするとそれだけで大仕事だ。使う側だって全ての画面に対応するハードボタンの設定画面があったとしたら、それはそれで嫌だろう。
なんだか結論がはっきりしないが、それも仕方ない。僕自身、この問題をもてあましているのだから。
コメント
eye - 09/21/2005 06:12:29 PM
陰郎 - 09/22/2005 12:37:47 AM
> eye さん
悩みますよね．．．作り手にとっては永遠のテーマですね。
EIJ - 09/26/2005 12:09:30 PM
確かにこの問題は悩ましいところですが、私の解は
- アプリケーション側で menuボタン、selectボタン、cancelボタン等を定義し各画面での処理はこれらのボタンに対してアサインする
- 実際のボタンと1.のボタンとのマッピングはユーザ側で変更可能とする
- 代表的なデバイスについては推奨設定を提供する
ユーザは自機種を選択するのみで推奨設定が利用できる
ただし、変更したい場合は変更可能
このように仕様を決めると実装上はイベントループの最初で keyDown イベントをフックして内部的な myEvent に置き換えるようにして、各画面の EventHanlder では myEvent に対して処理を記述することで、新しいデバイスが出てきたときのコードへの影響を最小限に押さえることができます
拙作"ぐるグル"がこの実装の典型例なので、気が向いたら試してみてください。
＃ただしtreoのキーへのアサインは実装していませんが(^^;
＃＃いじってる暇ないです、、
陰郎 - 09/26/2005 12:40:43 PM
> EIJ さん
こんにちは。
keyDown イベントと内部イベントのマッピングを設定可能にする、という部分は私もやっているのですが、３の「代表的なデバイスについては推奨設定を提供する」というのはいいですね。各種デバイス向けのプリセットを提供するということですよね。これ、今度やってみようと思います。
いずれにせよ、フルカスタム可能にしようとすれば画面ごとに設定画面が必要になりますが、プリセットで対応できるならば些細な画面の設定までフルカスタム可能にする必要もないかもしれませんしね。
ハードボタンの設定については、もうひとつ考えていることがありますが、それについてまた新しいエントリを書くことにします．．．
EIJ - 09/26/2005 06:13:00 PM
EIJです
ちょっぴり違います
私の解では、内部的な menuボタン、selectボタン、cancelボタンなどと各画面での動作のマッピングは固定です
例えば、ユーザが HardKey1 を select にマッピングしたとすると（この部分はユーザにより設定可能）、どの画面でもHardKey1を押したときにselectという機能をユーザが選択したことになります。アプリ側ではselectという機能が選択されたときに適当であると思われる機能が実行されるように実装されています。
この解ではユーザが設定可能なのはハードキーと内部イベントのマッピングのみで内部イベントと内部イベントに対応して各画面で実行される機能のマッピングは固定です。
陰郎さんも気にされている通り、あまりに設定の自由度を上げるとかえって扱いにくくなってしまいますから(^^;
陰郎 - 09/26/2005 06:33:39 PM
EIJ さん、度々ありがとうございます。
> 例えば、ユーザがHardKey1をselectにマッピングしたとすると（この部分はユーザにより設定可能） > どの画面でもHardKey1を押したときにselectという機能をユーザが選択したことになります
おぉ！ やっと理解しました。そういうことですか。
内部的なボタンの定義を画面間で共有するわけですね。そうすることで、マッピング１つで全ての画面にその設定が反映される、と（まだ違ってたらゴメンナサイ）。
画面数が多くて、かつどの画面でも同じような操作がある場合に特にパワーを発揮しそうですね。プリセットとあわせて、これも近いうちに使わせて頂く可能性大です。
このページのタグ
Page tag : Palm
Copyright(C) 2005-2018 project-enigma.
Generated by CL-PREFAB.
同感。いつも悩みます。