成员变量VS setArguments的片段

问题描述

我已经注意到，在对碎片（特别是DialogFragment)他们这样做，从我期待不同的两件事情：

I've noticed that in the Android reference for Fragments (notably DialogFragment) that they do a couple of things different from what I'd expect:

1）。使用公共静态FOO的newInstance（）方法，而不是一个构造函数。
2）。值传递使用setArguments而不是成员变量onCreateDialog。

1). Use public static foo newInstance() method rather than a constructor.
2). Pass values to onCreateDialog using setArguments rather than member variables.

我读过的newInstance出现使用反射时要preferrable。不过，我真的不明白为什么他们通过捆绑传递参数。我不得不虽然使用的成员变量会更安全（不使用字符串从地图上获取），希望有更小的开销。

I've read that newInstance appears to be preferrable when using reflection. However I really don't understand why they're passing parameters via a bundle. I'd have though using member variables would be safer (not using a string to fetch from a map) and would have less of an overhead.

有什么想法？

推荐答案

我也偶然发现了这一点，并发现了一些优势，使用的参数捆绑在实例字段

I've also stumbled upon this and found a few advantages to using the arguments Bundle over instance fields:

• 如果它在一个捆绑 Android系统知道它，可以创建和摧毁你的片段 （使用强制参/默认的构造和平常生命周期方法），而只是通过在参数重新捆绑。这样，没有参数迷失在低内存查杀小号preE或最终的方向改变（这常常打我的第一个发展中的较少旋转的仿真器后部署到真实设备）。

• If it's in a Bundle the Android system knows about it and can create and destroy your Fragment (using the mandatory parameterless/default constructor and usual lifecycle methods), and just pass in the arguments bundle again. This way no arguments get lost on a low memory killing spree or the eventual orientation changes (this often hits me on first deploy to a real device after development in the less-rotating emulator).

您可以只通过额外捆绑的活动的作为-是一个片段嵌在布局;例如我经常用这个当我有一个活动显示一个片段全屏，需要一定的ID（或的ContentProvider URI）知道该怎么显示/做。我有时甚至添加更多的东西到捆绑（或复印件）之前，我通过它，例如：

You can just pass the extras Bundle of an Activity as-is to a Fragment embedded in the layout; e.g. I often use this when I have an Activity that displays a Fragment "fullscreen" and needs some ID (or ContentProvider URI) to know what to display/do. I sometimes even add more stuff to a Bundle (or a copy) before I pass it on, e.g.

@Override
protected void onCreate(final Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);

  if (savedInstanceState == null) { // not a re-creation
    final Bundle args = new Bundle(getIntent().getExtras());
    args.putInt(CoverImageFragment.BACKGROUND_RESOURCE, android.R.color.black);
    final Fragment fragment = CoverImageFragment.newInstance(args);
    getSupportFragmentManager()
      .beginTransaction()
      .add(android.R.id.content, fragment)
      .commit();
  }
}

它使开发片段接近一个活动的，即<$的方式C $ C>捆绑为输入参数，没有例外。

It keeps the way of developing a Fragment close to that of an Activity, i.e. Bundle as "input parameters, no exceptions".

至于你提到的缺点：

• 我觉得开销是最小的，因为你很可能不会被查询捆绑在一个紧密的循环，因此让出曾经在你的论点的数据的onCreate（）， onViewCreate（）等并不坏。

• I think the overhead is minimal because you most likely won't be querying the Bundle in a tight loop, so getting your argument data out once in onCreate(), onViewCreate(), etc. isn't that bad.

有关类型安全，捆绑有各种不同的的getXXXX（）方法，甚至过载提供一个默认值，如果缺了点什么/可选：）

For type-safety, Bundle has all the different getXXXX() methods, and even overloads to provide a default value if a something is missing/optional :)

对于的newInstance（）的方法，我认为他们是一个简单的方法来封装新和 setArguments（）要求我的片段;我有时会提供额外的 MyFragment的newInstance（字符串singleIdOfWhatToDisplay）创建两个捆绑和片段一气呵成，并返回一个随时可以去片段实例。

As for the newInstance() methods, I think of them as an easy way to encapsulate the new and setArguments() calls for my Fragment; I sometimes provide an additional MyFragment newInstance(String singleIdOfWhatToDisplay) that creates both the Bundle and Fragment in one go and returns a ready-to-go Fragment instance.

这篇关于成员变量VS setArguments的片段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！