Почему ViewModel создается через Provider?

Почему ViewModel создается через Provider?

Краткий ответ: ViewModel создается через Provider (а точнее, через ViewModelProvider) для обеспечения правильного жизненного цикла, контекстной привязки и сохранения состояния при изменениях конфигурации (например, повороте экрана). Это ключевой механизм архитектурного компонента ViewModel, который отделяет данные UI от жизненного цикла Activity/Fragment.

Детальное объяснение

1. Отделение логики от жизненного цикла UI

Основная цель ViewModel — хранить и управлять данными, связанными с UI, таким образом, чтобы они переживали изменения конфигурации (например, поворот экрана). Если бы ViewModel создавалась напрямую в Activity/Fragment (через new ViewModel()), она была бы уничтожена вместе с ними при повороте. ViewModelProvider решает эту проблему, предоставляя механизм хранения ViewModel вне жизненного цикла UI-компонентов.

// Неправильно: ViewModel будет уничтожена при повороте
class MyActivity : AppCompatActivity() {
    private val viewModel = MyViewModel() // Прямое создание
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
    }
}

// Правильно: ViewModel переживает поворот
class MyActivity : AppCompatActivity() {
    private val viewModel: MyViewModel by viewModels() // Использование ViewModelProvider
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
    }
}

2. Механизм работы ViewModelProvider

ViewModelProvider действует как фабрика и хранилище ViewModel. Он использует ViewModelStore (хранилище ViewModel), привязанное к конкретному контексту (Activity или Fragment):

• Для Activity: ViewModelStore привязан к Activity, поэтому все ViewModel, созданные для этой Activity, будут существовать до ее окончательного уничтожения (не при повороте).
• Для Fragment: ViewModelStore привязан к Fragment, но также может быть привязан к родительской Activity для разделения данных между Fragment.

// Пример внутренней логики ViewModelProvider (упрощенно)
class ViewModelProvider(
    private val store: ViewModelStore,
    private val factory: Factory
) {
    fun <T : ViewModel> get(modelClass: Class<T>): T {
        val key = "androidx.lifecycle.ViewModelProvider.DefaultKey:" + modelClass.canonicalName
        var viewModel = store.get(key)
        
        if (modelClass.isInstance(viewModel)) {
            return viewModel as T
        } else {
            viewModel = factory.create(modelClass)
            store.put(key, viewModel)
            return viewModel as T
        }
    }
}

3. Сохранение состояния при повороте экрана

Когда происходит изменение конфигурации:

• Activity уничтожается и создается заново
• ViewModelStore сохраняется системой через onRetainNonConfigurationInstance() (в старых API) или через ViewModelStoreOwner в новых
• ViewModelProvider при создании новой Activity извлекает существующие ViewModel из сохраненного хранилища

4. Внедрение зависимостей и кастомные Factory

ViewModelProvider поддерживает фабрики для создания ViewModel с параметрами:

class MyViewModelFactory(private val repository: Repository) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        if (modelClass.isAssignableFrom(MyViewModel::class.java)) {
            return MyViewModel(repository) as T
        }
        throw IllegalArgumentException("Unknown ViewModel class")
    }
}

// Использование с фабрикой
class MyActivity : AppCompatActivity() {
    private val viewModel: MyViewModel by viewModels {
        MyViewModelFactory(Injection.provideRepository())
    }
}

5. Преимущества использования ViewModelProvider

1. Согласованность жизненного цикла: ViewModel живет столько, сколько нужно соответствующему UI-компоненту
2. Избегание утечек памяти: ViewModel не держит ссылки на View, Activity или Fragment
3. Разделение данных между Fragment: ViewModel, привязанная к Activity, может использоваться несколькими Fragment
4. Тестируемость: ViewModel легко тестируется без зависимостей от Android-компонентов
5. Стандартизация: Единый подход для всей команды

Практическое использование

В современных приложениях используются расширения KTX:

// Для Activity
private val viewModel: MyViewModel by viewModels()

// Для Fragment
private val viewModel: MyViewModel by viewModels()

// ViewModel, общая для нескольких Fragment (привязанная к Activity)
private val sharedViewModel: SharedViewModel by activityViewModels()

Архитектурное значение

Использование ViewModelProvider является частью рекомендованной Google архитектуры Android-приложений:

• UI-контроллеры (Activity/Fragment) отвечают только за отображение данных и обработку пользовательского ввода
• ViewModel хранит данные UI и обрабатывает логику презентации
• Repository управляет источниками данных

Этот подход обеспечивает следование принципу единой ответственности, упрощает тестирование и повышает стабильность приложения.

Заключение

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