Çoklu JFrame Kullanımı: İyi mi Kötü Uygulama mı? [kapalı]

Görüntüleri görüntüleyen ve bir veritabanından sesler çalan bir uygulama geliştiriyorum. GUI veritabanına görüntü eklemek için ayrı bir JFrame kullanıp kullanmayacağınıza karar vermeye çalışıyorum.

Sadece birden fazla JFrame penceresi kullanmanın iyi bir uygulama olup olmadığını merak ediyorum?

Sadece birden fazla JFrame kullanmanın iyi bir uygulama olup olmadığını merak ediyorum.

Kötü (kötü, kötü) uygulama.

• Kullanıcı dostu değil: Kullanıcı yalnızca birini görmeyi beklerken görev çubuğunda birden çok simge görür. Ayrıca kodlama problemlerinin yan etkileri ..
• Kodlamak ve sürdürmek için bir kabus:
  • Bir kalıcı iletişim bu iletişim kutusunun içeriği teklifler odak dikkatine kolay fırsat - seçmek / düzeltme / Bu iptal, sonra devam edin. Birden çok çerçeve yoktur.
  • Üst öğe tıklatıldığında bir üst öğe içeren bir iletişim kutusu (veya kayan araç çubuğu) öne çıkacaktır; istenen davranış buysa bunu çerçevelere uygulamanız gerekir.

Bir GUI'de birçok öğeyi görüntülemenin çeşitli yolları vardır, örneğin:

• CardLayout(kısa demo. ). Şunun için iyi:
  1. Sihirbaz gibi iletişim kutuları gösteriliyor.
  2. İlişkili bir bileşeni olan öğeler için liste, ağaç vb. Seçimlerin görüntülenmesi.
  3. Bileşen yok ve görünür bileşen arasında çevirme.
• JInternalFrame/JDesktopPane tipik olarak bir MDI için kullanılır .
• JTabbedPane bileşen grupları için.
• JSplitPane Biri veya diğeri (boyut) arasındaki önemi kullanıcının ne yaptığına göre değişen iki bileşeni görüntülemenin bir yolu.
• JLayeredPane çok iyi .. katmanlı bileşenler.
• JToolBargenellikle eylem veya denetim grupları içerir. GUI etrafında sürüklenebilir veya tamamen kullanıcı ihtiyacına göre kapalı olabilir. Yukarıda belirtildiği gibi, bunu yapan ebeveyne göre en aza indirir / geri yükler.
• Bir öğe olarak JList(aşağıdaki basit örnek).
• Düğüm olarak a JTree.
• İç içe düzenler .
  

Ancak bu stratejiler belirli bir kullanım durumunda işe yaramazsa aşağıdakileri deneyin. Diyalogların üst öğesi olarak çerçeveyi kullanarak, serbest kayan öğelerin geri kalanı için tek bir ana JFrame, daha sonra sahip JDialogveya JOptionPaneörnekler görün.

Birçok resim

Birden çok öğenin görüntü olduğu bu durumda, aşağıdakilerden birini kullanmak daha iyi olur:

1. JLabelKullanıcının o anda ilgilendiği resmi görüntülemek için tek bir (kaydırma bölmesinde ortalanmış). Görüldüğü gibi ImageViewer.
   
2. Tek bir satır JList. Bu cevapta görüldüğü gibi . Bunun 'tek sıralı' kısmı sadece hepsi aynı boyutlardaysa çalışır. Alternatif olarak, görüntüleri anında ölçeklendirmeye hazırsanız ve bunların hepsi aynı en boy oranıysa (örneğin 4: 3 veya 16: 9).

