23,27 €
Writing appealing cross-device applications today in Java ME is challenging as implementation differences in fonts, layout, and menus can make your application look and behave very differently on different devices. So far, the only way out has been low-level programming with its associated complexity.
The Lightweight UI Toolkit (LWUIT), an open source Java library, offers Java ME developers an easy-to-use API for creating impressive user interfaces with a device-independent look and feel. The LWUIT library contains many components and tools for bringing consistency and visual gloss to the user interface of your applications, and this book will take you through all of this, to help you get the user interfaces you want.
Java ME allows us to write applications that are, generally speaking, portable across a wide range of small devices that support the platform. While the basic functionalities usually work well on all supported devices, the area that does pose problems for developers is the User Interface. Native implementations of javax.microedition.lcdui - the primary API for UIs in Java ME - differ so widely from one device to another that maintaining a device-independent and uniform look and feel is virtually impossible. Another problem with the javax.microedition.lcdui package is that it does not support components and capabilities that can fully satisfy present day user expectations. The Lightweight UI Toolkit is the solution to these problems. LWUIT offers a wide range of components with a device-independent look and feel for building UIs. While some of these widgets are also available under lcdui, there are a number of new ones too. These additions enable application developers to design UIs that can come very close to their desktop counterparts in terms of visual sophistication and LWUIT is not just about new components either. The API supports a whole range of new functionalities (like Theming and Transitions) too.
This book takes Java ME developers through the library, with examples showing how to use the main components and functionalities. It also goes beyond a description of what is available by showing how to extend the library by plugging in custom-built classes.
Build captivating and device-independent UI screens using the LWUIT library
This book presents LWUIT through an optimum mix of theory and practice. Classes are described and their applications are demonstrated through a large number of examples. Example code is thoroughly analyzed and many screenshots are included to show what happens when the code is executed. Custom classes are built progressively with a thorough explanation of each step. The book also presents the underlying structural features of LWUIT that are important for skillful use of the API
This book is for Java ME developers who want to create compelling user interfaces for Java ME applications, and want to use LWUIT to make this happen
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 353
Veröffentlichungsjahr: 2009
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: August 2009
Production Reference: 1120809
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847197-40-5
www.packtpub.com
Cover Image by Parag Kadam (<[email protected]>)
Author
Biswajit Sarkar
Reviewers
Lucas Hasik
Valentin Crettaz
Acquisition Editor
Douglas Paterson
Development Editor
Dhiraj Chandiramani
Technical Editor
Shadab Khan
Copy Editor
Leonard D'Silva
Indexer
Monica Ajmera
Editorial Team Leader
Akshara Aware
Project Team Leader
Priya Mukherjee
Project Coordinator
Zainab Bagasrawala
Proofreader
Claire Lane
Production Coordinator
Shantanu Zagade
Cover Work
Shantanu Zagade
Biswajit Sarkar is an electrical engineer with a specialization in Programmable Industrial Automation. He has had extensive experience across the entire spectrum of Industrial Automation—from hardware and firmware designing for general and special purpose Programmable Controllers, to marketing and project management. He also leads a team of a young and highly talented group of engineers engaged in product (both hardware and software) development. He has been associated with a wide variety of automation projects, including controls for special purpose machines, blast furnace charge control, large air pollution control systems, controls for cogeneration plants in sugar factories, supervisory control for small hydel plants, turbine governors, and substation automation including associated SCADA.
Currently Biswajit consults on Industrial Automation and Java ME based applications. He has written extensively for Java.net on Java Native Interface, Java ME and LWUIT. He has taught courses on mathematics and analytical reasoning at a number of leading institutes in India. Biswajit has also taught a specially designed course on Java for MS and Ph.D. students as well as post doctoral fellows at the Center for Coastal Physical Oceanography, Old Dominion University, Norfolk, Virginia (USA).
Biswajit, originally from Calcutta, now lives in Nashik, India with his wife.
This book would never have seen daylight had it not been for the excellent support that I received from the editorial team at Packt Publishing. I must express my grateful appreciation of the roles played by Douglas Paterson at the critical formative stage of the book, and, later by Dhiraj Chandiramani. Lata Basantani and Zainab Bagasrawala made sure that the project remained on schedule, while Shadab Khan and his team deftly guided the completion process. I am grateful for the comments of the reviewers that helped me maintain clarity of thought, and ensured the technical integrity of the book.
On the personal front, first and foremost, I am indebted to Dada who equipped me with the ability to undertake such an activity. The encouragement and unstinting support I received from my wife Jyoti were a great source of strength and helped me survive those difficult times when I was nearly swamped by my various commitments and the temptation to give up was great. Isaac, my son-in-law, has always encouraged me to write and was a great confidence booster. Finally, I must acknowledge the sacrifices made by my grandchildren Anunita and Ian who spent many unhappy days and evenings without my participation in their games.
Lukas Hasik is Java enthusiast that likes to break the limits. However, he will always remember that real life happens out of the wires and chips.
Lukas works for SUN Microsystems from fall 2000. He used to be part of the NetBeans team, where he led a Quality Assurance team for NetBeans Mobility and NetBeans Core & Platform. Lukas has moved to the Compute Cloud group in 2009 and leads the QA team. He spoke at several conferences on topics about Java, Tools, and Testing.
I'd like to thank my employer for the extra time that I spent on airplanes, at airports, and in hotels during business trips. Those are the moments that I used for reviewing this book, and thanks to my wife Kamila for her patience during the nights of insomnia.
Valentin Crettaz holds a master degree in Information and Computer Science from the Swiss Federal Institute of Technology in Lausanne, Switzerland (EPFL). After he finished studying in 2000, Valentin worked as a software engineer with SRI International (Menlo Park, USA) and as a principal engineer in the Software Engineering Laboratory at EPFL. In 2002, as a good patriot, he came back to Switzerland to co-found a start-up called Condris Technologies, a company that provides IT development and consulting services and specializes in the creation of innovative next-generation software architecture solutions as well as secure wireless telecommunication infrastructures.
From 2004 to 2008, Valentin served as a senior IT consultant in one of the largest private banks in Switzerland, where he worked on next generation e-banking platforms.
Starting in 2008, Valentin joined Goomzee Corporation as Chief Software Guru. Goomzee is a Montana-based company that provides solutions for connecting buyers and sellers in any market vertical through mobile interactions.
Valentin also owns a small consultancy business called Consulthys, a new venture that strongly focuses on leveraging Web 2.0 technologies in order to reduce the cultural gap between IT and business people.
The Lightweight Toolkit (LWUIT) is designed to help developers to create highly attractive User Interfaces for MIDP 2.0 and CLDC 1.1 compliant small devices like mobile phones. This toolkit supports a number of interesting widgets and features like theming, animations, transitions, and logging. LWUIT also addresses the issue of fragmentation by making it possible to implement screens with a device independent look and feel.
This book covers the widgets and functionalities of the library in detail, demonstrating their use with a large number of examples and a profusion of screenshots. A number of structural and architectural issues are discussed to help you gain insight into the inner workings of the library.
LWUIT is an evolving library and we are bound to see modifications and additions to its current repertoire. The knowledge you gain from this book will help you significantly in understanding these changes and in remaining up-to-date. The Lightweight Toolkit Library is an external API that is not an integral part of the Java platform and has to be bundled with an application meant for a physical device. One implication of this is that any application you write based on a given version (like version 1.1) will not become obsolete and will work on future devices too.
This book will equip you with the knowledge and skills required to create applications that will impress users with visual sophistication.
Chapter 1 tells you what LWUIT is all about and, broadly, how it operates. Starting with an overview of LWUIT which present the widgets and the functional features, this chapter goes on to discuss the basic architecture of LWUIT and ends with introductions to the two classes that are its foundations—LWUITImplementation and Display.
Chapter 2 lists the items that you will need to download and tells you where to find them. It prepares you for trying out the examples in the book and for creating your own applications by building a demo project. Next, you get to know the Component class, the component rendering process, and the Graphics class. Finally, this chapter lays the foundation for using Style and Animation with components.
Chapter 3 deals with the Container class, which is designed to be the holder of components. There are a number of descendants of Container—the Form, the Dialog, the Calendar and the TabbedPane. These classes also are discussed in detail with examples to show how they can be used in applications.
Chapter 4 covers Labels and the three components that are its descendants. These are the Button, the CheckBox and the RadioButton. RadioButtons exhibit special properties when they work with the ButtonGroup class and this aspect is demonstrated through an example. This chapter also takes a look at the Border class, which is used in the examples.
Chapter 5 demonstrates how flexible a List, and its subclass ComboBox, can be. This flexibility is shown through the examples that use custom renderers to enhance the appearance and functionality of lists and combo boxes.
Chapter 6 explores TextArea and TextField—the two classes that enable users to enter, display and edit text. A text field has the interesting property of in-place editing and this is treated in detail in this chapter.
Chapter 7 takes you through the various layout managers that arrange components on containers. There are six layout managers and the examples show the different ways in which these classes place components. The root of these six classes is the Layout class, which too is studied here.
Chapter 8 shows how custom components can be built. Building such a component involves not only visual aspects but also issues like styling, event handling and event generation. All of these topics are dealt with in this chapter through the examples.
Chapter 9 demonstrates how LWUIT handles various non-code elements that may be required by an application. Images, Fonts, and Animation Resources are examples of such elements. Resource files are used to package these elements and the Resources class provides the methods for extracting them from a resource file. The LWUIT bundle contains LWUIT Designer, which is a very convenient utility for creating resource files. This chapter examines how resource files are built and used.
Chapter 10 is about Themes. Themes are used to establish visual coherence through all the screens of an application. The LWUIT Designer is the tool that displays, edits and builds the themes that define how your applications will look. In this chapter, you will learn about themes, their usage and how they can be created.
Chapter 11 shows off two fascinating functionalities of LWUIT—Animations and Transitions. Animations involve repeated rendering on a component while Transitions determine the way in which a form is moved out of or brought into display. In this chapter, you will study these two features and see how to use them in actual applications. You will also see how to develop a custom transition which demonstrates the process of such customization.
Chapter 12 shows you how the Painter interface can be used to customize the appearance of a component’s background. This chapter also explains how a transparent or translucent layer (like a glass pane) can be placed over a form to implement interesting visual effects.
Chapter 13 covers two useful utilities that come with the LWUIT library. These are the Effects and the Log classes. The Effects class simulates the reflection of an image and appends the reflection to the original image. The Log class enables you to monitor at runtime the inner workings of the classes that you write. This can be a very effective debugging tool. This chapter demonstrates the use of Effects and Log classes. It also examines the structure of Log class through an example that builds its subclass to provide additional capabilities.
The following are required for this book:
The LWUIT bundle—this can be downloaded from https://lwuit.dev.java.net/servlets/ProjectDocumentList
A JDK. If you do not have one installed on your computer, you can get the latest version at http://java.sun.com/javase/downloads/index.jsp
The Sprint Wireless Toolkit 3.3.2 which is available at http://developer.sprint.com/site/global/develop/technologies/java_me/p_java_me.jsp
This book is for Java ME developers who want to create compelling user interfaces for Java ME applications, and want to use LWUIT to make this happen.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "We can include other contexts through the use of the include directive."
A block of code will be set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be shown in bold:
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "clicking the Next button moves you to the next screen".
Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, and mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Visit http://www.packtpub.com/files/code/7405_Code.zip to directly download the example code.
The downloadable files contain instructions on how to use them.
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
The Lightweight User Interface Toolkit (LWUIT) is a UI library for the Java ME platform. It enables a developer to create visually attractive and functionally sophisticated user interfaces that look and behave the same on all Java ME enabled devices compatible with MIDP 2.0 and CLDC 1.1. In this library, there are enhancements to graphical components that are part of the javax.microedition.lcdui package, brand new widgets like the TabbedPane and Dialog, and there is also support for new features like animation and transition. The Swing like architecture of LWUIT permits customization of the appearance of an application. And, best of all, it makes sure that our applications will look just the same, regardless of the platform they are deployed on.
In this chapter, we shall cover the following:
By the time you get through this chapter, you will know what LWUIT is all about, and broadly, how it operates.
Java ME allows us to write applications that are, generally speaking, portable across a wide range of small devices that support the platform. While the basic functionalities usually work well on all supported devices, the area that does pose problems for developers is the User Interface. Native implementations of javax.microedition.lcdui—the primary API for UIs in Java ME, differ so widely from one device to another, that maintaining a device-independent and uniform look-and-feel is virtually impossible.
Non-uniform look-and-feel is not the only reason why developers have been waiting for something better to turn up. The javax.microedition.lcdui package does not support components and capabilities that can fully satisfy present day user expectations.
This is why the arrival of 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 too. These additions 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. LWUIT is not just about new components. The API supports a whole range of new functionalities (Theming, Transitions, and more).
Our overview of LWUIT will discuss the following aspects:
A Component is an object that has a visible avatar. Generally speaking, a component can also sense and react to customer inputs. A Widget is a specific type of component with its own distinctive look and feel. A button is a widget and so is a combo box.
During our exploration of LWUIT, we shall keep using the terms Widget, Component (with a capital C) and component. To make sure that we avoid any confusion, let us define what we mean by these terms. The LWUIT library has a Component class that is the superclass for all widgets and embodies their essential qualities. The word Component (yes, with a capital C) will be used to refer to the class, while component (with a lowercase C) will mean any instance of the Component class. This principle of distinguishing between Component and component will be applicable to all classes and their instances. So the word Label refers to the class, and the word label refers to a specific object of that class.
The widgets are the visible faces of LWUIT. So before we delve into the inner details of the library, let us check out the widgets. The following figure is the widget family tree showing all major widgets.
Among the widgets, the Container is the basic 'holder' which can contain other components, including other containers. This nesting ability of containers allows complex and elaborate UIs to be built-up. The arrangement of components within a container is taken care of by a layout manager.
Form is a container with a TitleBar at the top, on which the title of the form can be written, and a MenuBar at the bottom for commands and menu. The space between the two bars is for the content pane, which holds the components that are to be placed on the form.
The container branch of the family tree also has Dialog, TabbedPane, and Calendar. All of these Widgets will be introduced here, and dealt with in detail in Chapter 3.
The previous screenshot shows a form and its constituent areas. The title of the form appears on the TitleBar, and the border at the bottom with the Exit command is the MenuBar. We can also see where the content pane goes.
A TabbedPane lets a number of component groups share the same space. Each group of components has a tab associated with it, and the user sees only the group corresponding to the tab that has been selected.
The default placement of tabs is at the top of the pane. However, it is possible to position them at the left, right or at the bottom of the pane. The following screenshot shows a tabbed pane with the tabs at the top, and with the first tab selected.
This widget shows date information and supports 'scrolling' through dates and months. The following screenshot shows a calendar:
A Dialog is a component that is usually displayed against a tinted background and covers a part of the screen. By default, a dialog is modal, that is, it blocks the calling thread until it is closed by calling the dispose () method. Dialogs can be one of five types:
Dialogs can be used to convey information to the user at runtime, and also to collect user feedback. The type of the dialog would normally determine the sound to play when the dialog is displayed. It is possible to add icons to a dialog to graphically indicate the dialog type. The following screenshot shows a simple warning dialog with the Ok and Cancel commands:
A Label displays images and text that cannot be selected. A label does not interact with the user. A number of alignment possibilities are supported for positioning the label, and also for positioning the text with respect to the image on the label. Label and its descendants (Button, RadioButton, and CheckBox) are covered in Chapter 4.
A Button is primarily intended for capturing an input from a user. In a way, we can think of a button as a label that can sense user action—specifically, a click.
The Button class extends Label. A button has states, and it generates an action event when selected and clicked on. Like a label, a button can have a descriptive text or an image or both. The three states of a button are as follows:
A button has two subclasses—RadioButton and CheckBox. A radio button has all of the functionalities of a button. In addition, a radio button can be added to a ButtonGroup, which allows it to maintain its selection state exclusively within the group. Within a button group, only one radio button can be in the pressed state at a time. If another radio button is clicked on, then the one that was in the pressed state earlier will get deselected. Also note that once a radio button is in the pressed state, clicking on it does not change the state.
A check box is similar to a radio button in the sense that it can remember its state, if it has been selected by being clicked on. However, repetitive clicking on a check box will toggle its state between selected and deselected. Another difference is that a check box cannot be a part of button group.
A number of labels, buttons, radio buttons, and check boxes are shown in the following screenshot. The screenshot shows that the first two buttons are in the default state, while the third is in the rollover state. Both the check boxes are shown selected, but only one radio button in each group is selected.
TextArea is a component that displays text that may be editable. The editing is performed using the native system editor, which often opens a new screen. A text area uses the concept of constraints just like TextField of javax.microedition.lcdui. The constraints allow a text area to be tailored to accept a particular type of input like a password or an email address. We shall study this in detail when we discuss TextArea in Chapter 6. The following screenshot shows a form with a text area:
A TextField (this one is a part of LWUIT) extends TextArea, and provides a single line text display. It differs significantly from TextArea in the way that it supports text editing. In Chapter 6, we shall study TextField in detail.
A List is a very widely used component that presents a number of information items to the user. The items are presented in a single column, but each item may contain multiple lines of text and images.
The data structure of a list is represented by the ListModel interface. Therefore, a list is not tied to any specific data structure, and can display information from any object that implements this interface. Similarly, the rendering of a list is performed by any class that implements the ListCellRenderer interface, thus making it possible to create the kind of look the application developer wants. The library includes default implementations of the above interfaces that make it easy to instantiate a list.
List and its subclass ComboBox will be discussed in Chapter 5. The following screenshot shows a simple list with four items:
Compare this with the list shown in the following screenshot and its significantly different appearance. The application behind the following screenshot implements its own renderer to achieve a very polished and attractive look. We shall see how to write custom renderers in Chapter 5.
The ComboBox is a space saving component that drops down a list when its button is clicked on. The user can then select one of the items on that list. As ComboBox extends List, you can use custom models and renderers for combo boxes too. The following screenshot shows a combo box with a four item drop-down list:
LWUIT incorporates a number of 'behind the scenes' support elements that make it possible for the functional features to operate. We shall now take a look at these elements, and see how they work.
Applications often require non-code items. For example, an image used as an icon for a label by an application, is such an item. LWUIT allows such items to be packaged in bundles.
A resource bundle is essentially a binary file that can be loaded into a device. An application can have more than one resource file, and each such file can contain resource elements of the same or different types.
The following types of resource elements are supported:
Individual resource elements can be extracted by a set of appropriate methods in the Resource class. Resource files can be built by using the LWUIT Designer, which is an utility that is a part of the LWUIT bundle. In Chapter 9, we shall study the Resource class and resource files, and we shall also learn how to use the LWUIT Designer.
LWUIT brings the power of sophisticated layout managers to the design of UIs for small devices. These managers are responsible for arranging widgets on a container.
The managers supported are:
Layout managers will be covered in Chapter 7.
LWUIT provides a very convenient way of defining the appearance of a component at a single point. Each component has a Style object associated with it. The attributes related to the look of the component can be set within this object. The attributes are:
When a component is generated, it constructs a default style object. The values of the attributes of this object can be changed at runtime to modify the appearance of a component. We will talk about styles in greater detail in Chapter 3. We will also use style objects to specify the appearance of a widget in many other chapters.
The Painter interface, discussed in Chapter 12, allows you to draw on the background of a component. A painter can be used to draw a specific pattern on the background of one, or a group of components. The LWUIT package provides two classes that implement this interface:
A painter can also be used as a transparent or translucent layer called a glass pane on top of a form.
An interesting feature of LWUIT is that it manages the appearance of an entire application from a single point. The UIManager is the class that co-ordinates the visual aspects of an application. This is a singleton to ensure that there is only one instance of UIManager per application. The methods of this class enable it to impose the same look on all components and to localize the UI on the fly. As UIManager is the class that controls the rendering of components, there will be many examples in this book that will demonstrate the use of this class.
LookAndFeel is the interface that takes care of all rendering for an application. Therefore, it is possible to completely customize the appearance of an application by implementing the appropriate methods of this interface. The concrete implementation of LookAndFeel that comes with the LWUIT package is DefaultLookAndFeel and this class controls the actual rendering of the default look of the application. We can also plug in a custom implementation of LookAndFeel, by using the setLookAndFeel method of UIManager. We shall use DefaultLookAndFeel in many of our examples in this book.
A really interesting aspect of LWUIT is that it goes beyond just components, and offers features that enable us to produce very sophisticated UIs. In this section, we introduce these features.
The LWUIT library supports animation at different levels, and also the implementation of different modes of transition from one form to the next one to be displayed. In the context of LWUIT, animation essentially allows objects to paint succeeding frames at timed intervals. Transition refers to the way in which a form is brought into, or taken out of the display screen. SlideTransition, for instance, makes the new form slide in pushing the old one out.
The basic implementations of such transitions are achieved through the mechanisms provided by the Animation interface and the classes Motion, Transition, CommonTransitions, and Transitions3D, which are in the com.sun.lwuit.animations package.
The Animation interface defines objects that can be animated. All components are inherently capable of performing animation tasks, as all of them implement Animation.
Transition is an abstract class that represents animation from one form into another. Its two concrete subclasses are:
Motion is a class that implements motion equations. The types of motion that are built-in are Linear, Spline, and Friction.
In Chapter 11, we shall go into the details of these two functionalities, and create a custom transition.
A Theme defines a uniform look for all visual components in an application. A theme file is essentially a list of key-value pairs that define the relevant attributes. We have seen that a style object specifies how a particular component instance will look. A theme can be thought of as a common style for the components that appear in it as "keys". For example, if you want all buttons in your application to have a green background, then you can do it by defining an appropriate "key-value" pair in your theme. We shall learn how to apply themes in Chapter 10.
This is a debugging aid that allows you to log information at runtime. The com.sun.lwuit.util.Log class provides methods for logging information into a log file (created in the root directory) using the FileConnection API, for example, and also for displaying logged information on a form. You can use the information saved in the log file through the FileConnection API.
The use of logging will be studied in Chapter 13.
The creators of LWUIT have said that this library has been inspired by Swing. Naturally, the architecture of LWUIT has adopted a number of features from Swing, modified to fit the constraints imposed by the small device environment in which it is meant to operate.
Like Swing, LWUIT renders all the visual entities itself, and does not derive them from native equivalents. This ensures device independence and visual uniformity. Two other features that are of interest to us are the modified Model-View-Controller (MVC) model and the Event Dispatch Thread (EDT).
The modified MVC model separates the logic (and data) that specifies the behavior of a component from the part that takes care of its appearance and user interface. For example, a list will have a part that contains the items to be shown (the model), and another that defines its look and its interaction with the user like scrolling (the combined view and controller). The two parts will interact with each other through predefined rules. In the context of LWUIT, this means that the look and feel of a list can be modified by plugging in a new combination of view and controller. The new list will look, and perhaps interact with the user differently from the "standard" list that comes with the library. However, its operation will be correct, as long as the rules of interaction between the two parts of the list are adhered to. In essence, this is the concept of the pluggable look and feel (PLAF) capability that LWUIT offers us. Through PLAF we can customize the visual aspects of a component quite easily.
The EDT is a thread that handles all interaction between the LWUIT objects in an application. Since the interactions take place over a single channel, they occur serially. This helps to avoid logical race conditions, and the highly frustrating bugs that they can produce.
In the next section, we shall see how EDT handles inter-component communication, and how critical it is to the proper operation of LWUIT-based user interfaces.
The LWUITImplementation is an abstract class that extends javax.microedition.lcdui.game.GameCanvas, and performs a number of critical functions. The GameCanvasImplementation class extends LWUITImplementation, and implements the abstract methods of its superclass. To obtain an instance of LWUITImplementation, the createImplementation method of the ImplementationFactory class needs to be called. This method returns an instance of GameCanvasImplementation that works as the default LWUIT implementation. This activity of creating an LWUIT implementation object is performed by the Display class, as explained in the next section, and is transparent to the application developer. Although, a developer who wants to use LWUIT to create a user interface would have no need to have access to this class, a broad understanding of the role played by the LWUITImplementation class helps in more effective utilization of the library.
The key issue about the structure of LWUIT is that it is built on top of javax.microedition.lcdui—the UI package that comes with MIDP 2.0. This means LWUIT needs to use the infrastructure provided by lcdui to render everything. Specifically, lcdui has to provide a surface on which LWUIT can draw. So the starting point for an LWUIT application is an instance of LWUITImplementation (which is actually a game canvas object) on which all components are drawn. Regardless of the number of forms and widgets in your application, there is just one instance of game canvas, which is used for rendering the various visual entities. Therefore, when you see a form replace another on the screen, remember that the new form has been drawn on the same object on which the earlier form had been rendered.
In addition to being the common rendering surface, LWUITImplementation performs two very important tasks—it listens for all commands directed to the LWUIT environment, and also acts as EDT, the main thread for input events, painting, and animation. To get an idea of how this works, let's consider a simple example. The following screenshot shows three buttons with the top-most button having focus:
If the scroll-down key is pressed now, then an event is sent to the underlying game canvas, that is, the LWUIT implementation object. The LWUIT implementation object does not directly act on the event, but puts it in a queue for the EDT to handle.
The EDT takes events sequentially from the queue, and sends them to the form that is currently on display. The form keeps track of the component within it that has focus. It also knows the details of components contained by it, and the order in which focus will move from component to component. When the form finds that it has received a scroll-down event, it transfers focus to the next button. If the select key is pressed, then the form would know the event is meant for the button that has focus, and would retransmit the event to the appropriate button. The button will redraw itself as its state has changed, and call the registered listener(s). Finally, when the event reaches the listener for the button, the required action is taken.
