Тренды

Топ-10 типичных ошибок при реализации паттерна MVVM в Android

24.03.2025

Паттерн Model-View-ViewModel (MVVM) является неотъемлемой частью Android-разработки, обеспечивая четкое разделение задач и способствуя поддержке кода. Однако распространенные ошибки могут привести к раздутым, неуправляемым или глючным реализациям. В этой статье рассмотрим 10 самых распространенных ошибок MVVM, а также выясним их причины и разберем способы исправления на практических примерах.

1. Перегрузка ViewModel

Ошибка

Разработчики часто рассматривают ViewModel как единое целое для бизнес-логики, UI-логики и обработки данных, что приводит к появлению раздутых и сложных классов.

Некорректный пример

class MyViewModel : ViewModel() {
    fun fetchData() {
        // Сложная бизнес-логика
        val result = performComplexCalculation()
        // Получение данных из API
        val data = api.getData()
        // Непосредственное обновление UI
        textView.text = data.toString()
    }
}

Почему это некорректно

В этом примере ViewModel отвечает за бизнес-логику, получение данных и даже обновление UI. Это нарушает принцип единственной ответственности, делая ViewModel сложной для тестирования, поддержки и расширения. Кроме того, прямое взаимодействие с UI из ViewModel нарушает принцип разделения задач, тесно связывая ViewModel с определенными UI-элементами.

Корректный пример

class MyViewModel(private val repository: MyRepository) : ViewModel() {

    private val _userData = MutableLiveData<User>()
    val userData: LiveData<User> get() = _userData

    fun fetchUserData() {
        viewModelScope.launch {
            val data = repository.getUserData()
            _userData.postValue(data)
        }
    }
}

Чем этот пример лучше?

В этой версии ViewModel сосредоточена исключительно на управлении данными, связанными с UI. Бизнес-логика и получение данных делегированы репозиторию, что позволяет соблюсти принцип разделения задач. ViewModel раскрывает LiveData для UI, обеспечивая обновление UI в ответ на изменения данных без прямого манипулирования.

2. Игнорирование принципа разделения задач

Ошибка

Прямое обращение к UI-элементам во ViewModel или выполнение в ней обновлений UI.

Некорректный пример

class MyViewModel : ViewModel() {
    fun updateUI(data: String) {
        // Обновление UI-элемента напрямую
        textView.text = data
    }
}

Почему это некорректно?

Такой подход нарушает принцип MVVM, жестко связывая ViewModel с определенными UI-компонентами. Это не только усложняет тестирование ViewModel, но и снижает гибкость UI, поскольку ViewModel теперь зависит от наличия определенных UI-элементов.

Корректный пример

class MyViewModel : ViewModel() {
    private val _uiState = MutableLiveData<UIState>()
    val uiState: LiveData<UIState> = _uiState

    fun fetchData() {
        _uiState.value = UIState.Loading
        // Получение данных 
        _uiState.value = UIState.Success(data)
    }
}

Чем этот пример лучше?

Здесь ViewModel не манипулирует UI-компонентами напрямую. Вместо этого ViewModel раскрывает объект LiveData, представляющий UI-состояние. UI наблюдает за LiveData и обновляется соответствующим образом. Такой подход сохраняет полное разделение между ViewModel и UI, что способствует лучшей тестируемости и гибкости.

3. Неправильное управление LiveData

Ошибка

Создание нескольких объектов LiveData для каждого UI-компонента, что приводит к фрагментации и сложности в обслуживании кодовой базы.

Некорректный пример

class MyViewModel : ViewModel() {
    val name = MutableLiveData<String>()
    val age = MutableLiveData<Int>()
    val loading = MutableLiveData<Boolean>()
}

Почему это некорректно?

Такой подход приводит к увеличению числа объектов LiveData, что делает ViewModel загроможденной и трудноуправляемой. Это также усложняет UI-логику: UI теперь должен наблюдать за несколькими объектами LiveData, что увеличивает риск несогласованности и ошибок.

Корректный пример

data class UserProfileUIState(
    val name: String = "",
    val age: Int = 0,
    val loading: Boolean = false
)

class UserProfileViewModel : ViewModel() {
    private val _uiState = MutableLiveData<UserProfileUIState>()
    val uiState: LiveData<UserProfileUIState> = _uiState

    fun loadUserProfile() {
        _uiState.value = UserProfileUIState(loading = true)
        // Получение данных о профиле пользователя
        _uiState.value = UserProfileUIState(name = "John Doe", age = 30, loading = false)
    }
}

Чем этот пример лучше?

Группируя связанные состояния UI в один класс данных, этот подход упрощает ViewModel и делает ее более удобной в управлении. UI должен наблюдать только за одним объектом LiveData, что снижает сложность и делает код более удобным для сопровождения и менее подверженным ошибкам.

4. Непоследовательная обработка данных

Ошибка

Получение данных непосредственно в ViewModel вместо использования репозитория или слоя источника данных.

