UI पर प्रगति की रिपोर्टिंग के लिए सर्वश्रेष्ठ रणनीति

11

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

UI और लॉजिक लेयर्स के करीबी युग्मन से बचने के लिए, आमतौर पर किसी प्रकार के प्रॉक्सी के माध्यम से संचार होना सबसे अच्छा होता है। यही है, बैक-एंड को अपने स्वयं के UI तत्वों में हेरफेर नहीं करना चाहिए, या सीधे मध्यस्थ परत के साथ बातचीत भी नहीं करनी चाहिए।

जाहिर है, इस काम को करने के लिए कहीं न कहीं कॉल बैक करना होगा। मैंने आमतौर पर इसे दो तरीकों में से एक में लागू किया है:

बैक-एंड के लिए एक परिवर्तनशील वस्तु को पास करें, और बैक-एंड में प्रगति पर इसमें बदलाव करें। जब कोई परिवर्तन होता है तो ऑब्जेक्ट फ्रंट-एंड को सूचित करता है।
फॉर्म के कॉल-बैक फ़ंक्शन void f(ProgressObject)या ProgressObject -> unitबैक-एंड इनवॉइस पास करें। इस मामले में, बैक-एंड निर्माण करता है ProgressObjectऔर यह पूरी तरह से निष्क्रिय है। जब भी मैं प्रगति की रिपोर्ट करना चाहता हूं, उसे हर बार एक नई वस्तु का निर्माण करना चाहिए।

इन तरीकों की कमियां और फायदे क्या हैं? क्या उपयोग करने के लिए सहमत-सर्वोत्तम विधि है? क्या उनके उपयोग के लिए अलग-अलग परिस्थितियां हैं?

क्या रिपोर्टिंग प्रगति की पूरी तरह से अलग-अलग तकनीकें हैं जिन्हें मैंने अनदेखा कर दिया है?

design object-oriented gui

— GregRos
स्रोत

1

उत्परिवर्ती बनाम अपरिवर्तनीय के बारे में, फायदे और कमियां उसी तरह हैं जैसे वे कहीं और हैं। प्रगति वस्तु के संबंध में, यह बहुत हल्का हो सकता है; यह एकल संख्या के रूप में सरल हो सकता है: एक प्रतिशत।

— रॉबर्ट हार्वे

@RobertHarvey प्रगति ऑब्जेक्ट का आकार आमतौर पर UI आवश्यकताओं पर निर्भर करता है। उदाहरण के लिए विंडोज कॉपी डायलॉग देखें। मुझे लगता है कि इसके लिए बहुत सारी जानकारी चाहिए।

— ग्रेग्रोस

1

@RobertHarvey यह मेरे लिए खबर है। यह क्या है?

— ग्रेगरोस

1

मैं काट लूंगा। हम BackgroundWorkerउस आरएच का उपयोग करते हैं। एक "प्रगति फ़ॉर्म", आदि के साथ एक कस्टम वर्ग में लिपटे हुए और एक अपवाद के संचार के लिए एक सरल तंत्र - जैसा BackgroundWorkerकि डिज़ाइन द्वारा एक अलग थ्रेड में चलता है। कुछ हद तक हम इसकी विशेषताओं का उपयोग .Net द्वारा सुझाए गए तरीके से करते हैं और फिर इसे मुहावरेदार कहा जा सकता है। और किसी भी भाषा / ढांचे के संदर्भ में "मुहावरेदार" सबसे अच्छा हो सकता है।

— राडारबॉब

2

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

— डॉक ब्राउन

8

बैक-एंड के लिए एक परिवर्तनशील वस्तु को पास करें, और बैक-एंड में प्रगति पर इसमें बदलाव करें। जब कोई परिवर्तन होता है तो ऑब्जेक्ट फ्रंट-एंड को सूचित करता है।

यदि इस संबंध में बैकएंड सूचित नहीं किया गया तो दक्षता को संतुलित करना मुश्किल है। देखभाल के बिना आप पा सकते हैं कि आपकी प्रगति को बढ़ाने से उस समय को दोगुना या तिगुना हो जाता है जब आप एक बहुत ही चिकनी प्रगति अद्यतन के लिए लक्ष्य कर रहे हैं, तो ऑपरेशन को पूरा करने में समय लगता है।

