कई JFrames का उपयोग: अच्छा या बुरा अभ्यास? [बंद किया हुआ]

Question

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

मैं सोच रहा हूँ कि क्या कई JFrame विंडो का उपयोग करना अच्छा है?

Answer 1

मैं सोच रहा हूँ कि क्या कई JFrames का उपयोग करना अच्छा है?

बुरा (बुरा, बुरा) अभ्यास।

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

---

एक जीयूआई में कई तत्वों को प्रदर्शित करने के कई तरीके हैं, जैसे:

• CardLayout(लघु डेमो। ) चलो अच्छा ही हुआ:
  1. संवाद की तरह जादूगर दिखा रहा है।
  2. प्रदर्शित सूची, वृक्ष आदि उन वस्तुओं के लिए चयन जिनमें एक संबद्ध घटक है।
  3. कोई घटक और दृश्य घटक के बीच फ़्लिप करना।
• JInternalFrame/JDesktopPane आमतौर पर एमडीआई के लिए उपयोग किया जाता है ।
• JTabbedPane घटकों के समूहों के लिए।
• JSplitPane दो घटकों को प्रदर्शित करने का एक तरीका, जिसमें एक या दूसरे (आकार) के बीच का महत्व उपयोगकर्ता के अनुसार भिन्न होता है।
• JLayeredPane अब तक कई अच्छी तरह से .. घटक।
• JToolBarआमतौर पर कार्यों या नियंत्रणों के समूह होते हैं। जीयूआई के आसपास खींचा जा सकता है, या इसे पूरी तरह से उपयोगकर्ता की जरूरत के अनुसार बंद कर सकता है। जैसा कि ऊपर बताया गया है, ऐसा करने वाले माता-पिता के अनुसार कम से कम / बहाल करेगा।
• एक में आइटम JList(नीचे सरल उदाहरण)।
• के रूप में नोड्स में JTree।
• नेस्टेड लेआउट ।
  
  

लेकिन अगर वे रणनीतियाँ किसी विशेष उपयोग के मामले में काम नहीं करती हैं, तो निम्नलिखित प्रयास करें। एक एकल मुख्य की स्थापना करें JFrame, फिर बाकी फ़्लोटिंग तत्वों के लिए JDialogया JOptionPaneउदाहरण दिखाई देते हैं, संवाद के लिए मूल के रूप में फ्रेम का उपयोग करते हुए।

कई चित्र

इस मामले में जहां कई तत्व चित्र हैं, इसके बजाय निम्नलिखित में से किसी एक का उपयोग करना बेहतर होगा:

1. JLabelउपयोगकर्ता जो भी उस पल में रुचि रखता है प्रदर्शित करने के लिए एक एकल (एक स्क्रॉल फलक में केंद्रित)। जैसा देखा गया है ImageViewer।
   
   
2. एक एकल पंक्ति JList। जैसा कि इस उत्तर में देखा गया है । उस 'एकल पंक्ति' का हिस्सा केवल तभी काम करता है जब वे सभी समान आयाम हों। वैकल्पिक रूप से, यदि आप मक्खी पर छवियों को स्केल करने के लिए तैयार हैं, और वे सभी समान पहलू अनुपात (उदाहरण 4: 3 या 16, 9) हैं।

Answer 2

JFrameजब से मैंने स्विंग ऐप्स की प्रोग्रामिंग शुरू की है, तब से कई दृष्टिकोण मेरे द्वारा लागू किए गए हैं। अधिकांश भाग के लिए, मैंने शुरुआत में ऐसा किया क्योंकि मुझे कोई बेहतर नहीं पता था। हालाँकि , जैसा कि मैंने एक डेवलपर के रूप में अपने अनुभव और ज्ञान में परिपक्व किया और जैसा कि कई और अधिक अनुभवी जावा देवों के विचारों को ऑनलाइन पढ़ना और अवशोषित करना शुरू किया, मैंने कई दृष्टिकोणों (वर्तमान परियोजनाओं और भविष्य की परियोजनाओं दोनों में) से दूर जाने का प्रयास किया JFrame) केवल साथ मिलने के लिए ... यह प्राप्त करें ... मेरे ग्राहकों से प्रतिरोध! जैसे ही मैंने JInternalFrameअलग-अलग घटकों के लिए "बच्चे" खिड़कियों को नियंत्रित करने के लिए मोडल संवादों को लागू करना शुरू किया , मेरे ग्राहक शिकायत करने लगे! मैं काफी हैरान था, जैसा कि मैं सोच रहा था कि मैं सबसे अच्छा अभ्यास कर रहा हूं! लेकिन, जैसा कि वे कहते हैं, "एक खुशहाल पत्नी एक खुशहाल जीवन है।" वही अपने ग्राहकों के लिए चला जाता है। बेशक, मैं एक ठेकेदार हूं इसलिए मेरे अंतिम-उपयोगकर्ता मेरे पास, डेवलपर तक सीधी पहुंच रखते हैं, जो स्पष्ट रूप से एक सामान्य परिदृश्य नहीं है।

