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 xem có sử dụng JFrame riêng biệt để 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 sử dụng nhiều cửa sổ JFrame có tốt không?

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

Thực hành tồi (tệ, không tốt).

• 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 chỉ mong 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 để viết mã và duy trì:
  • Một hộp thoại modal Mời cơ hội dễ dàng để sự chú ý tập trung vào các nội dung của hộp thoại - chọn / sửa chữa / hủy này, sau đó tiến hành. Nhiều khung hình không.
  • 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 triển khai điều đó trong khung nếu đó là hành vi mong muốn.

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

• CardLayout( bản demo ngắn . ). Tốt cho:
  1. Hiển thị thuật sĩ giống như hộp thoại.
  2. Hiển thị các lựa chọn danh sách, cây, v.v. cho các mục có một thành phần liên quan.
  3. Lật giữa không có thành phần và thành phần hiển thị.
• 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 hoặc cái kia (kích thước) thay đổi tùy theo những gì người dùng đang làm.
• JLayeredPane xa nhiều thành phần tốt .. lớp.
• JToolBarthường chứa các nhóm hành động hoặc điều khiển. Có thể kéo xung quanh GUI hoặc tắt nó 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 a JList(ví dụ đơn giản bên dưới).
• Như các nút trong a JTree.
• Bố cục lồng nhau .
  

Nhưng nếu những chiến lược đó không hoạt động cho một trường hợp sử dụng cụ thể, hãy thử những 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ử thả nổi tự do, sử dụng khung làm cha cho các hộp thoại.

Nhiều hình ảnh

Trong trường hợp này, khi nhiều phần tử là hình ảnh, tốt hơn nên sử dụng một trong hai phần tử sau để thay thế:

