在 Fragment 中覆盖 setArguments()答案

【问题标题】：Overriding setArguments() in Fragment在 Fragment 中覆盖 setArguments()
【发布时间】：2016-09-14 09:30:57
【问题描述】：

我知道将参数传递给 Fragments 的推荐方法是使用静态方法并创建一个包并在 Fragment 上调用 setArguments()/getArguments()：

public static MyFragment newInstance(int arg1, int arg2) {
    Bundle b = new Bundle();
    b.putInt("key1", arg1);
    b.putInt("key2", arg2);
    MyFragment frag = new MyFragment();
    frag.setArguments(b);
}

public View onCreateView(....) {
    Bundle b = getArguments();
    memberVar1 = b.getInt("key1");
    memberVar2 = b.getInt("key2");
    .....
}

如果我错了，请纠正我，但似乎以下方法也有效，不需要稍后调用 getArguments()：

@Override
public void setArguments(Bundle args) {
    memberVar1 = args.getInt("key1");
    memberVar2 = args.getInt("key2");
}

这是基于在 Fragment 类中实现 setArguments() 的方式。如果这允许在 Fragment 重新创建时访问 mArguments，那么不应该同样适用于 setArguments() 调用中设置的其他变量吗？

659     public void setArguments(Bundle args) {
660         if (mIndex >= 0) {
661             throw new IllegalStateException("Fragment already active");
662         }
663         mArguments = args;
664     }

除了惯例之外，这两种情况是否比另一种有优势？

【问题讨论】：

标签： android android-fragments

【解决方案1】：

您不应该有理由必须重写 setArguments(...) 方法...这是您可以采取的一种可能的方法来“清理”传递的参数。

创建一个新类，例如MyFragmentArguments.java。

public class MyFragmentArguments {
public long keyOne;
public long keyTwo;

public MyFragmentArguments(long keyOne, long keyTwo) {
    this.keyOne = keyOne;
    this.keyTwo = keyTwo;
}

public MyFragmentArguments(Bundle bundle) {
    this.keyOne = bundle.getLong("KEY_ONE");
    this.keyTwo = bundle.getLong("KEY_TWO");
}

public Bundle toBundle() {
    Bundle args = new Bundle();
    args.putLong("KEY_ONE", keyOne);
    args.putLong("KEY_TWO", keyTwo);

    return args;
}

}

然后，您可以（非常干净地）调用：

final MyFragmentArguments arguments = new MyFragmentArguments (getArguments());

if(arguments != null) { 
    // do something with arguments.keyOne & arguments.keyTwo
}

通过这种方式，您可以避免覆盖 android 操作系统中内置的某些内容的意外副作用 - 无论何时您都应该强烈质疑这一点。

【讨论】：

我的问题不是关于清洁，而是关于后果。我想知道是否有人知道覆盖该方法的意外副作用，我知道这可能是一个难以回答的问题。
只要您确保遵循方法setArguments 的初衷，就不会产生任何后果。我想要表达的真正观点是，你不应该重写它来实现你想要做的事情。此外，以您提议的方式覆盖 setArguments 确实违反了 SOLID 原则 - 更改 setArguments 的调用者可能会导致需要更改基本方法，这可能会导致意外后果的连锁反应。

【解决方案2】：

一旦调用 setArguments 的超级实现，就可以保持模式的完整性。

【讨论】：