Android पर MVC पैटर्न

497

क्या एंड्रॉइड के लिए जावा में मॉडल-व्यू-कंट्रोलर पैटर्न को लागू करना संभव है?

या यह पहले से ही गतिविधियों के माध्यम से लागू किया गया है? या Android के लिए MVC पैटर्न को लागू करने का एक बेहतर तरीका है?

— मोहित देशपांडे
स्रोत

64

आपका प्रश्न बहुत अच्छा है। लेकिन समाधान के रूप में चिह्नित उत्तर मेरी राय में सही नहीं है। यह कई लोगों को गुमराह कर सकता है।

— सगर

4

मेरे 2 पोस्ट यहाँ देखें Android आर्किटेक्चर: MV?

— डोरी

1

एमवीसी का पालन करने के लिए नियमों का एक अतिरिक्त सेट है या एक्टिविटी, एक्सएमएल, रिसोर्सेस के कारण एंड्रॉइड डेवलपमेंट पहले से ही एमवीसी के अनुरूप है?

— udun की ज्वाला

3

@ डोरी, मैं आपका लिंक ठीक करता हूं: Android आर्किटेक्चर: MV?

— एंड्रीबेटा

यह आलेख ठीक उसी तरह से मेल खाता है जो आप देख रहे हैं, एक व्यावहारिक उदाहरण के माध्यम से एंड्रॉइड में एमवीसी: digigene.com/altecture/android-altecture-part-2-mvc

— अली नेम

239

Android में आपके पास MVC नहीं है, लेकिन आपके पास निम्नलिखित हैं:

आप अपने उपयोगकर्ता इंटरफ़ेस को विभिन्न XML फ़ाइलों में रिज़ॉल्यूशन, हार्डवेयर आदि द्वारा परिभाषित करते हैं ।
आप अपने संसाधनों को विभिन्न XML फ़ाइलों में लोकेल इत्यादि से परिभाषित करते हैं ।
आप की तरह clases विस्तार ListActivity , TabActivity और से एक्सएमएल फ़ाइल के मेकअप उपयोग inflaters ।
आप अपने व्यावसायिक तर्क के लिए जितनी चाहें उतनी कक्षाएं बना सकते हैं।
आपके लिए बहुत सारे Utils पहले ही लिखे जा चुके हैं - DatabaseUtils, Html।

— Pentium10
स्रोत

3

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

8

जो कोई भी कहता है कि "Android MVC है" कृपया एक सप्ताह के लिए Backbone.js (हाँ, क्लाइंट साइड js) का प्रयास करें और फिर वापस आकर कहें कि "Android MVC है"। आप अंत में इस प्रश्न को समझेंगे और हम क्यों पूछते रहेंगे :)

— मार्क पीटरसन

14

"Android में आपके पास MVC नहीं है" ???? Android में, अन्य भाषाओं की तरह, आपके पास MVC है यदि आप MVC चाहते हैं।

— लोरेंजो बारबगली

1

@LorenzoBarbagli उनका मतलब है, एंड्रॉइड MVC को डिज़ाइन द्वारा ऐप्स में लागू नहीं करता (जैसा कि iOS करता है)। आपको एमवीसी, एमवीपी या कुछ और का स्वाद लागू करना होगा अगर आप यह हासिल करना चाहते हैं कि एमवीसी क्या प्रदान करता है - अर्थात् चिंताओं का पृथक्करण और एक पृथक, आसानी से परीक्षण योग्य मॉडल।

— Piovezan

नहीं। निश्चित रूप से Android में MVC है, लेकिन अधिक अंतर्निहित है। यह सिर्फ एंड्रॉइड संरचनाओं के अनुसार एक अलग तरीके से लागू किया गया है।

— 6rchid

229

कोई सार्वभौमिक रूप से अद्वितीय एमवीसी पैटर्न नहीं है। MVC एक ठोस प्रोग्रामिंग ढांचे के बजाय एक अवधारणा है। आप किसी भी प्लेटफॉर्म पर अपने खुद के MVC को लागू कर सकते हैं। जब तक आप निम्नलिखित मूल विचार से चिपके रहते हैं, आप MVC को लागू कर रहे हैं:

मॉडल: क्या प्रस्तुत करना है
देखें: रेंडर कैसे करें
नियंत्रक: ईवेंट, उपयोगकर्ता इनपुट

