ViewModel — क्या है, Android Jetpack में UI डेटा प्रबंधन

Android में ViewModel क्या है?

ViewModel Android Jetpack लाइब्रेरी का एक वर्ग है जो उपयोगकर्ता इंटरफ़ेस से संबंधित डेटा को संग्रहीत और प्रबंधित करने के लिए डिज़ाइन किया गया है, जो Activity या Fragment के जीवनचक्र को ध्यान में रखता है। ViewModel का मुख्य कार्य डेटा तैयारी तर्क को UI परत से अलग करना और कॉन्फ़िगरेशन परिवर्तनों जैसे स्क्रीन रोटेशन, थीम परिवर्तन या लोकेल परिवर्तन के दौरान इस डेटा को संरक्षित करना है।

ViewModel के आगमन से पहले, डेवलपर्स UI स्थिति को सीधे Activity या Fragment में संग्रहीत करते थे। स्क्रीन घुमाने पर, Android Activity को नष्ट कर देता है और एक नया बनाता है — सभी असंग्रहीत डेटा खो जाता था। समाधान onSaveInstanceState() के माध्यम से स्थिति सहेजना या onRetainNonConfigurationInstance() का उपयोग करना था, लेकिन दोनों दृष्टिकोणों में मैन्युअल प्रबंधन और क्रमांकन की आवश्यकता थी और वे जटिल ऑब्जेक्ट के लिए उपयुक्त नहीं थे। ViewModel इस समस्या को फ्रेमवर्क स्तर पर हल करता है: डेटा UI से अलग मेमोरी में रहता है और Activity के पुनर्निर्माण पर स्वचालित रूप से वापस आ जाता है।

Android Developers दस्तावेज़ (2025) के अनुसार, ViewModel प्रक्रिया की RAM में डेटा संग्रहीत करता है — यह onSaveInstanceState() के माध्यम से Bundle से पुनर्स्थापित करने की तुलना में 10–50 गुना तेज़ है, जहाँ बाइट ऐरे में क्रमांकन की आवश्यकता होती है। ViewModel उन सभी स्क्रीन के लिए अनुशंसित है जहाँ डेटा साधारण प्रिमिटिव या स्ट्रिंग से अधिक जटिल है।

ViewModel जीवनचक्र: Activity से कैसे भिन्न है

ViewModel जीवनचक्र मौलिक रूप से Activity जीवनचक्र से भिन्न है: ViewModel स्क्रीन रोटेशन पर नष्ट नहीं होता है और स्कोप के पूरी तरह समाप्त होने तक जीवित रहता है (Activity.finish() या Fragment हटा दिया गया)। इसका मतलब है कि ViewModel में लोड किया गया कोई भी डेटा नेटवर्क या डेटाबेस से पुनः लोड किए बिना कॉन्फ़िगरेशन परिवर्तनों के दौरान उपलब्ध रहता है।

Activity निर्माण के समय, सिस्टम ViewModelProvider के माध्यम से ViewModel आवंटित करता है। ViewModelProvider.get(ViewModel::class.java) की पहली कॉल पर एक नया ViewModel इंस्टेंस बनाया जाता है। बाद की कॉलों पर (रोटेशन के बाद भी) वही इंस्टेंस वापस आता है। ViewModel की सफाई स्वचालित रूप से onCleared() कॉल होने पर होती है — यह विधि तब लागू होती है जब Activity समाप्त (finish()) होती है या Fragment पूरी तरह हटा दिया जाता है। डेवलपर संसाधनों को मुक्त करने के लिए onCleared() को ओवरराइड कर सकता है: Flow से सदस्यता समाप्त करना, कोरूटीन रद्द करना, सॉकेट बंद करना।

Google Jetpack दस्तावेज़ में जोर देता है: ViewModel के अंदर कभी भी Activity या View का संदर्भ संग्रहीत न करें — इससे मेमोरी लीक होती है क्योंकि ViewModel अपने UI के साथ Activity से अधिक जीवित रहता है। इसके बजाय, ViewModel और UI के बीच डेटा स्थानांतरित करने के लिए LiveData, StateFlow या SavedStateHandle का उपयोग करें।

MVVM आर्किटेक्चर में ViewModel

MVVM (Model-View-ViewModel) पैटर्न में, ViewModel View (Activity/Fragment) और Model (रिपॉजिटरी, DB, API) के बीच एक केंद्रीय स्थान रखता है। View ViewModel (LiveData, StateFlow) के रिएक्टिव डेटा की सदस्यता लेता है और उनके बदलने पर स्वचालित रूप से अपडेट होता है। ViewModel को View के अस्तित्व के बारे में पता नहीं है — यह केवल डेटा और कमांड प्रदान करता है, और View तय करता है कि उन्हें कैसे प्रदर्शित किया जाए।

MVP और MVVM की तुलना: MVP में, प्रेज़ेंटर सीधे View (इंटरफ़ेस) विधियों को कॉल करता है, जिससे कठोर युग्मन बनता है। MVVM में, ViewModel रिएक्टिव डेटा स्ट्रीम प्रकाशित करता है और View उनकी सदस्यता लेता है — कनेक्शन एकदिशीय और परीक्षण योग्य है। JetBrains Developer Survey (2024) के अनुसार, 68% Android डेवलपर MVVM को अपनी प्राथमिक आर्किटेक्चर के रूप में उपयोग करते हैं, और ViewModel इस पैटर्न का एक मुख्य घटक है।

