MVVM + Jetpack

Hãy tưởng tượng cách làm KHÔNG có MVVM trước: bạn viết mọi thứ ngay trong Activity/Fragment — gọi API, tự parse dữ liệu, tự cập nhật từng ô trên màn hình, tất cả trong MỘT file. Ban đầu có vẻ nhanh, nhưng file đó phình to rất nhanh, rất khó đọc lại sau vài tuần, và gần như không thể viết test cho nó (vì test cần dựng cả một màn hình thật). Tệ hơn, như bạn đã học ở phần Android fundamentals: Activity có thể bị đập bỏ và dựng lại bất cứ lúc nào (xoay màn hình) — nên dữ liệu để ngay trong đó rất dễ mất.

MVVM giải quyết bằng cách chia công việc ra ba vai trò, mỗi vai trò chỉ làm ĐÚNG MỘT việc: UI chỉ có nhiệm vụ hiển thị đúng những gì được đưa cho nó và báo lại khi người dùng làm gì; ViewModel giữ dữ liệu hiện tại của màn hình và quyết định phải làm gì khi có hành động; Repository biết cách lấy dữ liệu thật (từ mạng hoặc máy) và đưa về cho ViewModel ở dạng sạch, dễ dùng.

Có một nguyên tắc xuyên suốt cần nhớ: dữ liệu chỉ nên ĐI THEO MỘT CHIỀU. State (dữ liệu hiện tại) đi từ ViewModel xuống UI để hiển thị — UI chỉ đọc, không tự sửa. Hành động (event) đi từ UI lên ViewModel khi người dùng bấm/gõ gì đó — UI chỉ báo lại, không tự quyết định phải làm gì tiếp. Nhờ luồng một chiều này, tại bất kỳ lúc nào bạn cũng biết chắc dữ liệu đang ở đâu và ai vừa mới đổi nó, không phải đoán.

ViewModel giữ dữ liệu hiện tại của màn hình (state) và xử lý các hành động người dùng gửi lên. Điều đặc biệt — và cũng là lý do ViewModel tồn tại — là nó KHÔNG bị đập bỏ khi Activity bị dựng lại lúc xoay màn hình (đúng như bạn đã học ở phần Android fundamentals). Vì vậy quy tắc đơn giản: dữ liệu nào cần giữ khi xoay màn hình, đặt trong ViewModel; đừng đặt trong biến của Activity/Fragment.

class ProductViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow<UiState>(UiState.Loading)
    val uiState: StateFlow<UiState> = _uiState.asStateFlow()

    // UI gọi hàm này khi người dùng kéo để làm mới — không tự gọi API
    fun onRefresh() = loadProducts()

    private fun loadProducts() { /* ... xem chi tiết ở phần Coroutines/Flow */ }
}

Hãy nghĩ Repository như một nhân viên lễ tân: ViewModel chỉ cần hỏi "cho tôi danh sách sản phẩm", còn việc thực tế dữ liệu đó lấy từ đâu — gọi API qua mạng, đọc từ database lưu sẵn trên máy, hay kết hợp cả hai — là chuyện của Repository, ViewModel không cần biết và không nên biết.

Lợi ích cụ thể: nếu sau này bạn muốn thêm cache (lưu tạm để mở app lần sau đỡ phải tải lại), hoặc đổi hẳn thư viện gọi mạng, bạn chỉ cần sửa trong Repository — ViewModel không cần đổi một dòng nào, vì nó chỉ biết tới "cái interface" chứ không biết chi tiết bên trong.

interface ProductRepository {
    suspend fun getProducts(): List<Product>
}

// bản thật: lấy từ API
class DefaultProductRepository(
    private val api: ProductApi
) : ProductRepository {
    override suspend fun getProducts() =
        api.getProducts().map { it.toDomain() }
}

// bản giả dùng khi viết test: trả sẵn một list có sẵn, không cần mạng thật
class FakeProductRepository(
    private val fake: List<Product>
) : ProductRepository {
    override suspend fun getProducts() = fake
}

Hãy so sánh hai tình huống thật. Tình huống 1: màn hình danh sách sản phẩm đang hiển thị 20 sản phẩm. Bạn xoay màn hình, Activity dựng lại — bạn MUỐN 20 sản phẩm đó hiện lại y như cũ, không mất. Tình huống 2: bạn vừa đặt hàng thành công, app hiện một Snackbar "Đặt hàng thành công!". Ngay sau đó bạn xoay màn hình — bạn KHÔNG muốn Snackbar đó hiện lại lần nữa, vì việc đặt hàng chỉ xảy ra một lần, không phải liên tục.