इसके बारे में भी इस तरह सोचें: जब आप अपने मॉडल को प्रोग्राम करते हैं, तो मॉडल को रेंडरिंग (या प्लेटफ़ॉर्म विशिष्ट कोड) के बारे में चिंता करने की आवश्यकता नहीं होनी चाहिए। मॉडल दृश्य से कहता है, मुझे कोई फर्क नहीं पड़ता कि आपका रेंडर एंड्रॉइड या आईओएस या विंडोज फोन है, यह वही है जो मुझे प्रस्तुत करने की आवश्यकता है। दृश्य केवल प्लेटफ़ॉर्म-विशिष्ट रेंडरिंग कोड को हैंडल करेगा।

क्रॉस-प्लेटफ़ॉर्म अनुप्रयोगों को विकसित करने के लिए मॉडल को साझा करने के लिए मोनो का उपयोग करने पर यह विशेष रूप से उपयोगी है ।

— रेमन चैन
स्रोत

12

जबकि यह सच है, और अच्छी तरह से, यह सिद्धांत है और लोग व्यावहारिक हैं!

— ट्वीस्ट्रीमोब

1

@TWiStErRob लेकिन डिजाइन पैटर्न सैद्धांतिक, अमूर्त विचार हैं, जो उन्हें साकार करने का सिर्फ एक तरीका नहीं है। यह स्वीकार करते हुए कि "मैं MVC को सिद्धांत रूप में समझना नहीं चाहता, मैं इसे लागू करना चाहता हूं" मुझे लगता है जैसे यह परिणाम हो सकता है "मैं अपनी रसोई में वॉशिंग मशीन लगाने जा रहा हूं क्योंकि वॉशिंग मशीन क्लीनर ™ पैटर्न को लागू करती है। और रसोई की जरूरत है कि ”।

— ल्यूक

1

मुझे लगता है कि उदाहरण अमूल्य हैं क्योंकि वे दिखाते हैं कि दूसरे लोग क्या लेकर आए हैं। कोई उन पर सुधार कर सकता है और उनके प्रयास से सीख सकता है। पहिया को सुदृढ़ करने के लिए सभी की आवश्यकता नहीं है। एंड्रॉइड के संदर्भ में और यह जटिल जीवनचक्र है एक डिजाइन पैटर्न में समस्याओं को संबोधित नहीं किया जाता है, लेकिन हर कोई उनका सामना करेगा। यही मेरा अभिप्राय व्यावहारिक से है।

— ट्वीस्टरेब डेब

47

एंड्रॉइड पर कार्य, दृश्य और गतिविधियां एंड्रॉइड यूआई के साथ काम करने का तरीका बेक्ड-इन हैं और मॉडल-व्यू-व्यूमॉडल (एमवीवीएम) पैटर्न का कार्यान्वयन है , जो संरचनात्मक रूप से समान है (उसी परिवार में) मॉडल-व्यू -controller।

मेरी जानकारी के अनुसार, इस मॉडल को तोड़ने का कोई तरीका नहीं है। यह शायद किया जा सकता है, लेकिन आप मौजूदा मॉडल के सभी लाभ को खो देंगे और काम करने के लिए अपनी खुद की यूआई परत को फिर से लिखना होगा।

— डेरिक बेली
स्रोत

29

कुछ खोज के बाद, सबसे उचित उत्तर निम्नलिखित है:

MVC पहले से ही Android में लागू किया गया है:

देखें = लेआउट, संसाधन और निर्मित कक्षाएं जैसे Buttonव्युत्पन्न से android.view.View।
नियंत्रक = गतिविधि
मॉडल = अनुप्रयोग तर्क को लागू करने वाली कक्षाएं

(इस तरह से गतिविधि में कोई एप्लिकेशन डोमेन लॉजिक नहीं है।)

एक छोटे डेवलपर के लिए सबसे उचित बात यह है कि इस पैटर्न का पालन करें और यह करने की कोशिश करें कि Google ने क्या नहीं करने का फैसला किया है।

PS ध्यान दें कि गतिविधि को कभी-कभी पुनरारंभ किया जाता है, इसलिए यह मॉडल डेटा के लिए कोई जगह नहीं है (पुनरारंभ करने का सबसे आसान तरीका android:configChanges="keyboardHidden|orientation"एक्सएमएल से चूकना और अपने डिवाइस को चालू करना है)।

संपादित करें

