ब्राउज़र-आधारित एप्लिकेशन या स्टैंड-अलोन जीयूआई ऐप?

Question

मुझे यकीन है कि इससे पहले पूछा गया है, लेकिन मुझे यह नहीं मिल रहा है।

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

मैं वर्तमान में जीआईआई के लिए wxPython के साथ लागू एक पायथन कार्यक्रम पर काम कर रहा हूं। एप्लिकेशन बस उपयोगकर्ता-प्रविष्टि फॉर्म और संवाद है। मैं अपने पास विजेट (भविष्य के विस्तार के लिए) के कारण पीईक्यूटी में जाने पर विचार कर रहा हूं, फिर मुझे एहसास हुआ कि मैं शायद एक ही सामान को करने के लिए ब्राउज़र का उपयोग कर सकता हूं।

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

---

संपादित स्पष्टीकरण के लिए, अभी आवेदन ब्राउज़र आधारित होगा के रूप में, नहीं वेब आधारित। सभी जानकारी क्लाइंट कंप्यूटर पर स्थानीय रूप से संग्रहीत की जाएगी; कोई भी सर्वर कॉल करने की आवश्यकता नहीं होगी और इंटरनेट एक्सेस की आवश्यकता नहीं है (हालांकि बाद में यह आ सकता है)। यह WxPython/PyQt GUI के बजाय बस ब्राउज़र GUI होगा। उम्मीद है कि समझ में आता है।

Answer 1

ब्राउज़र आधारित करने के लिए स्पष्ट फायदे:

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

और जीयूआई के लिए आधारित:

• कुछ अनुप्रयोगों (जैसे: छवि संपादन) यकीनन एक देशी जीयूआई आवेदन
• नेटवर्क पहुँच

की आवश्यकता नहीं है में बेहतर काम भी देखें this question पर मेरी टिप्पणियां:

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

यह निर्णय के लिए आता है: क्या आप विकास प्रयास को कम करना चाहते हैं और एक जीयूआई है जो प्रत्येक प्लेटफॉर्म पर बिल्कुल सही नहीं लग रहा है और महसूस करता है, या आप उपयोगकर्ता अनुभव को अधिकतम करना चाहते हैं? यदि आप दूसरा विकल्प चुनते हैं, तो आपको प्रत्येक प्लेटफ़ॉर्म के लिए एक सामान्य बैकएंड और कस्टम UI विकसित करना होगा। [संपादित करें: या एक वेब अनुप्रयोग का उपयोग करें।]

एक और सोचा था कि मैं सिर्फ था: तुम भी है कि आपके आवेदन manipulates और जहां यह संग्रहीत किया जाता है जिस प्रकार का डेटा विचार करने की जरूरत है, और उन है कि के बारे में कैसा महसूस होता होगा। लोग स्पष्ट रूप से ठीक हैं, उनके फेसबुक प्रोफाइल डेटा को वेबसर्वर पर संग्रहीत किया जाता है, लेकिन यदि आप एमईओबी जैसे वित्त आवेदन लिख रहे हैं तो वे अलग-अलग महसूस कर सकते हैं और आप अपने सभी व्यक्तिगत वित्तीय विवरण अपने सर्वर पर स्टोर करना चाहते हैं। आप इसे काम करने में सक्षम हो सकते हैं, लेकिन इसके लिए आवश्यक सुरक्षा को लागू करने और उपयोगकर्ताबेस को आश्वस्त करने के लिए बहुत सारे प्रयास की आवश्यकता होगी कि उनका डेटा सुरक्षित है। उस स्थिति में आप तय कर सकते हैं कि यदि आप मूल जीयूआई ऐप के साथ जाते हैं तो समग्र प्रयास कम होता है।

Answer 2

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

Answer 3

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

जब तक आपकी मुख्य सुविधा है, इंटरफेस ("यदि यह एक मुख्य व्यवसाय समारोह है -। यह अपने आप करते हैं, कोई बात नहीं क्या", देखने Joel on Software से In Defense of Not-Invented-Here Syndrome), मुझे लगता है कि ब्राउज़र प्रदर्शन करने में सक्षम हो जाएगा स्क्रैच से जीयूआई विकसित करने से बेहतर प्रस्तुति और हैंडलिंग फॉर्म। इसके अलावा, इसका उल्लेख न करें कि एचटीएमएल फॉर्म बनाने और ब्राउजर द्वारा पोस्ट किए जाने के बाद उन्हें प्रोसेस करने के विरोध में जीयूआई को कोड करने में काफी समय लगेगा।