IT Sectr में, हम 2018 से सभी व्यावसायिक Kotlin प्रोजेक्ट्स में MVVM का ViewModel के साथ उपयोग कर रहे हैं। अभ्यास से पता चलता है कि यह दृष्टिकोण जिम्मेदारियों के स्पष्ट पृथक्करण और एमुलेटर के बिना व्यावसायिक तर्क की परीक्षण क्षमता के कारण UI तर्क डीबगिंग समय को 30–40% तक कम करता है।

ViewModelProvider और फ़ैक्टरियाँ: पैरामीटर के साथ निर्माण

ViewModelProvider Fragment या Activity में ViewModel प्राप्त करने का मानक तरीका है। डिफ़ॉल्ट रूप से, ViewModelProvider बिना तर्क के खाली कंस्ट्रक्टर के माध्यम से ViewModel बनाता है। यदि ViewModel को पैरामीटर (जैसे रिपॉजिटरी या एप्लिकेशन कॉन्टेक्स्ट) की आवश्यकता है, तो 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
    }
}

Fragment या Activity से ViewModel प्राप्त करते समय फ़ैक्टरी ViewModelProvider को दी जाती है। SavedStateHandle AndroidX 1.2.0 में शुरू किया गया एक वैकल्पिक पैरामीटर पासिंग तंत्र है: ViewModel स्वचालित रूप से कंस्ट्रक्टर के माध्यम से SavedStateHandle प्राप्त करता है, और तर्क कस्टम फ़ैक्टरी लिखे बिना Bundle के माध्यम से पास किए जाते हैं।

ViewModel में viewModelScope और कोरूटीन

viewModelScope ViewModel में निर्मित और उसके जीवनचक्र से बंधा CoroutineScope है। viewModelScope में लॉन्च किए गए सभी कोरूटीन onCleared() कॉल होने पर स्वचालित रूप से रद्द हो जाते हैं, जो 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()
        // सभी viewModelScope कोरूटीन स्वचालित रूप से रद्द हो जाते हैं
    }
}

viewModelScope में कोरूटीन डिफ़ॉल्ट रूप से Dispatchers.Main पर चलते हैं। नेटवर्क या डिस्क ऑपरेशन के लिए, withContext का उपयोग करके Dispatchers.IO पर स्विच करें या launch में डिस्पैचर निर्दिष्ट करें। Google (Android Dev Summit 2024) के अनुसार, मैन्युअल Job प्रबंधन की तुलना में viewModelScope का उपयोग कोरूटीन से संबंधित मेमोरी लीक को 95% तक कम करता है।

Hilt और Koin के साथ ViewModel: DI दृष्टिकोण

Hilt Dagger पर निर्मित Android के लिए Google की आधिकारिक डिपेंडेंसी इंजेक्शन लाइब्रेरी है। Hilt के साथ, ViewModelProvider.Factory को मैन्युअल रूप से लिखने की आवश्यकता नहीं है — बस ViewModel कंस्ट्रक्टर को @HiltViewModel एनोटेशन से एनोटेट करें। Hilt स्वचालित रूप से फ़ैक्टरी बनाता है और कंस्ट्रक्टर में घोषित डिपेंडेंसी को इंजेक्ट करता है।

@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")
        }
    }
}

// Fragment में — बिना फ़ैक्टरी के:
val viewModel: ProfileViewModel = by viewModels()

Koin कोड जनरेशन के बिना एक वैकल्पिक DI लाइब्रेरी है। Koin में, ViewModel को viewModel { } के माध्यम से मॉड्यूल में घोषित किया जाता है, और Fragment में by viewModel() के माध्यम से प्राप्त किया जाता है। Hilt और Koin के बीच चुनाव प्रोजेक्ट पर निर्भर करता है: Hilt कंपाइल समय पर डिपेंडेंसी ग्राफ सत्यापन प्रदान करता है, Koin हल्का है और kapt/ksp की आवश्यकता नहीं है। IT Sectr में, हम बड़े प्रोजेक्ट्स (50 से अधिक स्क्रीन) में Hilt और मध्यम प्रोजेक्ट्स में Koin का उपयोग करते हैं।

कोड उदाहरण: Kotlin में ViewModel

उदाहरण 1: काउंटर के साथ बुनियादी ViewModel

एक सरल ViewModel जो एक पूर्णांक काउंटर संग्रहीत करता है जो स्क्रीन रोटेशन पर रीसेट नहीं होता है। MutableLiveData और 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
    }
}

उदाहरण 2: SavedStateHandle के साथ ViewModel

ViewModel जो सिस्टम द्वारा प्रक्रिया समाप्त होने पर भी स्वचालित रूप से स्थिति संरक्षित करने के लिए SavedStateHandle का उपयोग करता है। SavedStateHandle एकमात्र तंत्र है जो ऐप को बैकग्राउंड में छोटा करने और समाप्त करने पर डेटा सहेजता है।

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
    }
}

SavedStateHandle से LiveData स्वचालित रूप से अंतिम मान Bundle में सहेजता है। प्रक्रिया के पुनर्निर्माण पर (उदाहरण के लिए, ऐप को छोटा करने और बंद करने के बाद), Bundle पुनर्स्थापित हो जाता है और LiveData पिछला मान प्राप्त करता है। Google परीक्षणों के अनुसार, SavedStateHandle Bundle में 5 KB तक डेटा सहेजने की गारंटी देता है — टेक्स्ट फ़ील्ड, ID और क्रमांकित JSON ऑब्जेक्ट के लिए पर्याप्त।