professional java user interfaces phần 7 potx

368 Web-Based User Interfaces 2:8 PM 9 March 2006 c09.fm 1.0 9.3 Implementing Web applications with Java This section discusses the main technologies available for implementing Web GUIs with Java. Before going into details, it briefly introduces the ‘big picture’ in current architectures for Web GUIs. The typical architecture of a Web application One of the most striking differences in building Web interfaces using Java tech- nology, rather than applications, is the fact that Web pages are defined in non- object-oriented languages. This results in an ‘impedance mismatch’ between the presentation technology and the remainder of the code that is implemented with Java classes and other languages, similar to that created by relational databases. Web presentation also impacts GUI interaction, which usually results in GUIs with a lower level of user interaction than for desktop application GUIs, such as lack of features like drag and drop, undo, and so on. In Web GUIs event-based communication is usually needed less, because Web clients usually provide less interactive features for users, which is reflected on the server-side implementa- tion. Furthermore, additional care is devoted to simplifying the generation of the GUI in the markup language of choice, and the content assembly of different areas of the GUI. A Web GUI typically communicates with a Web server, submitting HTTP requests that the Web server forwards to other parts of the Web application. Such requests contain the session state and the data related to the current request. Although many arrangements are possible, the Web server is usually part of a Web tier in a J2EE architecture, interacting with the business and enterprise information system tier. Design details of Java Web applications can be found in countless books, such as (Alur, Crupi and Malks 2001) for J2EE patterns, (Fowler et al. 2003) for general Figure 9.10 Too compact a navigation design c09.fm Page 368 Thursday, March 9, 2006 2:09 PM Implementing Web applications with Java 369 2:8 PM 9 March 2006 c09.fm 1.0 enterprise patterns, (Marinescu 2002) for EJB-specific design patterns and (Johnson 2003) for a general introduction to J2EE applications. Basic Java Web GUI technologies Java Web technology can be seen historically as a stack of technologies that have grown by accretion over the years – that is, a higher-level layer on top of an existing, less powerful one – in an attempt to provide more powerful features with lower complexity for developers. This technology stack can be roughly described from the bottom as: • Servlet technology (from the first half of 1997) accepts and processes Web requests using server-side Java code executed in a specialized container application, the servlet container. • JSP (JavaServer Pages) technology (from the first half of 1999) builds on top of the Servlet technology to provide easier management of dynamic Web pages. • JSF (JavaServer Faces) technology, whose first specification release was at the end of 2003, builds on JSP technology to provide higher-level specification for user interfaces. Given its novelty, JSF deserves a brief introduction of its own. JavaServer Faces 7 is a framework for visual components for Web applications that allows the creation of Web GUIs that run on a Java server. The GUI’s rendering is left to the browser. Components are rendered separately from their logical definition – different types of table widgets can be used, or the same command component can be rendered as a button or hyperlink as needed, for example. JSF comprises a Java API and custom tag libraries. The API represents UI compo- nents, manages state, handles events, and validates input, as well as supporting internationalization and accessibility options. JSP custom tag libraries are provided for defining visual components within a JSP page, and for binding components to server-side objects. Tag libraries can be created using various disparate Web presen- tation technologies. The stack of technologies for Web GUIs for server-side Java is shown in Figure 9.11. 7. Defined in Java Specification Request (JSR) 127. c09.fm Page 369 Thursday, March 9, 2006 2:09 PM 370 Web-Based User Interfaces 2:8 PM 9 March 2006 c09.fm 1.0 Java applets Instead of adopting a markup-based technology to represent primary content within a browser, developers can use Java applets embedded in Web pages and interpreted by a dedicated browser plug-in that launches a JVM to execute them. Two main options are available: • Java 1.1 support. This can be achieved by targeting the older JDK Version 1.1, does not require any additional installation, as JRE 1.1 comes pre-installed on all the main Web browsers, and can optionally take advantage of other libraries for more sophisticated services. Swing can also be loaded as a sepa- rate library, and a wide range of third-party libraries and client environments that support JDK 1.1 exist. For a discussion about such third-party technolo- gies, see Chapter 11. • Targeting the Java 2 environment. Writing code for the Java 2 platform makes it easier to achieve sophisticated graphical effects and in general to take advan- tage of its more powerful and up-to-date software runtime environment. The major drawback of this approach is the need to download and install the JRE plug-in. Java applets are not straightforward mini-applications written in Java, as Java game developers know only too well. Code written for a general applet container must target a number of different environments – different applet containers built for different browsers all differ slightly from each other, even for different versions of the same browser – and must cope with their quirks uniformly. Figure 9.11 Basic technology stack for server-side Java Web GUIs c09.fm Page 370 Thursday, March 9, 2006 2:09 PM From Web applications to rich clients 371 2:8 PM 9 March 2006 c09.fm 1.0 Fortunately, Java applets have been available since late 1995, so a wide knowledge base is available to developers. Despite their demise in favor of more domain- specific technologies such as Flash, Java applets are still a viable and competitive choice in many scenarios. There are niches of application domains in which Java applet technology is widely used, such scientific simulation, didactic client-side Web applications in general, small applications, video games, and so on. 9.4 From Web applications to rich clients The architectural discussion of Web applications mentioned code that resides on the server tier and provides Web content suitable for display on a client Web browser. From a technical viewpoint, Web applications with basic GUI design requirements are simpler to build than desktop applications, because of their more regular structure and the wide availability of mature support frameworks. On the other hand, the sheer range of possibilities available when building a desktop application GUI can confuse developers with a background solely of Web programming. Accommodating a desktop application GUI as an additional client of an enter- prise application poses the following challenges for Java developers whose programming background is mainly in Web technology: • The intricacies of putting together a desktop GUI go far beyond laying out widgets on a screen, as this book demonstrates. • Given the current stack of technologies available for building desktop appli- cation GUIs, developers are more involved in GUI design details when working on desktop applications than for Web-based ones. This poses a number of critical issues regarding usability, visual design, and others that only developers themselves can solve. • Developers work in an environment in which the domain model and busi- ness logic is already built and working on the application’s servers. Some parts of it might be able to be extended to accommodate specific needs of the desktop application GUI, but much of the domain is often given ‘as is’ to GUI developers. This poses problems if the business domain was weakly modeled on and/or influenced by the Web paradigm, or if details dependent on Web issues leaked into the model itself, such as a page-oriented API for obtaining query results. • When it is not feasible to separate the Web-oriented user interface aspects fully from the business domain, the simplest solution may be to reuse some of the existing code for the rich client application. This will inevitably tend to create a Web-like GUI that costs as much as a full-blown desktop GUI, as well as being harder to maintain because of the common dependencies with c09.fm Page 371 Thursday, March 9, 2006 2:09 PM 372 Web-Based User Interfaces 2:8 PM 9 March 2006 c09.fm 1.0 the Web-specific code. Such an approach, although sometimes unavoidable, can lead to dangerous long-term maintenance scenarios, and impact the quality of the GUI design itself, which can have extensive ramifications on customers and the real value added to the whole application. Different development habits Web development and GUI development are slightly different animals, for a number of reasons: • Development and installation brings a number of issues and technical deci- sions that Web GUIs don’t have. • User are always ready to judge the results of your work, and expect a more compelling experience from desktop application GUIs than from Web GUIs. Desktop applications are usually preferred over Web clients because of their better user experience, especially in specific areas, such as for repetitive users, or business-critical tasks, so developers must satisfy higher expecta- tions than merely providing a ‘Web interface.’ • Rich client platforms, although catching up, are still less refined and usable than their server-side counterparts, and a unifying standard is missing 8 , something like EJB on the server side, for example. This confuses developers who are familiar with the Web technology landscape and who often prefer using raw GUI toolkits and few other support libraries even when devel- oping mid-sized projects. Deeper software design differences also exist when the same design strategies are applied to the two different scenarios. As an example of this, consider the differ- ences between the MVC (Model-View-Controller) design introduced in Chapter 6 for desktop applications, and its corresponding version for the Web. The classic MVC design for the Web 9 organizes an application into: • A model with its data representation and business logic. • A number of views for the model, providing data presentation and user input. • A controller to dispatch requests and handle control flow. This design works fine over the Web, where requests to the server comprise a small fraction of the total volume of user interactions in the client GUI. There is thus no need to add the Observer pattern to track changes among the various parts, and hundreds if not thousands of MVC instances may be active at the same 8. See the discussion in Chapter 13 about standard components for rich client applications. 9. See the Struts library or, for a general reference, (Alur, Crupi and Malks 2001). c09.fm Page 372 Thursday, March 9, 2006 2:09 PM Summary 373 2:8 PM 9 March 2006 c09.fm 1.0 time, all needing to interact with each other (at least when the Swing toolkit is used). It is little wonder therefore that Web developers feel a bit lost when building complex desktop GUIs, and resort to vague concepts like the ‘need to centralize controllers’ or to set up some form of central command management. Despite being called by the same name, client-side and server-side MVCs are very different when it comes to their details. 9.5 Summary This chapter discussed the scenario for Web GUIs using Java technology, covering some aspects of Web GUI design in relation to the general concepts introduced in Chapter 2. We covered the implementation aspects of Java Web GUIs and the architecture of Java Web applications. Differences between desktop and Web GUIs were high- lighted for the common case of adding a rich client to an existing server application. We also mentioned differences between client and server applications in the imple- mentation of some common design strategies, such as MVC. c09.fm Page 373 Thursday, March 9, 2006 2:09 PM c09.fm Page 374 Thursday, March 9, 2006 2:09 PM 10 J2ME User Interfaces 2:14 PM 9 March 2006 c10.fm 1.0 This chapter introduces the user interfaces supported by the Java 2 Micro Edition (J2ME or JME) edition. Java platforms other than J2EE/J2SE, such as the JavaCard environment, which has no explicit GUI support, won’t be covered. The practical examples in this chapter are based on the J2ME Mobile Information Device Profile (MIDP). However, most of the material in this chapter, whenever not explicitly expressed otherwise, applies to J2ME GUIs in general, not only MIDP GUIs. J2ME is introduced briefly with a technical introduction of this programming environment, followed by some details about GUI design for this profile. Practical examples are given. A questionnaire for assessing the usability of J2ME applica- tions can be found in Appendix B. This chapter is structured as follows: 10.1, Introduction to the MID profile briefly introduces the J2ME MID profile. 10.2, The MIDP UI API introduces the details of the API for MIDP GUIs. 10.3, Designing MIDP GUIs provides an overview of GUI design for MIDP GUIs. 10.4, Designing navigation discusses the specific of navigation in a MIDP GUI. 10.5, An example custom item discusses the customization of a MIDP GUI compo- nent by means of a practical example. 10.6, An example ad-hoc item shows an example an ad-hoc item component for representing numeric data using pie charts. 10.7, An example application introduces the Park MIDP application, illustrating a GUI design and development approach to navigation. 10.1 Introduction to the MID profile J2ME is targeted at embedded and consumer electronics devices. It has two primary types of component – configurations and profiles. The J2ME architecture is composed of a few configurations that define the common features for a class of devices. Two configurations are currently available: • The Connected Limited Device Configuration (CLDC), designed for devices with constrained hardware resources. Such devices typically run on either a J2ME User Interfaces c10.fm Page 375 Thursday, March 9, 2006 2:15 PM 376 J2ME User Interfaces 2:14 PM 9 March 2006 c10.fm 1.0 16- or 32-bit CPU and have 512 Kilobytes or less of memory available for client applications and the Java platform itself. • The Connected Device Configuration (CDC), aimed at next-generation devices with more robust resources than CLDC devices. These configurations dictate the Java virtual machine, core libraries and some APIs, while leaving the differences between each device to be described by a profile. User interfaces are defined on a per-profile basis, allowing for maximum flexibility when taking advantage of device characteristics. Tailoring APIs to a particular profile allows for efficiency and accuracy, but results in several different class packages and slightly different vendor-specific API implementations. This chapter concentrates on the MID profile, part of the CLDC configuration. The MID profile is aimed at modeling the large category of Java-enabled wireless handheld devices. Such profiles describe all issues, such as the user interface, the application model, networking, and persistence storage, that are related to Java- enabled mobile devices like two-way pagers and cellular phones. We focus on the UI API here. An application running on this type of Java-enabled devices is referred to as a MIDlet, because it can be deployed seamlessly on a wide range of different MIDP- compliant devices, just as an applet is deployed in different Web browsers. This capability is one of the most important features of the J2ME initiative for wireless devices, and has the potential to create a completely new and huge market for such software applications. The MID profile has been designed both to abstract applications from the client hardware on which they run, and to ease the develop- ment of similar applications. The latter aspect arises when we discuss the UI API, which has been modeled around the typical UI seen in today’s consumer cellular phones. Both the terms applet and application are used to refer to MIDP programs. For more information about the J2ME platform, visit: http://www.javasoft.com/products/j2me/ The code suggested here was developed and executed using various develop- ment tools. The J2ME Wireless Toolkit from Sun, for MIDP 2.0, is available at http://www.javasoft.com/products/j2mewtoolkit/ . Main UI concepts The J2ME MIDP GUI API has been designed for generic handheld devices with LCD screens of various sizes, a typical minimum being 96 x 96 pixels, and running on hardware with limited resources. The richness of concepts and software architec- tures employed in the AWT and Swing APIs in the desktop Java world is clearly out c10.fm Page 376 Thursday, March 9, 2006 2:15 PM Introduction to the MID profile 377 2:14 PM 9 March 2006 c10.fm 1.0 of reach here, even if the MID profile assumes quite powerful hardware – at least when compared with other embedded devices or the JavaCard specification. The basic functionalities provided include the capability of manipulating the device’s screen to show a top-level component, a widget that occupies the whole screen, that has been decorated previously with simpler UI components, referred to as items. There is always only one screen object active at a time, representing the whole contents of the current device’s display: the concept of multiple windows is absent. Applications simply switch from one screen to another. No navigation semantics have been provided, both for generality and because applications are expected to be simple and not require many different screens and menus. One common navigation semantic seen on such devices, for example, is stack-like screen navigation, in which users find their way from one screen to another, closing the current one and redisplaying the previous one as screens are ‘piled’ to resemble a hierarchical organization. Navigation styles are left to the application developer’s implementation. Only basic widgets and a simple user input framework are provided. The Java classes provided are designed to reduce the need for subclassing by providing a comprehensive range of built-in options. It is important to note that, given the nature of the platform, developers must always query the current screen size for all but the simplest UI screens: assuming a fixed screen size can produce unusable UIs on MIDP-enable devices. The lifecycle of a MIDlet The lifecycle of a MIDlet is important, because it involves the concept of screen management directly. The native module that handles MIDlets in the MIDP- enabled device is called the application manager. A MIDlet can be in one of the following three states: • Paused. The MIDlet is shallowly initialized – that is, it does not use or hold any resources. The instance is quiescent in device RAM and is waiting for the application manager to be activated. This state is reached every time the appli- cation management invokes the pauseApp method on the given MIDlet, not only after its creation. The MIDlet screen is removed from the device display. • Active. The application manager has activated the MIDlet by invoking its startApp method. The MIDlet must explicitly assign the screen device. • Destroyed. This state is entered only once, and instructs the MIDlet to release all its resources and terminate its execution. All the UI initialization is performed in the startApp method. c10.fm Page 377 Thursday, March 9, 2006 2:15 PM [...]... J2ME User Interfaces Figure 10.6 The Park applet’s GUI structure Figure 10 .7 shows the main menu for the applet on the left, and the ‘About’ box on the right Figure 10 .7 The Park applet’s main menu The most interesting screen in this applet is the Payment Details screen, which persists the user data from session to session In the demo applet it is implemented very naïvely, as shown in Figure 10 .7 Figure... relevant to graphical user interfaces in Java 2 Micro Edition briefly, demonstrating the built-in support for GUIs in the J2ME MID profile It also discussed some simple demonstration examples of the use of such libraries, together with some high-level strategies for organizing the user interface of a MIDP applet GUI 2:14 PM 9 March 2006 c10.fm 1.0 11 Java Tools and Technologies Java Tools and Technologies... 378 J2ME User Interfaces User input management User input is handled both at high level, using Command objects, and at low level using the device keys directly Although the latter solution is available, it is discouraged, because... 11 .7, Profiling tools illustrates some profiler tools for Java GUIs 11.8, GUI builders discusses some visual editors for content assembly that are available for Java developers 11.9, Presentation layer technologies demonstrates some Swing look and feels and presentation technologies for SWT 11.10, Declarative GUIs with Java discusses the various alternatives for specifying GUIs declaratively for Java- based... Screens instances are tightly coupled 2:14 PM 9 March 2006 c10.fm 1.0 392 J2ME User Interfaces Finally, the AppData class contains all the business data required by the application In the trivial implementation used here, AppData uses has only two attributes: • The user s amount of parking credit – the money attribute • The user s name This class is also responsible for retrieving and saving data persistently,... it is supposed to help users, while giving a strong brand identification to the product However, such efforts sometimes end with incomplete, arbitrary GUIs that can confuse end users Users become accustomed to a mobile device’s look and feel, and may be uncomfortable with a downloaded applet that behaves ‘weirdly.’ Figure 10.3 shows a sample custom alert box that illustrates this7 Figure 10.3 An ad-hoc... the details Aiming for professional user interfaces on constrained devices should involve a constant focus on usability rather than other, secondary, issues This is not often the case: with tight deadlines and tough technical challenges to cope with, usability concerns often slip away 10.2 The MIDP UI API This section describes the practical UI component classes provided in the javax.microediton.lcdui... 2 Documentation 1 Training 1 Integration 1 Professional Services 1 Table 11.2 Table 2 OSMM recommended minimum scores Type of user Purpose of Use Pragmatist Experimentation 25 40 Pilot 40 60 Production 11.3 Early adopters 60 70 SWT or Swing? After a general introduction to OSS evaluation comes perhaps the most critical choice in technology selection for a Java GUI project, one that will shape the development... aimed at expert users that need more data and a richer interaction, such as people that spend most of the day driving in the city – taxi drivers, delivery drivers, and so on • Leveraging a limited information style5 This type of user would prefer a mainly textual application, where details are limited and only basic congestion information is provided This version will accommodate most users, so cheaper... keep these related items close, presenting a puzzling experience to the user 10.5 An example custom item We are now ready to see some practical examples of J2ME MIDP applications In contrast to desktop computers and other rich computing appliances, wireless devices have a limited set of features, and this influences their user interfaces A common error when developing MIDP GUIs is to try and achieve . GUIs for server-side Java is shown in Figure 9.11. 7. Defined in Java Specification Request (JSR) 1 27. c09.fm Page 369 Thursday, March 9, 2006 2:09 PM 370 Web-Based User Interfaces 2:8 PM 9 March. in the startApp method. c10.fm Page 377 Thursday, March 9, 2006 2:15 PM 378 J2ME User Interfaces 2:14 PM 9 March 2006 c10.fm 1.0 User input management User input is handled both at high level,. resources. Such devices typically run on either a J2ME User Interfaces c10.fm Page 375 Thursday, March 9, 2006 2:15 PM 376 J2ME User Interfaces 2:14 PM 9 March 2006 c10.fm 1.0 16- or 32-bit