सभी को नमस्कार! आज मैं एंड्रॉइड एप्लिकेशन के आर्किटेक्चर के बारे में बात करना चाहूंगा।
वास्तव में, मुझे वास्तव में इस विषय पर रिपोर्ट और लेख पसंद नहीं हैं, लेकिन हाल ही में मुझे इस बात का अहसास हुआ है जिसके साथ मैं साझा करना चाहूंगा।

जब मैंने पहली बार आर्किटेक्चर से परिचित होना शुरू किया, तो मेरी नजर एमवीपी पर पड़ी। मुझे सादगी पसंद थी और भारी मात्रा में प्रशिक्षण सामग्री की उपलब्धता थी।
लेकिन समय के साथ, मैंने नोटिस करना शुरू कर दिया कि कुछ गलत था। एक भावना थी कि यह बेहतर संभव है।

लगभग सभी कार्यान्वयन जो मैंने देखा था, इस तरह से देखा: हमारे पास एक सार वर्ग है जिसमें से हम अपने सभी प्रस्तुतकर्ताओं को विरासत में लेते हैं।

class MoviePresenter(private val repository: Repository) : BasePresenter<MovieView>() { fun loadMovies() { coroutineScope.launch { when (val result = repository.loadMovies()) { is Either.Left -> view?.showError() is Either.Right -> view?.showMovies(result.value) } } } } 

हम प्रत्येक स्क्रीन के लिए एक दृश्य इंटरफ़ेस भी बनाते हैं, जिसके साथ प्रस्तुतकर्ता काम करेगा

 interface MovieView : MvpView { fun showMovies(movies: List<Movie>) fun showError() } 

आइए इस दृष्टिकोण के नुकसानों को देखें:

1. आपको प्रत्येक स्क्रीन के लिए एक व्यू इंटरफ़ेस बनाना होगा। बड़ी परियोजनाओं पर, हमारे पास बहुत सारे अतिरिक्त कोड और फाइलें होंगी जो पैकेज नेविगेशन को मुश्किल बनाती हैं।
2. प्रस्तुतकर्ता का पुन: उपयोग करना मुश्किल है, क्योंकि यह दृश्य से बंधा हुआ है, और इसके विशिष्ट तरीके हो सकते हैं।
3. एक विशिष्ट स्थिति गायब है। कल्पना करें कि हम नेटवर्क के लिए एक अनुरोध कर रहे हैं, और इस समय हमारी गतिविधि मर रही है और एक नया निर्माण किया जा रहा है। डेटा तब आया जब व्यू अभी प्रस्तुतकर्ता से बंधा हुआ नहीं है। जब यह दृश्य प्रस्तुतकर्ता के लिए बाध्य है, तो इस डेटा को कैसे दिखाना है, यह भीख माँगता है? उत्तर: केवल बैसाखी। उदाहरण के लिए, Moxy के पास एक ViewState है जो ViewCommand सूची को संग्रहीत करता है। यह समाधान काम करता है, लेकिन मुझे ऐसा लगता है कि कोड को देखने की स्थिति को बचाने के लिए कोड को खींचना अतिश्योक्तिपूर्ण है (मल्टीडेक्स आपके विचार से बहुत करीब है। प्लस, असेंबली एनोटेशन प्रसंस्करण शुरू कर देगा, जो इसे लंबा कर देगा। हाँ, आप कहेंगे कि अब हमारे पास है) वृद्धिशील kapt, लेकिन इसके संचालन के लिए कुछ शर्तें आवश्यक हैं)। प्लस व्यूकोमांड पार्सलेबल या सीरीयलेबल नहीं हैं, जिसका अर्थ है कि हम उन्हें प्रक्रिया की मृत्यु के मामले में बचा नहीं सकते हैं। यह लगातार महत्वपूर्ण है ताकि कुछ भी न खोएं। इसके अलावा, एक निश्चित राज्य की अनुपस्थिति इसे केंद्रीय रूप से बदलने की अनुमति नहीं देती है, और इससे कीड़े को पुन: उत्पन्न करना मुश्किल हो सकता है।

आइए देखें कि क्या ये समस्याएं अन्य आर्किटेक्चर में हल हैं।

MVVM

 class MovieViewModel(private val repository: Repository) { val moviesObservable: ObservableProperty<List<Movie>> = MutableObservableProperty() val errorObservable: ObservableProperty<Throwable> = MutableObservableProperty() fun loadMovies() { coroutineScope.launch { when (val result = repository.loadMovies()) { is Either.Left -> errorObservable.value = result.value is Either.Right -> moviesObservable.value = result.value } } } } 

आइए ऊपर उल्लेखित बिंदुओं के माध्यम से चलते हैं:

