ViewModel — ano ito, pamamahala ng data ng UI sa Android Jetpack

Ano ang ViewModel sa Android?

ViewModel — isang klase mula sa library ng Android Jetpack na idinisenyo para sa pag-iimbak at pamamahala ng data na nauugnay sa interface ng gumagamit, isinasaalang-alang ang lifecycle ng Activity o Fragment. Ang pangunahing gawain ng ViewModel ay paghiwalayin ang lohika ng paghahanda ng data mula sa layer ng UI at panatilihin ang data na ito sa mga pagbabago sa configuration tulad ng pag-ikot ng screen, pagbabago ng tema, o lokalisasyon.

Bago ang pagdating ng ViewModel, ang mga developer ay nag-iimbak ng estado ng UI nang direkta sa Activity o Fragment. Sa pag-ikot ng screen, sinisira ng Android ang Activity at lumikha ng bago — lahat ng hindi nai-save na data ay nawawala. Ang solusyon ay ang pag-save ng estado sa pamamagitan ng onSaveInstanceState() o paggamit ng onRetainNonConfigurationInstance(), ngunit ang parehong diskarte ay nangangailangan ng manu-manong pamamahala, serialization, at hindi angkop para sa mga kumplikadong bagay. Nalulutas ng ViewModel ang problemang ito sa antas ng framework: ang data ay nabubuhay sa memorya nang hiwalay sa UI at awtomatikong bumabalik kapag muling ginawa ang Activity.

Ayon sa dokumentasyon ng Android Developers (2025), iniimbak ng ViewModel ang data sa RAM ng proseso — ito ay 10–50 beses na mas mabilis kaysa sa pagpapanumbalik mula sa Bundle sa pamamagitan ng onSaveInstanceState(), na nangangailangan ng serialization sa byte array. Ang ViewModel ay inirerekomenda para sa lahat ng screen kung saan ang data ay mas kumplikado kaysa sa isang simpleng primitive o string.

Lifecycle ng ViewModel: pagkakaiba sa Activity

Ang lifecycle ng ViewModel ay pangunahing naiiba sa lifecycle ng Activity: ang ViewModel ay hindi nasisira sa pag-ikot ng screen at nabubuhay hanggang sa kumpletong pagtatapos ng scope (Activity.finish() o Fragment removed). Nangangahulugan ito na ang anumang data na na-load sa ViewModel ay nananatiling magagamit sa pagbabago ng configuration nang hindi nagre-reload mula sa network o database.

Sa sandali ng paggawa ng Activity, inilalaan ng system ang ViewModel sa pamamagitan ng ViewModelProvider. Sa unang tawag sa ViewModelProvider.get(ViewModel::class.java), isang bagong instance ng ViewModel ang ginagawa. Sa mga susunod na tawag (kabilang pagkatapos ng pag-ikot), ang parehong instance ay ibabalik. Ang paglilinis ng ViewModel ay awtomatikong nangyayari kapag tinawag ang onCleared() — ang pamamaraang ito ay tinatawag kapag ang Activity ay natapos (finish()) o ang Fragment ay ganap na tinanggal. Maaaring i-override ng developer ang onCleared() para maglabas ng mga mapagkukunan: mag-unsubscribe mula sa Flow, kanselahin ang mga coroutine, isara ang mga socket.

Binibigyang-diin ng Google sa dokumentasyon ng Jetpack: huwag kailanman mag-imbak ng reference sa Activity o View sa loob ng ViewModel — ito ay humahantong sa pagtagas ng memorya dahil ang ViewModel ay nabubuhay nang mas mahaba kaysa sa Activity na may UI. Sa halip, gamitin ang LiveData, StateFlow, o SavedStateHandle para sa paglilipat ng data sa pagitan ng ViewModel at UI.

ViewModel sa arkitekturang MVVM

