User Interface « Graphics Desktop « Java Articles

HTML is a wonderful thing. It lets you lay out complicated user interfaces with a minimum of fuss; it does a great job of separating UI structure and layout from business logic; it's easy to write; and it's easy to maintain. Abstract Window Toolkit (AWT)/Swing layout is, in contrast, annoyingly difficult to use. You must modify (and recompile) code to change the look of your screens, and the code for a trivial layout is itself nontrivial, extending to many pages. Wouldn't it be nice if you could specify your entire client-side user interface in HTML?

In "Create Client-Side User Interfaces in HTML, Part 1," I discussed in depth HTMLPane, a class that simplifies layout of client-side user interfaces by letting you specify them in HTML and providing a way to submit a form to your program rather than a Web server. Now I conclude this series by examining HTMLPane code. You should read last month's article if you haven't already.

The user interface components supplied with early versions of Java -- which are still present in the java.awt package -- are called heavyweight components. They are called heavyweight components because a native user interface component is used to display each Java component -- a technique that gives Java applications the same look and feel as other applications written for a particular platform. These components are considered heavy because they require twice as many classes to implement -- a Java class plus its associated native class. They also have the unfortunate side effect of being opaque, which means that they can't be used to implement components with transparent regions, or components of non-rectangular shapes.

This column, my last on the AWT, introduces five techniques for enhancing a user interface. The techniques draw upon and extend the concepts learned in my previous two columns. I will describe how to select the font, the background color, and the foreground color of components; how to specify the preferred size of a component, and the insets of a container; and how to enable and disable components on the fly.

You may think that this technique can only be used for rapid prototyping or impressive rapid development demos, and that when you try to create a real-life business application, it will fail. But this is not true. The trick is in giving the model some tips in order to lay out the data for the user, or in order to throw some event in some circumstance. But you do not define the user interface, you only refine an automatically generated one.

It is in this context that the arrival of Lightweight User Interface Toolkit (LWUIT) is so exciting. LWUIT offers a wide range of widgets for building UIs. While some of these widgets are also available under lcdui, there are a number of new ones that enable application developers to design UIs that can come very close to their desktop counterparts in terms of visual sophistication. Even the components that are also offered by lcdui have been functionally enhanced. And LWUIT is not just about new components, either. The API supports a whole range of new functionalities, too -- theming, transitions, and more.

All is not lost! This article explains how to create user-interface elements that change dynamically. Although hand-coding is required, it turns out to be easy in the Java language, particularly when using the Abstract Window Toolkit (AWT). A simple demo application is included, along with source code.

Find out how you can build a graphical user interface with the Abstract Window Toolkit (AWT) and Java Foundation Classes/Swing (JFC/Swing) APIs.

JGoodies focuses on Java look, UI design and usability. We provide articles, libraries, example applications, desktop patterns and a Swing application architecture.

Prior to the release of the Java 2 platform, the Abstract Window Toolkit (AWT) was the extent of the Java platform's graphical capabilities. Various technologies, such as Swing, were introduced as optional extensions. With the Java 2 platform, most of these extensions have found their way into the core as part of the Java Foundation Classes (JFC). JFC refers to the entire set of graphical and user interface technologies included in the Java 2 platform, including AWT and Swing. In this article, we'll explore each of the major components of the JFC and then discuss some of the optional extensions.

Hand-coding a GUI in the Java language can be a tedious and error-prone process, regardless of the widget set you use. It's far easier to use a markup language to specify GUIs. The IBM Reflexive User Interface Builder (RIB) is an application that constructs and renders Java AWT/Swing and Eclipse SWT GUIs based upon a descriptive XML document, referred to as a script. RIB is both a specification for a markup language in which to describe Java GUIs and an engine for creating and rendering them. You can use RIB as a standalone application to test and evaluate basic GUI layout and functionality, or as a library within the context of a Java application to create and render GUIs for the application.

Lastly, if your goal is simply to attack some usability hot spots in an existing HTML-based user interface or to deliver a standards-based, plug-in-free, better-than-browser user experience, Ajax is the way to go. At this point in the hype cycle, Ajax seems to be emerging as the most popular Web 2.0 technology choice, but I wouldn't discount the role the other technologies will play over time as they mature.

As you've seen, a menu is a little window that is painted in front of your screen. It is really implemented as some special Dialog window. As with desktop applications, you can show a dialog window to warn, inform, or obtain some input from users. By default, all dialogs are modal; they intercept all input and block the background form/window, which is the common scenario when showing a dialog. A mode-less dialog window is planned for future releases of LWUIT.

In this article, I will look at the Yahoo User Interface (YUI) library in more detail. The YUI is an AJAX framework, but it is also a generic JavaScript library that provides a lot of Web 2.0 widgets or UI elements, effects, and tools for web developers.

I've actually written about this sort of stuff before, but not for JavaWorld, and the articles I've written now are out of date, so I thought I'd take another stab at the problem of describing object-oriented systems from the UI designer's point of view. Hopefully, by the time I'm done you'll understand in general terms how a UI in an object-oriented system has to work. I'll also endeavor to clarify why not one of the RAD tools on the market today (Visual Café, Visual Age for Java, Visual J++, JBuilder -- you name it) is usable if your final goal is a well-crafted object-oriented system.

The first analysis-level class of interest -- Rpn -- contains the main() method and little else. Though they aren't shown in the diagram, the class also contains a constructor and implementations of all the methods required by the interfaces. In an attempt to reduce the clutter a bit, I usually don't show these in a Unified Model Language (UML) diagram. As is the case with many object-oriented programs, main() (and the Rpn class, for that matter) aren't much to look at. Object-oriented systems tend to be networks of cooperating objects, with no central God class that controls everything from above. There's no spider sitting in the middle of the web pulling strands. An object-oriented system's main() method, as a consequence, typically creates a few objects, hooks them up to each other, and then terminates. That's exactly what happens here: main() creates an instance of the Parser and Math_stack, hooks them up to each other, and terminates.

Adding its salary to a sum is also a reasonable request to ask of Employee in some situations; both of the following are workable object-oriented solutions, since neither exposes the way in which salaries are implemented:

Bertrand Meyer, the author of the Eiffel language, came up with the notion of pre- and postconditions, commonly called assertions. Eiffel, described in Object-Oriented Software Construction (see Resources) supports those concepts directly within the syntax of the language. Java, unfortunately, provides no such support.

This sort of dynamic adaptability is essential when implementing user interfaces using the architecture that I described in the July and September columns (which you should read before proceeding -- I assume that you're familiar with the architecture I presented in those articles). In this architecture, a control layer builds a presentation from visual proxies of attributes that are provided by an abstraction-layer object. The abstraction layer cannot know the context in which the proxy will be asked to display itself, so the proxy must accommodate whatever space is available automatically.