Đây chính là khác biệt giữa hai loại dữ liệu UI. State là dữ liệu "hiện tại" — luôn cần được hiển thị lại mỗi khi màn hình được vẽ (dù vẽ lần đầu hay vẽ lại sau khi xoay). Event một lần là một hành động chỉ nên xảy ra đúng MỘT LẦN — hiện snackbar, điều hướng qua màn khác — dù màn hình có bị vẽ lại bao nhiêu lần sau đó cũng không được lặp lại nó.

Lỗi hay gặp: nếu bạn lưu luôn "cần hiện snackbar" là một phần của state (StateFlow), thì đúng như tình huống 1, mỗi lần vẽ lại màn hình (xoay máy) cái state đó bị đọc lại và snackbar hiện ra lần nữa — dù bạn chẳng đặt hàng thêm lần nào.

Đây chính là cách một người mới thường vô tình làm trước khi biết tới SharedFlow hay Channel: vẫn để "cần hiện snackbar" nằm trong state như bình thường, nhưng tự thêm một bước dọn dẹp — ngay sau khi UI xử lý xong, gọi một hàm để ViewModel đặt field đó về lại null.

data class UiState(
    val products: List<Product> = emptyList(),
    val orderSuccessMessage: String? = null,   // vẫn chỉ là 1 field trong state
)

// UI: hiện xong PHẢI TỰ NHỚ gọi hàm dọn, không thì bug ở tình huống 2 lại xảy ra
LaunchedEffect(state.orderSuccessMessage) {
    state.orderSuccessMessage?.let { message ->
        showSnackbar(message)
        viewModel.onSnackbarShown()   // reset lại về null trong ViewModel
    }
}

Vậy SharedFlow và Channel khác nhau ở đâu? Cả hai đều đảm bảo "chỉ nhận một lần", nhưng khác nhau đúng một điểm: chuyện gì xảy ra nếu ViewModel gửi event vào ĐÚNG LÚC chưa có UI nào đang lắng nghe (ví dụ một khoảnh khắc rất ngắn lúc UI đang xoay màn hình, tạm ngừng collect).

• Channel giống một hộp thư: event gửi vào sẽ NẰM CHỜ TRONG HỘP (có sức chứa giới hạn) cho tới khi có người tới nhận, dù lúc gửi chưa ai đứng đó cả. Channel không làm mất event.
• SharedFlow ở cấu hình mặc định cho event một lần (replay = 0, không thêm buffer) giống việc hét lên giữa một căn phòng: nếu đúng lúc đó không ai đang lắng nghe, câu đó MẤT LUÔN, không được giữ lại cho ai nghe sau. ViewModel emit ngay lúc UI tạm ngừng collect là event biến mất, không báo lỗi gì cả.

private val _events = Channel<UiEvent>(Channel.BUFFERED)
val events = _events.receiveAsFlow()

fun onItemClick(id: String) {
    // gửi một lệnh "hãy điều hướng" — lệnh này chỉ được xử lý đúng 1 lần
    viewModelScope.launch { _events.send(UiEvent.NavigateToDetail(id)) }
}

private val _events = MutableSharedFlow<UiEvent>(
    extraBufferCapacity = 1,               // đệm thêm, không chỉ trông chờ replay
    onBufferOverflow = BufferOverflow.DROP_OLDEST,
)
val events = _events.asSharedFlow()

Navigation component quản lý việc chuyển màn hình ở một nơi duy nhất: khai báo trước tất cả màn hình và đường đi giữa chúng (gọi là graph), lo việc truyền dữ liệu an toàn giữa hai màn hình (Safe Args — ví dụ truyền đúng id sản phẩm, không phải đoán kiểu dữ liệu), và tự quản lý việc bấm Back nên quay về đâu. Với Compose có bản riêng là Navigation Compose.

SavedStateHandle chính là phiên bản "dễ dùng hơn" của thứ bạn đã gặp ở phần Android fundamentals — onSaveInstanceState. Bạn không cần tự override hàm nào cả, chỉ cần khai báo SavedStateHandle trong constructor của ViewModel, và Android tự nối nó với đúng cơ chế lưu/khôi phục đó. Nhờ vậy dữ liệu trong SavedStateHandle bền hơn cả configuration change — nó còn sống sót qua cả việc app bị dọn hẳn (process death), khác với một biến bình thường trong ViewModel chỉ sống qua xoay màn hình.

Một công dụng rất thực tế: SavedStateHandle cũng là nơi bạn nhận lại đúng tham số mà Navigation đã truyền qua (ví dụ id của sản phẩm khi chuyển từ danh sách sang chi tiết).

class DetailViewModel(
    savedStateHandle: SavedStateHandle,
    repository: ProductRepository
) : ViewModel() {
    // id được Navigation truyền qua khi mở màn hình chi tiết
    private val productId: String = checkNotNull(savedStateHandle["id"])
    // ... dùng productId để gọi repository.getProduct(productId)
}