1. MVVM में, VIew का अब कोई इंटरफ़ेस नहीं है, क्योंकि यह केवल ViewModel में अवलोकन योग्य क्षेत्रों की सदस्यता लेता है।
2. ViewModel का पुन: उपयोग करना आसान है क्योंकि यह व्यू के बारे में कुछ नहीं जानता है। (पहले पैराग्राफ से इस प्रकार है)
3. MVVM में, राज्य की समस्या हल हो जाती है, लेकिन पूरी तरह से नहीं। इस उदाहरण में, हमारे पास ViewModel में संपत्ति है, जहां से View डेटा लेता है। जब हम नेटवर्क के लिए एक अनुरोध करते हैं, तो डेटा को संपत्ति में संग्रहीत किया जाएगा, और सदस्यता लेते समय दृश्य मान्य डेटा प्राप्त करेगा (और आप भी एक नखरे के साथ नृत्य नहीं करते हैं)। हम संपत्ति को लगातार बना सकते हैं, जो उन्हें प्रक्रिया की मृत्यु की स्थिति में संरक्षित करने की अनुमति देगा।

MVI

परिभाषित क्रिया, पक्ष और राज्य

 sealed class Action { class LoadAction(val page: Int) : Action() class ShowResult(val result: List<Movie>) : Action() class ShowError(val error: Throwable) : Action() } sealed class SideEffect { class LoadMovies(val page: Int) : SideEffect() } data class State( val loading: Boolean = false, val data: List<Movie>? = null, val error: Throwable? = null ) 

इसके बाद Reducer आता है

 val reducer = { state: State, action: Action -> when (action) { is Action.LoadAction -> state.copy(loading = true, data = null, error = null) to setOf( SideEffect.LoadMovies(action.page) ) is Action.ShowResult -> state.copy( loading = false, data = action.result, error = null ) to emptySet() is Action.ShowError -> state.copy( loading = false, data = null, error = action.error ) to emptySet() } } 

और SideHffects को संभालने के लिए EffectHandler

 class MovieEffectHandler(private val movieRepository: MovieRepository) : EffectHandler<SideEffect, Action> { override fun handle(sideEffect: SideEffect) = when (sideEffect) { is SideEffect.LoadMovies -> flow { when (val result = movieRepository.loadMovies(sideEffect.page)) { is Either.Left -> emit(Action.ShowError(result.value)) is Either.Right -> emit(Action.ShowResult(result.value)) } } } } 

हमारे पास क्या है:

1. MVI में, हमें View के लिए अनुबंधों का एक गुच्छा बनाने की भी आवश्यकता नहीं है। आपको केवल रेंडर (स्टेट) फ़ंक्शन को परिभाषित करने की आवश्यकता है।
2. इसका पुन: उपयोग करने के लिए, दुर्भाग्य से, इतना सरल नहीं है, क्योंकि हमारे पास राज्य है, जो काफी विशिष्ट हो सकता है।
3. एमवीआई में, हमारे पास एक निश्चित स्थिति है कि हम कम फ़ंक्शन के माध्यम से केंद्र बदल सकते हैं। इसके लिए धन्यवाद, हम राज्य परिवर्तनों को ट्रैक कर सकते हैं। उदाहरण के लिए, लॉग में सभी परिवर्तन लिखें। यदि एप्लिकेशन क्रैश होता है तो हम अंतिम स्थिति पढ़ सकते हैं। प्लस स्टेट लगातार हो सकता है, जो आपको प्रक्रिया की मृत्यु को संभालने की अनुमति देता है।

परिणाम

MVVM प्रक्रिया मृत्यु की समस्या को हल करता है। लेकिन, दुर्भाग्य से, यहां की स्थिति अभी भी अनिश्चित है और केंद्र बदल नहीं सकता है। यह, निश्चित रूप से, एक माइनस है, लेकिन अभी भी स्थिति एमवीपी की तुलना में स्पष्ट रूप से बेहतर हो गई है। एमवीआई राज्य की समस्या को हल करता है, लेकिन दृष्टिकोण ही थोड़ा जटिल हो सकता है। साथ ही, UI के साथ एक समस्या है, क्योंकि एंड्रॉइड में वर्तमान UI टूलकिट खराब है। MVVM में, हम UI को टुकड़ों में अपडेट करते हैं, और MVI में हम इसे संपूर्ण रूप में अपडेट करने का प्रयास करते हैं। इसलिए, एक अनिवार्य ui के लिए, MVVM बेहतर व्यवहार करेगा। यदि आप एमवीआई का उपयोग करना चाहते हैं, तो मैं आपको आभासी / वृद्धिशील डोम और एंड्रॉइड के लिए पुस्तकालयों के सिद्धांत के साथ खुद को परिचित करने की सलाह देता हूं: लिथो, एविल, जेटपैक कंपोज (आपको इंतजार करना होगा)। या आप अपने हाथों से डिफरेंशियल ले सकते हैं।

ऊपर दिए गए सभी आंकड़ों के आधार पर, मैं आपको सलाह दूंगा कि एप्लिकेशन डिज़ाइन करते समय MVVM और MVI के बीच चयन करें। तो आपको अधिक आधुनिक और सुविधाजनक दृष्टिकोण प्राप्त होता है (विशेषकर एंड्रॉइड की वास्तविकताओं में)।

पुस्तकालय जो इन दृष्टिकोणों को लागू करने में मदद कर सकते हैं:
MVVM - https://github.com/Miha-x64/Lychee
MVI - https://github.com/egroden/mvico , https://github.com/badoo/MVICore , https://github.com/arkivanov/MVIDroid

ध्यान देने के लिए आप सभी का धन्यवाद!