Çoklu JFrameyaklaşım, Swing uygulamalarını programlamaya başladığımdan beri uyguladığım bir şeydi. Çoğunlukla, başlangıçta yaptım çünkü daha iyisini bilmiyordum. Ancak , bir geliştirici olarak deneyimim ve bilgimde olgunlaştığım ve çok daha deneyimli Java geliştiricilerinin görüşlerini okumaya ve almaya başladığımda , çok sayıda yaklaşımdan (hem mevcut projelerde hem de gelecekteki projelerde) kaymaya çalıştım. JFrame) sadece benim ... müşterilerimden bu dirençle karşılaşacaksınız! JInternalFrameAyrı bileşenler için "alt" pencereleri ve pencereleri denetlemek için kalıcı iletişim kutuları uygulamaya başladığımda , müşterilerim şikayet etmeye başladı!En iyi uygulama olduğunu düşündüğüm şeyi yaptığım için oldukça şaşırdım! Ama dedikleri gibi, "Mutlu bir eş mutlu bir hayattır." Aynı şey müşterileriniz için de geçerli. Tabii ki, ben bir yükleniciyim, bu yüzden son kullanıcılarım, ortak bir senaryo değil, geliştirici bana doğrudan erişim var.

Bu yüzden, çoklu JFrameyaklaşımın faydalarını ve mit-büstünün, diğerlerinin sunduğu bazı eksilerini açıklayacağım.

1. Düzende nihai esneklik - Ayrı ayrı özelliklere izin vererek JFrame, son kullanıcınıza ekranındaki içeriği yayma ve kontrol etme yeteneği verirsiniz. Konsept "açık" ve daraltıcı değildir. Bir büyük JFrameve bir sürü JInternalFrames'ye gittiğinizde bunu kaybedersiniz .
2. Çok modülerleştirilmiş uygulamalar için iyi çalışır - Benim durumumda, çoğu uygulamada birbirleriyle hiçbir ilgisi olmayan 3-5 büyük "modül" var. Örneğin, bir modül bir satış kontrol paneli ve bir modül bir muhasebe kontrol paneli olabilir. Birbirleriyle ya da hiçbir şeyle konuşmuyorlar. Ancak, yönetici her ikisini de açmak isteyebilir ve görev çubuğunda ayrı çerçeveler olması hayatını kolaylaştırır.
3. Son kullanıcıların dış materyale referans vermesini kolaylaştırır - Bir keresinde, bu durum vardı: Uygulamamın "Yeni Ekle" yi tıklayabileceğiniz bir "veri görüntüleyicisi" vardı ve bir veri giriş ekranı açacaktı. Başlangıçta her ikisi de JFrames. Ancak, veri giriş ekranının JDialog, üst öğesi veri görüntüleyici olan bir ekran olmasını istedim . Ben değişiklik yaptık ve hemen o küçültmek veya kapatmak gerçeğinden ağır dayanıyordu bir son kullanıcıdan bir çağrı aldı görüntüleyici ve tutmak editörü o programın başka bir bölümüne (veya bir web sitesi, ben don başvurulan ederken açık hatırlamıyorum). O, değil o ilk ve olmaya giriş iletişim ihtiyacı vardı, bu yüzden bir çok monitörde başka bir şeyikinci olarak, veri görüntüleyici tamamen gizli. Bu bir ile imkansızdı JDialogve kesinlikle bir ile imkansız olurdu JInternalFrame. Dürüstçe onu JFramesakıl sağlığı için ayrı olarak değiştirdim , ama bana önemli bir ders verdi.
4. Efsane: Kodlaması zor - Bu benim tecrübelerim için geçerli değil. Bir oluşturmak için herhangi bir kolay olurdu neden görmüyorum JInternalFramebir daha JFrame. Aslında, tecrübelerime göre, JInternalFramesçok daha az esneklik sunuyor. JFrameUygulamalarımda gerçekten iyi çalışan s açılış ve kapanışlarını ele almak için sistematik bir yol geliştirdim . Çerçeveyi neredeyse tamamen çerçevenin kodunun içinden kontrol ediyorum; Yeni çerçevenin oluşturulması, SwingWorkerkullanıcı çalışır benim açmalısınız vb iki kez All açmak için eğer ön çerçeveyi getiren / geri, o kumandayı arka plan iş parçacığı ve EDT üzerinde GUI koduna veri alma s JFrames edilir genel statik yöntemi open()ve açık yöntemi birwindowClosing() olay geri kalanı ele alır (çerçeve zaten açık mı? açık değil, yükleniyor mu? vb.) Bu yaklaşımı bir şablon yaptım, böylece her kare için uygulanması zor değil.
5. Efsane / Kanıtlanmamış: Kaynak Ağır - Bu spekülatif ifadenin arkasında bazı gerçekleri görmek istiyorum. Belki de, JFramea'dan daha fazla alana ihtiyaç duyabiliyor JInternalFrameolsanız da JFrame, 100 s açsanız bile , gerçekten kaç tane daha kaynak tüketirsiniz? Endişeniz kaynaklar yüzünden bellek sızıntısıysa: çağırmak dispose(), çöp toplama için çerçeve tarafından kullanılan tüm kaynakları serbest bırakır (ve yine diyorum ki, a JInternalFrameaynı endişeyi çağırmalıdır).