1. Một JLabel(căn giữa trong ngăn 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 'hàng đơn' của chỉ hoạt động nếu chúng có cùng kích thước. Ngoài ra, nếu bạn chuẩn bị chia tỷ lệ hình ảnh đang bay và chúng đều có cùng tỷ lệ khung hình (ví dụ: 4: 3 hoặc 16: 9).

Phương JFramepháp đa phương pháp đã được tôi triển khai kể từ khi bắt đầu lập trình ứng dụng Swing. Phần lớn, tôi đã làm điều đó ngay từ đầu vì tôi không biết cách nào tốt 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, đồng thời 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ên mạng, tôi đã cố gắng chuyển khỏi JFramecách tiếp cận đa phương pháp (cả trong các dự án hiện tại và các dự án tương lai ) chỉ để được đáp ứng với ... nhận được ... sự kháng cự này từ khách hàng của tôi! Khi tôi bắt đầu triển khai các hộp thoại phương thức để điều khiển các cửa sổ và cửa sổ "con" JInternalFramecho cá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 điều mà tôi nghĩ là phương pháp hay nhất! Nhưng, như người ta nói, "Một người vợ hạnh phúc là một cuộc sống hạnh phúc." Đối với 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 JFramephương pháp đa phương pháp, 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 cao nhất trong bố cục - 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 khả năng trải rộng và kiểm soát những gì trên màn hình của họ. Khái niệm mang lại cảm giác "mở" và không hạn chế. Bạn mất điều này khi bạn đi về phía một lớn JFramevà một loạt các JInternalFrames.
2. Hoạt động tốt cho các ứng dụng được mô-đun hóa rất cao - 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à trang tổng quan bán hàng và một mô-đun có thể là trang tổng quan 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ở ra 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à màn hình JDialogcó cha mẹ là người xem dữ liệu. Tôi đã thực hiện thay đổi và ngay lập tức tôi nhận được cuộc gọi từ một người dùng cuối, người chủ yếu dựa 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 phần khác của chương trình (hoặc một trang web, tôi không 't nhớ). Anh ấy không sử dụng nhiều màn hình, vì vậy anh ấy cần hộp thoại nhập là đầu tiên và thứ khác là 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 a JDialogvà chắc chắn cũng sẽ không thể với a JInternalFrame. Tôi miễn cưỡng đổi nó trở lại thành tách biệt JFramesvì sự tỉnh táo của anh ấy, nhưng nó đã dạy tôi một bài học quan trọng.
4. Lầm tưởng: Khó viết mã - Điều này không đúng theo kinh nghiệm của tôi. Tôi không hiểu tại sao việc tạo a sẽ dễ dàng JInternalFramehơn a JFrame. Trên 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 các JFrameứng dụng của tôi thực sự hoạt động tốt. Tôi kiểm soát khung gần như hoàn toàn từ trong chính mã của khung; tạo khung mới, SwingWorkerđiều khiển việc truy xuất dữ liệu trên các luồng nền và mã GUI trên EDT, khôi phục / đưa lên trước khung nếu người dùng cố gắng mở nó hai lần, v.v. Tất cả những gì bạn cần để mở của tôi JFramelà 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ột windowClosing()sự kiện sẽ xử lý phần còn lại (khung đã mở chưa? có phải nó đang mở không, nhưng đang tải? v.v.) Tôi đã thực hiện cách tiếp cận này thành một mẫu nên không khó thực hiện cho từng khung .
5. Huyền thoại / Chưa được chứng minh: Resource Heavy - Tôi muốn xem một số sự thật đằng sau tuyên bố mang tính suy đoán này. Mặc dù, có lẽ, bạn có thể nói rằng một JFramecần nhiều dung lượng hơn một JInternalFrame, ngay cả khi bạn mở 100 JFramegiây, bạn sẽ thực sự tiêu tốn thêm bao nhiêu tài nguyên? Nếu mối quan tâm của bạn là bộ nhớ bị rò rỉ do tài nguyên: việc gọi dispose()giải phóng tất 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, a JInternalFramenên gọi chính xác mối quan tâm tương tự).

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 nữa. 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 được ưa chuộng. 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 đã đưa ra 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 của MDI:

• có thể có một vài cửa sổ ở dạng không phải hình chữ nhật - để chúng không ẩn màn hình nền hoặc cửa sổ khác khỏi quá 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 trên 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 trong một trong các cửa sổ nội bộ sẽ tập trung vào toàn bộ cửa sổ Excel, do đó ẩn cửa sổ khỏi một 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 các màn hình không có cùng độ phân giải

SDI (Giao diện một tài liệu, tức 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, tức là mọi cửa sổ có thể có nhiều tài liệu):

Tôi muốn phản bác lại lập luận "không thân thiện với người dùng" bằng một ví dụ mà tôi vừa mới 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. Chúng tôi đã cố gắng duy trì ứng dụng của mình ở chế độ duy nhất này nhiều nhất có thể.

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 hệ thống tạo và người dùng có thể nhấp vào biểu tượng trên mỗi dòng để mở hộp thoại xem báo cáo. Trình xem này đang 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ọ.

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 có mô hình, để 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, suy nghĩ 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 hụt' này trong hệ thống của chúng tôi.

Họ đang mở một trình xem, sử dụng cơ sở '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 kết quả báo cáo khác nhau mà họ muốn xem.

Vì vậy, tôi hài lòng và làm cho người xem trở thành người mẫu. Điều này có nghĩa là mỗi người xem có một biểu tượng trên 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 hồi áp đảo từ họ là họ YÊU nó. Đây là một trong những cải tiến phổ biến nhất gần đây 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 bạn rằng những gì họ muốn là xấu, nhưng cuối cùng nó sẽ không mang lại cho bạn bất kỳ sự ủng hộ nào.

MỘT SỐ LƯU Ý:

• Có vẻ như cách tốt nhất là sử dụng JDialog cho các cửa sổ không có mô hình này
• Sử dụng các hàm tạo sử dụng đối số mới ModalityTypethay vì boolean modal. Đây là những gì cung cấp 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 có mô hình, hãy chuyển giá trị gốc rỗng cho hàm tạo, nhưng định vị chúng liên quan đến cửa sổ 'mẹ' của chúng.
• Phiên bản 6 của Java trên Windows có một lỗi có nghĩa là cửa sổ chính của bạn có thể trở nên 'luôn ở trên cùng' mà bạn không cần thông báo. Nâng cấp lên phiên bản 7 để sửa lỗi này

Tạo một jInternalFrame vào khung chính và làm cho nó ẩn. 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);

Đã lâu rồi kể từ lần cuối cùng tôi chạm vào swing nhưng nói chung là thực hành điều này không tốt. 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ẽ một JFrame mà loại vùng chứa cửa sổ khác, chẳng hạn như Dialog hoặc JInternalFrame.

• Không thân thiện với người dùng: Không dễ dàng để điều hướng vào một loạt các JFrame bị mắc kẹt với nhau, nó sẽ giống 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 JInternalFrame Đây là một kiểu ngụy biện, bây giờ 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 hơn) so với những gì chúng ta đã nghĩ thông qua mẫu Desktop và JInternalFrame, vì vậy tôi khuyên bạn nên sử dụng nó.

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

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à các vấn đề.

Tôi nghĩ rằng sử dụng nhiều Jframes không phải là một ý kiến ​​hay.

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 JPanelcác s này . Vì vậy, nó cho phép chúng tôi tự do hiển thị nhiều hơn những thứ trong JFrame.

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

Để chuyển đổi giữa việc JPanelsử dụng này JMenuBarvới JMenuItemscho mỗi 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à nên thay đổi một cái JFramecho những nhu cầu khác nhau của chúng ta hơn là có nhiều cái JFrame.

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, sau đó bạn có thể quyết định cách điền nó. Nó giống như có một phương pháp để tính giá trị trung bình của một tập hợp các số liệu. Bạn có tạo phương pháp này nhiều lần không?

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ô hình singleton trong hầu hết các dự án của mình.