Việc sử dụng nhiều JFrames: Thực hành tốt hay xấu? [đóng cửa]

Tôi đang phát triển một ứng dụng hiển thị hình ảnh và phát âm thanh từ cơ sở dữ liệu. Tôi đang cố gắng quyết định có sử dụng JFrame riêng để thêm hình ảnh vào cơ sở dữ liệu từ GUI hay không.

Tôi chỉ tự hỏi liệu có nên sử dụng nhiều cửa sổ JFrame không?

Tôi chỉ tự hỏi liệu có nên sử dụng nhiều JFrames không?

Xấu (xấu, xấu) thực hành.

• Người dùng không thân thiện: Người dùng nhìn thấy nhiều biểu tượng trong thanh tác vụ của họ khi mong đợi chỉ nhìn thấy một biểu tượng. Cộng với các tác dụng phụ của các vấn đề mã hóa ..
• Một cơn ác mộng để mã hóa và duy trì:
  • Một hộp thoại phương thức cung cấp cơ hội dễ dàng để tập trung sự chú ý vào nội dung của hộp thoại đó - chọn / sửa / hủy cái này, sau đó tiến hành. Nhiều khung hình thì không.
  • Một hộp thoại (hoặc thanh công cụ nổi) có cha mẹ sẽ xuất hiện trước khi cha mẹ được nhấp vào - bạn phải thực hiện điều đó trong các khung nếu đó là hành vi mong muốn.

Có bất kỳ số cách hiển thị nhiều thành phần trong một GUI, ví dụ:

• CardLayout( bản demo ngắn . ). Tốt cho:
  1. Trình hướng dẫn hiển thị như hộp thoại.
  2. Hiển thị danh sách, cây, vv lựa chọn cho các mục có thành phần liên quan.
  3. Lật giữa không có thành phần và thành phần có thể nhìn thấy.
• JInternalFrame/JDesktopPane thường được sử dụng cho MDI .
• JTabbedPane cho các nhóm thành phần.
• JSplitPane Một cách để hiển thị hai thành phần trong đó tầm quan trọng giữa cái này hay cái kia (kích thước) thay đổi tùy theo những gì người dùng đang làm.
• JLayeredPane rất nhiều thành phần tốt .. lớp phủ.
• JToolBarthường chứa các nhóm hành động hoặc điều khiển. Có thể được kéo xung quanh GUI hoặc tắt hoàn toàn theo nhu cầu của người dùng. Như đã đề cập ở trên, sẽ giảm thiểu / khôi phục theo cha mẹ làm như vậy.
• Như các mục trong một JList(ví dụ đơn giản dưới đây).
• Là các nút trong a JTree.
• Bố trí lồng nhau .
  

Nhưng nếu những chiến lược đó không hiệu quả cho một trường hợp sử dụng cụ thể, hãy thử cách sau. Thiết lập một chính duy nhất JFrame, sau đó có JDialoghoặc các JOptionPanethể hiện xuất hiện cho phần còn lại của các phần tử nổi tự do, sử dụng khung làm cha mẹ cho các hộp thoại.

Nhiều hình ảnh

Trong trường hợp có nhiều yếu tố là hình ảnh, tốt hơn nên sử dụng một trong hai yếu tố sau:

1. Một JLabel( duy nhất trong một ô cuộn) để hiển thị bất kỳ hình ảnh nào mà người dùng quan tâm tại thời điểm đó. Như đã thấy trong ImageViewer.
   
2. Một hàng duy nhất JList. Như đã thấy trong câu trả lời này . Phần 'một hàng' chỉ hoạt động nếu chúng có cùng kích thước. Thay phiên, nếu bạn chuẩn bị chia tỷ lệ hình ảnh một cách nhanh chóng và tất cả chúng đều có cùng tỷ lệ khung hình (ví dụ 4: 3 hoặc 16: 9).

Cách JFrametiếp cận đa dạng là điều tôi đã triển khai kể từ khi tôi bắt đầu lập trình ứng dụng Swing. Đối với hầu hết các phần, tôi đã làm điều đó ngay từ đầu bởi vì tôi không biết gì hơn. Tuy nhiên , khi tôi trưởng thành về kinh nghiệm và kiến ​​thức của mình với tư cách là một nhà phát triển và khi bắt đầu đọc và tiếp thu ý kiến ​​của rất nhiều nhà phát triển Java có kinh nghiệm trực tuyến, tôi đã cố gắng tránh xa nhiều JFramecách tiếp cận (cả trong các dự án hiện tại và các dự án trong tương lai ) chỉ được đáp ứng với ... có được ... sự phản kháng này từ khách hàng của tôi! Khi tôi bắt đầu thực hiện các hộp thoại phương thức để kiểm soát các cửa sổ "con" và JInternalFramecác thành phần riêng biệt, khách hàng của tôi bắt đầu phàn nàn!Tôi khá ngạc nhiên, vì tôi đang làm những gì tôi nghĩ là tốt nhất - thực hành! Nhưng, như họ nói, "Một người vợ hạnh phúc là một cuộc sống hạnh phúc." Khách hàng của bạn cũng vậy. Tất nhiên, tôi là một nhà thầu nên người dùng cuối của tôi có quyền truy cập trực tiếp vào tôi, nhà phát triển, đây rõ ràng không phải là một kịch bản phổ biến.

