Penggunaan Beberapa JFrame: Praktik Baik atau Buruk? [Tutup]
Saya sedang mengembangkan aplikasi yang menampilkan gambar, dan memutar suara dari database. Saya mencoba memutuskan apakah akan menggunakan JFrame terpisah atau tidak untuk menambahkan gambar ke database dari GUI.
Saya hanya ingin tahu apakah praktik yang baik menggunakan beberapa jendela JFrame?
Jawaban
Saya hanya ingin tahu apakah praktik yang baik menggunakan beberapa JFrame?
Praktik buruk (buruk, buruk).
- Pengguna tidak ramah: Pengguna melihat beberapa ikon di bilah tugas mereka saat berharap untuk melihat hanya satu. Ditambah efek samping dari masalah pengkodean ..
- Mimpi buruk untuk membuat kode dan mempertahankan:
- Sebuah dialog modal menawarkan kesempatan mudah untuk fokus perhatian pada isi dialog yang - pilih / memperbaiki / membatalkan ini, kemudian melanjutkan. Beberapa frame tidak.
- Dialog (atau bilah alat mengambang) dengan induk akan muncul ke depan saat induk diklik - Anda harus mengimplementasikannya dalam bingkai jika itu perilaku yang diinginkan.
Ada beberapa cara untuk menampilkan banyak elemen dalam satu GUI, misalnya:
- CardLayout( demo singkat . ). Baik untuk:
- Menampilkan wizard seperti dialog.
- Menampilkan daftar, pohon, dll. Pilihan untuk item yang memiliki komponen terkait.
- Membalik antara tidak ada komponen dan komponen yang terlihat.
- JInternalFrame/JDesktopPane biasanya digunakan untuk MDI .
- JTabbedPane untuk kelompok komponen.
- JSplitPane Cara untuk menampilkan dua komponen yang kepentingannya antara satu atau lainnya (ukuran) bervariasi sesuai dengan apa yang dilakukan pengguna.
- JLayeredPane jauh banyak ... komponen berlapis.
- JToolBarbiasanya berisi kelompok tindakan atau kontrol. Dapat diseret di sekitar GUI, atau dinonaktifkan sepenuhnya sesuai kebutuhan pengguna. Seperti yang disebutkan di atas, akan meminimalkan / memulihkan menurut orang tua melakukannya.
- Seperti item dalam a JList(contoh sederhana di bawah).
- Sebagai node dalam file JTree.
- Tata letak bersarang .
Tetapi jika strategi tersebut tidak berhasil untuk kasus penggunaan tertentu, coba yang berikut ini. Tetapkan satu utama JFrame
, lalu buat JDialogatau JOptionPanemuncul instance untuk elemen mengambang bebas lainnya, menggunakan bingkai sebagai induk untuk dialog.
Banyak gambar
Dalam kasus ini, di mana beberapa elemen adalah gambar, akan lebih baik menggunakan salah satu dari berikut ini:
- Satu
JLabel
(di tengah panel gulir) untuk menampilkan gambar mana pun yang diminati pengguna pada saat itu. Seperti yang terlihat di ImageViewer.
- Satu baris
JList
. Seperti yang terlihat pada jawaban ini . Bagian 'baris tunggal' yang hanya berfungsi jika semuanya memiliki dimensi yang sama. Bergantian, jika Anda siap untuk menskalakan gambar dengan cepat, dan semuanya memiliki rasio aspek yang sama (mis. 4: 3 atau 16: 9).
Berbagai JFrame
pendekatan telah menjadi sesuatu yang saya terapkan sejak saya mulai memprogram aplikasi Swing. Sebagian besar, saya melakukannya di awal karena saya tidak tahu apa-apa. Namun , ketika saya semakin dewasa dalam pengalaman dan pengetahuan saya sebagai pengembang dan ketika mulai membaca dan menyerap pendapat dari begitu banyak pengembang Java online yang lebih berpengalaman, saya berusaha untuk beralih dari berbagai JFrame
pendekatan (baik dalam proyek saat ini maupun proyek masa depan ) hanya untuk bertemu dengan ... dapatkan ini ... penolakan dari klien saya! Ketika saya mulai menerapkan dialog modal untuk mengontrol jendela "anak" dan JInternalFrame
s untuk komponen terpisah, klien saya mulai mengeluh! Saya cukup terkejut, karena saya melakukan apa yang saya pikir sebagai praktik terbaik! Tapi, seperti yang mereka katakan, "Istri yang bahagia adalah hidup yang bahagia." Hal yang sama berlaku untuk klien Anda. Tentu saja, saya adalah kontraktor sehingga pengguna akhir memiliki akses langsung ke saya, pengembang, yang jelas bukan skenario umum.
Jadi, saya akan menjelaskan manfaat dari berbagai JFrame
pendekatan, serta menghilangkan mitos beberapa kontra yang disajikan orang lain.
- Fleksibilitas tertinggi dalam tata letak - Dengan mengizinkan
JFrame
s yang terpisah , Anda memberi pengguna akhir kemampuan untuk menyebar dan mengontrol apa yang ada di layarnya. Konsepnya terasa "terbuka" dan tidak mengekang. Anda kehilangan ini saat Anda memilih satu besarJFrame
dan banyakJInternalFrame
s. - Bekerja dengan baik untuk aplikasi yang sangat termodulasi - Dalam kasus saya, sebagian besar aplikasi saya memiliki 3 - 5 "modul" besar yang benar-benar tidak ada hubungannya sama sekali. Misalnya, satu modul mungkin menjadi dasbor penjualan dan satu mungkin menjadi dasbor akuntansi. Mereka tidak berbicara satu sama lain atau apa pun. Namun, eksekutif mungkin ingin membuka keduanya dan keduanya menjadi bingkai terpisah di bilah tugas membuat hidupnya lebih mudah.
- Memudahkan pengguna akhir untuk mereferensikan materi luar - Suatu kali, saya mengalami situasi ini: Aplikasi saya memiliki "penampil data", yang darinya Anda dapat mengeklik "Tambah Baru" dan akan membuka layar entri data. Awalnya, keduanya
JFrame
s. Namun, saya ingin layar entri data menjadiJDialog
yang orang tuanya adalah penampil data. Saya membuat perubahan, dan segera saya menerima panggilan dari pengguna akhir yang sangat bergantung pada fakta bahwa dia dapat meminimalkan atau menutup penampil dan menjaga editor tetap terbuka sementara dia mereferensikan bagian lain dari program (atau situs web, saya tidak tidak ingat). Dia tidak menggunakan multi-monitor, jadi dia membutuhkan dialog entri menjadi yang pertama dan yang lain menjadi yang kedua, dengan penampil data benar-benar tersembunyi. Ini tidak mungkin dengan aJDialog
dan pasti tidak mungkin denganJInternalFrame
juga. Saya dengan enggan mengubahnya kembali menjadi terpisahJFrames
karena kewarasannya, tetapi itu memberi saya pelajaran penting. - Mitos: Sulit untuk dikodekan - Ini tidak benar menurut pengalaman saya. Saya tidak mengerti mengapa akan lebih mudah untuk membuat
JInternalFrame
daripada aJFrame
. Faktanya, menurut pengalaman saya,JInternalFrames
menawarkan jauh lebih sedikit fleksibilitas. Saya telah mengembangkan cara sistematis untuk menangani pembukaan & penutupanJFrame
aplikasi saya yang benar-benar berfungsi dengan baik. Saya mengontrol frame hampir sepenuhnya dari dalam kode frame itu sendiri; pembuatan bingkai baru,SwingWorker
yang mengontrol pengambilan data pada utas latar belakang dan kode GUI pada EDT, memulihkan / menampilkan bingkai ke depan jika pengguna mencoba membukanya dua kali, dll. Yang Anda perlukan untuk membuka bingkai sayaJFrame
adalah memanggil metode statis publikopen()
dan metode terbuka, dikombinasikan denganwindowClosing()
acara menangani sisanya (apakah frame sudah terbuka? apakah itu tidak terbuka, tapi memuat? dll.) Saya membuat pendekatan ini sebagai template sehingga tidak sulit untuk diterapkan untuk setiap frame . - Myth / Unproven: Resource Heavy - Saya ingin melihat beberapa fakta di balik pernyataan spekulatif ini. Meskipun, mungkin, Anda dapat mengatakan bahwa suatu
JFrame
kebutuhan lebih dari satuJInternalFrame
, bahkan jika Anda membuka 100JFrame
s, berapa banyak lagi sumber daya yang benar-benar akan Anda konsumsi? Jika kekhawatiran Anda adalah kebocoran memori karena sumber daya: pemanggilandispose()
membebaskan semua sumber daya yang digunakan oleh frame untuk pengumpulan sampah (dan, sekali lagi saya katakan, aJInternalFrame
harus meminta perhatian yang persis sama).
Saya telah menulis banyak dan saya merasa seperti saya bisa menulis lebih banyak. Ngomong-ngomong, saya harap saya tidak mendapat suara negatif hanya karena itu opini yang tidak populer. Pertanyaan ini jelas sangat berharga dan saya harap saya telah memberikan jawaban yang berharga, meskipun itu bukan pendapat umum.
Contoh bagus dari banyak bingkai / satu dokumen per bingkai ( SDI ) vs satu bingkai / banyak dokumen per bingkai ( MDI ) adalah Microsoft Excel. Beberapa manfaat MDI:
- dimungkinkan untuk memiliki beberapa jendela dalam bentuk non persegi panjang - sehingga mereka tidak menyembunyikan desktop atau jendela lain dari proses lain (mis. browser web)
- dimungkinkan untuk membuka jendela dari proses lain melalui satu jendela Excel saat menulis di jendela Excel kedua - dengan MDI, mencoba menulis di salah satu jendela internal akan memberikan fokus ke seluruh jendela Excel, sehingga menyembunyikan jendela dari proses lain
- ada kemungkinan untuk memiliki dokumen yang berbeda pada layar yang berbeda, yang sangat berguna jika layar tidak memiliki resolusi yang sama
SDI (Single-Document Interface, yaitu setiap jendela hanya dapat memiliki satu dokumen):
MDI (Multiple-Document Interface, yaitu setiap jendela dapat memiliki banyak dokumen):
Saya ingin melawan argumen "tidak ramah pengguna" dengan contoh yang baru saja saya tangani.
Dalam aplikasi kami, kami memiliki jendela utama tempat pengguna menjalankan berbagai 'program' sebagai tab terpisah. Sebisa mungkin kami telah mencoba untuk menyimpan aplikasi kami di satu jendela ini.
Salah satu 'program' yang mereka jalankan menampilkan daftar laporan yang telah dibuat oleh sistem, dan pengguna dapat mengklik ikon di setiap baris untuk membuka dialog penampil laporan. Penampil ini menunjukkan halaman laporan yang setara dengan potret / lanskap A4, sehingga pengguna menyukai jendela ini karena cukup besar, hampir memenuhi layar mereka.
Beberapa bulan yang lalu kami mulai mendapatkan permintaan dari pelanggan kami untuk membuat model jendela penampil laporan ini, sehingga mereka dapat membuka beberapa laporan pada waktu yang sama.
Untuk beberapa waktu saya menolak permintaan ini karena menurut saya ini bukan solusi yang baik. Namun, pikiran saya berubah ketika saya mengetahui bagaimana pengguna mengatasi 'kekurangan' sistem kami ini.
Mereka membuka penampil, menggunakan fasilitas 'Save As' untuk menyimpan laporan sebagai PDF ke direktori tertentu, menggunakan Acrobat Reader untuk membuka file PDF, dan kemudian mereka akan melakukan hal yang sama dengan laporan berikutnya. Mereka akan menjalankan beberapa Pembaca Akrobat dengan berbagai keluaran laporan yang ingin mereka lihat.
Jadi saya mengalah dan membuat penampil modeless. Ini berarti bahwa setiap penampil memiliki ikon bilah tugas.
Ketika versi terbaru dirilis kepada mereka minggu lalu, tanggapan yang luar biasa dari mereka adalah bahwa mereka MENYUKAINYA. Ini adalah salah satu peningkatan terbaru kami yang paling populer pada sistem.
Jadi, Anda melanjutkan dan memberi tahu pengguna bahwa apa yang mereka inginkan itu buruk, tetapi pada akhirnya hal itu tidak akan membantu Anda.
BEBERAPA CATATAN:
- Tampaknya praktik terbaik menggunakan JDialog untuk jendela modeless ini
- Gunakan konstruktor yang menggunakan baru
ModalityType
daripadamodal
argumen boolean . Inilah yang memberi dialog ini ikon bilah tugas. - Untuk dialog modeless, teruskan null parent ke konstruktor, tetapi tempatkan mereka sesuai dengan jendela 'parent' -nya.
- Java versi 6 di Windows memiliki bug yang berarti jendela utama Anda dapat menjadi 'selalu di atas' tanpa Anda beri tahukan. Tingkatkan ke versi 7 untuk memperbaikinya
Buat jInternalFrame menjadi bingkai utama dan jadikan tidak terlihat. Kemudian Anda dapat menggunakannya untuk acara selanjutnya.
jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
Sudah lama sejak terakhir kali saya menyentuh ayunan tetapi secara umum adalah praktik yang buruk untuk melakukan ini. Beberapa kelemahan utama yang terlintas dalam pikiran:
Ini lebih mahal: Anda harus mengalokasikan lebih banyak sumber daya untuk menggambar JFrame dari jenis wadah jendela lainnya, seperti Dialog atau JInternalFrame.
Tidak ramah pengguna: Tidak mudah untuk menavigasi ke sekelompok JFrame yang saling menempel, itu akan terlihat seperti aplikasi Anda adalah sekumpulan aplikasi yang tidak konsisten dan desain yang buruk.
Sangat mudah untuk menggunakan JInternalFrame Ini semacam retorical, sekarang jauh lebih mudah dan orang lain lebih pintar (atau dengan lebih banyak waktu luang) daripada kita telah memikirkan pola Desktop dan JInternalFrame, jadi saya akan merekomendasikan untuk menggunakannya.
Praktek yang buruk pasti. Salah satu alasannya adalah bahwa ini tidak terlalu 'ramah pengguna' karena setiap JFrame
menampilkan ikon bilah tugas baru. Mengontrol beberapa rambut JFrame
akan membuat Anda merobek rambut Anda.
Secara pribadi, saya akan menggunakan ONE JFrame
untuk jenis aplikasi Anda. Metode menampilkan banyak hal terserah Anda, ada banyak. Canvas
es, JInternalFrame
, CardLayout
, bahkan JPanel
s mungkin.
Beberapa objek JFrame = Sakit, masalah, dan masalah.
Saya pikir menggunakan banyak Jframe
s bukanlah ide yang baik.
Sebaliknya kita bisa menggunakan JPanel
lebih dari satu atau lebih JPanel
dalam satu sama JFrame
.
Juga kita bisa beralih di antara ini JPanel
. Jadi ini memberi kami kebebasan untuk menampilkan lebih dari satu hal di JFrame
.
Untuk masing-masing JPanel
kita dapat merancang hal-hal yang berbeda dan semua ini JPanel
dapat ditampilkan JFrame
satu per satu.
Untuk beralih di antara ini JPanel
gunakan JMenuBar
dengan JMenuItems
untuk masing-masing JPanel
atau 'JButton for each
JPanel`.
Lebih dari satu JFrame
bukanlah praktik yang baik, tetapi tidak ada salahnya jika kita menginginkan lebih dari satu JFrame
.
Tetapi lebih baik untuk mengubah satu JFrame
untuk kebutuhan kita yang berbeda daripada memiliki beberapa JFrame
.
Jika frame akan memiliki ukuran yang sama, mengapa tidak membuat frame dan meneruskan frame tersebut sebagai referensi.
Ketika Anda telah melewati bingkai, Anda kemudian dapat memutuskan bagaimana mengisinya. Ini seperti memiliki metode untuk menghitung rata-rata sekumpulan angka. Apakah Anda akan membuat metode ini berulang kali?
Ini bukan praktik yang baik tetapi meskipun Anda ingin menggunakannya, Anda dapat menggunakan pola tunggal sebagai kebaikannya. Saya telah menggunakan pola tunggal di sebagian besar proyek saya.