हम एमवीसी के बारे में बात कर रहे हैं , लेकिन एफएमवीसी , फ्रेमवर्क - मॉडल - व्यू - नियंत्रक कहने के लिए ऐसा होगा । फ्रेमवर्क (Android OS) घटक जीवन चक्र और संबंधित घटनाओं के अपने विचार लगाता है, और व्यवहार में नियंत्रक ( Activity/ Service/ BroadcastReceiver) इन के साथ मुकाबला करने के लिए सभी जिम्मेदार का पहला है फ्रेमवर्क घटनाओं -imposed (जैसे OnCreate () )। क्या उपयोगकर्ता इनपुट को अलग से संसाधित किया जाना चाहिए? यहां तक कि अगर यह होना चाहिए, तो आप इसे अलग नहीं कर सकते हैं, उपयोगकर्ता इनपुट इवेंट भी एंड्रॉइड से आते हैं।

वैसे भी, कम कोड जो एंड्रॉइड-विशिष्ट नहीं है जिसे आपने अपने Activity/ Service/ BroadcastReceiver, बेहतर में डाल दिया है।

— 18446744073709551615
स्रोत

3

गतिविधि की UI तक सीधी पहुंच है, जबकि MVC कंट्रोलर में व्यू (केवल इसके विपरीत) के बारे में पता नहीं होना चाहिए।

— कोनराड मोरव्स्की

2

@KonradMorawski हममम .... एक दृश्य बातें प्रदर्शित करने के बारे जानने और के बारे में नियंत्रक ? नियंत्रक केButton बारे में जानना , का एक बच्चा ? यह अधिक तर्कसंगत लगता है कि दृश्य केवल चीजों को प्रदर्शित करने के बारे में जानते हैं। और यह ध्यान में रखते हुए कि मॉडल केवल डेटा की प्रकृति के बारे में जानता है, यही कारण है कि नियंत्रक की आवश्यकता है: कुछ को मॉडल और दृश्य दोनों के बारे में पता होना चाहिए ।

— 18446744073709551615

4

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

— कोनराड मोरावस्की

1

मुझे लगता Serviceहै कि नियंत्रक की छतरी के नीचे भी आते हैं

— CL22

1

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

— श्रीनेकजेक २२'१५

18

कोई एकल MVC पैटर्न नहीं है जिसे आप मान सकते हैं। एमवीसी कमोबेश यही बताता है कि आपको डेटा और दृश्य को मिंग नहीं करना चाहिए, ताकि उदाहरण के लिए डेटा या कक्षाएं रखने के लिए जिम्मेदार हैं जो डेटा को संसाधित कर रहे हैं सीधे दृश्य को प्रभावित कर रहे हैं।

लेकिन फिर भी, जिस तरह से एंड्रॉइड कक्षाओं और संसाधनों से संबंधित है, आप कभी-कभी एमवीसी पैटर्न का पालन करने के लिए भी मजबूर होते हैं। मेरी राय में अधिक जटिल वे गतिविधियां हैं जो कभी-कभी देखने के लिए जिम्मेदार होती हैं, लेकिन फिर भी एक ही समय में नियंत्रक के रूप में कार्य करती हैं।

यदि आप XML फ़ाइलों में अपने विचारों और लेआउट को परिभाषित करते हैं, तो रिसोर्स फ़ोल्डर से अपने संसाधनों को लोड करें, और यदि आप अपने कोड में इन चीजों को कम या ज्यादा करने से बचते हैं, तो आप वैसे भी MVC पैटर्न का अनुसरण कर रहे हैं।

— RoflcoptrException
स्रोत

14

आप एंड्रॉइड में एमवीसी को लागू कर सकते हैं, लेकिन यह "मूल रूप से समर्थित" नहीं है और कुछ प्रयास करता है।

इसने कहा, मैं व्यक्तिगत रूप से एंड्रॉइड डेवलपमेंट के लिए बहुत क्लीनर आर्किटेक्चर पैटर्न के रूप में एमवीपी की ओर रुख करता हूं । और एमवीपी कहने से मेरा यह मतलब है:

यहाँ छवि विवरण दर्ज करें

मैंने यहां एक अधिक विस्तृत उत्तर भी पोस्ट किया है ।

एंड्रॉइड में एमवीसी / एमवीपी कार्यान्वयन के विभिन्न तरीकों के साथ खेलने के बाद, मैं एक उचित वास्तुशिल्प पैटर्न के साथ आया, जिसे मैंने इस पोस्ट में वर्णित किया है: एमवीपी और एमवीसी आर्किटेक्चरल पैटर्न एंड्रॉइड में ।

— Vasiliy
स्रोत

14

Android पर MVC को लागू करने के लिए मुझे जो सबसे अच्छा संसाधन मिला वह है यह पोस्ट :

