片段交互回调：onAttach（）vs setter

Question

我试图实现一个漂亮的，可重复使用的片段，并且我很难选择设置交互回调的模式。我当然熟悉the docs，但我对其中描述的方法有一些疑问。

我们假设我们有一个带回调接口的片段：

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永远不会为空（只要片段还活着）

缺点：

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

2。一个二传手

简单的侦听模式。

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

赞成

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

缺点

• 在调用回调方法之前需要进行nullcheck
• 不会自动绑定片段娱乐（通过在活动onAttachFragment中设置回调轻松修复）

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

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

Answer 1

我通常使用官方记录的方法。在极少数情况下，它与我的app结构\复杂性不太匹配，我发现EventBus模型通常可以很好地工作。

https://github.com/greenrobot/EventBus