Çok yazdım ve daha fazla yazabileceğimi hissediyorum. Her neyse, umarım aşağı oy vermezim çünkü bu popüler olmayan bir görüştür. Soru açıkça değerli bir soru ve umarım ortak görüş olmasa bile değerli bir cevap verdim.

Tek kare / kare başına birden çok belge ( MDI ) ve birden çok kare / kare başına tek belge ( SDI ) için mükemmel bir örnek Microsoft Excel'dir. MDI'nın bazı avantajları:

• dikdörtgen olmayan bir şekilde birkaç pencereye sahip olmak mümkündür - böylece masaüstünü veya başka bir pencereyi başka bir işlemden gizlemezler (örn. web tarayıcısı)
• ikinci Excel penceresinde yazarken başka bir işlemden bir pencereyi bir Excel penceresi üzerinde açmak mümkündür - MDI ile, dahili pencerelerden birinde yazmaya çalışmak tüm Excel penceresine odaklanacaktır, böylece pencereyi başka bir işlemden gizleyecektir
• farklı ekranlarda farklı belgelere sahip olmak mümkündür, bu da özellikle ekranlar aynı çözünürlüğe sahip olmadığında yararlıdır

SDI (Tek Belge Arabirimi, yani her pencerede yalnızca tek bir belge olabilir):

MDI (Çok Belgeli Arayüz, yani her pencerede birden çok belge olabilir):

Daha yeni katıldığım bir örnekle "kullanıcı dostu değil" argümanına karşı çıkmak istiyorum.

Bizim uygulamada, kullanıcıların çeşitli sekmeleri ayrı sekmeler olarak çalıştırdığı bir ana penceremiz var. Uygulamamızı mümkün olduğunca bu tek pencerede tutmaya çalıştık.

Çalıştırdıkları 'programlardan' biri, sistem tarafından oluşturulan raporların bir listesini sunar ve kullanıcı bir rapor görüntüleyici iletişim kutusu açmak için her satırdaki bir simgeyi tıklayabilir. Bu görüntüleyici, raporun dikey / yatay A4 sayfalarının eşdeğerlerini gösteriyor, bu nedenle kullanıcılar bu pencereyi oldukça büyük, neredeyse ekranlarını dolduruyor.

Birkaç ay önce, müşterilerimizden bu rapor görüntüleyici pencerelerini modelleme yapma isteklerini almaya başladık, böylece aynı anda birden fazla rapor açabilsinler.

Bunun iyi bir çözüm olduğunu düşünmediğim için bir süre bu talebe karşı koydum. Ancak, kullanıcıların sistemimizin bu 'eksikliğinden' nasıl geçtiğini öğrendiğimde fikrim değişti.

Raporu belirli bir dizine PDF olarak kaydetmek için 'Farklı Kaydet' özelliğini kullanarak, PDF dosyasını açmak için Acrobat Reader'ı kullanarak bir görüntüleyici açıyorlardı ve bir sonraki raporda da aynısını yapacaklardı. Bakmak istedikleri çeşitli rapor çıktılarıyla çalışan birden fazla Acrobat Okuyucuya sahip olacaklardı.

Böylece izleyiciyi modelsiz bıraktım. Bu, her görüntüleyicide bir görev çubuğu simgesi olduğu anlamına gelir.

En son sürüm geçen hafta piyasaya sürüldüğünde, onlardan gelen ezici tepki, onu SEVMEKTİR. Sistemdeki en popüler geliştirmelerimizden biri oldu.