मैंने अपनी एक परियोजना के लिए एक ही डिजाइन का पालन किया, और इसने बहुत अच्छा काम किया। मैं एंड्रॉइड पर शुरुआती हूं, इसलिए मैं यह नहीं कह सकता कि यह सबसे अच्छा समाधान है।

मैंने एक संशोधन किया: मैंने एप्लिकेशन क्लास में प्रत्येक गतिविधि के लिए मॉडल और नियंत्रक को तुरंत बदल दिया ताकि परिदृश्य-चित्र मोड में बदलाव होने पर इन्हें फिर से बनाया न जाए।

— हर्वे डोनर
स्रोत

8

यदि लेख एक दिन हटा दिया जाता है, तो सारांश प्राप्त करना बहुत अच्छा होगा।

— pqsk

12

मैं JDPeckham से सहमत हूं, और मेरा मानना है कि अकेले XML किसी एप्लिकेशन के UI भाग को लागू करने के लिए पर्याप्त नहीं है।

हालाँकि, यदि आप गतिविधि को दृश्य का हिस्सा मानते हैं तो MVC को लागू करना काफी सीधा है। आप अनुप्रयोग को ओवरराइड कर सकते हैं (जैसा कि गतिविधि में getApplication () द्वारा लौटाया गया है) और यह यहाँ है कि आप एक नियंत्रक बना सकते हैं जो आपके आवेदन के जीवनकाल के लिए जीवित रहता है।

(वैकल्पिक रूप से आप सिंगलटन पैटर्न का उपयोग कर सकते हैं जैसा कि एप्लिकेशन प्रलेखन द्वारा सुझाया गया है)

— typingduck
स्रोत

12

एमवीसी- एंड्रॉइड पर आर्किटेक्चर एंड्रॉइड में एमवीसी के बजाय किसी भी एमवीपी का पालन करना बेहतर है। लेकिन फिर भी प्रश्न के उत्तर के अनुसार यह समाधान हो सकता है

विवरण और दिशानिर्देश

     Controller -
        Activity can play the role.
        Use an application class to write the
        global methods and define, and avoid
        static variables in the controller label
    Model -
        Entity like - user, Product, and Customer class.
    View -
        XML layout files.
    ViewModel -
        Class with like CartItem and owner
        models with multiple class properties
    Service -
        DataService- All the tables which have logic
        to get the data to bind the models - UserTable,
        CustomerTable
        NetworkService - Service logic binds the
        logic with network call - Login Service
Helpers -
        StringHelper, ValidationHelper static
        methods for helping format and validation code.
SharedView - fragmets or shared views from the code
        can be separated here

AppConstant -
        Use the Values folder XML files
        for constant app level

नोट 1:

अब यहां जादू का टुकड़ा है जो आप कर सकते हैं। एक बार जब आप कोड के टुकड़े को वर्गीकृत कर लेते हैं, तो बेस इंटरफेस क्लास लिखें, जैसे कि IEntity और IService। सामान्य विधियों की घोषणा करें। अब अमूर्त वर्ग बेससेवा बनाएं और अपने स्वयं के तरीकों की घोषणा करें और कोड को अलग करें।

नोट 2: यदि आपकी गतिविधि कई मॉडल प्रस्तुत कर रही है, तो गतिविधि में कोड / तर्क लिखने के बजाय, टुकड़ों में विचारों को विभाजित करना बेहतर है। तो बेहतर है। इसलिए भविष्य में अगर दृश्य में दिखाने के लिए किसी और मॉडल की आवश्यकता है, तो एक और टुकड़ा जोड़ें।

नोट 3: कोड का पृथक्करण बहुत महत्वपूर्ण है। आर्किटेक्चर में हर घटक स्वतंत्र होना चाहिए जो आश्रित तर्क न हो। यदि संयोग से यदि आपके पास कुछ आश्रित तर्क हैं, तो बीच में एक मानचित्रण तर्क वर्ग लिखें। यह भविष्य में आपकी मदद करेगा।

— DropAndTrap
स्रोत

11

लेआउट, संसाधनों, गतिविधियों और इरादों का उपयोग करके एंड्रॉइड यूआई निर्माण एमवीसी पैटर्न का कार्यान्वयन है। कृपया इस पर अधिक जानकारी के लिए निम्न लिंक देखें - http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

पीडीएफ के लिए दर्पण

— अरुणाभ दास
स्रोत

7

लिंक टूटा हुआ है साहब

— चूहा-ए-तात-ए-तात राततौली

2