MVI (Model-View-Intent) KHÔNG phải một công nghệ hay thư viện riêng, cũng không phải một thứ đối lập với MVVM. Bạn vẫn dùng đúng ViewModel + StateFlow như mọi thứ ở trên trang này — MVI chỉ là một bộ QUY TẮC chặt hơn mà bạn tự đặt ra khi viết code bên trong ViewModel đó. Nói cách khác: MVVM là kiểu kiến trúc chung (UI - ViewModel - Repository) mà cả trang này đã nói, còn MVI là một cách LÀM CỤ THỂ, nghiêm ngặt hơn, để viết đúng phần ViewModel trong kiến trúc đó.

Để hiểu vì sao người ta nghĩ ra MVI, hãy tưởng tượng một tình huống rất thật. Màn hình danh sách sản phẩm của bạn cùng lúc phải lo nhiều việc: đang tải lại danh sách (loading), người dùng vừa bấm xoá một sản phẩm (đang gọi mạng để xoá), rồi mạng chập chờn báo lỗi. Nếu theo kiểu MVVM thoải mái, mỗi việc bạn để một luồng state riêng — isLoading, isDeleting, deleteError, danh sách sản phẩm — bốn thứ này cập nhật ĐỘC LẬP, mỗi cái đổi vào một thời điểm khác nhau.

Vấn đề nảy sinh ở những khoảnh khắc chúng "đá nhau": có lúc isDeleting đã bật true nhưng danh sách chưa kịp bỏ item đó ra, hoặc deleteError đã có nhưng isDeleting vẫn chưa tắt — và UI phải tự đoán trong mớ đó nên vẽ gì. Đây là loại bug rất khó tái hiện vì nó phụ thuộc thứ tự các luồng cập nhật. MVI sinh ra để chặn trước đúng loại bug này: nếu chỉ có MỘT state duy nhất, thì tại mọi thời điểm bốn thông tin đó luôn là một bức ảnh chụp nhất quán, không thể lệch pha nhau.

So với sơ đồ MVVM ở đầu trang (một chồng tầng UI → ViewModel → Repository → data, dữ liệu đi lên xuống theo trục dọc), sơ đồ MVI là một VÒNG khép kín — nhấn mạnh điểm cốt lõi: mọi thứ chỉ chạy theo đúng một chiều, hết vòng lại quay về đầu, không có lối tắt. Ba điều MVI siết chặt chính là để giữ cái vòng đó luôn sạch: (1) chỉ MỘT state duy nhất, (2) mọi hành động đi qua MỘT cửa vào, (3) chỉ MỘT cách đổi state. Ba mục dưới đây lần lượt là ba điều đó; cuối cùng sẽ có phần UI khép lại vòng và một bảng so sánh gom lại.

Ở MVVM thông thường (như phần trên đã trình bày), bạn có một StateFlow<UiState> chính. Nhưng MVVM không cấm bạn thêm state phụ khi cần — ví dụ muốn có thêm cờ "đang xoá sản phẩm", nhiều người sẽ tiện tay thêm một MutableStateFlow riêng nữa. Làm vậy vài lần, ViewModel có thể có 3-4 luồng state khác nhau, và rất dễ xảy ra tình huống hai luồng "không khớp nhau" tại một thời điểm (ví dụ isLoading đã false nhưng isDeleting lại đang true mà UI không rõ nên ưu tiên hiển thị gì).

MVI đặt ra một luật CỨNG: toàn bộ những gì UI cần để vẽ màn hình phải nằm trong DUY NHẤT MỘT object bất biến, thường gọi là State. Không có state phụ nằm rải rác nơi khác. Muốn thêm thông tin gì, thêm field vào chính state đó — không được tạo thêm một luồng mới.

// Kiểu MVVM thoải mái: thêm luồng mới mỗi khi cần — dễ làm, dễ rối
class ProductViewModel(...) : ViewModel() {
    val uiState: StateFlow<UiState> = ...
    val isDeleting = MutableStateFlow(false)          // thêm tuỳ hứng
    val deleteError = MutableStateFlow<String?>(null)  // rồi thêm tiếp
}

// Kiểu MVI: mọi thứ dồn vào một state duy nhất, không có luồng phụ nào khác
data class ProductScreenState(
    val products: List<Product> = emptyList(),
    val isLoading: Boolean = false,
    val isDeleting: Boolean = false,
    val deleteError: String? = null,
)

class ProductViewModel(...) : ViewModel() {
    private val _state = MutableStateFlow(ProductScreenState())
    val state: StateFlow<ProductScreenState> = _state.asStateFlow()
}