इसलिए, मैं कई JFrameदृष्टिकोणों के लाभों की व्याख्या करने जा रहा हूं , साथ ही साथ कुछ मिथक-पर्दाफाश भी कर रहा हूं जो दूसरों ने प्रस्तुत किए हैं।

1. लेआउट में अंतिम लचीलापन - अलग-अलग JFrameएस की अनुमति देकर , आप अपने अंतिम-उपयोगकर्ता को फैलाने और उसके स्क्रीन पर क्या है इसे नियंत्रित करने की क्षमता देते हैं। अवधारणा "खुला" और गैर-संकुचित महसूस करती है। आप इसे खो देते हैं जब आप एक बड़े JFrameऔर एस के एक झुंड की ओर जाते हैं JInternalFrame।
2. बहुत ही संशोधित अनुप्रयोगों के लिए अच्छी तरह से काम करता है - मेरे मामले में, मेरे अधिकांश अनुप्रयोगों में 3 - 5 बड़े "मॉड्यूल" हैं जिनका वास्तव में एक-दूसरे के साथ कोई लेना-देना नहीं है। उदाहरण के लिए, एक मॉड्यूल एक सेल्स डैशबोर्ड हो सकता है और एक अकाउंटिंग डैशबोर्ड हो सकता है। वे एक दूसरे से या कुछ भी बात नहीं करते। हालाँकि, कार्यकारी दोनों को खोलना चाहता है और टास्कबार पर अलग फ्रेम होने से उसका जीवन आसान हो जाता है।
3. अंत उपयोगकर्ताओं के लिए बाहरी सामग्री को संदर्भित करना आसान बनाता है - एक बार, मेरे पास यह स्थिति थी: मेरे ऐप में एक "डेटा दर्शक" था, जिसमें से आप "नया जोड़ें" पर क्लिक कर सकते थे और यह डेटा प्रविष्टि स्क्रीन खोल देगा। प्रारंभ में, दोनों JFrameएस थे । हालाँकि, मैं चाहता था कि डेटा एंट्री स्क्रीन एक JDialogअभिभावक हो, जो डेटा व्यूअर हो। मैंने बदलाव किया, और तुरंत मुझे एक अंतिम-उपयोगकर्ता से एक कॉल मिला, जो इस तथ्य पर बहुत अधिक निर्भर था कि वह दर्शक को कम या बंद कर सकता है और संपादक को खुला रख सकता है जबकि उन्होंने कार्यक्रम के एक अन्य भाग (या एक वेबसाइट, मैं डॉन को संदर्भित किया है) 'याद है)। वह मल्टी-मॉनीटर पर नहीं है , इसलिए उसे एंट्री डायलॉग के लिए पहले और कुछ और होने की जरूरत है, जिसमें डेटा दर्शक पूरी तरह से छिपा हो। यह एक के साथ असंभव था JDialogऔर निश्चित रूप से एक के JInternalFrameरूप में अच्छी तरह से असंभव हो गया होता । मैंने अपने संन्यास के JFramesलिए अलग होने के कारण इसे बदल दिया , लेकिन इसने मुझे एक महत्वपूर्ण सबक सिखाया।
4. मिथक: हार्ड कोड करना - यह मेरे अनुभव में सच नहीं है। मैं यह नहीं देखता कि ए की JInternalFrameतुलना में बनाना आसान क्यों होगा JFrame। वास्तव में, मेरे अनुभव में, JInternalFramesबहुत कम लचीलापन प्रदान करते हैं। मैंने JFrameअपने ऐप्स में खुलने और बंद होने से निपटने का एक व्यवस्थित तरीका विकसित किया है जो वास्तव में अच्छा काम करता है। मैं फ्रेम के कोड के भीतर से लगभग पूरी तरह से फ्रेम को नियंत्रित करता हूं; नए फ्रेम का निर्माण, SwingWorkerजो बैकग्राउंड थ्रेड्स पर डेटा की पुनर्प्राप्ति और ईडीटी पर जीयूआई कोड को नियंत्रित करता है, फ्रेम को सामने लाने / बहाल करने के लिए यदि उपयोगकर्ता इसे दो बार खोलने की कोशिश करता है, आदि। आप सभी को मेरा JFrameएस खोलने की आवश्यकता है। सार्वजनिक स्थैतिक विधि open()और खुली विधि को कॉल करें , एक windowClosing()घटना के साथ संयुक्त बाकी को संभालता है (क्या फ्रेम पहले से खुला है? क्या यह नहीं है, लेकिन लोड हो रहा है? आदि) मैंने इसे एक दृष्टिकोण बनाया है, इसलिए प्रत्येक फ्रेम के लिए इसे लागू करना मुश्किल नहीं है। ।
5. मिथक / अप्रमाणित: संसाधन भारी - मैं इस सट्टा कथन के पीछे कुछ तथ्य देखना चाहूंगा। हालाँकि, शायद, आप एक JFrameज़रूरत से ज़्यादा जगह की ज़रूरत कह सकते हैं JInternalFrame, भले ही आप 100 JFrameएस खोलें , आप वास्तव में कितने अधिक संसाधनों का उपभोग करेंगे? यदि आपकी चिंता संसाधनों के कारण मेमोरी लीक है: dispose()कचरा संग्रह के लिए फ्रेम द्वारा उपयोग किए जाने वाले सभी संसाधनों को मुक्त करना (और, फिर से मैं कहता हूं, एक JInternalFrameबिल्कुल चिंता का विषय होना चाहिए)।

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