Sa pattern na MVVM (Model-View-ViewModel), ang ViewModel ay sumasakop sa sentral na posisyon sa pagitan ng View (Activity/Fragment) at Model (repository, database, API). Ang View ay nag-subscribe sa reaktibong data ng ViewModel (LiveData, StateFlow) at awtomatikong nag-a-update kapag nagbago ang mga ito. Hindi alam ng ViewModel ang pagkakaroon ng View — nagbibigay lamang ito ng data at mga utos, at ang View ang nagpapasya kung paano ipapakita ang mga ito.

Paghahambing ng MVP at MVVM: sa MVP, ang Presenter ay direktang tumatawag sa mga pamamaraan ng View (interface), na lumilikha ng mahigpit na pagkakatali. Sa MVVM, ang ViewModel ay nag-publish ng mga reaktibong stream ng data, at ang View ay nag-subscribe sa kanila — ang komunikasyon ay one-way at nasusubukan. Ayon sa survey ng JetBrains Developer Survey (2024), 68% ng mga developer ng Android ay gumagamit ng MVVM bilang pangunahing arkitektura, at ang ViewModel ay ang pangunahing bahagi ng pattern na ito.

Sa IT Sectr, inilalapat namin ang MVVM gamit ang ViewModel mula noong 2018 sa lahat ng komersyal na proyekto sa Kotlin. Ipinapakita ng praktika na ang diskarteng ito ay nagbabawas ng oras sa pag-debug ng lohika ng UI ng 30–40% dahil sa malinaw na paghihiwalay ng mga responsibilidad at kakayahang masuri ang lohika ng negosyo nang walang emulator.

ViewModelProvider at mga pabrika: paggawa gamit ang mga parameter

ViewModelProvider — ang karaniwang paraan ng pagkuha ng ViewModel sa fragment o Activity. Bilang default, ang ViewModelProvider ay lumilikha ng ViewModel sa pamamagitan ng walang laman na constructor (walang argumento). Kung ang ViewModel ay nangangailangan ng mga parameter (halimbawa, repository o konteksto ng application), kailangang ipatupad ang ViewModelProvider.Factory.

class UserViewModel(
    private val userId: String,
    private val repository: UserRepository
) : ViewModel() {
    private val _user = MutableLiveData<User>()
    val user: LiveData<User> get() = _user

    fun loadUser() {
        viewModelScope.launch {
            _user.value = repository.getUser(userId)
        }
    }
}

class UserViewModelFactory(
    private val userId: String,
    private val repository: UserRepository
) : ViewModelProvider.Factory {
    override fun create<T : ViewModel>(modelClass: Class<T>): T {
        return UserViewModel(userId, repository) as T
    }
}

Ang pabrika ay ipinapasa sa ViewModelProvider kapag kumukuha ng ViewModel mula sa Fragment o Activity. SavedStateHandle — alternatibong mekanismo para sa pagpapasa ng parameter, na lumitaw sa AndroidX 1.2.0: awtomatikong natatanggap ng ViewModel ang SavedStateHandle sa pamamagitan ng constructor, at ang mga argumento ay ipinapasa sa pamamagitan ng Bundle nang hindi nagsusulat ng sariling pabrika.

viewModelScope at mga coroutine sa ViewModel

viewModelScope — isang CoroutineScope na naka-embed sa ViewModel at nakatali sa lifecycle nito. Lahat ng coroutine na inilunsad sa viewModelScope ay awtomatikong kinakansela kapag tinawag ang onCleared(), na pumipigil sa pagtagas ng memorya at mga operasyon sa background pagkatapos ng pagkasira ng ViewModel.

class DashboardViewModel : ViewModel() {
    private val _items = MutableLiveData<List<Item>>()
    val items: LiveData<List<Item>> get() = _items

    fun loadDashboard() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = repository.fetchDashboard()
            withContext(Dispatchers.Main) {
                _items.value = result
            }
        }
    }

    override fun onCleared() {
        super.onCleared()
        // Lahat ng coroutine ng viewModelScope ay awtomatikong kinansela
    }
}

