コメントが長すぎますが、質問のコメント内で議論を続けます。
逆に考える必要があります。ID はフラグメントではなく、アクティビティに対してローカルであるという事実を受け入れてください。
はい、フラグメントとアクティビティの結合が不十分です。ほとんどの場合、フラグメントからのコールバックはフラグメントをアクティビティにリンクし (インターフェイスを使用する場合でも、それほどクリーンではありません)、アクティビティからフラグメントに引数を渡すには、静的ファクトリ メソッドを使用して、フラグメントを構築し、その引数を設定する必要があります。 setArgs 経由。
そして、あなたの質問はすべて、そのような結合の問題に関するものです。アクティビティの各フラグメントのローダー ID は、他のすべてのフラグメントで使用される ID と重複してはなりません。アクティビティレベルにあるフラグメントの制約があるため、これも結合制約です。そうです、フラグメントにローカルなローダーを導入することで、Android によってフラグメント レベルで解決された可能性があります。
それにもかかわらず、それを解決し、相対的な分離スキームを維持するエレガントな方法があるかもしれません。たとえば、フラグメント内のローダーに「適切な」ID を生成し、重複を防ぐ ID のファクトリを作成できます (id++ が最適です)。
public interface IdFactory {
public int createId();
}
次に、各フラグメント内で、ローダーが必要な場合:
this.newLoaderId = idFactory.createId();
ファクトリは、次の 3 つの戦略のいずれかを使用して、すべてのフラグメントで共有できます。
シングルトン。各フラグメントは IdFactory にアクセスします
IdFactory idFactory = DefaultIdFactory.getInstance();
IdFactory を実装するクラスのインスタンスを 1 つ作成し、そのクラスのインスタンスをアプリケーション クラスのデータ フィールドにして、getter を指定します。各フラグメントは、次を使用してアクセスできます
IdFactory idFactory = ((MyApplication)getActivity().getApplicationContext() ).getIdFactory();
アクティビティ レベルで工場を作成します。アクティビティは IdFactory インターフェースを実装するか、それを行う内部クラスを提供できます。各フラグメントは、以下を使用してファクトリにアクセスします。
IdFactory idFactory = getActivity().getIdFactory(); //または IdFactory idFactory = (IdFactory)getActivity();
3 番目のオプションは、正確なニーズに従い、アクティビティのライフ サイクルに従うため、ファクトリのガベージ コレクションを可能にするため、優れています。
RoboGuice や Dagger などの依存性注入フレームワークを使用するなど、他のオプションもありますが、それはあまり標準的ではありません。