Vì vậy, tôi sẽ giải thích những lợi ích của JFramecách tiếp cận đa phương tiện, cũng như huyền thoại phá vỡ một số nhược điểm mà những người khác đã trình bày.

1. Tính linh hoạt tối đa trong cách bố trí - Bằng cách cho phép các JFrames riêng biệt , bạn cung cấp cho người dùng cuối của bạn khả năng dàn trải và kiểm soát những gì trên màn hình của anh ấy / cô ấy. Khái niệm này cảm thấy "mở" và không hạn chế. Bạn mất điều này khi bạn tiến tới một nhóm lớn JFramevà một JInternalFrames.
2. Hoạt động tốt cho các ứng dụng được mô đun hóa - Trong trường hợp của tôi, hầu hết các ứng dụng của tôi có 3 - 5 "mô-đun" lớn thực sự không liên quan gì đến nhau. Ví dụ: một mô-đun có thể là bảng điều khiển bán hàng và một mô-đun có thể là bảng điều khiển kế toán. Họ không nói chuyện với nhau hay bất cứ điều gì. Tuy nhiên, giám đốc điều hành có thể muốn mở cả hai và chúng là các khung riêng biệt trên thanh tác vụ giúp cuộc sống của anh ta dễ dàng hơn.
3. Giúp người dùng cuối dễ dàng tham khảo tài liệu bên ngoài - Một lần, tôi gặp tình huống này: Ứng dụng của tôi có "trình xem dữ liệu", từ đó bạn có thể nhấp vào "Thêm mới" và nó sẽ mở màn hình nhập dữ liệu. Ban đầu, cả hai đều là JFrames. Tuy nhiên, tôi muốn màn hình nhập dữ liệu là JDialogcha mẹ có trình xem dữ liệu. Tôi đã thực hiện thay đổi và ngay lập tức tôi nhận được một cuộc gọi từ một người dùng cuối, người phụ thuộc rất nhiều vào thực tế rằng anh ta có thể thu nhỏ hoặc đóng trình xem và giữ cho trình chỉnh sửa mở trong khi anh ta tham khảo một phần khác của chương trình (hoặc một trang web, tôi không Tôi không nhớ). Anh ấy không ở trên nhiều màn hình, vì vậy anh ấy cần hộp thoại đầu tiên và một cái gì đó khácđứng thứ hai, với trình xem dữ liệu hoàn toàn bị ẩn. Điều này là không thể với một JDialogvà chắc chắn cũng sẽ không thể với một JInternalFrame. Tôi bực bội thay đổi nó trở lại tách biệt JFramesvì sự tỉnh táo của anh ấy, nhưng nó đã dạy cho tôi một bài học quan trọng.
4. Quan niệm: Khó mã hóa - Điều này không đúng trong kinh nghiệm của tôi. Tôi không thấy lý do tại sao việc tạo ra một thứ dễ dàng JInternalFramehơn a JFrame. Trong thực tế, theo kinh nghiệm của tôi, JInternalFramescung cấp ít linh hoạt hơn nhiều. Tôi đã phát triển một cách có hệ thống để xử lý việc mở và đóng JFrames trong các ứng dụng của mình thực sự hoạt động tốt. Tôi kiểm soát khung hình gần như hoàn toàn từ chính mã của khung; việc tạo ra các khung mới, SwingWorkerlà kiểm soát việc thu hồi các dữ liệu về chủ đề nền và mã GUI trên EDT, phục hồi / đưa ra trước khung nếu cố gắng sử dụng để mở nó hai lần, vv Tất cả bạn cần để mở của tôi JFrames là gọi một phương thức tĩnh công khai open()và phương thức mở, kết hợp với mộtwindowClosing() sự kiện xử lý phần còn lại (khung đã mở chưa? nó không mở, nhưng đang tải? v.v.) Tôi đã thực hiện phương pháp này một mẫu để không khó thực hiện cho từng khung.
5. Chuyện hoang đường / Chưa được chứng minh: Tài nguyên nặng - Tôi muốn thấy một số sự thật đằng sau tuyên bố đầu cơ này. Mặc dù, có lẽ, bạn có thể nói JFramecần một không gian nhiều hơn a JInternalFrame, ngay cả khi bạn mở 100 JFramegiây, bạn thực sự sẽ tiêu thụ bao nhiêu tài nguyên? Nếu mối quan tâm của bạn là rò rỉ bộ nhớ vì tài nguyên: việc gọi dispose()sẽ giải phóng tất cả các tài nguyên được sử dụng bởi khung để thu gom rác (và, một lần nữa tôi nói, JInternalFramenên gọi chính xác mối quan tâm đó).