एकाधिक फ़्रेम / फ़्रेम (प्रति ) एकल दस्तावेज़ ( SDI ) बनाम फ्रेम ( MDI ) प्रति फ्रेम में एक से अधिक दस्तावेज़ का एक बड़ा उदाहरण Microsoft Excel है। एमडीआई के कुछ लाभ:

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

SDI (एकल-दस्तावेज़ इंटरफ़ेस, अर्थात, प्रत्येक विंडो में केवल एक ही दस्तावेज़ हो सकता है):

एमडीआई (मल्टीपल-डॉक्यूमेंट इंटरफेस, यानी, हर विंडो में कई डॉक्यूमेंट हो सकते हैं):

Answer 3

मैं एक उदाहरण के साथ "उपयोगकर्ता के अनुकूल नहीं" तर्क का मुकाबला करना चाहता हूं, जो कि मैं अभी भी शामिल हूं।

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

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

कुछ महीने पहले हमें अपने ग्राहकों से इन रिपोर्ट व्यूअर विंडो को मॉडल बनाने के लिए अनुरोध मिलना शुरू हुआ, ताकि वे एक ही समय में कई रिपोर्ट खोल सकें।

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

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

इसलिए मैंने भरोसा किया और दर्शक को आदर्श बनाया। इसका मतलब है कि प्रत्येक दर्शक के पास एक टास्क-बार आइकन है।

जब पिछले हफ्ते उन्हें नवीनतम संस्करण जारी किया गया था, तो उनकी ओर से भारी प्रतिक्रिया यह है कि उन्होंने इसे पसंद किया। यह सिस्टम के लिए हमारे सबसे लोकप्रिय हाल के एन्हांसमेंट्स में से एक रहा है।

इसलिए आप आगे बढ़ें और अपने उपयोगकर्ताओं को बताएं कि वे जो चाहते हैं वह बुरा है, लेकिन अंततः यह आपको कोई एहसान नहीं करेगा।

कुछ नोट:

• JDialog का उपयोग इन मॉडल विंडो के लिए करना सबसे अच्छा अभ्यास लगता है
• ModalityTypeबूलियन modalतर्क के बजाय नए का उपयोग करने वाले कंस्ट्रक्टर का उपयोग करें । यह वही है जो इन संवादों को कार्य-बार आइकन देता है।
• मॉडल के संवादों के लिए, एक अशक्त माता-पिता को निर्माता के पास भेज दें, लेकिन उन्हें उनकी 'मूल' विंडो के सापेक्ष खोजें।
• विंडोज पर जावा के संस्करण 6 में एक बग है जिसका अर्थ है कि आपकी मुख्य विंडो आपको बताए बिना 'हमेशा शीर्ष पर' बन सकती है। इसे ठीक करने के लिए संस्करण 7 में अपग्रेड करें