लगता है कि यह COSC346-lab2.2up.pdf फ़ाइल में पूर्ण विवरण शामिल नहीं है।

— जेम्स

9

एंड्रॉइड का MVC पैटर्न उनके एडॉप्टर कक्षाओं के साथ कार्यान्वित किया जाता है । वे एक नियंत्रक को "एडेप्टर" से बदलते हैं। एडेप्टर के लिए विवरण बताता है:

एक एडॉप्टर ऑब्जेक्ट एक एडॉप्टर व्यू और उस दृश्य के अंतर्निहित डेटा के बीच एक सेतु का काम करता है।

मैं इसे केवल एक Android एप्लिकेशन के लिए देख रहा हूं जो डेटाबेस से पढ़ता है, इसलिए मुझे नहीं पता कि यह अभी तक कितनी अच्छी तरह काम करता है। हालाँकि, यह Qt के मॉडल-व्यू-डेलिगेट आर्किटेक्चर जैसा लगता है, जिसका दावा है कि यह पारंपरिक MVC पैटर्न से एक कदम ऊपर है। कम से कम पीसी पर, क्यूटी का पैटर्न काफी अच्छी तरह से काम करता है।

— बेन
स्रोत

9

हालाँकि यह पोस्ट पुरानी प्रतीत होती है, फिर भी मैं इस क्षेत्र में Android के लिए हाल के विकास के बारे में सूचित करने के लिए निम्नलिखित दो जोड़ना चाहूंगा:

एंड्रॉइड-बाइंडिंग - एक फ्रेमवर्क प्रदान करना जो डेटा मॉडल में एंड्रॉइड व्यू विजेट के बंधन को बढ़ाता है। यह Android अनुप्रयोगों में MVC या MVVM पैटर्न को लागू करने में मदद करता है।

रॉबोगुइस - रोबोग्यूइस अनुमान को विकास से बाहर ले जाता है। अपने दृश्य, संसाधन, सिस्टम सेवा, या किसी अन्य ऑब्जेक्ट को इंजेक्ट करें, और रोबोग्यूइस को विवरण का ध्यान रखें।

— महेंद्र लिया
स्रोत

9

मॉडल व्यू कंट्रोलर (MVC)

यहाँ छवि विवरण दर्ज करें

विवरण:

जब हम सॉफ्टवेयर विकास में मुख्य बड़ी परियोजनाओं के लिए है, MVC आमतौर पर प्रयोग किया जाता है क्योंकि यह परियोजनाओं के आयोजन का एक सार्वभौमिक तरीका है।
नए डेवलपर्स जल्दी से परियोजना के लिए अनुकूल हो सकते हैं
बड़ी परियोजनाओं और क्रॉस प्लेटफॉर्म के विकास में भी मदद करता है।

MVC पैटर्न अनिवार्य रूप से यह है:

मॉडल: क्या प्रदर्शित करने के लिए। यह डेटा स्रोत हो सकता है (उदाहरण: सर्वर, ऐप में कच्चा डेटा)
देखें: यह कैसे प्रदर्शित होता है यह xml हो सकता है। यह एक प्रस्तुति फिल्टर के रूप में अभिनय कर रहा है। एक दृश्य इसके मॉडल (या मॉडल भाग) से जुड़ा होता है और प्रस्तुति के लिए आवश्यक डेटा प्राप्त करता है।
नियंत्रक: उपयोगकर्ता इनपुट जैसी घटनाओं को संभालना। यह गतिविधि हो

एमवीसी की महत्वपूर्ण विशेषता: हम या तो मॉडल या दृश्य या नियंत्रक को संशोधित कर सकते हैं फिर भी अन्य को प्रभावित नहीं कर सकते हैं

कहें कि हम दृश्य में रंग बदलते हैं, दृश्य का आकार या दृश्य की स्थिति। ऐसा करने से यह मॉडल या नियंत्रक को प्रभावित नहीं करेगा
मान लें कि हम मॉडल को बदलते हैं (संपत्ति से प्राप्त डेटा से प्राप्त डेटा के बजाय) फिर भी यह दृश्य और नियंत्रक को प्रभावित नहीं करेगा
मान लें कि हम नियंत्रक (गतिविधि में तर्क) को बदलते हैं, यह मॉडल और दृश्य को प्रभावित नहीं करेगा

— Devrath
स्रोत

2

