Почему не рекомендуется использовать не дефолтный конструктор фрагмента?

Почему не рекомендуется использовать не-дефолтный конструктор во Fragment?

Основная причина заключается в механизме восстановления состояния (state restoration) в Android. Когда система уничтожает и воссоздает фрагмент (например, при повороте экрана или из-за нехватки памяти), она использует дефолтный конструктор (конструктор без аргументов) для повторного создания экземпляра. Если вы определили собственный конструктор с параметрами, система не сможет его вызвать — это приведёт к исключению InstantiationException.

Ключевые проблемы не-дефолтных конструкторов:

1. Нарушение жизненного цикла восстановления
   Система Android сохраняет состояние фрагмента в Bundle (через onSaveInstanceState()), но не сохраняет параметры конструктора. При воссоздании фрагмент будет создан "пустым", что может вызвать NullPointerException или некорректное поведение.

2. Антипаттерн для передачи данных
   Использование конструктора для передачи аргументов противоречит рекомендованной архитектуре фрагментов. Вместо этого следует использовать фабричные методы и аргументы (arguments).

Рекомендуемый подход: фабричный метод + Bundle

class DetailFragment : Fragment() {
    private val itemId: Long by lazy { 
        arguments?.getLong(ARG_ITEM_ID) ?: -1L 
    }

    companion object {
        private const val ARG_ITEM_ID = "item_id"

        // Фабричный метод для создания фрагмента с аргументами
        fun newInstance(itemId: Long): DetailFragment {
            return DetailFragment().apply {
                arguments = Bundle().apply {
                    putLong(ARG_ITEM_ID, itemId)
                }
            }
        }
    }
}

Преимущества этого подхода:

• Совместимость с системным восстановлением: Аргументы автоматически сохраняются и восстанавливаются системой через Bundle.
• Единый интерфейс создания: Чёткий метод newInstance() документирует обязательные параметры.
• Безопасность типов: Компилятор проверяет типы параметров при вызове фабричного метода.
• Гибкость: Можно добавлять новые параметры без изменения сигнатуры конструктора.

Альтернатива: ViewModel + SavedStateHandle

В современных приложениях с архитектурными компонентами рекомендуется использовать ViewModel вместе с SavedStateHandle, который переживает пересоздание фрагмента:

class DetailViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
    private val itemId: Long = savedStateHandle.get("item_id") ?: -1L
    
    fun setItemId(id: Long) {
        savedStateHandle.set("item_id", id)
    }
}

// Во фрагменте
private val viewModel: DetailViewModel by viewModels()

Исключения и особые случая

1. Dependency Injection (Dagger, Hilt)
   Для инъекции зависимостей через конструктор фрагмента можно использовать специальные подходы:

   // С Hilt
   @AndroidEntryPoint
   class InjectedFragment @Inject constructor(
       private val repository: DataRepository
   ) : Fragment()
   

   Но даже в этом случае фреймворк берет на себя управление жизненным циклом и обеспечивает корректное восстановление.

2. Безпараметрические зависимости
   Если зависимость не требует параметров и может быть пересоздана, иногда используют кастомные конструкторы, но это усложняет тестирование и восстановление состояния.

Вывод

Использование не-дефолтного конструктора нарушает контракт жизненного цикла фрагмента и создаёт хрупкие зависимости. Рекомендуемая практика — передача данных через аргументы Bundle или использование ViewModel с архитектурными компонентами. Это обеспечивает предсказуемое поведение при конфигурационных изменениях и корректное восстановление состояния, что критически важно для пользовательского опыта в Android-приложениях.