评论太长了,但我会在您的问题评论中继续我们的讨论。
你应该反其道而行之:接受 ID 是活动本地的事实,而不是片段的本地。
是的,片段和活动之间的耦合很差。大多数情况下,来自片段的回调将片段链接到一个活动(即使使用接口也不是那么干净),并且为了将参数从活动传递给片段:您必须使用静态工厂方法来构建片段并设置其参数通过 setArgs。
您的问题完全是关于这样一个耦合问题:活动的每个片段中的加载程序 ID 不应与所有其他片段使用的 ID 重叠。这也是一个耦合约束,因为我们对位于活动级别的片段有一个约束。你是对的,Android 可以通过在片段本地引入加载器来解决片段级别的问题。
然而,可能有一些优雅的方法来解决这个问题并保留一个相对的解耦方案。例如,您可以创建一个 ID 工厂,为片段内的加载程序生成“好”ID 并防止重叠(id++ 将是完美的):
public interface IdFactory {
public int createId();
}
然后在每个片段中,当你需要一个加载器时:
this.newLoaderId = idFactory.createId();
工厂可以使用以下三种策略之一由所有片段共享:
单身人士。每个片段将通过以下方式访问 IdFactory
IdFactory idFactory = DefaultIdFactory.getInstance();
创建一个实现 IdFactory 的类的单个实例,将该类的该实例作为应用程序类中的数据字段,并为其提供一个 getter。每个片段都可以使用
IdFactory idFactory = ((MyApplication)getActivity().getApplicationContext() ).getIdFactory();
在活动级别创建您的工厂。活动可以实现 IdFactory 接口,或者它们可以提供一个内部类来实现它。然后每个片段将使用以下命令访问工厂:
IdFactory idFactory = getActivity().getIdFactory(); //或IdFactory idFactory = (IdFactory)getActivity();
第三种选择更好,因为它将遵循您的确切需求并遵循活动生命周期,允许您的工厂被垃圾收集。
还有其他选项,例如使用 RoboGuice 或 Dagger 或任何其他依赖注入框架,但这不是标准的。