Некорректный пример

class MyViewModel : ViewModel() {
    private val _userData = MutableLiveData<User>()
    val userData: LiveData<User> get() = _userData

    init {
        // Получение данных непосредственно в ViewModel
        val data = api.getUserData()
        _userData.value = data
    }
}

Почему это некорректно?

Получение данных непосредственно в ViewModel смешивает задачи, поскольку ViewModel теперь обрабатывает и получение данных, и UI-логику. Это делает ViewModel более сложной и трудной для тестирования, а также создает зависимость от конкретных источников данных, что снижает гибкость.

Корректный пример

class MyRepository {
    fun getUserData(): User {
        // Получение данных из локальной базы данных или из сети
    }
}

class MyViewModel(private val repository: MyRepository) : ViewModel() {
    val userData: LiveData<User> = liveData {
        emit(repository.getUserData())
    }
}

Чем этот пример лучше?

Делегируя получение данных репозиторию, ViewModel продолжает фокусироваться на своей основной роли: управлении данными, связанными с UI. Репозиторий обрабатывает получение данных, делая код более модульным, более удобным для тестирования и обеспечивая гибкость при изменении источников данных, не затрагивая ViewModel.

5. Пренебрежение тестированием

Ошибка

Игнорирование модульных тестов для ViewModel из-за кажущейся сложности или нехватки времени.

Некорректный пример

// Тесты для логики ViewModel не прописаны 
class MyViewModel : ViewModel() {
    fun fetchData() {
        // Бизнес-логика
    }
}

Почему это некорректно?

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

Корректный пример

@Test
fun `test loading state`() {
    val viewModel = MyViewModel(repository)
    viewModel.fetchData()
    assertEquals(UIState.Loading, viewModel.uiState.value)
}

Чем этот пример лучше?

Тестирование ViewModel гарантирует правильную работу логики в различных сценариях. Это также делает кодовую базу более удобной для сопровождения: можно с уверенностью проводить рефакторинг, зная, что тесты отловят любые регрессии. Тестирование имеет решающее значение для обеспечения качества и надежности кода в долгосрочной перспективе.

6. Неправильное использование корутин или RxJava

Ошибка

Запуск корутин (coroutines) или подписка на наблюдаемые объекты непосредственно в ViewModel без надлежащего управления областью видимости, что приводит к утечкам памяти или сбоям.

Некорректный пример

class MyViewModel : ViewModel() {
    fun fetchData() {
        // Запуск корутины без надлежащего учета области видимости
        GlobalScope.launch {
            val data = repository.getData()
            _uiState.value = UIState.Success(data)
        }
    }
}

Почему это некорректно?

Использование GlobalScope для корутин внутри ViewModel может привести к утечке памяти и неожиданному поведению, поскольку жизненный цикл корутины не связан с жизненным циклом ViewModel. Если ViewModel очищается (например, когда пользователь переходит в другое место), корутина продолжает выполняться, что может привести к сбоям или непоследовательности данных.

Корректный пример

class MyViewModel : ViewModel() {
    fun fetchData() {
        viewModelScope.launch {
            val data = repository.getData()
            _uiState.value = UIState.Success(data)
        }
    }
}

Чем этот пример лучше?

viewModelScope привязана к жизненному циклу ViewModel, что гарантирует автоматическое завершение всех корутин при очистке ViewModel. Это предотвращает утечки памяти и гарантирует, что корутины не продолжат выполняться, когда они больше не нужны, что приводит к более безопасному и предсказуемому коду.

7. Отсутствие надлежащей обработки ошибок

Ошибка

Отсутствие обработки исключений в ViewModel, приводящее к сбоям или плохому пользовательскому опыту.

Некорректный пример

class MyViewModel : ViewModel() {
    fun fetchData() {
        val data = repository.getData()
        _uiState.value = UIState.Success(data)
    }
}

Почему это некорректно?

Такой подход предполагает успешность получения данных во всех случаях, что редко бывает в реальных приложениях. Без надлежащей обработки ошибок любое исключение приведет к нарушению работы приложения или к неопределенному состоянию, что чревато неудовлетворительным пользовательским опытом.

Корректный пример

class MyViewModel : ViewModel() {
    private val _errorState = MutableLiveData<String>()
    val errorState: LiveData<String> = _errorState

    fun fetchData() {
        viewModelScope.launch {
            try {
                val data = repository.getData()
                _uiState.value = UIState.Success(data)
            } catch (e: Exception) {
                _errorState.value = "Failed to fetch data: ${e.message}"
            }
        }
    }
}

Чем этот пример лучше?

Такой подход гарантирует, что ошибки будут пойманы и изящно обработаны внутри ViewModel. Пользователя можно проинформировать об ошибке через UI, а приложение будет продолжать работать без сбоев. Таким образом, получаем более надежное и удобное приложение.

8. Тесная связь между ViewModel и репозиторием

Ошибка