Tôi đã viết rất nhiều và tôi cảm thấy mình có thể viết nhiều hơn. Dù sao, tôi hy vọng tôi không bị bỏ phiếu đơn giản vì đó là một ý kiến ​​không phổ biến. Câu hỏi rõ ràng là một câu hỏi có giá trị và tôi hy vọng tôi đã cung cấp một câu trả lời có giá trị, ngay cả khi đó không phải là ý kiến ​​chung.

Một ví dụ tuyệt vời về nhiều khung / tài liệu đơn trên mỗi khung ( SDI ) so với khung đơn / nhiều tài liệu trên mỗi khung ( MDI ) là Microsoft Excel. Một số lợi ích MDI:

• có thể có một vài cửa sổ ở dạng không phải hình chữ nhật - vì vậy chúng không ẩn máy tính để bàn hoặc cửa sổ khác khỏi quy trình khác (ví dụ: trình duyệt web)
• có thể mở một cửa sổ từ một quy trình khác qua một cửa sổ Excel trong khi viết trong cửa sổ Excel thứ hai - với MDI, cố gắng viết vào một trong các cửa sổ bên trong sẽ tập trung vào toàn bộ cửa sổ Excel, do đó ẩn cửa sổ khỏi quy trình khác
• có thể có các tài liệu khác nhau trên các màn hình khác nhau, điều này đặc biệt hữu ích khi màn hình không có cùng độ phân giải

SDI (Giao diện một tài liệu, nghĩa là mọi cửa sổ chỉ có thể có một tài liệu duy nhất):

MDI (Giao diện nhiều tài liệu, nghĩa là mọi cửa sổ có thể có nhiều tài liệu):

Tôi muốn chống lại đối số "không thân thiện với người dùng" bằng một ví dụ mà tôi vừa tham gia.

Trong ứng dụng của chúng tôi, chúng tôi có một cửa sổ chính nơi người dùng chạy các 'chương trình' khác nhau dưới dạng các tab riêng biệt. Càng nhiều càng tốt, chúng tôi đã cố gắng giữ ứng dụng của chúng tôi vào cửa sổ duy nhất này.

Một trong những 'chương trình' mà họ chạy trình bày danh sách các báo cáo được tạo bởi hệ thống và người dùng có thể nhấp vào biểu tượng trên mỗi dòng để bật mở hộp thoại xem báo cáo. Trình xem này hiển thị tương đương với (các) trang A4 dọc / ngang của báo cáo, vì vậy người dùng thích cửa sổ này khá lớn, gần như lấp đầy màn hình của họ.

Một vài tháng trước, chúng tôi đã bắt đầu nhận được yêu cầu từ khách hàng của mình để làm cho các cửa sổ trình xem báo cáo này không bị biến đổi, để họ có thể mở nhiều báo cáo cùng một lúc.

Trong một thời gian, tôi đã từ chối yêu cầu này vì tôi không nghĩ rằng đây là một giải pháp tốt. Tuy nhiên, tâm trí của tôi đã thay đổi khi tôi phát hiện ra cách người dùng giải quyết vấn đề 'thiếu sót' này trong hệ thống của chúng tôi.

Họ đang mở trình xem, sử dụng tiện ích 'Lưu dưới dạng' để lưu báo cáo dưới dạng PDF vào một thư mục cụ thể, sử dụng Acrobat Reader để mở tệp PDF và sau đó họ sẽ làm tương tự với báo cáo tiếp theo. Họ sẽ có nhiều Trình đọc Acrobat chạy với các đầu ra báo cáo khác nhau mà họ muốn xem xét.

Vì vậy, tôi đã đồng ý và làm cho người xem không thể sửa đổi. Điều này có nghĩa là mỗi người xem có một biểu tượng thanh tác vụ.

Khi phiên bản mới nhất được phát hành cho họ vào tuần trước, phản ứng áp đảo từ họ là họ YÊU nó. Đây là một trong những cải tiến phổ biến gần đây nhất của chúng tôi đối với hệ thống.

