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

Вопрос о гарантии вызова кастомного конструктора фрагмента

Короткий ответ: Нет, при изменении конфигурации нет гарантии, что будет вызван кастомный конструктор фрагмента.

Это фундаментальное ограничение архитектуры Android, и понимание причин критически важно для правильной работы с фрагментами.

Почему кастомный конструктор не вызывается?

Система Android воссоздает фрагменты при изменении конфигурации (поворот экрана, изменение языка и т.д.) с помощью стандартного конструктора без параметров. Это происходит потому, что:

1. Фреймворк не знает параметров вашего кастомного конструктора - он не может "угадать", какие аргументы нужно передать
2. Восстановление состояния происходит через Bundle - система использует механизм savedInstanceState
3. Архитектурное ограничение - фреймворк требует наличия публичного конструктора без параметров

Что происходит вместо этого?

// Пример проблемного фрагмента с кастомным конструктором
class MyFragment(private val userId: String) : Fragment() {
    // Проблема: при повороте система попытается создать фрагмент через MyFragment()
    // Такого конструктора нет - будет исключение!
}

// Правильный подход с фабричным методом
class MyFragment : Fragment() {
    private var userId: String? = null
    
    companion object {
        private const val ARG_USER_ID = "user_id"
        
        fun newInstance(userId: String): MyFragment {
            val fragment = MyFragment()
            val args = Bundle().apply {
                putString(ARG_USER_ID, userId)
            }
            fragment.arguments = args
            return fragment
        }
    }
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Восстанавливаем данные из аргументов
        userId = arguments?.getString(ARG_USER_ID)
    }
}

Рекомендуемые подходы

Для передачи данных во фрагмент используйте следующие паттерны:

1. Фабричные методы (newInstance) - наиболее распространенный подход

2. Аргументы через Bundle - единственный надежный способ сохранить данные:

   // Создание фрагмента с аргументами
   val fragment = MyFragment().apply {
       arguments = bundleOf("key" to value)
   }
   

3. ViewModel с SavedStateHandle (рекомендуется для Android Jetpack):

   class MyViewModel(savedStateHandle: SavedStateHandle) : ViewModel() {
       private val userId: String = savedStateHandle["user_id"] ?: ""
       
       // Данные автоматически сохраняются при изменении конфигурации
   }
   

4. Использование onAttach() или onCreate() для получения контекста/активности

Что гарантированно вызывается?

При изменении конфигурации система гарантированно вызывает:

• Конструктор без параметров (его обязательно нужно объявить)
• onCreate(Bundle?) - с восстановленным savedInstanceState
• onCreateView() - для восстановления UI
• onViewCreated() - после создания представления

Исключение и его причина

Если вы объявили только кастомный конструктор без конструктора по умолчанию:

class MyFragment(private val data: String) : Fragment() {
    // ОШИБКА: При повороте система упадет с InstantiationException
}

Вы получите исключение:

android.app.Fragment$InstantiationException: 
Unable to instantiate fragment: make sure class name exists, 
is public, and has an empty constructor

Выводы

• Никогда не полагайтесь на кастомные конструкторы для передачи данных во фрагмент
• Всегда предоставляйте публичный конструктор без параметров
• Используйте Bundle (аргументы) для передачи начальных данных
• Для данных, связанных с UI, используйте ViewModel - это современный рекомендованный подход
• Система восстанавливает только то, что помещено в Bundle в onSaveInstanceState()

Правильная работа с жизненным циклом фрагментов — основа стабильности Android-приложений. Современные подходы с ViewModel и SavedStateHandle значительно упрощают обработку изменений конфигурации, избавляя от многих рутинных операций с Bundle.