アプリケーションファイルの置き場


アプリケーションは/Applicationsディレクトリか、もしくは現在のユーザの~/Applicationsディレクトリへ配置するべきです。/Applicationディレクトリに配置されたアプリケーションは、システム上のすべてのユーザに対して利用可能です。ユーザのホームディレクトリに配置されたアプリケーションは、そのユーザにのみ利用可能となります。

アプリケーションが実行するために必要な、すべてのリソースやデータファイルは、アプリケーションバンドルの内部に属している必要があります。

けれども、アプリケーションはしばしば、テンプレート、プラグイン、その他の、インストールすべきか否かを含めて、ユーザがある程度のコントロールを持つ、アプリケーション拡張のための追加ファイルを伴います。同様に、アプリケーションはアプリケーションバンドルの中に属すべきではない、キャッシュファイルや一時ファイルを生じることがあります。

以降のセクションは、アプリケーションファイルのために適切な場所、不適切な場所のいくつかの例を含んでいます。特定のLibraryサブディレクトリの目的と、意図されている内容についての情報は、「Libraryディレクトリ」(17ページ)を参照してください。

補助ファイル

補助ファイルとは、アプリケーションを補助するけれども、アプリケーションの実行には必要とされない、あらゆる種類のファイルのことです。書類のテンプレートやサンプルファイルは、補助ファイルの簡単な例です。

ただし、あなたはカスタム設定や、あなたのアプリケーションの作業空間のためのプリセットデータファイルといった、よりアプリケーションに結びついた情報を記録することもできます。これらの例における情報は、(ユーザのデータと対比して)特定のアプリケーションに本質的に結び付けられていますが、アプリケーションの実行には必須ではありません。

ほとんどすべての補助ファイルに対して好まれる場所は、適切なドメインのApplication Supportディレクトリの中です。あなたの補助ファイルを記録するために、どのドメインを選ぶのかは、これらのリソースの意図している用途に応じて決まります。

もし、書類テンプレートのように、リソースがシステム上のすべてのユーザに適用されるのであれば、これらは/Library/Application Supportの中に置いてください。【→ローカルドメイン】

もし、作業空間設定ファイルのように、リソースがユーザ固有であれば、これらは現在のユーザの、~/Library/Application Supportディレクトリの中に置いてください。【→ユーザドメイン】

Application Supportディレクトリの内部で、あなたは常に補助ファイルを、あなたのアプリケーション名か会社名をとった独自のサブディレクトリの中に配置すべきです。通常、あなたはアプリケーション名を使用するべきですが、多数の同じリソースを共有する、複数の製品がある場合は、あなたの会社名を使用する必要性を感じることでしょう。この独自のサブディレクトリ内のリソースを、どのように構成するかは、完全にあなた次第となります。

たとえ補助ファイルがユーザ固有だとしても、あなたのアプリケーションは複数ユーザセッションからのアクセスが困難であってはいけません。ファストユーザスイッチとリモートログインのために、同一ユーザがコンピュータに複数回ログインすることがありえます。補助ファイルには、複数ユーザセッションの振る舞いに悪影響を及ぼすおそれのある、いかなるデータも含めるべきではありません。すべてのセッションは正確に同じ振る舞いを目にする必要があります。

プラグイン

プラグインは、アプリケーションの振る舞いを拡張したコードバンドルです。Mac OS Xは、コンテキストメニューや、インターネットの構成要素、その他の事柄を扱うための、いくつかの種類の専用プラグインに対応しています。

また、あなたはサードパーティの開発者にあなたのアプリケーションの振る舞いを拡張させるための、あなたのアプリケーション用のプラグイン インタフェースを定義することもできます。

Mac OS Xのプラグインは、一般的にローカルドメイン、システムドメインのいずれかの、Libraryディレクトリのサブディレクトリの中に属しています。これらのプラグインの、ユーザ固有版は、同様にユーザドメインの中に属することができます。標準的なLibraryのサブディレクトリの一覧については、「Libraryディレクトリ」(17ページ)を参照してください。

アプリケーションプラグインのために好まれる場所は、アプリケーションバンドルそのものの内部です。アプリケーションバンドルは、もともとの、そしてサードパーティ製のプラグインを記録するための、Pluginsディレクトリを含むことができます。ユーザはこのディレクトリに、Finderの「情報を見る」ウインドウを用いてプラグインを加えることができます。サードパーティのプラグイン開発者も、インストーラパッケージを使用して、自動的にプラグインをインストールすることができます。

もしあなたのアプリケーションが、プラグインの一式を別のアプリケーションと共有するのであれば、あなたはLibrary/Application Support内の、あなたの独自のサブディレクトリにもプラグインをインストールすることができます。

