Чому я хочу уникати конструкторів за замовчуванням у фрагментах?

Я створюю додаток за допомогою Fragmentsі в одному з них я створив конструктор, який не використовується за замовчуванням, і отримав це попередження:

Avoid non-default constructors in fragments: use a default constructor plus Fragment#setArguments(Bundle) instead

Може хтось скаже мені, чому це не гарна ідея?

Чи можете ви також підказати, як я це досяг:

public static class MenuFragment extends ListFragment {
    public ListView listView1;
    Categories category;

    //this is my "non-default" constructor
    public MenuFragment(Categories category){
        this.category = category;
    }....

Без використання конструктора за замовчуванням?

Складіть об’єкт групи та вставте свої дані (у цьому прикладі ваш Categoryоб’єкт). Будьте обережні, ви не можете передавати цей об'єкт безпосередньо в пакет, якщо тільки це не можна серіалізувати. Я думаю, що краще зібрати свій об’єкт на фрагменті, а в комплект вкласти лише ідентифікатор чи щось інше. Це код для створення та додавання пакета:

Bundle args = new Bundle();
args.putLong("key", value);
yourFragment.setArguments(args);

Після цього у своєму фрагменті отримайте доступ до даних:

Type value = getArguments().getType("key");

Це все.

Схоже, жодна з відповідей насправді не відповідає "чому використовувати пакет для передачі параметрів, а не конструктори за замовчуванням"

Причина, чому вам слід передавати параметри через пакет, полягає в тому, що коли система відновить fragment(наприклад, при зміні конфігурації), вона автоматично відновить ваш bundle.

Зворотні виклики люблять onCreateабо onCreateViewповинні читати параметри з bundle- таким чином ви гарантовано відновите стан fragmentправильно до того самого стану, з яким fragmentбуло ініціалізовано (зауважте, що цей стан може відрізнятися від того, onSaveInstanceState bundleщо передається в onCreate/onCreateView)

Рекомендація щодо використання статичного newInstance()методу - лише рекомендація. Ви можете використовувати конструктор, що не використовується за замовчуванням, але переконайтеся, що ви заповнюєте параметри ініціалізації bundleвсередині тіла цього конструктора. І прочитайте ці параметри в методах onCreate()або onCreateView()методах.

У вас Fragmentне повинно бути конструкторів через те, як це FragmentManagerстворюється. Ви повинні мати newInstance()статичний метод, визначений необхідними параметрами, а потім зв’язати їх і встановити як аргументи фрагмента, до якого ви згодом можете отримати доступ із Bundleпараметром.

Наприклад:

public static MyFragment newInstance(int title, String message) {
    MyFragment fragment = new MyFragment();
    Bundle bundle = new Bundle(2);
    bundle.putInt(EXTRA_TITLE, title);
    bundle.putString(EXTRA_MESSAGE, message);
    fragment.setArguments(bundle);
    return fragment ;
}

І прочитайте ці аргументи на onCreate:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    title = getArguments().getInt(EXTRA_TITLE);
    message = getArguments().getString(EXTRA_MESSAGE);

    //...
}

Таким чином, якщо їх від'єднати і повторно приєднати, стан об'єкта може зберігатися через аргументи, як і bundlesприєднаний до Intents.

Якщо ви використовуєте параметр для якогось класу. спробуйте це

SomeClass mSomeInstance;
public static final MyFragment newInstance(SomeClass someInstance){
    MyFragment f = new MyFragment();
    f.mSomeInstance = someInstance;
    return f;
}

Я думаю, немає різниці між статичним конструктором та двома конструкторами (порожній і параметризований, який зберігає аргументи в пакет аргументів фрагмента), швидше за все, це правило створено для зменшення ймовірності забути застосувати конструктор no-arg в Java , що неявно генерується при наявності перевантаження.

У своїх проектах я використовую Kotlin і реалізую фрагменти з первинним конструктором no-arg та вторинним конструктором для аргументів, який просто зберігає їх у пакет і встановлює як аргументи Fragment, все працює добре.

Якщо фрагмент використовує конструктори за замовчуванням після зміни конфігурації, фрагмент втратить усі дані.