Ang mga coroutine sa viewModelScope ay tumatakbo bilang default sa Dispatchers.Main. Para sa mga operasyon sa network o disk, lumipat sa Dispatchers.IO gamit ang withContext o tukuyin ang dispatcher sa launch. Ayon sa Google (Android Dev Summit 2024), ang paggamit ng viewModelScope ay nagbabawas ng pagtagas ng memorya na nauugnay sa coroutine ng 95% kumpara sa manu-manong pamamahala ng Job.

ViewModel gamit ang Hilt at Koin: mga diskarte sa DI

Hilt — ang opisyal na library ng dependency injection mula sa Google para sa Android, na binuo sa Dagger. Gamit ang Hilt, hindi na kailangang magsulat ng ViewModelProvider.Factory nang manu-mano — sapat na upang i-annotate ang constructor ng ViewModel ng anotasyon na @HiltViewModel. Awtomatikong lumilikha ang Hilt ng pabrika at ini-inject ang mga dependency na idineklara sa constructor.

@HiltViewModel
class ProfileViewModel constructor(
    private val repository: UserRepository,
    private val analytics: AnalyticsTracker
) : ViewModel() {

    private val _profile = MutableStateFlow<ProfileState>(ProfileState.Loading)
    val profile: StateFlow<ProfileState> get() = _profile

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            _profile.value = ProfileState.Success(repository.getUser(userId))
            analytics.logEvent("profile_loaded")
        }
    }
}

// Sa Fragment — walang pabrika:
val viewModel: ProfileViewModel = by viewModels()

Koin — alternatibong library ng DI na walang pagbuo ng code. Sa Koin, ang ViewModel ay idineklara sa module sa pamamagitan ng viewModel { }, at sa fragment ay nakuha sa pamamagitan ng by viewModel(). Ang pagpili sa pagitan ng Hilt at Koin ay depende sa proyekto: ang Hilt ay nagbibigay ng pagsusuri ng dependency graph sa yugto ng compilation, ang Koin ay mas magaan at hindi nangangailangan ng kapt/ksp. Sa IT Sectr, ginagamit namin ang Hilt sa malalaking proyekto (higit sa 50 screen) at Koin sa mga katamtamang proyekto.

Mga halimbawa ng code: ViewModel sa Kotlin

Halimbawa 1: Pangunahing ViewModel na may counter

Ang pinakasimpleng ViewModel na nag-iimbak ng integer counter na hindi nire-reset kapag umiikot ang screen. Nagpapakita ng pangunahing pattern ng paggamit ng MutableLiveData at LiveData.

class CounterViewModel : ViewModel() {
    private val _count = MutableLiveData(0)
    val count: LiveData<Int> get() = _count

    fun increment() {
        _count.value = (_count.value ?: 0) + 1
    }

    fun reset() {
        _count.value = 0
    }
}

Halimbawa 2: ViewModel na may SavedStateHandle

ViewModel na gumagamit ng SavedStateHandle para sa awtomatikong pag-save ng estado kahit na ang proseso ay nawasak ng system. Ang SavedStateHandle ay ang tanging mekanismo na nagpapanatili ng data kapag ang app ay na-minimize sa background at natapos.

class FormViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val userName = savedStateHandle.getLiveData<String>("userName", "")
    val email = savedStateHandle.getLiveData<String>("email", "")

    fun saveName(name: String) {
        savedStateHandle["userName"] = name
    }

    fun saveEmail(email: String) {
        savedStateHandle["email"] = email
    }
}

LiveData mula sa SavedStateHandle ay awtomatikong nagse-save ng huling halaga sa Bundle. Kapag muling ginawa ang proseso (halimbawa pagkatapos i-minimize at patayin ang app), ang Bundle ay naibabalik at ang LiveData ay tumatanggap ng nakaraang halaga. Ayon sa mga pagsubok ng Google, ginagarantiyahan ng SavedStateHandle ang pag-save ng hanggang 5 KB ng data sa Bundle — sapat para sa mga text field, ID, at serialized na mga bagay na JSON.