Böylece devam edip kullanıcılarınıza istediklerinin kötü olduğunu söylersiniz, ancak sonuçta size hiçbir iyilik yapmaz.

BAZI NOTLAR:

• JDialog'ları bu modelsiz pencereler için kullanmak en iyi uygulama gibi görünüyor
• ModalityTypeBoole modalargümanından ziyade new öğesini kullanan yapıcıları kullanın . Bu iletişim kutularına görev çubuğu simgesi veren şey budur.
• Modelsiz iletişim kutuları için yapıcıya boş bir üst öğe iletin, ancak bunları üst öğe pencerelerine göre bulun.
• Windows'ta Java 6 sürümünde bir hata var; bu, ana pencerenizin siz söylemeden 'her zaman üstte' olabileceği anlamına gelir. Bunu düzeltmek için sürüm 7'ye yükseltin

Ana çerçeveye bir jInternalFrame yapın ve görünmez yapın. Daha sonra başka etkinlikler için kullanabilirsiniz.

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

Salıncağa son kez dokunduğumdan beri bir süredir ama genel olarak bunu yapmak kötü bir uygulamadır. Akla gelen ana dezavantajlardan bazıları:

• Daha pahalı: Dialog veya JInternalFrame gibi bir pencere konteyneri gibi bir JFrame çizmek için daha fazla kaynak ayırmanız gerekecek.

• Kullanıcı dostu değil: Birbirine yapışmış bir grup JFrame'e gitmek kolay değildir, uygulamanız tutarsız ve kötü tasarımlı bir dizi uygulama gibi görünecektir.

• JInternalFrame'i kullanmak çok kolay Bu tür bir retoriktir, şimdi Masaüstü ve JInternalFrame modelinden düşündüğümüzden daha akıllı (veya daha fazla boş zaman) olan diğer insanlar çok daha kolay ve bu yüzden kullanmanızı tavsiye ederim.

Kesinlikle kötü uygulama. Bunun bir nedeni, her birinin JFrameyeni bir görev çubuğu simgesi göstermesi nedeniyle çok 'kullanıcı dostu' olmamasıdır . Birden fazla JFrames kontrol etmek saçınızı yırtacak.

Şahsen ben JFramesenin tür başvuru için ONE kullanırdım . Birden çok şeyi görüntüleme yöntemleri size kalmış, çok şey var. Canvases, JInternalFrame, CardLayout, hatta JPanelbelki bu.

Birden çok JFrame nesnesi = Ağrı, sorun ve problemler.

Bence birden fazla Jframes kullanmak iyi bir fikir değil.

Bunun yerine kullanabilirsiniz JPanelbirinden daha fazlası veya daha fazla JPanelaynı yer JFrame.

Ayrıca bu JPanels arasında geçiş yapabiliriz . Bu yüzden bize, bir şeyden daha fazlasını gösterme özgürlüğü veriyor JFrame.

Her biri için JPanelfarklı şeyler tasarlayabiliriz ve bunların hepsi JPanelteker JFrameteker gösterilebilir .

Bunlar arasında geçiş yapmak için her biri veya 'JButton JPanel` ile birlikte JPanelkullanın .JMenuBarJMenuItemsJPanelfor each

Birden fazla JFrameiyi bir uygulama değildir, ancak birden fazla istersek yanlış bir şey yoktur JFrame.

Ama JFramebirden fazla JFrames yerine farklı ihtiyaçlarımız için birini değiştirmek daha iyidir .

Çerçeveler aynı boyutta olacaksa, neden çerçeveyi oluşturmuyorsunuz ve çerçeveyi referans olarak geçmiyorsunuz.

Çerçeveyi geçtikten sonra nasıl yerleştireceğinize karar verebilirsiniz. Bir dizi rakamın ortalamasını hesaplamak için bir yönteme sahip olmak gibi bir şey olurdu. Yöntemi tekrar tekrar yaratır mısınız?

İyi bir uygulama değildir, ancak kullanmak isteseniz bile singleton desenini iyi olarak kullanabilirsiniz. Projemin çoğunda singleton kalıplarını iyi kullandım.