Что такое стратегии в Moxy?

Что такое стратегии в Moxy?

В библиотеке Moxy (ныне известной как Moxy 2.x или Moxy Legacy) стратегии — это один из ключевых механизмов, определяющих логику обновления View в паттерне Model-View-Presenter (MVP). Они отвечают за то, когда и как изменения состояния Presenter передаются во View, особенно в контексте жизненного цикла Android (например, поворот экрана, переход между фрагментами). Стратегии позволяют гибко управлять поведением привязки View и Presenter, решая проблемы вроде утечек памяти, избыточных обновлений или потери данных.

Основная проблема, которую решают стратегии

В классическом MVP без Moxy Presenter часто напрямую вызывает методы View. При изменении конфигурации (например, повороте) View уничтожается и создаётся заново, но Presenter может сохраняться. Это приводит к ошибкам: Presenter держит ссылку на "старую" уничтоженную View (утечка памяти) или новые данные не отображаются, так как View не привязана. Moxy решает это через стратегии обновления View, которые контролируют, когда View получает обновления от Presenter.

Как работают стратегии в Moxy?

Moxy использует аннотации @StateStrategyType на методах Presenter, которые изменяют состояние View. Эти аннотации указывают, какая стратегия применяется для каждого метода. При вызове такого метода Moxy не обновляет View напрямую, а ставит команду на обновление в очередь, которая выполняется согласно выбранной стратегии. Вот основные встроенные стратегии:

1. AddToEndSingleStrategy (по умолчанию) — добавляет команду в конец очереди, но если такая же команда уже есть, она заменяется последней. Полезна для обновлений, где важно только конечное состояние (например, отображение прогресса загрузки).

   @StateStrategyType(AddToEndSingleStrategy::class)
   fun showProgress(visible: Boolean)
   

2. SkipStrategy — игнорирует все вызовы метода, кроме первого. Используется для одноразовых действий, например, показ тоста.

   @StateStrategyType(SkipStrategy::class)
   fun showError(message: String)
   

3. AddToEndStrategy — добавляет каждую команду в конец очереди, даже если они одинаковые. Подходит для последовательных обновлений, например, добавление элементов в список.

   @StateStrategyType(AddToEndStrategy::class)
   fun addItem(item: String)
   

4. OneExecutionStrategy — команда выполняется один раз и сразу удаляется из очереди. Если View пересоздаётся, команда не повторяется.

   @StateStrategyType(OneExecutionStrategy::class)
   fun navigateToNextScreen()
   

Пример использования стратегий

Допустим, у нас есть Presenter, который управляет загрузкой данных:

class UserPresenter : MvpPresenter<UserView>() {
    @StateStrategyType(AddToEndSingleStrategy::class)
    fun showLoading(show: Boolean) {
        viewState.showLoading(show)
    }

    @StateStrategyType(AddToEndStrategy::class)
    fun addUsers(users: List<User>) {
        viewState.addUsers(users)
    }

    @StateStrategyType(SkipStrategy::class)
    fun showToast(message: String) {
        viewState.showToast(message)
    }
}

Здесь:

• showLoading использует AddToEndSingleStrategy, чтобы избежать множественных вызовов показа/скрытия прогресса.
• addUsers применяет AddToEndStrategy, так как каждый вызов добавляет новые данные.
• showToast использует SkipStrategy, чтобы тосты не накапливались при повороте экрана.

Почему стратегии важны?

• Управление жизненным циклом: Стратегии гарантируют, что View получит актуальные данные после пересоздания (например, после поворота). Moxy автоматически перепривязывает Presenter к новой View и применяет накопленные команды.
• Предотвращение утечек: Presenter не держит жёсткую ссылку на View, а взаимодействует через прокси-объект viewState, который управляется стратегиями.
• Гибкость: Можно комбинировать стратегии для разных методов, оптимизируя поведение под конкретные сценарии.
• Тестируемость: Стратегии изолируют логику обновления View, упрощая unit-тесты Presenter.

Заключение

Стратегии в Moxy — это мощный инструмент для декларативного управления обновлениями View в MVP. Они абстрагируют сложности жизненного цикла Android, позволяя разработчику сосредоточиться на бизнес-логике, а библиотеке — корректно обрабатывать пересоздание View. Без стратегий пришлось бы вручную управлять состоянием, что увеличило бы риск ошибок. В Moxy 2.x стратегии остаются центральным элементом, хотя в более новых подходах (например, с использованием Jetpack Compose или ViewModel) их роль может меняться.