Thiết kế giao diện động với Swing

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:17

Thêm vào BST

Báo xấu

115
lượt xem 32
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Chuyến đi đến các vùng ngoài của Swing API Peter Seebach, Tác giả, 自由职业者 Tóm tắt: Bộ công cụ Giao diện người dùng (UI) của Swing làm cho nó có thể, mặc dù không luôn dễ dàng, cập nhật động các giao diện người dùng để đáp lại các sự kiện hoặc hành động của người dùng. Bài viết này xem xét một số cách phổ biến mà bạn có thể xây dựng các UI được cập nhật động, xem xét vài cạm bẫy có thể gặp trên đường đi và một số nguyên tắc để giúp bạn quyết...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Thiết kế giao diện động với Swing

Thiết kế giao diện động với Swing Chuyến đi đến các vùng ngoài của Swing API Peter Seebach, Tác giả, 自由职业者 Tóm tắt: Bộ công cụ Giao diện người dùng (UI) của Swing làm cho nó có thể, mặc dù không luôn dễ dàng, cập nhật động các giao diện người dùng để đáp lại các sự kiện hoặc hành động của người dùng. Bài viết này xem xét một số cách phổ biến mà bạn có thể xây dựng các UI được cập nhật động, xem xét vài cạm bẫy có thể gặp trên đường đi và một số nguyên tắc để giúp bạn quyết định khi nào đây là cách tiếp cận thích hợp cho công việc. Bộ công cụ Swing cung cấp nhiều công cụ để tạo các giao diện người dùng và một mảng kì lạ về các tùy chọn để thay đổi các giao diện này trong vòng đời của chương trình. Sử dụng cẩn thận các tính năng này có thể dẫn đến giao diện thích ứng động theo nhu cầu của người dùng và đơn giản hóa tương tác. Sử dụng không cẩn thận các tính năng tương tự có thể dẫn đến các chương trình rất khó hiểu hoặc thậm chí các chương trình hoàn toàn không sử dụng được. Bài viết này giới thiệu công nghệ và triết lý về các UI động và giúp bạn vượt qua lúc khó khăn khi xây dựng các UI hiệu quả. Bạn sẽ thay đổi mã nguồn dựa trên ứng dụng chương trình giới thiệu (demo) của SwingSet2 được đảm bảo với JDK của Sun (xem Resources); UI của ứng dụng này sử dụng một số đặc tính động và dùng như một điểm khởi đầu tuyệt vời để hiểu chúng. Đình chỉ một tiện ích (widget) Hình thức đơn giản nhất của UI động là làm xám màu của các mục hay nút ấn của trình đơn chưa sẵn sàng. Việc đình chỉ các widget UI thực hiện theo cùng cách với
tất cả các widget; hàm setEnabled() là một tính năng của lớp Component (Thành phần). Liệt kê 1 cho thấy mã để đình chỉ một nút: Liệt kê 1. Đình chỉ một nút button.setEnabled(false); Ngay cả hành động đơn giản chuyển sang màu xám một tùy chọn trình đơn không sử dụng hoặc nút hộp thoại liên quan đến sự thỏa hiệp với người sử dụng. Mặc dù một nút ấn đã chuyển sang màu xám ngay lập tức thông báo cho người dùng rằng một hành động cụ thể không thể thực hiện được, những nó không cho họ biết tại sao. Điều này có thể là một vấn đề với người dùng, người có thể không hiểu lý do (xem Các nguyên tắc chung). Thật dễ dàng, khi bạn có thể nhìn thấy. Câu hỏi là khi nào bạn nên kích hoạt hay đình chỉ một nút. Một quyết định thiết kế chung là đình chỉ một nút khi nó không thích hợp. Ví dụ, nhiều chương trình đình chỉ nút Save (và mục trình đơn tương ứng bất kỳ) khi một tệp đã không được thay đổi kể từ lần lưu nó cuối cùng. Lời cảnh báo chủ yếu cho việc đình chỉ các nút là nhớ kích hoạt lại chúng ở thời điểm thích hợp. Ví dụ, nếu có một bước xác nhận giữa việc nhấn vào một nút và hoàn thành hành động của nó, nút đó phải được kích hoạt ngay cả khi việc xác nhận không thành công.
Điều chỉnh các phạm vi Đôi khi một ứng dụng cần điều chỉnh phạm vi của một số widget, nh ư là một Spinner (quay tròn) hoặc Slider (thanh trượt ), một cách động. Điều này có thể phức tạp hơn nó mong đợi. Các Slider, nói cụ thể, có các tính năng thứ cấp -- các dấu thời gian, khoảng cách dấu thời gian và các nhãn -- mà chúng có thể cần phải được điều chỉnh cùng với phạm vi đó để tránh bị lỗi nặng. Chương trình giới thiệu (demo) SwingSet2 không trực tiếp làm bất kỳ cái gì về điều này, do đó bạn sẽ thay đổi nó bằng cách gắn một ChangeListener cho một thanh trượt để có thể thay đổi thanh trượt khác. Nhập lớp SliderChangeListener mới, chỉ ra trong Liệt kê 2: Liệt kê 2. Thay đổi một phạm vi của thanh trượt class SliderChangeListener implements ChangeListener { JSlider h; SliderChangeListener(JSlider h) { this.h = h; }
public void stateChanged(ChangeEvent e) { JSlider js = (JSlider) e.getSource(); int i = js.getValue(); h.setMaximum(i); h.repaint(); } } Khi thanh trượt ngang thứ ba được tạo ra (một thanh trượt trong bản demo ban đầu có dấu đánh dấu tất cả các đơn vị và ghi nhãn tại 5, 10 và 11), một SliderChangeListener mới cũng được tạo ra, chuyển qua thanh trượt đó như là đối số hàm tạo (constructor). Khi thanh trượt dọc thứ ba (có phạm vi 0 đến100) được tạo ra, SliderChangeListener mới được thêm vào nó như là một người nghe (listener) thay đổi. Điều này làm việc gần như mong đợi: Điều chỉnh thanh trượt dọc thay đổi phạm vi của thanh trượt ngang. Thật không may, các dấu và các nhãn cũng chẳng làm việc tốt. Các nhãn có tối đa năm dấu làm việc tốt miễn là phạm vi này không quá lớn, nhưng nhãn phụ tại 11 nhanh chóng là vấn đề về tính sử dụng, như trong Hình 1:
Hình 1. Các nhãn chạy cùng nhau Cập nhật các dấu và các nhãn Giải pháp rõ ràng sẽ đơn giản là đặt khoảng cách đánh dấu trên thanh trượt ngang, bất cứ khi nào giá trị tối đa của nó được cập nhật, như thể hiện trong Liệt kê 3: Liệt kê 3. Thiết lập khoảng cách đánh dấu
// DOES NOT WORK int tickMajor, tickMinor; tickMajor = (i > 5) ? (i / 5) : 1; tickMinor = (tickMajor > 2) ? (tickMajor / 2) : tickMajor; h.setMajorTickSpacing(tickMajor); h.setMinorTickSpacing(tickMinor); h.repaint(); Liệt kê 3 đúng theo như nó thực hiện, nhưng nó không dẫn đến sự thay đổi nào cho các nhãn được vẽ trên màn hình. Bạn phải thiết lập các nhãn một cách riêng biệt, sử dụng setLabelTable(). Thêm một dòng nữa để sửa chữa nó: h.setLabelTable(h.createStandardLabels(tickMajor)); Điều này vẫn còn để mặc cho bạn với các nhãn lẻ tại 11 đã được thiết lập ban đầu. Tất nhiên, mục đích này là phải có một nhãn luôn ở đầu mút phải của thanh trượt. Bạn có thể làm việc này bằng cách loại bỏ nhãn cũ (trước khi thiết lập giá trị tối đa mới) và sau đó thêm một nhãn mới. Mã này hầu như làm việc:
Liệt kê 4. Thay thế các nhãn public void stateChanged(ChangeEvent e) { JSlider js = (JSlider) e.getSource(); int i = js.getValue(); // clear old label for top value h.getLabelTable().remove(h.getMaximum()); h.setMaximum(i); int tickMajor, tickMinor; tickMajor = (i > 5) ? (i / 5) : 1; tickMinor = (tickMajor > 2) ? (tickMajor / 2) : tickMajor; h.setMajorTickSpacing(tickMajor); h.setMinorTickSpacing(tickMinor);
h.setLabelTable(h.createStandardLabels(tickMajor)); h.getLabelTable().put(new Integer(i), new JLabel(new Integer(i).toString(), JLabel.CENTER)); h.repaint(); } Nếu tôi đã nói với bạn một lần, thì tôi đã nói với bạn hai lần Bởi hầu như tôi muốn nói là, mặc dù các mã trong Liệt kê 4 loại bỏ nhãn ở 11, nó không gắn nhãn mới tại i; thay vào đó, bạn chỉ thấy các nhãn tại các khoảng tickMajor. Giải pháp này ban đầu hơi gây sốc: Liệt kê 5. Thúc đẩy cập nhật hiển thị h.setLabelTable(h.getLabelTable()); Trên thực tế hoạt động có vẻ vô nghĩa này có một tác động đáng kể. Các nhãn cho một thanh trượt được tạo ra bất cứ khi nào bảng nhãn được thiết lập. Không có cuộc gọi lại đặc biệt nào đối với các thay đổi trên bảng, do đó các giá trị mới được bổ sung vào bảng không nhất thiết phải có hiệu quả; không có hoạt động n ào rõ
ràng trong Liệt kê 5 có tác dụng phụ để cho Swing biết nó phải cập nhật hiển thị. (Vì sợ bạn nghĩ rằng tôi đã tự phát minh điều này, hãy chú ý rằng mã gốc SwingSet có lời gọi như vậy). Điều này chỉ có một vấn đề. Mong muốn rất hợp lý để đảm bảo rằng một nh ãn xuất hiện ở cuối thanh trượt đôi khi đặt hai nhãn ngay liền kề với nhau, hoặc thậm chí còn chồng lên nhau, như trong Hình 2: Hình 2. Xếp chồng các nhãn ở cuối thanh trượt
Có thể có một số giải pháp cho vấn đề này. Một là viết mã riêng của bạn để điền các giá trị vào bảng nhãn và dừng trình tự trước, để cho nhãn cuối cùng trong trình tự đó được phân tách một chút khỏi đầu mút của thanh trượt này. Tôi sẽ để lại phần này như là một bài tập cho bạn. Cập nhật các trình đơn Trong nhiều trường hợp, để hạn chế các thay đổi trình đơn để cho phép và đình chỉ các mục trình đơn là hoàn toàn thực tế. Cách tiếp cận này tùy thuộc vào cảnh báo chung được áp dụng để đình chỉ các mục: Tránh bỏ quên chương trình của bạn trong trạng thái không sử dụng được do vô tình đình chỉ các mục chủ yếu. Cũng có thể thêm hoặc xoá các mục trình đơn hoặc các trình đơn con. Thật không dễ dàng để thay đổi một JMenuBar; không có giao diện nào để loại bỏ hoặc thay thế các trình đơn riêng biệt khỏi thanh này. Nếu bạn muốn thay đổi một thanh (để khỏi thêm các trình đơn mới vào đầu mút phải của nó), bạn cần phải tạo một thanh mới và dùng nó thay thế cho một thanh cũ. Các thay đổi cho các trình đơn riêng biệt có hiệu lực ngay lập tức; bạn không cần phải xây dựng một trình đơn trước khi gắn nó vào một thanh hoặc trình đơn khác. Khi bạn cần phải thay đổi lựa chọn của mình về các tùy chọn trình đơn, cách dễ nhất là thay đổi một trình đơn cụ thể. Tuy nhiên, bạn có thể muốn thêm vào và loại bỏ toàn bộ các trình đơn và để làm như vậy chẳng có khó khăn đặc biệt nào. Liệt kê 6 cho thấy một ví dụ đơn giản của một phương thức chèn một trình đơn vào thanh trình đơn trước một chỉ mục đã cho. Ví dụ này giả định rằng JMenuBar được thay thế được gắn vào một đối tượng JFrame, nhưng bất cứ điều gì cho phép
bạn nhận được và thiết lập các thanh menu sẽ làm việc theo một cách giống như vậy: Liệt kê 6. Chèn một trình đơn vào thanh trình đơn public void insertMenu(JFrame frame, JMenu menu, int index) { JMenuBar newBar = new JMenuBar(); JMenuBar oldBar = frame.getJMenuBar(); MenuElement[] oldMenus = oldBar.getSubElements(); int count = oldBar.getMenuCount(); int i; for (i = 0; i < count; ++i) { if (i == index) newBar.add(menu); newBar.add((JMenu) oldMenus[i]); }
frame.setJMenuBar(newBar); } Mã này không phải là những gì mà tôi đã nhắm trước tiên; phiên bản cuối cùng này, được sửa chữa cẩn thận để nó hoạt động, phản ánh một vấn đề khó khăn về các thói quen thú vị. Ban đầu có thể có vẻ như cách rõ ràng để thực hiện điều này sẽ là sử dụng getComponentAtIndex(), nhưng điều đó đã bị phản đối. May mắn thay, giao diện getSubElements() là đủ tốt. Khuôn mẫu với JMenu cho newBar.add() có lẽ an toàn, nhưng tôi không thích nó. Giao diện getSubElements() hoạt động trên trình đơn, không chỉ là các thanh trình đơn; các trình đơn có thể có các phần tử con theo một số kiểu, nhưng các JMenu là các phần tử duy nhất mà bạn có thể thêm vào JMenuBar. Vì vậy bạn phải tạo khuôn mẫu phần tử đó cho JMenu để vượt qua nó đến phương thức JMenuBar.add(). Thật không may là nếu bản sửa đổi API trong tương lai cho phép bạn thêm các phần tử của các kiểu khác với JMenu cho một JMenuBar, thì nó sẽ không còn cần thiết nữa, hoặc thậm chí an toàn, để tạo khuôn mẫu các phần tử trả về tới JMenu. Mã trong Liệt kê 6 phản ánh một điều khác ngoài thói quen giao diện khôn ngoan; vấn đề trình đơn phải được lưu trữ trước. Khi các trình đơn được thêm vào thanh mới, chúng được tách khỏi thanh cũ. Mã trong Liệt kê 7, mặc dù nó có vẻ tương tự, nhưng không làm việc; vòng lặp chấm dứt sớm: Liệt kê 7. Vòng lặp kết thúc quá sớm
// DOES NOT WORK for (i = 0; i < oldBar.getMenuCount(); ++i) { if (i == index) newBar.add(menu); newBar.add((JMenu) oldMenus[i]); } Những người dùng được hưởng lợi từ tính nhất quán trong một giao diện; một trình đơn đã cho luôn ở cùng chỗ. Để thuận tiện cho người dùng, hãy cố gắng giữ cho các trình đơn có thể thay đổi về đầu mút phải của danh sách các trình đơn, còn với các trình đơn không thay đổi được đặt ở những vị trí cố định phía bên trái. Tương tự như vậy, khi luôn luôn có thể, hãy giữ cho các mục ở cùng một vị trí trong một trình đơn. Một mục trình đơn chuyển sang màu xám ít gây rối cho người dùng hơn một mục đến và đi, bởi vì các mục khác trên trình đơn đang không được di chuyển theo nhiều hướng. Vòng lặp trong Liệt kê 7 sao chép chỉ một nửa các mục đó. Ví dụ, nếu bốn mục có trên thanh trình đơn để bắt đầu, nó sao chép hai mục đầu tiên. Sau khi sao chép mục thứ nhất, i là 1 và getMenuCount() trả về 3; sau khi sao chép mục thứ hai, i là 2 và getMenuCount() trả về 2, do đó, vòng lặp kết thúc. Tôi không thể tìm thấy bất kỳ tài liệu hướng dẫn về "tính năng" nào, theo đó việc thêm một trình đơn vào một thanh loại bỏ nó khỏi thanh khác, vì vậy nó có thể không phải do cố ý. Vẫn còn, thật dễ dàng đủ để tiến gần đến.
Loại bỏ một trình đơn từ một thanh trình đơn dễ dàng hơn một chút; chỉ cần sao chép tất cả các trình đơn khác hơn từ thanh cũ đến thanh mới, và bạn đã hoàn tất. Thật dễ dàng! Nếu giao diện của bạn sử dụng rất nhiều thông tin cập nhật tr ình đơn động, có lẽ tốt hơn là tạo ra một bộ các thanh trình đơn và chuyển giữa chúng, thay vì cập nhật chúng lúc đang hoạt động trong tất cả thời gian. Tuy nhiên, nếu bạn thay đổi nhiều trình đơn, bạn cũng có thể khiến người dùng của bạn theo cách hoàn toàn điên rồ. Lỗi viết: Trong quá trình soạn thảo bài viết này, tôi đã không chú ý đến danh sách các phương thức kế thừa của lớp JMenuBar. Trong thực tế, nó có cả phương pháp remove (loại bỏ) và add (bổ sung) sẵn sàng để loại bỏ hay chèn một chỉ số đặc biệt. Bài học nữa là: hãy kiểm tra các phương thức kế thừa, không chỉ các phương thức lớp cụ thể. Thay đổi lại kích thước cửa sổ Một điều rất may mắn là trong đa số trường hợp, việc thay đổi kích thước cửa sổ xảy ra tự động. Nhưng bạn cần phải tính đến một vài tác động về việc thay đổi kích thước. Các thanh nút ấn, các thanh trình đơn và các tính năng tương tự có thể trở thành vấn đề trong một cửa sổ rất nhỏ. Các bảng (panel) đồ họa mà chương trình của bạn quản lý tự nó cần phải đáp ứng các sự kiện thay đổi kích cỡ. H ãy để cho Swing xử lý đóng gói các phần tử UI, nhưng chú ý đến kích thước của các phần tử; không chỉ nhận được kích thước một lần và tiếp tục sử dụng các giá trị đó.
Khôn khéo hơn, một số quyết định thiết kế, như tần suất của các dấu trên các thanh trượt, có thể được cập nhật hợp lý để đáp ứng với các sự kiện thay đổi kích thước cửa sổ. Độ rộng của một thanh trượt 100 pixel (điểm ảnh) không thể có nhiều nhãn có thể đọc như độ rộng một thanh trượt 400 điểm ảnh. Bạn có thể muốn lấy thêm một số các UI của bạn bằng cách thêm toàn bộ các tính năng tiện lợi mới về hiển thị lớn hơn. Tuy nhiên, phần lớn, bạn có thể bỏ qua việc thay đổi kích thước cửa sổ. Những gì bạn không nên làm là ngăn chặn hay ghi đè lên nó không cần thiết. Sự thuận tiện bên lề so với mã thể hiện của bạn không là điều cần thiết. Một kích thước cửa sổ tối thiểu có thể là hợp lý, nhưng hãy cho phép mọi người tạo ra các cửa sổ lớn như họ muốn. Nguyên tắc chung Bộ công cụ Swing cung cấp rất nhiều tính linh hoạt cho thiết kế giao diện người dùng. Được sử dụng cẩn thận, tùy chọn về cập nhật một giao diện trong lúc đang hoạt động có thể đơn giản hóa giao diện đó đáng kể; việc trình bày một trình đơn chỉ khi tùy chọn của nó áp dụng, ví dụ, có thể dễ dàng hơn cho người sử dụng. Thật không may, một số tính năng API làm cho cách tiếp cận này có khả năng là một thói quen nhỏ và những tác dụng phụ và các tương tác không phải lúc nào cũng được tạo tài liệu tốt như bạn mong muốn. Nếu bạn có ý tưởng về giao diện động, thì hãy sẵn sàng dành chút thời gian nữa cho việc gỡ rối. Bạn cũng có thể đang hoạt động ngoài các góc của thư viện Swing và thấy mình cần phải tiến gần đến nắm bắt các hành vi và/hoặc các lỗi.
Đừng để việc thiếu sự thực hiện rõ ràng ngăn cản bạn. Ví dụ JMenuBar của bài viết này cho thấy, ngay cả khi không có sự hỗ trợ cho một nhiệm vụ trong API, bạn vẫn có thể có khả năng tự mình thực hiện nó, mặc dù có một chút gián tiếp. Đừng quá nhiệt tình. Các UI động lúc tốt nhất của chúng là khi chúng làm cho các hạn chế vốn có rõ ràng hơn cho người dùng. Lý tưởng, một người dùng có thể thậm chí không nhận thấy rằng một giao diện đang thay đổi. Nế u thời gian duy nhất mà chúng có thể sử dụng trình đơn Object (Đối tượng) của chương trình là khi chúng có một đối tượng được chọn, thì chúng sẽ không nhớ rằng trình đơn đó không có phần thời gian còn lại ở đó. Mặt khác, nếu có một khả năng tồn tại là người dùng không thể đoán được lí do không có sẵn một tùy chọn, tốt hơn là để người dùng thử một hành động và nhận được thông báo lỗi thông tin. Điều này đặc biệt quan trọng đối với một số hành động. Nếu tùy chọn save bị đình chỉ, điều đó không giúp gì nhiều, khi tôi muốn lưu dữ liệu của mình. Chương trình này rất có thể nghĩ rằng nó đã được lưu lại, nhưng tại sao không cho tôi lưu nó! Và nếu có một lý do cụ thể tại sao tôi không thể lưu tệp này, có lẽ tôi muốn biết đó là gì. Thiết kế giao diện, mặc dù đã nhiều năm nghiên cứu, vẫn còn là một lĩnh vực trẻ theo nhiều cách khác nhau. Hãy thử nghiệm một chút. Các thay đổi động cho các UI có thể là một tính năng tuyệt vời làm cho chúng rõ ràng hơn, đơn giản hơn, và phản ứng nhanh hơn. Việc thêm các tính năng động yêu cầu bất cứ thứ gì từ công việc cần một vài phút đến một nhiệm vụ cần thời gian đáng kể. Mục lục
Đình chỉ một tiện ích (widget)  Điều chỉnh các phạm vi  Cập nhật các trình đơn  Thay đổi lại kích thước cửa sổ  Nguyên tắc chung 