Настройка архитектуры MVVM для Android-приложения
MVVM — де-факто стандарт для Android с момента, когда Google выпустил Architecture Components в 2017 году. ViewModel + LiveData/StateFlow + Repository — эта связка описана в официальных гайдлайнах, поддерживается Jetpack и понятна любому Android-разработчику. Проблема не в том, что MVVM сложен — а в том, что его легко реализовать неправильно.
Типичные ошибки, которые ломают архитектуру
ViewModel с контекстом. Если ViewModel хранит Context или ссылку на Activity/Fragment — это утечка памяти и нарушение смысла паттерна. ViewModel переживает пересоздание Activity при повороте экрана. Для работы с ресурсами используем AndroidViewModel с Application-контекстом только когда иного выхода нет, или выносим строки/ресурсы в отдельный слой.
LiveData в Repository. Repository возвращает LiveData<List<User>> — и теперь Repository связан с Android-фреймворком. Правильно: Repository работает с Flow<List<User>> (coroutines), ViewModel конвертирует в StateFlow через stateIn или .asLiveData().
Бизнес-логика в ViewModel. ViewModel должен трансформировать данные для UI, не реализовывать бизнес-правила. Сложная логика — в UseCase-классах между ViewModel и Repository.
Как выглядит правильный MVVM на Kotlin
@HiltViewModel
class UserProfileViewModel @Inject constructor(
private val getUserProfile: GetUserProfileUseCase
) : ViewModel() {
private val _uiState = MutableStateFlow<ProfileUiState>(ProfileUiState.Loading)
val uiState: StateFlow<ProfileUiState> = _uiState.asStateFlow()
fun loadProfile(userId: String) {
viewModelScope.launch {
getUserProfile(userId)
.onSuccess { _uiState.value = ProfileUiState.Success(it) }
.onFailure { _uiState.value = ProfileUiState.Error(it.message) }
}
}
}
sealed class ProfileUiState {
object Loading : ProfileUiState()
data class Success(val profile: UserProfile) : ProfileUiState()
data class Error(val message: String?) : ProfileUiState()
}
В Fragment или Composable подписываемся на uiState через collectAsStateWithLifecycle() — это безопаснее, чем collect, потому что автоматически останавливает сбор при переходе в background.
Repository и источники данных
Repository — единственная точка входа для ViewModel в данные. Реализует протокол-интерфейс. Внутри решает: брать из Room, из Retrofit или из кеша:
class UserRepositoryImpl @Inject constructor(
private val api: UserApi,
private val dao: UserDao
) : UserRepository {
override fun getProfile(id: String): Flow<UserProfile> = flow {
val cached = dao.getUser(id)
if (cached != null) emit(cached.toDomain())
val remote = api.fetchUser(id)
dao.insert(remote.toEntity())
emit(remote.toDomain())
}
}
Hilt для DI
Без Hilt в Android MVVM приходится вручную создавать ViewModelFactory. Hilt (@HiltViewModel + @Inject) избавляет от этого: Dagger-граф генерируется на этапе компиляции, ошибки конфигурации видны сразу, а не в рантайме.
Что настраиваем
Структура пакетов: data (api, db, repository impl), domain (models, repository interfaces, use cases), presentation (viewmodels, ui). Подключение Hilt. Настройка базового Repository с Room + Retrofit. Образцовый ViewModel с StateFlow и sealed class для UI-состояний. Тесты ViewModel через kotlinx-coroutines-test и turbine.
Сроки
Настройка MVVM-структуры с нуля: 2–4 дня. Рефакторинг существующего Activity-based проекта: 1–3 недели. Стоимость рассчитывается индивидуально.