解説
設定をファイル内に保存する方法は自由です。フラットな構造で保存してアプリケーションの起動時にハンドルに直接読み込むことも、もっと複雑な形式で保存することもできます。
設定ファイルにはどんな名前を付けるべきですますか。
設定ファイルに付ける名前は完全に自由です。DTS からの唯一のお願いは、終りを "Prefs" にしないことです。代わりに "Preferences" を使ってください。そのファイルに入っているものが、削除すると危険な謎の重要データでなく、単に例えば SurfWriter の設定であることをユーザによくわかるようにするためです。
これは些細な事柄と思われるかもしれませんが、アプリケーションの名前が長すぎて "Preferences" という部分が最後の文字列にならない場合を除き、省略は避けるべきです。これをタイプするのは一度だけなので (おそらく 'STR#' リソース内に)、名前が長くても問題になることはないはずです。
設定ファイルはどこに置きますか。
簡単な答えとしては、FindFolder への呼び出しで返される“初期設定”フォルダ内のひとつまたは複数のファイルに入れてください。
設定ファイルがひとつしかない場合は、“初期設定”フォルダ (FindFolder から返される) に入れてください。設定ファイルが複数の場合や、ログファイルなど“初期設定”フォルダに入れたい他のファイルがある場合は、“初期設定”フォルダ内にフォルダを作成して、そこにすべてのファイルを保存します。そうすれば、“初期設定”フォルダの中を整理することができます。
アプリケーションが複数の設定ファイルを必要とする場合は、“初期設定”フォルダ内に新規フォルダを作成し、設定ファイルをその追加したフォルダに入れるようにしてください。しかし、あらゆるファイルを“初期設定”フォルダ内の階層に保存するのがすべてのアプリケーションにとって最良の方法というわけではありません。例えば、複数ユーザが対象になる場合、多くのファイルを同じ“初期設定”フォルダに入れるのではなく、各ユーザ個人のフォルダに設定ファイルを保存したい場合もあるでしょう。
設定ファイルにはどんなファイルタイプとクリエータを使うべきですか。
ファイルタイプについて
設定ファイルのファイルタイプは 'pref' にするのがよいでしょう。このタイプを使うと、Finder の将来のバージョンが設定ファイルを“初期設定”フォルダから自動的に認識します。'pref' というファイルタイプを使うべきではない理由として思いつくのは、このファイルタイプを使うと次のような Finder のバルーンヘルプメッセージが出てしまうことだけです。
Finder の設定ファイル
このファイルには Finder の設定が保存されています。
ほとんどすべての設定ファイルが 'pref' のタイプを持っているため、これではユーザが混乱してしまいます。DTS では、アップルのエンジニアリング部門が Finder を修正すべきだと考えています。われわれはこの問題についてバグレポートを提出しました (ID は 2241857)。
“初期設定”フォルダ (または、“初期設定”フォルダ内のフォルダ) に設定ファイルの他に保存するファイルがある場合は、任意のタイプを使ってかまいません。例えば、“初期設定”フォルダにログファイルを入れる場合、'TEXT' タイプにするのが最も適切でしょう。設定ファイルでなく、開いても大丈夫だということがわかるからです。
つまり、設定ファイルであればタイプは 'pref' にするべきです。設定ファイルでなければ、“初期設定”フォルダに保存するファイルでも 'pref' タイプにしてはいけません。
クリエータコードについて
この問題については 3 つの説があります。最初の説は、設定ファイルにはアプリケーションのシグネチャに一致するクリエータコードを付けるべきだというもの。2 番目は、'????' というクリエータを付けるべきだというもの。3 番目は '????' でもなく、アプリケーションのシグネチャでもない、クリエータコード (登録されたもの) を付けるべきだというものです。
アプリケーションのクリエータコードを使用する場合
設定ファイルにアプリケーションのシグネチャと同じクリエータを与えるということには、次のようなもっともな理由があります (順不同)。
- ユーザがファイル名を変更した場合でも、クリエータコードによって簡単に設定ファイルを探すことができます。
- 「親のない」設定ファイルを削除するユーティリティアプリケーションが、そのファイルがどのアプリケーションに付属しているかがわかります。
- アプリケーションをローカライズしてもクリエータコードは変わらないため、アプリケーションコードは設定ファイルの名前を知る必要がなく、ローカライズが簡単になります。
ところが、次のように、設定ファイルのクリエータコードとしてアプリケーションのシグネチャを使わない方がよい理由もあります。
- ユーザが設定ファイルを開くとアプリケーションが起動します。この場合アプリケーション側ではこれに対応して何らかの処理をしなくてはなりません。これについては後で説明します。
'????' のクリエータコードを使用する場合
アプリケーションのクリエータコードを使わないで、'????' を使うことは次のような利点があります。
- ファイルを名前で探すのが非常に簡単です (ここをクリックするとこれを示すコードの断片にジャンプします)。
- '????' をクリエータコードとして登録する必要がありません。(実際には登録できません。どのアプリケーションにも属さないシグネチャとして明確に定義されています。)
- ユーザが設定ファイルを開こうとしてもアプリケーションは起動されません。
- ユーザに設定ファイルが開けない理由を伝えるため「アプリケーションが見つかりませんでした」メッセージ文字列を指定できます。
しかし、'????' というクリエータコードを使うと次のような不都合もあります。
- 設定ファイルを名前で探さなければならず、ローカライズの際に問題となる可能性があります。
- ユーティリティアプリケーションが、ユーザのシステムにもう存在しないアプリケーションの設定ファイルが残っていることを警告し、ユーザがそのファイルを削除してしまう可能性があります。逆に、同じようなユーティリティが、アプリケーションが削除されたにもかかわらず、設定ファイルを消さずに残してしまうこともあります。
- '????' のクリエータコードを使うと、同じクリエータコードを持つファイルが複数あるため、クリエータコードによって設定ファイルの場所を探すことができなくなります。
異なるクリエータコードを使う場合
アプリケーションのシグネチャでも '????' でもないクリエータコードを使うことには、次のような利点があります。
- 他では使われていないクリエータコードを付けることで、当然、設定ファイルを簡単に探すことができます。
- クリエータコードについては、ローカライズの問題は起こりません。
- ユーザが設定ファイルを開こうとしてもアプリケーションは起動されません。
- 「アプリケーションが見つかりませんでした」メッセージの文字列を指定して、ユーザに設定ファイルが開けない理由を伝えることができます。
しかし、この方法には他の場合とは多少異なる次のような不都合があります。
- 他のアプリケーションとのコンフリクトを避けるため、設定ファイルのクリエータコードを 2 番目のアプリケーションシグネチャとして登録する必要があります。
- 前例と同様、ユーティリティアプリケーションが親のない設定ファイルと認識します。
| 注意: この TECHNOTE の最後に、クリエータコードかファイル名 (またはその両方) で設定ファイルを探す方法を示すコードを掲載しました。これを基にして自分で検索コードを作成することができます。 |
設定のローカライズについて
アプリケーションが現在動作しているシステムとは違う言語コードで作成された設定ファイルをユーザが使用する可能性があります。例えば、米国人のユーザが日本人の同僚に設定ファイルを送ることがあります。
アプリケーションがファイル名でなくクリエータコードで設定ファイルを探すようになっていれば、日本のアプリケーションと米国で名前を付けた設定ファイルの組み合わせでもユーザの期待通り動作します。アプリケーションが設定ファイルを常に名前で開いたり、名前が特定の文字列であることを想定している場合は、設定ファイルを単純にコピーすることはできません。ユーザが設定ファイルのコピーを作り、複数の設定ファイル間ですばやく切り替えを行うようなことがしにくくなります。
「アプリケーションが見つかりませんでした」メッセージについて
「アプリケーションが見つかりませんでした」メッセージの文字列は 'STR ' リソース ID -16397 として、アプリケーションが作成するファイルに入れておくと、Finder がそのファイルが開けない理由をユーザに伝えるために使用します。このメッセージには、そのファイルを作成したアプリケーション名と、そのファイルの目的をユーザに伝えるものでなければなりません。この文字列は、設定ファイル (他のファイルも同様) に、アプリケーションのシグネチャとは違うクリエータコードを与える場合に使用する必要があります。こうして、ユーザが設定ファイルを開こうとすると次のようなメッセージが表示されます。
「このファイルには SurfWriter アプリケーションのユーザ設定が記述されています。このファイルを開いたり印刷することはできません。このファイルを有効にするには、システムフォルダ内の“初期設定”フォルダに保存する必要があります。」
「存在しないアプリケーションの名前」を表す文字列、'STR ' リソース ID -16396 もあります。このリソースはそのファイルを作成したアプリケーションの名前 (例えば”SurfWriter”) です。あるファイルを作成したアプリケーションが見つからないとき、ユーザにどのアプリケーションかを伝えるために Finder が使います。通常、この文字列はユーザが開く可能性のあるファイルに対してのみ使われます。
設定ファイルはどうやって見つけますか。
名前で設定ファイルを見つけるのはとても簡単です。そこにあるかないかの問題だからです。クリエータコードで設定ファイルを見つける場合は、“初期設定”フォルダ全体から正しいタイプのファイルを探す必要があります。同じクリエータコードを持つ複数ファイルが見つかった場合は、名前もチェックする必要があるでしょう。クリエータコードが '????' の場合がこれに該当します。
特定のクリエータコードを持つファイルを探すには、PBHGetFInfo にインデックスを指定して呼び出し、ディレクトリ内の各ファイルについての Finder 情報を取得してください。PBHGetFInfo への各呼び出しの後、パラメータブロックの ioDirID フィールドを再設定しなければならないことを覚えておいてください。PBHGetFInfo がこのフィールドの値を変更するからです。
設定ファイルには 'vers' リソースを含めるべきですか。
はい、含めなければなりません。アプリケーションを構成するファイルはすべて、ID 1 および 2 の 'vers' リソースを持たなければならず、当然、設定ファイルも例外ではありません。
'vers' リソースの直接の利点は、Finder の“情報を見る”ダイアログからユーザがより完全な情報を得ることができることです。ダイアログにはそのファイルが属するアプリケーション名とバージョンが表示されます。'vers' の他の利点は、プログラムの新バージョンが古い設定ファイルのバージョンを認識して新しい書式に変換する際に便利だということです。
設定ファイルに正しいアイコンを関連付けるにはどうしたらよいでしょう。
これは簡単です。設定ファイルに 'pref' のタイプを与えれば、自動的に正しいアイコン (設定ファイルのデフォルトアイコン) が付きます。アプリケーションのバンドルリソースに 'pref' エントリを作成してはいけません。設定ファイルに汎用アイコンを与えると、“初期設定”フォルダが開くのがずっと速くなります。
設定ファイルに汎用ではないアイコン (カスタムアイコン) を持たせることはおすすめしません。しかし、カスタムアイコンを使いたいならば、Finder カスタムアイコンを使って、アプリケーションが削除されても設定ファイルがアイコンを持つようにしてください。ユーザが設定ファイルを削除してもかまわないかを判断することができます。Finder カスタムアイコンを使用する別の理由は、Finder は場所のわかっている 1 個のファイル (設定ファイル) を開きさえすればよく、すべてのボリューム上のデスクトップデータベースを探す必要がなくなるからです。Apple Remote Access を通じてマウントされている AppleShare のボリュームがあると非常に遅くなってしまいます。
Finder カスタムアイコンの作成方法については『Inside Macintosh: Macintosh Toolbox Essentials』の第 7 章「Finder Interface, using the Finder Interface, Creating Customized Document Icons」を参照してください。
ユーザが設定ファイルをダブルクリックしたらどうしますか。
これは、設定ファイルにアプリケーションのシグネチャと同じクリエータコードを与えている場合にだけ起こる問題です。アプリケーションが設定ファイルを開くよう求められたときにどうするかについては、次のような判断が可能です。
- 設定ファイルは開くことができないというダイアログを表示する。
- 設定ファイルを開くことができないというダイアログを出すことで、ユーザはアプリケーションを起動したつもりだったが、自分が「開いた」のが何のファイルだったのかを理解します。
- ユーザによってはこのようなダイアログで混乱する人もいます。
- 設定ダイアログを開く。
- 設定ダイアログを開くというのは素晴らしい考えで、Mac にとてもふさわしく思われますが、解決しなければならない次のような問題もあり、それはこの TECHNOTE のような一般目的の文書の枠を超えるものです。
- どのファイルから設定値を引き出すか。現在のファイルからか、それとも新しく開いたファイルからか。
- ユーザが「OK」をクリックしたとき変更をどこに保存するのか。既存の設定ファイルに保存するのか、新しく開いた設定ファイルにするのか、それとも両方か。
- 新しく開いた設定ファイルがサーバにあって、書き込みができない場合はどうするか。
- ファイルに保存した設定のいくつかまたはすべてが明示的なダイアログで設定されなかった場合、ユーザに設定ファイルが変更されたことをどうやって伝えるか。
- 何もしない。
- 何もしないことがデベロッパにできる一番簡単なことです。
- クラッシュしてはいけません (アプリケーションの「文書を開く」アップルイベントのハンドラから 'pref' タイプのファイルを取り除く必要があります)。
- しかしこれはすぐれたユーザインタフェースとはいえません。ユーザがファイルをダブルクリックしたことを感知したことを何らかの方法で示すべきです。
ユーザインタフェースの問題を除けば、どの方法にも実際の不都合はありません。ユーザインタフェースをどうするかはデベロッパが決めてください (アップルにはこの件に関する公的見解はありません)。
設定ファイルが存在しない場合はどうしますか。
これは簡単そうに思えますが、2 つの違う意見があります。
2 つの意見は次の通りです。
- ファイルは作成しない。アプリケーションの設定はすべてデフォルト設定のファイルが存在するように設定する。ユーザが何か設定を変更したら変更を含む設定ファイルを作成する。
- 設定ファイルを作成し、デフォルトの値を入れる。
最初の方法の明らかな利点は、ユーザが設定をデフォルトの値から変更しなければ、設定ファイルが作成されないのでハードディスクが消費されないということです。また、アプリケーションをインストールして、試し、削除することが簡単にでき、システムから親のいなくなったファイルを探す必要がありません。このことは、ソフトウェアの試用版を配布するデベロッパのために特筆しておきます。
常に設定ファイルを作成する方が少しだけコードは簡単になるでしょう。ただ、設定ファイルが作成できない場合もあるわけで、設定ファイルなしでもアプリケーションが動作できるようにしておかなければならない点は同じです。実際に必要になるまで設定ファイルの作成を先延ばしにしたほうがよいでしょう。
設定ファイルが作成できない場合というのは、ひとつにはボリュームやシステムフォルダがロックされている場合です。この場合どう対処すべきかについては、次の「設定ファイルに書き込めない場合はどうしますか」を参照してください。
設定ファイルやフォルダを保存したい場所に、他のファイルやフォルダがすでに存在するという場合もあります。この場合どう対処すべきかは「別のアプリケーションと設定ファイルがコンフリクトを起こしたらどうしますか」のセクションを参照してください。
設定ファイルに書き込めない場合はどうしますか。
アプリケーションが設定ファイルの保存または更新ができない場合はどうしたらよいでしょうか。
- アプリケーションの実行をやめる。これは最悪の解決策です。最後の手段であり、最初に選択すべき方法ではありません。
- アプリケーションは続行する。ただユーザの設定は保存しない。
しかし、ユーザがプログラムを新しい設定で使いたい場合はどうなるのでしょう。
- ユーザが行った設定はすべて有効にする。ただし保存はできないことを警告する。この場合、プログラムは新しい設定で動作しなければなりません。
- 別のフォルダに保存する。プログラムが設定ファイルを任意のフォルダに保存できる場合は、ユーザに別の場所を問い合わせることで、設定ファイルの保存をキャンセルする必要はなくなります。
設定ファイルが壊れたらどうしますか。
アプリケーションの多くは、独自のリソースデータ構造体を含むリソースフォークのみの設定ファイルを用いて、起動時にそれを読み込みます。Resource Manager に基づいて設定ファイルを使う場合はその制約を知っておかなければなりません。重要なのは、現在の Resource Manager はリソースファイルを開く際にあまり強力なチェックを行わないことです。リソースファイルが壊れていて、Resource Manager がクラッシュしたりエラーを出すと、ユーザには問題を発見する方法はありません。ユーザがこれに気付いて壊れた設定ファイルを削除することはほとんど期待できません。
このような理由で、Resource Manager で設定ファイルを開く前に、設定ファイルのリソースマップをチェックしてください。このためのコードが「Internet Config」の一部にパブリックドメインとして提供されています。IC Programmers Kit の ICResourceForkSanity.c というファイルを探してください。
設定ファイルが壊れたら、ユーザにその事実を警告しなければならず、簡単に元に戻せないような処理をすぐに行ってはいけません。他のアプリケーションが設定ファイルを開いており、一時的に壊れているように見えるだけという可能性もあります。その場合はファイルを消したくはないでしょう。アプリケーションから最良と思われる対処方法をユーザに提案することはかまいませんが、問題解決の最終決断はユーザが行えるようにしてください。
他のアプリケーションが設定ファイルを開いているわけではなく、本当に壊れてしまったのなら、デフォルトの設定か、バックアップされた設定のいずれかで実行を続けるべきです。アプリケーションを終了して設定ファイルを削除するよう強いることはユーザを失望させます。アプリケーションはデフォルトの設定で完全に使用できる可能性があり、ユーザは急いで簡単な仕事を片づけてしまいたいのかもしれません。そのような場合にユーザに即座に問題を解決することを強いることは得策ではありません。
良い例として、Internet Config は設定ファイルのリソースフォークのコピーを同じ設定ファイルのデータフォークに保存します。リソースフォークが壊れたら、リソースフォークを消し、データフォーク内のデータから、保存されている設定をコピーして、実行を続けます。これは複雑な方法で、設定ファイルのサイズも倍になります。ただ、普通はたいしたディスクスペースを消費するわけではありません。
自分のアプリケーションでもこの方法を試してみたいなら、Internet Config のコードはパブリックドメインなので、無料でアプリケーションに取り込むことができます。
別のアプリケーションと設定ファイルがコンフリクトを起こしたらどうしますか。
設定を保存したい場所にすでに他のファイルやフォルダがある場合は、この事実をユーザに警告しなければなりませんが、そのまま実行できるようにします。
可能であれば、設定ファイルを別の場所に保存してください。そうすれば、コンフリクトが一時的でない場合、とりあえずユーザはどちらのアプリケーション使うことができます。別の場所に保存できないと、正しい設定ファイルがないアプリケーションを使うことになります。
この問題を一番簡単に回避するには、固有のクリエータコード (アプリケーションのシグネチャ) で設定ファイルを探すようにすることです。そうすればユーザが設定ファイルの名前を変更してもアプリケーションには影響がありません。
設定ファイルを名前で探すことにした場合、名前の中に登録済みの文字列 ("Apple" など) を使うと、コンフリクトを起こす可能性を減らす助けになります。 |
Internet Config source