मैं केवल कभी भी कैसे / मॉडल रिले जानकारी देखने के लिए एक नाली के रूप में नियंत्रक का उपयोग किया है। मैं उत्सुक हूं कि आपके पास एक दूसरे के साथ सीधे संपर्क में मॉडल और दृश्य कैसे हैं। क्या आपके पास इस कार्यान्वयन का एक स्रोत या उदाहरण है?

— जैक्सनक्रा

7

मुझे लगता है कि सबसे उपयोगी सरलीकृत स्पष्टीकरण यहाँ है: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

यहाँ मैंने जो कुछ भी देखा और पढ़ा है, इन सभी चीजों को लागू करने से यह कठिन हो जाता है और एंड्रॉइड के अन्य हिस्सों के साथ अच्छी तरह से फिट नहीं होता है।

अन्य श्रोताओं को कार्यान्वित करने वाली गतिविधि होने के कारण पहले से ही मानक Android तरीका है। सबसे हानिरहित तरीका यह होगा कि जावा ऑब्जर्वर को स्लाइड्स के वर्णन के साथ जोड़ दें और समूह को ऑनक्लिक और अन्य प्रकार के कार्यों को कार्य में शामिल करें जो अभी भी गतिविधि में हैं।

Android तरीका यह है कि गतिविधि दोनों करती है। यह वास्तव में किसी भी आसान कोडिंग का विस्तार करना या भविष्य बनाना नहीं है।

मैं दूसरी पोस्ट से सहमत हूं । यह पहले से ही लागू है, जिस तरह से लोगों के लिए उपयोग किया जाता है नहीं। एक ही फाइल में है या नहीं, पहले से ही अलग है। इसे अन्य भाषाओं और OS को फिट बनाने के लिए अतिरिक्त पृथक्करण बनाने की आवश्यकता नहीं है।

— एडमंड चांग
स्रोत

6

आपके द्वारा प्रदत्त लिंक टूट गया है।

— mmBs

6

यह देखकर आश्चर्य हुआ कि यहाँ के किसी भी पद ने इस प्रश्न का उत्तर नहीं दिया। वे या तो बहुत सामान्य हैं, अस्पष्ट हैं, गलत हैं या Android में कार्यान्वयन को संबोधित नहीं करते हैं।

MVC में, दृश्य परत केवल उपयोगकर्ता इंटरफ़ेस (UI) को दिखाना जानता है। यदि इसके लिए किसी डेटा की आवश्यकता है, तो यह इसे मॉडल लेयर से प्राप्त होता है। लेकिन व्यू सीधे मॉडल को डेटा खोजने के लिए नहीं कहता है, यह नियंत्रक के माध्यम से करता है । इसलिए नियंत्रक दृश्य के लिए आवश्यक डेटा प्रदान करने के लिए मॉडल को कॉल करता है । डेटा तैयार होने के बाद, नियंत्रक दृश्य को सूचित करता है कि डेटा मॉडल से अधिग्रहित होने के लिए तैयार है । अब दृश्य मॉडल से डेटा प्राप्त कर सकता है ।

इस प्रवाह को नीचे के रूप में संक्षेपित किया जा सकता है:

यह ध्यान देने योग्य है कि दृश्य मॉडल में डेटा की उपलब्धता के बारे में कंट्रोलर के माध्यम से जान सकता है - जिसे पैसिव एमवीसी के रूप में भी जाना जाता है - या मॉडल में डेटा का अवलोकन करके, जो कि सक्रिय एमवीसी है, रजिस्टर करके ।

कार्यान्वयन भाग पर, पहली चीज़ जो दिमाग में आती है वह यह है कि व्यू के लिए एंड्रॉइड घटक का क्या उपयोग किया जाना चाहिए ? Activity या Fragment ?

जवाब यह है कि इससे कोई फर्क नहीं पड़ता है और दोनों का उपयोग किया जा सकता है। देखें यूआई के साथ उपयोगकर्ता के बातचीत करने के लिए डिवाइस और प्रतिक्रिया पर यूजर इंटरफेस (यूआई) पेश करने के लिए सक्षम होना चाहिए। दोनों Activity और इसके Fragment लिए आवश्यक तरीके प्रदान करते हैं।

इस आलेख में उपयोग किए गए उदाहरण ऐप में मैंने दृश्य परत के Activity लिए उपयोग किया है , लेकिन इसका उपयोग भी किया जा सकता है।Fragment

पूरा नमूना ऐप मेरे GitHub रेपो की 'mvc' शाखा में पाया जा सकता है ।

मैंने यहां एक उदाहरण के माध्यम से एंड्रॉइड में एमवीसी आर्किटेक्चर के पेशेवरों और विपक्ष से निपटा है ।