फॉर्म v (f (ProgressObject) या ProgressObject -> यूनिट के बैक-एंड इनवॉइस के रूप में कॉल-बैक फ़ंक्शन पास करें। इस स्थिति में, बैक-एंड ProgressObject का निर्माण करता है और यह पूरी तरह से निष्क्रिय है। जब भी मैं प्रगति की रिपोर्ट करना चाहता हूं, उसे हर बार एक नई वस्तु का निर्माण करना चाहिए।

मुझे यहाँ इतना अंतर नहीं मिलता है।

क्या रिपोर्टिंग प्रगति की पूरी तरह से अलग-अलग तकनीकें हैं जिन्हें मैंने अनदेखा कर दिया है?

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

2

यह एक पुश और पुल अधिसूचना तंत्र के बीच का अंतर है।

यदि आप बैक-एंड कार्य को बैकग्राउंड / वर्कर थ्रेड में निष्पादित करने की अपेक्षा करते हैं, तो म्यूटेबल ऑब्जेक्ट ( पुल ) को UI द्वारा बार-बार पोल किया जाना चाहिए और सिंक्रनाइज़ किया जाना चाहिए।

कॉलबैक ( पुश ) केवल यूआई के लिए काम पैदा करेगा जब कुछ वास्तव में बदलता है। कई UI फ्रेमवर्क में UI थ्रेड पर चलने वाले कोड का एक टुकड़ा बनाने के लिए एक कार्यकर्ता थ्रेड से एक इनवोकऑनह्रेड कॉल करने योग्य है ताकि आप वास्तव में थ्रेड से संबंधित खतरों में चलने के बिना बदलाव कर सकें। (जानबूझ का मजाक)

सामान्य धक्का सूचनाओं में बेहतर होते हैं क्योंकि वे केवल तभी काम करते हैं जब काम करने की आवश्यकता होती है।

— शाफ़्ट सनकी
स्रोत

1

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

— रोबोट को

प्रगति ऑब्जेक्ट को नीचे भेजना अधिसूचना तंत्र को अस्पष्ट कर सकता है जिसका आप बैक-एंड से उपयोग कर रहे हैं, क्योंकि हो सकता है कि प्रगति ऑब्जेक्ट कॉल-बैक कर रहा हो। मैंने वास्तव में कभी भी एक पुल तंत्र का उपयोग नहीं किया है जहाँ तक मुझे याद है, और मैं इसके बारे में भूल गया: पी

— ग्रेगरोस 15

The mutable object (the pull) will need to be repeatably polled by the UI and synchronized if you expect the back-end task to be executed in a background/worker thread.

- नहीं यदि उत्परिवर्तनीय वस्तु स्वयं संवाद है, या इसके लिए एक कार्यशील इंटरफ़ेस है। बेशक, यह एक कॉलबैक के लिए वैसे भी है।

— रॉबर्ट हार्वे

1

है ना? ओपी स्पष्ट रूप से एक धक्का तंत्र के दो अलग-अलग रूपों का वर्णन करता है, किसी में भी एक मतदान आवश्यक नहीं है।

— डॉक ब्राउन

0

मैं AngularJS के साथ वेबस्केट का उपयोग कर रहा हूं। जब सामने का छोर एक संदेश प्राप्त करता है, तो इसे एक निर्दिष्ट संदेश क्षेत्र में प्रदर्शित करता है जो कुछ सेकंड के बाद खाली करने के लिए फ़ेड करता है। पीछे के छोर पर मैं एक संदेश कतार में स्थिति संदेश पोस्ट करता हूं। मैं केवल पाठ भेजता हूं, लेकिन कोई कारण नहीं है कि मैं प्रतिशत पूर्ण या स्थानांतरण गति जैसे मूल्यों के साथ स्थिति वस्तु नहीं भेज सकता।

— TMN
स्रोत

0

आप अपने "दो तरीकों" का उल्लेख करते हैं जैसे कि वे अलग-अलग अवधारणाएं हैं लेकिन मैं उस पर थोड़ा पीछे जाना चाहता हूं।

बैक-एंड के लिए एक परिवर्तनशील वस्तु को पास करें, और बैक-एंड में प्रगति पर इसमें बदलाव करें। जब कोई परिवर्तन होता है तो ऑब्जेक्ट फ्रंट-एंड को सूचित करता है।

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

लाभ और कमियों के लिए ...

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

विधि (1) के लिए एक ताकत यह है कि इंटरफ़ेस पर कई तरीकों को रखना आसान है, क्योंकि विधि (2) के कई कॉलबैक या कई संदर्भों के लिए स्विच स्टेटमेंट के साथ सिंगल कॉलबैक से निपटना आसान है।

— डैनियल टी।
स्रोत

-2

आपके द्वारा उपयोग की जाने वाली तकनीकें बहुत भिन्न हो सकती हैं।

मैं अलग-अलग परिदृश्य के साथ जानने की कोशिश करता हूं

डीबी के लिए अनुरोध
फ़ाइल डाउनलोड करें

Db के लिए एक साधारण लॉगिन अनुरोध (मतलब एक db से एक db से प्रतिक्रिया) एक रिपोर्ट प्रगति की जरूरत नहीं है, लेकिन यह अलग कार्य पूर्व में UI थ्रेड को बंद कर सकता है। async या बैकग्राउंडर, यहाँ आपको परिणाम के लिए केवल एक कॉलबैक की आवश्यकता है।

लेकिन क्या होगा यदि आप 1ml आइटम के साथ अपनी सभी इन्वेंट्री देखने के लिए क्वेरी करते हैं? इस क्वेरी को पूरा होने में कई मिनट लगने चाहिए, इसलिए इस स्थिति में आपको फॉर्म / आइटम में अपने व्यापार तर्क में अपनी पारेषण प्रगति को लागू करने की आवश्यकता है, तो आप अपने यूआई को अपडेट कर सकते हैं और विकल्प रद्द कॉलबैक दे सकते हैं।

फ़ाइल डाउनलोड के लिए एक ही मामला। आप हमेशा यहां अपनी प्रगति कॉलबैक बाइट्स के रूप में लागू कर सकते हैं, और http पर सभी कॉम्यूनिकेशन नियंत्रण बहुत सामान्य रूप से है।

अपने व्यक्तिगत दृष्टिकोण पर मैं अपने व्यवसाय प्रगति तर्क को केवल अपने ग्राहकों के लिए लागू करता हूं, अंत-बिंदु के साथ अन्य वस्तु साझा करने से बचता हूं।

— मार्को लुओंगो
स्रोत

1

यह वास्तव में फायदे / नुकसान के बारे में सवाल का जवाब नहीं देता है।

— बेन्नी

UI पर प्रगति की रिपोर्टिंग के लिए सर्वश्रेष्ठ रणनीति - कॉलबैक कैसे होना चाहिए?