Answer 4

मुख्य फ्रेम में एक JInternalFrame बनाएं और इसे अदृश्य बनाएं। फिर आप इसे आगे की घटनाओं के लिए उपयोग कर सकते हैं।

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);

Answer 5

पिछली बार जब मैंने स्विंग को टच किया था तब से कुछ समय हो गया है लेकिन सामान्य तौर पर ऐसा करना एक बुरा अभ्यास है। कुछ मुख्य नुकसान जो दिमाग में आते हैं:

• यह अधिक महंगा है: आपको JFrame खींचने के लिए और अधिक संसाधनों का आवंटन करना होगा जो कि अन्य प्रकार के विंडो कंटेनर, जैसे कि Dialog या JInternalFrame।

• उपयोगकर्ता के अनुकूल नहीं: एक साथ अटके हुए JFrame के एक झुंड में नेविगेट करना आसान नहीं है, ऐसा लगेगा कि आपका आवेदन असंगत और खराब डिज़ाइन के अनुप्रयोगों का एक सेट है।

• JInternalFrame का उपयोग करना आसान है। यह एक तरह से रेटोरिअल है, अब यह आसान है और अन्य लोग (या अधिक खाली समय के साथ) हम से पहले ही डेस्कटॉप और JInternalFrame पैटर्न के माध्यम से सोच चुके हैं, इसलिए मैं इसका उपयोग करने की सलाह दूंगा।

Answer 6

बुरा अभ्यास जरूर करें। एक कारण यह है कि यह इस तथ्य के लिए बहुत 'उपयोगकर्ता के अनुकूल' नहीं है कि हर JFrameनया टास्कबार आइकन दिखाता है। कई JFrames को नियंत्रित करने से आपको अपने बालों को बाहर निकालना होगा।

व्यक्तिगत रूप से, मैं JFrameआपके आवेदन के लिए वन का उपयोग करूंगा । कई चीजों को प्रदर्शित करने के तरीके आपके ऊपर हैं, कई हैं। Canvases, JInternalFrame, CardLayout, यहां तक कि JPanelसंभवतः है।

एकाधिक JFrame ऑब्जेक्ट्स = दर्द, परेशानी और समस्याएं।

Answer 7

मुझे लगता है कि कई Jframeएस का उपयोग करना एक अच्छा विचार नहीं है।

इसके बजाय हम उपयोग कर सकते हैं JPanelरों की तुलना में अधिक एक या अधिक JPanelएक ही में JFrame।

इसके अलावा, हम इस JPanelएस के बीच स्विच कर सकते हैं । इसलिए यह हमें चीज़ में से अधिक को प्रदर्शित करने की स्वतंत्रता देता है JFrame।

प्रत्येक के लिए JPanelहम विभिन्न चीजों को डिजाइन कर सकते हैं और यह सब एक बार में एक JPanelपर प्रदर्शित किया जा सकता है JFrame।

प्रत्येक या 'JButton JPanel` के लिए इस JPanelउपयोग के बीच स्विच करने JMenuBarके JMenuItemsलिए ।JPanelfor each

एक से अधिक JFrameएक अच्छा अभ्यास नहीं है, लेकिन अगर हम एक से अधिक चाहते हैं तो कुछ भी गलत नहीं है JFrame।

लेकिन यह बेहतर है कि JFrameहमारी विभिन्न आवश्यकताओं के लिए एक को बदलने के बजाय कई JFrameएस।

Answer 8

यदि फ़्रेम एक ही आकार के होने जा रहे हैं, तो फ़्रेम क्यों न बनाएं और फ़्रेम को पास करें, इसके बजाय इसके संदर्भ के रूप में।

जब आप फ्रेम पास कर लेते हैं तो आप यह तय कर सकते हैं कि इसे कैसे आबाद किया जाए। यह आंकड़ों के एक सेट के औसत की गणना करने के लिए एक विधि होने जैसा होगा। क्या आप बार-बार विधि का निर्माण करेंगे?

Answer 9

यह एक अच्छा अभ्यास नहीं है, लेकिन भले ही आप इसका उपयोग करना चाहते हैं, लेकिन आप सिंगलटन पैटर्न को इसके अच्छे के रूप में उपयोग कर सकते हैं। मैंने अपने अधिकांश प्रोजेक्ट में सिंगलटन पैटर्न का उपयोग किया है।