उन दिलचस्पी के लिए, मैं Android एप्लिकेशन वास्तुकला पर लेख की एक श्रृंखला शुरू कर दिया है यहाँ एक पूरा काम कर रहे एप्लिकेशन के माध्यम से, जिसमें मैं अलग आर्किटेक्चर की तुलना, यानी MVC, एमवीपी, MVVM, Android एप्लिकेशन विकास के लिए।

— अली नेम
स्रोत

मैंने एक आर्किटेक्चर कोर्स लिया है जहां प्रशिक्षक बताता है कि गतिविधियों और टुकड़ों को विचारों के रूप में उपयोग नहीं किया जाना चाहिए और वास्तव में नियंत्रक होना चाहिए और विचारों को अलग-अलग फाइलें होनी चाहिए। क्या आपके पास इस पर कोई राय या तर्क है कि ऐसा क्यों नहीं होना चाहिए?

— ब्रैंडनक्स

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

— अली नेम

5

एंड्रॉइड पर एमवीएक्स आपदा से थकने के कारण मैंने हाल ही में एक छोटा पुस्तकालय बनाया है जो अप्रत्यक्ष डेटा प्रवाह प्रदान करता है और एमवीसी की अवधारणा के समान है: https://github.com/zserge/anvil

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

फिर, एक बार जब आपका डेटा बदल दिया जाता है - वैश्विक "रेंडर ()" विधि को बुलाया जाएगा, और आपके विचारों को सबसे हालिया डेटा के साथ चालाकी से अपडेट किया जाएगा।

यहां कोड कॉम्पैक्टनेस (निश्चित रूप से मॉडल और नियंत्रक को आसानी से अलग किया जा सकता है) के लिए घटक के अंदर सब कुछ होने का एक उदाहरण है। यहां "गणना" एक मॉडल है, दृश्य () विधि एक दृश्य है, और "v -> गिनती ++" एक नियंत्रक है जो बटन क्लिकों को सुनता है और मॉडल को अपडेट करता है।