Ở MVVM, UI thường gọi trực tiếp một hàm public riêng cho mỗi hành động — onRefresh(), onItemClick(id), onDeleteClick(id)... mỗi hành động một hàm khác nhau. MVI đi xa hơn: gói TẤT CẢ hành động có thể xảy ra thành một sealed class gọi là Intent, và ViewModel chỉ có DUY NHẤT một cửa vào để nhận nó — giống hệt cách sealed class giúp bạn không bỏ sót trạng thái mà bạn đã học ở phần Kotlin core, chỉ áp dụng cho hành động thay vì cho trạng thái.

sealed interface ProductIntent {
    data object Refresh : ProductIntent
    data class ItemClicked(val id: String) : ProductIntent
    data class DeleteClicked(val id: String) : ProductIntent
}

class ProductViewModel(...) : ViewModel() {
    fun onIntent(intent: ProductIntent) {
        when (intent) {                              // không cần else
            ProductIntent.Refresh -> loadProducts()
            is ProductIntent.ItemClicked -> openDetail(intent.id)
            is ProductIntent.DeleteClicked -> deleteProduct(intent.id)
        }
    }
}

Ở MVVM, sau khi Repository trả dữ liệu về, ViewModel thường sửa thẳng state (gán _uiState.value = ...) ở nhiều chỗ khác nhau trong nhiều hàm. MVI gom việc "tạo state mới" về một khuôn duy nhất: nhận state cũ, đổi vài field, trả ra state mới — luôn bằng copy(), không bao giờ sửa state kiểu khác. Nhiều tài liệu gọi bước này là reducer. Không bắt buộc phải tách hẳn thành một hàm tên reducer, quan trọng là mọi thay đổi đều đi qua đúng khuôn đó.

private fun deleteProduct(id: String) {
    // Mỗi lần đổi state đều là _state.update { copy(...) } — không có cách nào khác
    _state.update { it.copy(isDeleting = true, deleteError = null) }
    viewModelScope.launch {
        try {
            repository.delete(id)                 // xoá xong: bỏ id khỏi list
            _state.update { it.copy(isDeleting = false, products = it.products - id) }
        } catch (e: Exception) {                  // lỗi: ghi vào chính state đó
            _state.update { it.copy(isDeleting = false, deleteError = e.message) }
        }
    }
}

Ba mục trên mới là phía ViewModel. Phải nhìn thêm phía UI thì cái "vòng một chiều" nhắc ở đầu mới thành hình thật. Phía UI trong MVI cực kỳ đơn giản, và đó là chủ đích: nó chỉ làm đúng hai việc — ĐỌC một state duy nhất để vẽ, và GỬI Intent lên khi người dùng làm gì. Không có việc thứ ba. UI không tự sửa state, không tự quyết định logic.

@Composable
fun ProductScreen(viewModel: ProductViewModel) {
    // ĐỌC: chỉ một state duy nhất, vẽ mọi thứ từ nó
    val state by viewModel.state.collectAsStateWithLifecycle()

    Column {
        if (state.isLoading) LoadingBar()
        state.deleteError?.let { ErrorBanner(it) }
        ProductList(
            products = state.products,
            // GỬI: mọi hành động đều đi qua onIntent, không gọi hàm riêng lẻ
            onRefresh = { viewModel.onIntent(ProductIntent.Refresh) },
            onDelete = { id -> viewModel.onIntent(ProductIntent.DeleteClicked(id)) },
        )
    }
}

Giờ ghép mọi thứ lại thành một kịch bản thật — người dùng bấm xoá một sản phẩm — để thấy dữ liệu chạy qua từng chặng ra sao, và vì sao đây đúng là thứ mà tình huống "list + đang xoá + lỗi mạng" ở đầu mục cần:

Ba quy tắc phía ViewModel cộng với phía UI vừa xem, tất cả trên cùng nền ViewModel + StateFlow của MVVM (không đổi công nghệ). Đặt cạnh nhau theo từng khía cạnh:

Cách hiểu gọn nhất để nhớ lâu: MVVM cho bạn tự do, MVI lấy bớt tự do đó để đổi lấy sự chắc chắn. Toàn bộ khác biệt của MVI gói trong ĐÚNG BA CÁI CẤM — nhớ ba dòng này là nhớ hết MVI:

Ba cái cấm này chính là ba dòng đầu của bảng so sánh phía trên, chỉ nói ngược lại cho dễ khắc vào đầu. Khi nào chúng đáng giá? Màn hình đơn giản: ba cái cấm chỉ làm bạn gõ nhiều hơn mà chẳng lợi gì, MVVM thường là đủ. Màn hình phức tạp nhiều trạng thái đan xen: chính ba cái cấm đó chặn trước loại bug "hai chỗ hiển thị mâu thuẫn" mà MVVM lỏng dễ mắc.