どこにプラグインを記録するか決定するときは、必ずライセンスの問題と、意図するユーザ体験に配慮してください。アプリケーションバンドルの中に記録されたプラグインは、常にアプリケーションと共に残ります。もしユーザがアプリケーションを別のボリュームにコピーすると、アプリケーションはインストールされたプラグインをすべて保持します。けれども、もしあなたがプラグインをLibrary/Application Supportサブディレクトリにインストールしていたら、これらのプラグインは特定のディスクパーティションから起動した、特定のユーザに限定されることでしょう。

一時ファイル

アプリケーションの多くは、一時的なデータを記録するために、一時ファイルを使用します。一時ファイルの生存期間は、その意図する用途に応じてさまざまです。

三次元画像の描画のような場合には、ファイルは作業データや計算を記録するために使用され、これらの計算の完了時にすぐに削除されるでしょう。

アプリケーションに関する実行時データは記録され、アプリケーションが終了したときにだけ削除されることがあります。また、ユーザがアプリケーションを次回起動するときまで生き続けることもあるでしょう。

たとえば、アプリケーションは一般的に、アプリケーションやシステムのクラッシュに備えた保険のような役目を果たす、書類の自動保存バージョンを記録するために、一時ファイルを使用します。

Mac OS Xは一時ファイルを記録するための、既定のディレクトリのセットを提供しています。

第一のディレクトリ(/tmp)は、最もローカルなファイルを置く場所ですが、あなたは決してこのパスを、あなたのアプリケーションにハードコーディングすべきではありません。ハードコーディングされたパスの使用は、あなたのコードの移植性と耐用性を制限します。代わりに、Carbonアプリケーションは(Core Service frameworkの)FSFindFolder関数を用いて、一時ディレクトリへの参照を取得すべきです。Cocoaアプリケーションは、Foundation KitのNSTemporaryDirectory関数を用いるべきです。

一時ファイルを保存するときは、確実にユニークな名前を使用してください。実行中のアプリケーションは、一般的に同じ一時ディレクトリを共有しています。 ファストユーザスイッチが有効な場合、同一アプリケーションのいくつかのインスタンスもこのディレクトリを共有することがあります。あなたのアプリケーションのそれぞれのインスタンスは、それぞれが作成したファイルを簡単に区別できるようにしておく必要があるでしょう。 あなたは、セッションIDとアプリケーション名を、あなたの一時ファイル名に直接結合させるか、あなたの一時ファイルを含むサブディレクトリを見分けるためにこの情報を利用することができます。セッションIDと、ファストユーザスイッチと共に行う安全な処理についての詳細は、Mac OS X Documenttionの、Multiple User Environmentsを参照してください。

キャッシュファイル

キャッシュファイルは、あなたのアプリケーションの性能を向上させるために一般的に用いられる、特殊な種類のファイルです。あなたは、高価な処理となることのあるデータを回収したり、作り直すような状況において、キャッシュファイルを使用することができます。たとえばウェブブラウザは、後の読み込み時間を短縮するために、内容に変更が無いと仮定して、以前訪れたウェブページをキャッシュします。

キャッシュファイルはほぼすべての場合において、~/Library/Cachesの独自のサブディレクトリに配置すべきです。独自のサブディレクトリの名前は、あなたのアプリケーションのバンドル識別子に一致させるべきでしょう。これらは一般的に、単一のユーザセッションに固有のものなので、あなたはあなたのキャッシュファイルや、その内容に、現在のユーザのセッションIDでタグ付けする必要もあります。これをどのように行うかについての詳細は、Mac OS X Documenttionの、Multiple User Environmentsを参照してください。

もし、アプリケーションのすべてのユーザに関連するキャッシュファイルがあれば、あなたはこれらをユーザドメイン(~/Library/Caches)の代わりに、ローカルドメイン(/Library/Caches)に記録することができます。

ユーザ空間を汚染してはいけません

ユーザドメイン(/Users)は、ユーザによって作成されたファイルのために意図されていることを忘れないことが大切です。

~/Libraryディレクトリを例外として、あなたのアプリケーションはユーザのホームディレクトリには決してファイルをインストールすべきではありません。特に、あなたはユーザのDocument【「書類」】ディレクトリや、/Users/Sharedディレクトリの中には決してファイルをインストールすべきではありません。

これらのディレクトリはユーザによってのみ変更される必要があります。

あなたのアプリケーションがクリップアートや、ユーザが普通に操作するであろうサンプルファイルを提供するとしても、あなたはこれらのファイルを、デフォルトではローカルドメインまたはユーザドメインのどちらかの、Library/Application Supportディレクトリに置くべきです。ユーザは必要であれば、このディレクトリからファイルを移動したりコピーすることができます。

もし、ユーザがこうしたファイルを見つけるかという点について心配であれば、あなたのアプリケーションのユーザインタフェースから、ユーザが直接これらを一覧したり、アクセスするための手段を搭載すべきでしょう。