Жесткое программирование (хардкодинг) зависимостей внутри ViewModel, что затрудняет тестирование или замену реализаций.

Некорректный пример

class MyViewModel : ViewModel() {
    private val repository = MyRepository()

    fun fetchData() {
        val data = repository.getData()
        _uiState.value = UIState.Success(data)
    }
}

Почему это некорректно?

Жесткое программирование репозитория непосредственно в ViewModel создает тесную связь между ними, затрудняя использование мока репозитория в тестах или его замену на другую реализацию. Это снижает гибкость и делает код более сложным для сопровождения.

Корректный пример

@HiltViewModel
class MyViewModel @Inject constructor(
    private val repository: MyRepository
) : ViewModel() {
    // Логика ViewModel 
}

Чем этот пример лучше?

При внедрении зависимостей (например, в Hilt) модель ViewModel отделяется от конкретной реализации репозитория. Это облегчает тестирование ViewModel, так как во время тестирования можно внедрить мок или фейк репозитория. Это также повышает гибкость, позволяя менять репозиторий без изменения ViewModel.

9. Неясные обязанности ViewModel

Ошибка

Размывание границ между тем, что должен обрабатывать компонент ViewModel, и тем, что должно обрабатываться компонентом View, приводит к путанице и усложняет обслуживание.

Некорректный пример

class MyViewModel : ViewModel() {
    fun updateUI() {
        // Форматирование данных для отображения в пользовательском интерфейсе непосредственно в ViewModel
        val formattedDate = SimpleDateFormat("yyyy-MM-dd", Locale.getDefault()).format(Date())
        textView.text = formattedDate
    }
}

Почему это некорректно?

В этом примере ViewModel выполняет задачи, связанные с UI, такие как форматирование данных и непосредственное обновление UI-элементов. Это размывает ответственность между ViewModel и View, что делает код более сложным для поддержки и менее гибким.

Корректный пример

class MyViewModel : ViewModel() {
    fun getFormattedDate(): String {
        val date = repository.getDate()
        return SimpleDateFormat("yyyy-MM-dd", Locale.getDefault()).format(date)
    }
}

Чем этот пример лучше?

При таком подходе компонент ViewModel сосредоточен на подготовке данных для UI без непосредственного манипулирования UI-элементами. Компонент View может обрабатывать логику отображения, обеспечивая четкое разделение задач и упрощая сопровождение как ViewModel, так и View.

10. Игнорирование учета жизненного цикла

Ошибка

Невыполнение требования создать ViewModel с учетом жизненного цикла, что может привести к утечкам памяти или неожиданному поведению.

Некорректный пример

class MyViewModel : ViewModel() {
    init {
        // Запуск процесса без учета жизненного цикла
        startProcess()
    }

    fun startProcess() {
        // Процесс, который может привести к утечке памяти
    }
}

Почему это некорректно?

Запуск процессов в ViewModel без учета жизненного цикла может привести к утечке памяти и другим проблемам. Так, когда ViewModel очищается (например, при переходе пользователя в другое место), текущие процессы могут продолжаться, потребляя ресурсы и потенциально вызывая сбои.

Корректный пример

class MyViewModel : ViewModel() {
    init {
        // Наблюдение за источниками или компонентами данных с учетом жизненного цикла
    }

    override fun onCleared() {
        super.onCleared()
        // Ресурсы для очистки
    }
}

Чем этот пример лучше?

Использование метода onCleared() позволит обеспечить правильную очистку ресурсов, когда ViewModel больше не нужна. Это предотвращает утечки памяти и гарантирует, что приложение останется работоспособным и не будет вести себя неожиданным образом.

Заключение

Понимание и недопущение распространенных ошибок MVVM значительно повышает сопровождение, тестируемость и общее качество Android-приложений. Следуя этим лучшим практикам, вы гарантируете надежность, масштабируемость и простоту в управлении MVVM-архитектуры в долгосрочной перспективе.

1. Перегрузка ViewModel

Ошибка

Некорректный пример

Почему это некорректно

Корректный пример

Чем этот пример лучше?

2. Игнорирование принципа разделения задач

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

3. Неправильное управление LiveData

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

4. Непоследовательная обработка данных

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

5. Пренебрежение тестированием

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

6. Неправильное использование корутин или RxJava

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

7. Отсутствие надлежащей обработки ошибок

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

8. Тесная связь между ViewModel и репозиторием

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

9. Неясные обязанности ViewModel

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

10. Игнорирование учета жизненного цикла

Ошибка

Некорректный пример

Почему это некорректно?

Корректный пример

Чем этот пример лучше?

Заключение

Читайте также

Хитрости объектно-ориентированного программирования. Часть 6 SLAP для функций

Алгоритм JavaScript: Array.forEach()

Расширения VS Code, в 3 раза повышающие скорость работы

Тесты

Что вы знаете о языке C++

Какая из профессий в IT-сфере подойдет именно вам?

Насколько хорошо вы знакомы с Mac?