जो मैंने पहले पाया था वह था कि मुझे एक दोस्त से एक सर्वेक्षण से परिणाम दर्ज करने के लिए आवेदन लिखने के लिए कहा गया था। सबसे पहले, मैं सर्वेक्षण को अपने सभी रेडियो बक्से के साथ दिखाने के लिए जावा एप्लेट लिख रहा था, जब उसने मुझे मारा कि मैं एक साधारण HTTP सर्वर लिखने से बेहतर होगा जो फॉर्म उत्पन्न करेगा और उन्हें संसाधित करेगा।

क्या यह वास्तव में नीचे आता है कि क्या आप या तो विकसित कर रहे हैं के लिए है:

1. यूजर इंटरफेस
2. डेटा प्रविष्टि आवेदन

आप एक डेटा प्रविष्टि आवेदन कर रहे हैं, तो ब्राउज़र इंटरफ़ेस को ब्राउज़र पर छोड़ दें, और अपनी मूल कार्यक्षमता पर ध्यान केंद्रित करें।

Answer 4

ब्राउज़र आधारित इंटरफेस के लाभ:

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

जीयूआई आधारित इंटरफेस के लाभ:

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

Answer 5

बहुत अच्छे सबूत हैं कि ज्यादातर मामलों में ट्रम्प-कार्ड समस्या तैनाती और समर्थनशीलता है। सामान्य रूप से ब्राउज़र ऐप्स कम ओवरहेड होते हैं; दो दर्जन से अधिक उपयोगकर्ताओं को लागू करने और समर्थन करने से पर्याप्त समर्थन संसाधनों का उपभोग हो सकता है। डेस्कटॉप सत्यापन के
पठन स्तर - - डेस्कटॉप
जवाबदेही - डेस्कटॉप
उपयोगकर्ता स्वीकृति - डेस्कटॉप

यूआई गुणवत्ता:

मैं एक मेज एक या दो साल पहले ऐसा ही कुछ दिखाया देखा
आदि - डेस्कटॉप
आदि - डेस्कटॉप
& स्थापित करें - ब्राउज़र
और ब्राउज़र जीतता है।

Answer 6

के एक पल है कि विकास/तैनाती/रखरखाव प्रयास/लागत बराबर है के लिए नाटक करते हैं और हम आवेदन उपयोगकर्ता के नजरिए से इस पर गौर:

कौन सा यूआई उपयोगकर्ता अधिक उपयोगी खोजने के लिए जा रहा है?

के उपयोग के

• आसानी शर्तों
• जवाबदेही
• परिचित नेविगेशन/उपयोग प्रतिमानों
• अन्य उपकरण/मंच पर उपयोग में अनुप्रयोगों की तरह अधिकांश (यानी, देशी)
में

मैं समझता हूं कि "उपयोगी" व्यक्तिपरक है। यदि मैं इससे दूर हो सकता हूं तो मैं व्यक्तिगत रूप से कभी भी एक उपयोगकर्ता के रूप में (डेवलपर नहीं, एक वेब इंटरफ़ेस के रूप में) कभी भी उपयोग नहीं करता। मैं से नफरत करता हूं।

कुछ ऐसे अनुप्रयोग हैं जो ब्राउज़र आधारित ऐप्स के रूप में विकसित करने के लिए समझ में नहीं आते हैं।

एक विकास परिप्रेक्ष्य

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

कई, कई स्टैंडअलोन जीयूआई अनुप्रयोग हैं जो केवल भयानक हैं, कोई तर्क नहीं है। एक बहु-मंच जीयूआई के लिए विकास/तैनाती और रखरखाव गैर-तुच्छ है।

अच्छा उपयोगकर्ता-इंटरफेस विकसित करना कठिन, अवधि है।

वास्तविकता यह है कि मैंने पिछले 10 वर्षों में अधिकतर वेब आधारित अनुप्रयोगों को विकसित करने में अपनी जिंदगी बनाई है, क्योंकि वे विकसित करने के लिए तेज़ हैं, तैनात करने में आसान हैं और पर्याप्त उपयोगिता प्रदान करते हैं जो लोग उन्हें उपयोग करते हैं।

मुझे विश्वास नहीं है कि अधिकतर उपयोगकर्ता वैकल्पिक विकल्प दिए जाने पर वेब इंटरफ़ेस का उपयोग करेंगे।

IMNSHO

Answer 7

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

रहे हैं जैसे एक वेब आवेदन किया जा रहा करने के लिए आकर्षित-पीठ, ..

यह एक वेब पेज है। ऐसी चीजें हैं जो आप आसानी से नहीं कर सकते हैं (आसानी से)

आप कुछ करने के लिए आसानी से ctrl + j कुंजी को मानचित्र नहीं कर सकते हैं। उदाहरण के लिए: गूगल स्प्रैडशीट कीबोर्ड शॉर्टकट मैप करने के लिए कोशिश करता है और काम करता है समय की सबसे, कभी कभी शॉर्टकट के ब्राउज़रों डिफ़ॉल्ट से निपटने अधिक लेता है ..

