Переменные-члены против setArguments во фрагментах

Я также наткнулся на это и обнаружил несколько преимуществ использования аргументов Bundle над полями экземпляра:

• Если он находится в Bundle, система Android знает об этом и может создать и уничтожить ваш Fragment (используя обязательный конструктор без параметров/по умолчанию и обычные методы жизненного цикла) и просто снова передать пакет аргументов. Таким образом, никакие аргументы не теряются из-за нехватки памяти или возможного изменения ориентации (это часто поражает меня при первом развертывании на реальном устройстве после разработки в эмуляторе с меньшей ротацией).

• Вы можете просто передать дополнительные функции Bundle из Activity как есть в Fragment, встроенные в макет; например Я часто использую это, когда у меня есть Activity, который отображает Fragment «полноэкранный режим» и нуждается в каком-то идентификаторе (или ContentProvider URI), чтобы знать, что отображать/делать. Иногда я даже добавляю еще что-то в Bundle (или копию), прежде чем передать его, например.

  @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();
    }
  }
  

• Он поддерживает способ разработки Fragment, близкий к Activity, то есть Bundle как «входные параметры, без исключений».

Что касается недостатков, о которых вы упомянули:

• Я думаю, что накладные расходы минимальны, потому что вы, скорее всего, не будете запрашивать Bundle в тесном цикле, поэтому получение данных аргумента один раз в onCreate(), onViewCreate() и т. д. не так уж плохо.

• Для безопасности типов Bundle имеет все различные методы getXXXX() и даже перегружается, чтобы предоставить значение по умолчанию, если что-то отсутствует/необязательно :)

Что касается методов newInstance(), я думаю о них как о простом способе инкапсулировать вызовы new и setArguments() для моего Fragment; Иногда я предоставляю дополнительный MyFragment newInstance(String singleIdOfWhatToDisplay), который создает Bundle и Fragment за один раз и возвращает готовый к работе экземпляр Fragment.

Я обнаружил, что это ОЧЕНЬ запутанная проблема (одна из многих, которые засоряют ландшафт Android).

setArguments() — это обходной путь для очень бесполезной потребности Android иметь конструктор без параметров, доступный для фрагментов.

Мое замешательство пришло волнами. Во-первых, методы, которые вы естественным образом переопределяете в своем Fragment (например, onCreate, onCreateView), получают параметр Bundle, который представляет savedInstanceState вашего Fragment. Это состояние экземпляра, по-видимому, не имеет НИЧЕГО общего со значениями, которые вы сохраняете через setArguments() и извлекаете через getArguments(). Оба используют Bundle, оба Bundles, скорее всего, будут доступны в рамках одного и того же переопределенного метода, и ни один из них не имеет ничего общего друг с другом.

Во-вторых, непонятно, как Android использует setArguments(). Android вызывает ваш конструктор без параметров для перестроения вашего Fragment при повороте, но, по-видимому, ТАКЖЕ вызовет тот метод setArguments(), который последний раз вызывался при создании Fragment.

Хм????

Удивительно, но правда. Все это создание Bundles с setArguments() безумием существует, чтобы компенсировать потребность в конструкторе Fragment без параметров.

Короче говоря, я использую статический метод newInstance для создания своего Fragment.

public MyFragment() {
    //satisfy Android
}

public static MyFragment newInstance(long record_id) {
    Log.d("MyFragment", "Putting " + record_id + " into newInstance");
    MyFragment f = new MyFragment();
    Bundle args = new Bundle();
    args.putLong("record_id", record_id);
    f.setArguments(args);
    return f;
}

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    /**
     * Perform an immediate check of arguments,
     * which ARE NOT the same as the bundle used
     * for saved instance state.
     */
    Bundle args = getArguments();
    if(args != null) {
        record_id = args.getLong("record_id");
        Log.d("MyFragment", "found record_id of " + String.valueOf(record_id));
    }
    if(savedInstanceState != null) {
        //now do something with savedInstanceState
    }
}

Я довольно новичок в программировании для Android, но это мое текущее понимание проблемы:

Конструктор фрагментов не может иметь никаких параметров. Когда ваша деятельность приостановлена, ваш фрагмент может быть выпущен. Прежде чем ваша активность будет возобновлена, система создаст новую версию вашего Фрагмента, вызвав конструктор. Если используется конструктор не по умолчанию, как Android должен знать, какие типы и значения используются для аргументов вашего конструктора Fragments?

Я не верю, что этот пакет выпущен. Пакет хранится именно так, чтобы его можно было передать обратно в ваш фрагмент после его воссоздания с помощью конструктора по умолчанию.

Филипп Райхарт ускользнул от этого в своем посте (на самом деле более чем ускользнул).

Так же хочу добавить еще один недостаток аргументов в том, что приходится динамически создавать фрагменты. Поскольку аргументы не очень хорошо работают, если вы создаете из xml. И я действительно ненавижу это.