片段交互回调:onAttach()vs setter

Question

我正在尝试实现一个漂亮的,可重用的片段,我很难选择设置交互回调的模式.我当然熟悉这些文档,但我对其中描述的方法有一些疑问.

假设我们有一个带回调接口的Fragment:

public class MyFragment extends Fragment {
    private Callbacks mCallbacks;
    public static interface Callbacks { /* ... */ }
}

到目前为止,我遇到了两种为Fragments设置回调的方法.

1.投射语境 onAttach()

Android开发指南中描述的方式.

@Override
public void onAttach(Context context) {
    super.onAttach(context);
    try {
        mCallbacks = (Callbacks) context;
    } catch (ClassCastException e) {
        throw new ClassCastException(context.toString() + " must implement Callbacks");
    }
}

优点:

• 写的代码不多
• mCallbacks 永远不会为空(只要片段还活着)

缺点:

• 如果我们在Activity中使用多个片段,会变得混乱
• 尝试使用同一Fragment类的多个实例时发生冲突
• 使用嵌套片段时的奇怪流程

一个二传手

简单的听众模式.

public void setCallbacks(Callbacks callbacks) {
    mCallbacks = callbacks;
}

优点

• 可以从任何地方设置和替换回调
• 可以使用匿名(或内部静态)回调类

缺点

• 在调用回调方法之前需要进行nullcheck
• 不会自动绑定Fragment娱乐(通过在Activity中设置回调轻松修复onAttachFragment)

我发现第一种方法不如第二种方法,因为它引入了不必要的限制并且在某种程度上违反了LoD,要求回调方法由Fragment所附加的Activity实现.它还通过强制将回调一直发送到Activity而不是仅发送到父Fragment来使与nest片段的交互变得复杂.然后,这是Android开发指南中建议的方法.我在这里错过了什么吗？

问题很简单,实现Fragment回调的最佳实践是什么？

Answer 1

我通常使用官方记录的方法。在极少数情况下，当它不太适合我的应用程序结构\复杂性时，我发现 EventBus 模型通常可以很好地工作。

https://github.com/greenrobot/EventBus