आप गुर्राना अलर्ट (एक ओएस एक्स अधिसूचना ढांचा) नहीं कर सकता। आप फाइल सिस्टम तक नहीं पहुंच सकते हैं। ऑफलाइन होने पर पहुंच की अनुमति देना मुश्किल है।

जावास्क्रिप्ट बहुत सीपीयू-भारी है।

Google स्प्रेडशीट दस्तावेज़ का आकार बदलने का प्रयास करें, या डिग पर एक पृष्ठ लोड करें (एक बहुत ही जावास्क्रिप्ट भारी साइट) - ब्राउज़र CPU उपयोग थोड़ी देर के लिए 100% पर होगा .. मूल डेस्कटॉप एप्लिकेशन में ऐसा करना छोटा है

जब आप उन्नयन करते हैं, तो आप उन्हें अपने सभी उपयोगकर्ताओं पर बल देते हैं। डेस्कटॉप एप्लिकेशन के साथ, उनके पास अपग्रेड करने का विकल्प नहीं है। उदाहरण के लिए, मुझे Google रीडर अपग्रेड में से कोई एक पसंद नहीं आया, लेकिन मैं अटक गया था। NetNewsWire (एक डेस्कटॉप अनुप्रयोग) का उपयोग करना, अगर मैं नवीनतम संस्करण में बदलाव पसंद नहीं है, मैं काफी आसानी से इस एक का उपयोग कर रख सकते हैं (या इसे प्रयास करें, और ढाल)

आप वेब सर्वर होना चाहिए हर समय सुलभ, कभी

के लिए सर्वर गायब हो जाता है, तो अपने उपयोगकर्ताओं कोई सहारा नहीं है। आवेदन चला गया है। यदि यह 10 मिनट के लिए नीचे है, वे इसे इस्तेमाल नहीं कर सकते।

---

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

"जावास्क्रिप्ट बहुत CPU- है (उदाहरण के <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?> के लिए या यहां तक ​​कि सर्वर-साइड स्क्रिप्टिंग का उपयोग करके) फार्म और डायलॉग बॉक्स HTML और जावास्क्रिप्ट में करने के लिए आसान कर रहे हैं:

" यह एक वेब -page है " भारी ": आपके आवेदन किसी भी जावास्क्रिप्ट (शायद कुछ क्लाइंट की ओर इनपुट सत्यापन उपयोगकर्ता क्लिक करता है की आवश्यकता होगी जैसी नहीं लगती" "? उन्हें किसी भी इनपुट त्रुटियों के बारे में चेतावनी देने के लिए,

जमा करें)" मजबूर उन्नयन ": मैं, यह वांछनीय हो सकता है की कल्पना के रूप में आप उन inputing नहीं चाहता पुराने तरीके से डेटा।

"सर्वर सुलभ होनी चाहिए": एक मुद्दा हो सकता है, लेकिन मुझे नहीं लगता कि यह एक बड़ा एक होगा .. आप एक केंद्रीय डेटाबेस में सभी उपयोगकर्ताओं डेटा स्टोर करना चाहते कहो, इस मुद्दा बन जाता है वैसे भी अपरिहार्य - वेब और डेटाबेस सर्वर चलाना केवल एक डेटाबेस (जीयूआई से कनेक्ट करने के लिए) से अधिक काम नहीं है

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

Answer 8

सब कुछ फायदे और disavantages है, लेकिन:

मैं अभी तक स्थानीय होस्ट, इंट्रानेट या इंटरनेट का उपयोग करने के लिए अच्छा लगता है पर एक ब्राउज़र आधारित अनुप्रयोग का उपयोग करने के लिए है, उत्तरदायी है, और जो यूजर इंटरफेस प्रतिसाद नहीं है ' एचटीएमएल/जेएस/सीएसएस की सीमाओं से सख्ती से सीमित नहीं है।

नोट: फ्लैश/जावा-आधारित यूआई एक अपवाद है (लेकिन यह कुछ संबंधों में भी बदतर है और मुझे नहीं लगता कि यह वास्तव में आप यहां क्या बात कर रहे हैं)।

Answer 9

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