Vì vậy, bạn tiếp tục và nói với người dùng của mình rằng những gì họ muốn là xấu, nhưng cuối cùng nó sẽ không giúp ích gì cho bạn.

MỘT SỐ LƯU Ý:

• Có vẻ là cách tốt nhất để sử dụng JDialog cho các cửa sổ không mod này
• Sử dụng các hàm tạo sử dụng đối số mới ModalityTypethay vì modalđối số boolean . Đây là những gì mang lại cho các hộp thoại này biểu tượng thanh tác vụ.
• Đối với các hộp thoại không chế độ, chuyển một cha mẹ null cho hàm tạo, nhưng xác định vị trí của chúng so với cửa sổ 'cha mẹ' của chúng.
• Phiên bản 6 của Java trên Windows có một lỗi , điều đó có nghĩa là cửa sổ chính của bạn có thể trở thành 'luôn ở trên đỉnh' mà bạn không nói với nó. Nâng cấp lên phiên bản 7 để sửa lỗi này

Tạo một jIternalFrame thành khung chính và làm cho nó vô hình. Sau đó, bạn có thể sử dụng nó cho các sự kiện tiếp theo.

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

Đã được một thời gian kể từ lần cuối cùng tôi chạm vào swing nhưng nói chung là một thực hành tồi để làm điều này. Một số nhược điểm chính xuất hiện trong tâm trí:

• Nó đắt hơn: bạn sẽ phải phân bổ nhiều tài nguyên hơn để vẽ JFrame mà loại bộ chứa cửa sổ khác, chẳng hạn như Hộp thoại hoặc JI INTERNalFrame.

• Không thân thiện với người dùng: Không dễ để điều hướng vào một loạt các JFrame bị mắc kẹt với nhau, có vẻ như ứng dụng của bạn là một tập hợp các ứng dụng không nhất quán và thiết kế kém.

• Thật dễ dàng để sử dụng JI INTERNalFrame Đây là loại hình retorical, giờ đây nó dễ dàng hơn và những người khác thông minh hơn (hoặc có nhiều thời gian rảnh rỗi hơn) chúng tôi đã nghĩ thông qua mẫu Desktop và JI INTERNalFrame, vì vậy tôi khuyên bạn nên sử dụng nó.

Thực hành xấu chắc chắn. Một lý do là nó không 'thân thiện với người dùng' vì thực tế là mọi JFramechương trình đều hiển thị một biểu tượng trên thanh tác vụ mới. Kiểm soát nhiều JFrames sẽ khiến bạn xé tóc ra.

Cá nhân, tôi sẽ sử dụng MỘT JFramecho loại ứng dụng của bạn. Phương pháp hiển thị nhiều thứ là tùy thuộc vào bạn, có rất nhiều. Canvases, JInternalFrame, CardLayout, thậm chí JPanellà có thể.

Nhiều đối tượng JFrame = Đau đớn, rắc rối và vấn đề.

Tôi nghĩ rằng sử dụng nhiều Jframes không phải là một ý tưởng tốt.

Thay vào đó chúng ta có thể sử dụng JPanelnhiều hơn một hoặc nhiều JPaneltrong cùng một JFrame.

Ngoài ra chúng ta có thể chuyển đổi giữa JPanels này . Vì vậy, nó cho chúng ta tự do để hiển thị nhiều hơn trên điều JFrame.

Đối với mỗi JPanelchúng ta có thể thiết kế những thứ khác nhau và tất cả điều này JPanelcó thể được hiển thị trên JFrametừng cái một.

Để chuyển đổi giữa việc JPanelsử dụng này JMenuBarvới JMenuItemstừng JPanelhoặc 'JButton for eachJPanel`.

Nhiều hơn một JFramekhông phải là một thực hành tốt, nhưng không có gì sai nếu chúng ta muốn nhiều hơn một JFrame.

Nhưng tốt hơn là thay đổi một JFramecho các nhu cầu khác nhau của chúng tôi thay vì có nhiều JFrames.

Nếu các khung sẽ có cùng kích thước, tại sao không tạo khung và chuyển khung sau đó làm tham chiếu đến nó.

Khi bạn đã vượt qua khung, bạn có thể quyết định làm thế nào để đưa vào khung. Nó giống như có một phương pháp tính trung bình của một tập hợp các số liệu. Bạn sẽ tạo phương thức nhiều lần?

Nó không phải là một thực hành tốt nhưng mặc dù bạn muốn sử dụng nó, bạn có thể sử dụng mô hình singleton là tốt. Tôi đã sử dụng các mẫu singleton trong hầu hết các dự án của tôi.