我正在尝试实现一个不错的、可重复使用的 Fragment,但我很难选择设置交互回调的模式。我当然熟悉the docs ,但我对其中描述的方法有一些疑问。
假设我们有一个带有回调接口(interface)的 Fragment:
public class MyFragment extends Fragment {
private Callbacks mCallbacks;
public static interface Callbacks { /* ... */ }
}
到目前为止,我遇到了两种为 Fragment 设置回调的方法。
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
永远不会为 null(只要 Fragment 还活着)
缺点:
- 如果我们在 Activity 中使用多个 Fragment 会变得困惑
- 尝试使用同一 Fragment 类的多个实例时发生冲突
- 使用嵌套 fragment 时的奇怪流程
2。二传手
简单的监听器模式。
public void setCallbacks(Callbacks callbacks) {
mCallbacks = callbacks;
}
优点
- 可以从任何地方设置和替换回调
- 可以使用匿名(或内部静态)回调类
缺点
- 在调用回调方法之前需要空值检查
- 不会自动绑定(bind) Fragment 重新创建(通过在 Activity 的
onAttachFragment
中设置回调很容易修复)
我发现第一种方法不如第二种方法,因为它引入了不必要的限制并且在某种程度上违反了 LoD,因为它要求回调方法由 Fragment 附加到的 Activity 实现。它还强制将回调一直发送到 Activity 而不是仅发送到父 Fragment,从而使与嵌套 fragment 的交互变得复杂。再一次,这是 Android 开发指南中建议的方法。我在这里遗漏了什么吗?
长话短说,实现 Fragment 回调的最佳实践是什么?
最佳答案
我通常使用官方记录的方法。在极少数情况下,当它不太适合我的应用程序结构\复杂性时,我发现 EventBus 模型通常工作得很好。
关于java - fragment 交互回调 : onAttach() vs setter,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44586899/