रूप में मैं इस लिखने के साथ ही मैं अपने ब्राउज़र विंडो को देखो, खिड़की शायद 12 इंच लंबा है, लेकिन खिड़की जिसमें मैं टाइप केवल शायद 3 इंच है। और कुल मिलाकर यह है कि 12 इंच से बाहर है, शायद दो पूर्ण इंच ब्राउज़र टूलबार, टैब, बुकमार्क की पंक्तियों और प्रस्थिति, जिनमें से कोई भी वेब अनुप्रयोग मैं के साथ बातचीत कर रहा हूँ के साथ कोई लेना देना साथ लिया जाता है। बहुत सारी बर्बाद जगह है (संपादन विंडो पूरी तरह से खिड़की के रूप में चौड़ी नहीं है, उदाहरण के लिए), जिन चीजों की मुझे आवश्यकता नहीं है, उन जगहों से भरा स्थान इत्यादि। कुछ सबसे मौलिक नियंत्रण (बैक बटन, मैं ' मैं आपको देख रहा हूं) पूरी तरह खराब डिजाइन किए गए वेब अनुप्रयोगों को तोड़ सकता है।

इस तथ्य का जिक्र नहीं है कि अगर मैं काफी लंबी प्रतिक्रिया टाइप करता हूं तो अब मैं स्क्रॉलबार के दो सेटों के साथ समाप्त होता हूं। stackoverflow.com आंशिक रूप से मुझे एक आकार बदलने योग्य टेक्स्ट क्षेत्र देकर संबोधित करता है लेकिन मुझे अभी भी पाठ को स्क्रॉल करने के लिए आंतरिक स्क्रॉलबार से बातचीत करना है, फिर ऊपर या नीचे ऐप नियंत्रणों तक पहुंचने के लिए पूरी विंडो को ऊपर या नीचे स्क्रॉल करें संपादन खिड़की के।

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

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

Answer 10

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

मैं इसके लिए सभी हूँ ...

Answer 11

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

वेब आधारित यूआई अधिक पोर्टेबल होगा क्योंकि विकास को एक मंच पर बाध्य नहीं किया जाता है, और यदि एप्लिकेशन रिमोट में चलता है तो इसे अपडेट करना और इसे जांचना आसान है (GUI ... को छोड़कर) एक सतत वातावरण (आपका सर्वर)। लेकिन आपको यह समझना चाहिए कि यह सब महान और वास्तव में ग्राउंडब्रैकिंग है, लेकिन यह कुछ गंभीर कमियों के साथ आता है। आप केवल सभी लक्ष्य प्रणाली के तहत आवेदन नहीं डिबग चाहिए, लेकिन यह भी प्रत्येक एकल ब्राउज़र के तहत प्रत्येक एकल लक्ष्य सिस्टम पर चलने ... और एक ही ब्राउज़र के कई संस्करणों मत भूलना कुछ समय के लिए coexists सकता है, और है कि प्रत्येक ब्राउज़र की सेटिंग्स शायद लोकप्रिय प्लगइन के विभिन्न सेट (और संस्करण) चला रही हैं जो इसे अलग-अलग व्यवहार करती है, और शायद नेटवर्क सेटिंग्स को उपयोगकर्ताओं द्वारा अनुकूलित किया जाएगा। तो आवेदन दूरदराज में है यह दिलचस्प नई समस्या का एक बहुत खुल जाता है, अलग अलग आईएसपी, जो आपको सर्वर, उपयोगकर्ता की मशीनों या बीच में कहीं भी की नेटवर्क समस्याओं के कारण बीच में विभिन्न समस्याओं, या सेवाओं टाइम छोड़ देंगे से शुरू। एक दूरस्थ एप्लिकेशन उन देशों के सभी उपयोगकर्ताओं के लिए एक विकल्प नहीं है जहां नेटवर्क सेवा कम गुणवत्ता वाली है, या उचित मूल्य नहीं है; यह आपके लिए भी सच है: आप केवल ऐसी सेवा प्रदान करना शुरू कर सकते हैं यदि आपके देश में बैंडविड्थ उचित और उचित मूल्य है। और अगर आवेदन कुछ उपयोगकर्ता के सिस्टम पर nontrivial करना है, तो आप शायद वैसे भी मंच निर्भर कोड का एक बहुत बनाने में बर्बाद हो जाएगा।

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

Answer 12

मेरे समाधान है इस

1. वेबसाइट अनुप्रयोगों स्पष्ट रूप से ब्राउज़रों
2. नेटवर्क अनुप्रयोगों कि तक पहुँचने ग्राहक कंप्यूटर
3. एक से अधिक ग्राहक द्वारा पहुँचा जा करने की जरूरत है कि किसी भी आवेदन ब्राउज़र से भी जाना जाता की जरूरत नहीं है पर जाने के एक समय में ब्राउज़र से भी जाना जाता
4. अनुप्रयोग जो जीयूआई के साथ रहता है और इस सॉफ्टवेयर है कि इसके उपयोग पर सुरक्षा का एक बहुत जरूरत शामिल हो सकते हैं नेटवर्क के लिए कोई स्पष्ट आवश्यकता के साथ ग्राहक प्रति इस्तेमाल किया जाएगा (एक ही सुरक्षा ब्राउज़र के लिए संबोधित किया जा सकता हालांकि आधारित)।

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

सभी निर्णय में वास्तव में आपका है! JavaFX और स्विंग का उपयोग कर जावा डेवलपर के रूप में इस समस्या के साथ मेरी समस्या का समाधान कर सकते हैं।