public MyView extends RenderableView {
  public MyView(Context c) {
      super(c);
  }

  private int count = 0;

  public void view() {
    frameLayout(() -> {              // Define your view hierarchy
      size(FILL, WRAP);
      button(() -> {
          textColor(Color.RED);      // Define view style
          text("Clicked " + count);  // Bind data
          onClick(v -> count++);     // Bind listeners
      });
    });
  }

अलग मॉडल और नियंत्रक के साथ ऐसा दिखेगा:

button(() -> {
   textColor(Color.RED);
   text("Clicked " + mModel.getClickCount());
   onClick(mController::onButtonClicked);
});

यहां प्रत्येक बटन पर क्लिक करें संख्या बढ़ाई जाएगी, फिर "रेंडर ()" कहा जाएगा, और बटन पाठ अपडेट किया जाएगा।

यदि आप कोटलिन का उपयोग करते हैं तो सिंटैक्स अधिक सुखद हो जाता है: http://zserge.com/blog/anvil-kotlin.html । इसके अलावा, लैम्बदास के बिना जावा के लिए वैकल्पिक वाक्यविन्यास है।

पुस्तकालय अपने आप में बहुत हल्का है, इसकी कोई निर्भरता नहीं है, कोई प्रतिबिंब नहीं का उपयोग करता है, आदि।

(अस्वीकरण: मैं इस पुस्तकालय का लेखक हूं)

— zserge
स्रोत

4

एक्सामारिन टीम ने जो स्पष्टीकरण दिया , उसके अनुसार (आईओएस एमवीसी पर "मुझे पता है कि यह अजीब लगता है, लेकिन एक सेकंड रुको"):

मॉडल (डेटा या एप्लिकेशन तर्क),
दृश्य (उपयोगकर्ता इंटरफ़ेस), और
नियंत्रक (पीछे कोड)।

मैं यह कह सकता हूँ:

एंड्रॉइड पर मॉडल बस पार्सलेबल ऑब्जेक्ट है। दृश्य XML लेआउट है, और नियंत्रक (गतिविधि + इसका टुकड़ा) है।

* यह सिर्फ मेरी राय है, किसी संसाधन या पुस्तक से नहीं।

— zaPlayer
स्रोत

4

एमवीसी वास्तुकला लागू नहीं है, लेकिन एक एमवीपी (मॉडल-व्यू-प्रस्तोता) वास्तुकला को लागू करने के लिए पुस्तकालयों / उदाहरणों का एक सेट मौजूद है।

कृपया, इन लिंक की जाँच करें:

Google ने Android आर्किटेक्चर MVP का एक उदाहरण जोड़ा:

https://github.com/googlesamples/android-architecture

— carlos.baez
स्रोत

3

मैंने देखा है कि कई लोग कह रहे हैं कि एमवीसी पहले से ही एंड्रॉइड में लागू है, लेकिन यह सच नहीं है। Android डिफ़ॉल्ट रूप से MVC का अनुसरण नहीं करता है।

क्योंकि मैं नहीं जानता कि Google कभी भी iPhone की तरह MVC कार्यान्वयन के प्रतिबंधों को लागू करेगा, लेकिन इसके डेवलपर्स के लिए जो अपने प्रोजेक्ट में उन्हें पेटेंट कराना चाहते हैं या तकनीक चाहते हैं, MVC के छोटे या सरल अनुप्रयोगों में उपयोग की आवश्यकता नहीं है, लेकिन अनुप्रयोग के रूप में बढ़ता है और जटिल हो जाता है और बाद के वर्षों में इसके कोड में संशोधन की आवश्यकता होती है, फिर एंड्रॉइड में एमवीसी पैटर्न की आवश्यकता होती है।

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

http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/

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

— लकी राणा
स्रोत

1

माना। एंड्रॉइड में अपने आप को लटकाने के लिए पर्याप्त लचीलापन है। आपकी गतिविधि बहुत तेज़ी से बढ़ सकती है और जटिल हो सकती है क्योंकि यह MVC के सभी तीन पहलुओं को संभालती है।

— स्कॉट बिग्स

2

जब हम एमवीसी, एमवीवीएम , या प्रस्तुति मॉडल लागू करते हैं को एक एंड्रॉइड ऐप पर लागू करते हैं, तो हम वास्तव में जो चाहते हैं वह एक स्पष्ट संरचित परियोजना और अधिक महत्वपूर्ण रूप से इकाई परीक्षणों के लिए आसान है।

इस समय, तीसरे पक्ष के ढांचे के बिना, आपके पास आमतौर पर बहुत सारे कोड होते हैं (जैसे एडएक्सएक्सएक्सस्टीनर (), findViewById (), आदि), जिसमें कोई व्यावसायिक मूल्य नहीं होता है।

क्या अधिक है, आपको सामान्य JUnit परीक्षणों के बजाय एंड्रॉइड यूनिट परीक्षणों को चलाना होगा, जो चलाने के लिए उम्र लेते हैं और यूनिट परीक्षणों को कुछ अव्यवहारिक बनाते हैं। इन कारणों के लिए, कुछ साल पहले हमने एक ओपन सोर्स प्रोजेक्ट शुरू किया, रोबोबाइंडिंग - एंड्रॉइड प्लेटफॉर्म के लिए एक डेटा-बाइंडिंग प्रेजेंटेशन मॉडल फ्रेमवर्क।

रोबोइंडिंग आपको यूआई कोड लिखने में मदद करता है जो पढ़ने, परीक्षण करने और बनाए रखने में आसान है। RoboBinding की जरूरत को हटा देता है अनावश्यक जैसे कि ऐडएक्सलिस्टनर या तो , और यूआई लॉजिक को प्रेजेंटेशन मॉडल में बदल देता है, जो कि पीओजेओ है और इसे सामान्य जेयूनाइट परीक्षणों के माध्यम से परीक्षण किया जा सकता है । रोबॉइंडिंग स्वयं इसकी गुणवत्ता सुनिश्चित करने के लिए 300 से अधिक JUnit परीक्षणों के साथ आता है।

— चेंग
स्रोत

1

मेरी समझ में, एंड्रॉइड जिस तरह से MVC पैटर्न को संभालता है वह इस प्रकार है:

आपके पास एक गतिविधि है, जो नियंत्रक के रूप में कार्य करती है। आपके पास एक वर्ग है जो डेटा प्राप्त करने के लिए ज़िम्मेदार है - मॉडल, और फिर आपके पास व्यू क्लास है जो कि दृश्य है।

जब दृश्य के बारे में बात करते हैं, तो ज्यादातर लोग केवल xml में परिभाषित इसके दृश्य भाग के लिए सोचते हैं। आइए यह न भूलें कि जावा वर्ग में परिभाषित व्यू में इसके निर्माणकर्ताओं, विधियों और आदि के साथ एक कार्यक्रम हिस्सा भी है।

— Rados
स्रोत