CHAPTER
1
The History of Java UI Toolkits
Almost 20 years have passed since Java was first released in 1995; the eighth major version was released in 2014. During these two decades, the IT world has rapidly evolved. The size, speed, and requirements of computer hardware have changed dramatically, as have the user interfaces of software. In 1995, computers were mainly used in offices, making a decorative user interface (UI) unimportant for most applications. Most dialogs consisted only of labels, text fields, and buttons. More complex graphical user interface (GUI) elements such as tables or tab panes were not supported by most of the UI toolkits. But as computing has evolved from a specialized niche to part of everyday life for millions of people worldwide, the importance of a polished, practical, and purposeful UI has become paramount. It is now normal to have a computer or tablet-based device at home to manage music, photos, or other private documents, and most people using applications today do not have technical backgrounds, which is why applications have to be intuitive and easy to use. A good layout and modern UI controls and effects can help generate a better user experience. By using up-to-date technologies and frameworks, developers can create outstanding web, desktop, and mobile applications, and that’s why UI toolkits, including the Java UI toolkits available with the Java Development Kit (JDK), have evolved over the last 20 years.
This chapter will give you an overview of the important Java-based UI toolkits and some rising trends. Today, most applications have their own style, and the views are laid out in a pixel-perfect way. You’ll find out how that came to be.
Java SE UI Toolkits
Several generations of UI toolkits have been introduced in the JDK over the years to allow developers to create state-of-the-art applications with Java. JavaFX is the newest framework to provide the ability to create and design desktop applications with Java. Before I discuss the controls of JavaFX in depth, it is important to take a short look at the history of Java-based UI toolkits that are part of Java Standard Edition (Java SE). By doing so, you will get an overview of the fundamental differences and similarities between several generations of UI toolkits, specifically in relation to the JavaFX controls.
AWT
The first version of the Java Abstract Window Toolkit (AWT) was introduced in 1996; AWT is an abstraction of the underlying native user interfaces. Since Java runs on various platforms, AWT supports only the least common denominator of these platforms, so it has only a small number of supported components. Standard controls such as buttons and text fields are available, but more complex components such as tables are not part of the toolkit. By using AWT, developers create GUI components in Java code. Simultaneously, a native graphical component is created as a counterpart by the operating system, and a peer class is used as the link between these two instances. (These kinds of components are called heavyweight components.) Developers can define the attributes of a component, such as the visible text of a button, by using the Java class. However, the Java application has no influence on the graphical representation of the components because the operating system (OS) is responsible for rendering the controls.
AWT was improved with Java 1.1; it included new features such as event listeners and new components such as the scroll pane. However, the great advantage of AWT is also its worst weakness: By using the toolkit, each Java-based application takes on the native look and feel of the operating system automatically. On Windows, the typical Windows buttons and combo boxes will be shown if you create an app by using the framework, for example. On Mac OS, all components are rendered by using the Aqua look (Apple’s default UI definition). It’s almost impossible to create new components or modify the look of a control to deliver an application with a unique appearance.
Java Foundation Classes and the Emergence of Swing
In parallel with Java 1.1, Netscape developed the Internet Foundation Classes (IFC) library that represents a completely platform-independent UI toolkit for Java. Unlike AWT, IFC does not create a wrapper around native components; it provides controls that are completely managed and rendered by pure Java. This technology was originally designed to display applets in the Netscape browser, and the main objective of IFC was to create browser-independent applications that have the same appearance on any OS. In 1997, Sun Microsystems and Netscape announced the intention to merge IFC into Java.
The Java Foundation Classes (JFC) framework is the result of integrating IFC into Java. The classes in the framework include AWT, Java2D, Swing, and some additional APIs. JFC has been part of Java SE since 1998, which means Swing has been part of Java SE since version 1.2 (Java 2) and has become the main UI toolkit of Java.
Swing
Unlike the base development of IFC, which was written from scratch as a new API, Swing’s control classes are based on AWT; however, the internal architecture of the framework is completely different from AWT. This approach was chosen for compatibility purposes. Swing offers a set of so-called lightweight components that are completely managed and rendered by Java. Because of this, you can achieve the same graphical representation of components across operation systems. From a technical point of view, the graphical output of Swing is based on Java2D, an API for rendering two-dimensional objects that is also part of JFC. Although the features of Java2D and Swing are not “state of the art” anymore, these were modern APIs with many incredible options when JFC was released. Even today, you can create astonishingly good results by using Swing.
All UI controls in Swing are based on the
JComponent class, which extends the AWT Component class. This ensures that the main concepts for using Swing components are already known by AWT developers, and AWT layout managers, for example, can be used to lay out Swing-based applications without any learning curve. Figure 1-1 shows a general overview of the class hierarchy of AWT and Swing components.
FIGURE 1-1. Class hierarchy for AWT and Swing
By using the Java2D API, you can change the appearance of Swing-based components at any time or even create new components from scratch. Swing uses a Model-View-Controller (MVC) approach internally, in which the graphical representation of components is separated from the model in a special UI class. The base skin of a Swing button is defined by the
ButtonUI class, for example. Since the operating system doesn’t draw the components in Swing, the controls will have the same look across OSs. To achieve this, Swing includes the LookAndFeel API. By using LookAndFeel (LAF), you can define your own style for the complete Swing component set. In fact, Swing comprises a set of cross-platform LAFs and system-dependent LAFs. If you want to develop an application that always looks like the underlying operating system, you set the OS-specific look and feel for Swing. A Java version for Mac OS includes the Aqua LAF, for example. This will render all components so that they look like native Mac OS controls. If your application is running on a Windows system, it can use the Windows LAF that is part of Java on every Windows-based PC. New versions of these LAFs have native support for creating controls that you can’t distinguish from native ones. The framework offers some helper methods as well. By using them, you can configure Swing to always use the provided system look and feel depending on which platform the application is running.Another advantage Swing has over AWT is the rich set of components it includes. For example, in Swing, you can find tables, lists, and tree-based controls to represent the application data in the way that best fits your application view. These controls can handle lists of data by using renderers to support large amounts of data and show or process them in the interface without any problems. Above all, these new and flexible components are the reason why Swing is used to develop business applications. With Swing’s ability to manage and render controls that support LAFs and its internal use of Java2D, along with the many open source libraries and frameworks that can be used to extend functionality, Swing deposed AWT and remained for several years the standard UI toolkit for creating graphical desktop applications in Java.
From today’s point of view, Swing also has some weaknesses. One weakness is that many graphical effects that are standard in today’s modern applications cannot be implemented by using Swing (or they need a lot of hacks and workarounds). Examples include reflections and blur effects. Animations are also missing from Swing’s API, and a Swing-based dialog needs a lot of boilerplate code. Although creating special skins for controls or creating new components from scratch is possible in Swing, it is difficult to do. It requires a lot of training, and there are many pitfalls you can trip over before being ready to develop usable components for Swing. These are crucial reasons why Swing needed to be replaced by a new UI toolkit. Hence, JavaFX emerged and has been the recommended UI toolkit since Java 8.
Before diving into the history and features of JavaFX, I’ll briefly cover a few other UI toolkits and place them in the historical context of the default Java SE toolkits.
Additional UI Toolkits
In addition to the default toolkits that are part of Java SE, some other UI-based frameworks have been developed over the years. SWT and Apache Flex are two examples of toolkits developed during the reign of Swing. SWT is based on Java, but Apache Flex has nothing to do with Java and even offers some concepts that JavaFX has picked up.
SWT
Parallel to the release of Java 2 in 1998, IBM decided to implement its next generation of development tools in Java. The first generation of IBM’s development environment, VisualAge for Java, was based on Smalltalk and used the common widget (CW) framework to create the surface. This API was a thin layer on top of the native components of the operating system and therefore resembled AWT. For the developers at IBM, it was important that the new development environment, which today is known as Eclipse, would be based on a native look and feel. Since Swing could not provide these requirements by supporting platform-specific LAFs, the developers decided to create a separate UI toolkit with the same features as CW. The result was the Standard Widget Toolkit (SWT).
Like AWT, SWT provides wrappers on top of native controls. The native controls are provided via the Java Native Interface (JNI), but SWT includes an API to write your own GUI components. Additionally, SWT provides a larger set of default controls than AWT does. All components that are not supported by an underlying OS are emulated in Java. Tables, for example, are supported by the Microsoft Windows platform, and SWT can depend on native components by using JNI. On an OS that doesn’t support tables, SWT will use a fallback and manage and render a table control completely in Java. With this functionality, developers can create an application with a native appearance and add controls or change the skin of controls to define a unique look for the app. Compared to Swing, SWT requires fewer system resources because most of the controls are managed by the OS and not by Java. Today, SWT is still the default UI toolkit of Eclipse and is also used in many projects that are based on the Eclipse rich client platform (RCP).
Apache Flex
In recent years, other languages have breathed new life into the field of UI toolkits. Apache Flex is an example of a toolkit developed in the last few years, and it was clearly designed for creating rich clients. It is based on Adobe Flex, which was passed to the Apache Foundation in 2012. Internally, Flex is based on Flash for rendering and offers its own programming language called ActionScript.
Flex offers some interesting techniques and concepts that have been sought after in Java UI toolkits. For example, with its MXML library, Flex provides an XML-based file format to define user interfaces and their layout. In these files, the structure of a view with all embedded controls and their attributes can be defined. Version 4 of Flex introduced Spark as a new architecture to skin and create controls in Flex. In Spark, all controls are split in two files: a skin file that is written in MXML and that defines the look of the component and an ActionScript class that defines the model and the controller. In addition, Flex provides support for effects and transformations.
The Way to JavaFX
As you can see, there are plenty of UI toolkits on the market, both based on Java and other languages. But no toolkit is perfect. Sometimes a cool feature is incompatible to the main architecture of a toolkit and can’t be added. Additionally, sometimes different UI toolkits have different philosophies. Some rely on native controls, while others have extended support for skinning. Another feature that has become more important over the years is the way the metadata of controls, such as the background or border and the layout of views, is described. Most modern toolkits remove this information from the source and add file types such as MXML in Flex or the XML layout in Android to define this information. Old Java-based UI toolkits like Swing can’t handle these needed features.
From F3 to JavaFX 8
The JavaFX story started with the F3 API developed by Chris Oliver at SeeBeyond. The company required a modern UI toolkit to create new desktop applications that looked superior to the competition, so Oliver started developing the F3 framework, and it was acquired by Sun Microsystems as part of the SeeBeyond acquisition during the API’s development. Oliver continued on at Sun to lead the development of F3, which was renamed and introduced as JavaFX at JavaOne in 2007. The first version of JavaFX was published one year later. However, version 1 of JavaFX (JavaFX Script) has very little to do with the current version; it was a script-based language for the Java platform that could interoperate with Java code.
After Oracle’s acquisition of Sun Microsystems, version 2 was announced that would be based completely on the Java API, which would allow any Java developer to use it with any IDE. By doing this, the barrier of entry to using JavaFX was reduced, and the competition for a great UI toolkit was leveled. JavaFX Script was also discontinued with this release. JavaFX supports a lot of effects, transformations, and animations, all of which will be covered in the following chapters.
What Kinds of Applications Can Be Built with JavaFX?
So, what kinds of applications can you build with JavaFX? As an initial answer, I would say every kind of application. For sure, some types of applications are a better match to a JavaFX-based technology stack than others, such as business applications that use databases or servers as the back end. All the needed components are part of the JDK and the JavaFX library, so you can create an application mostly the same way as you would have with Swing.
But JavaFX can do so much more. I have seen some 2D games that were created by using JavaFX with the great performance and features of the JavaFX scene graph API or the JavaFX canvas API. Additionally, JavaFX offers 3D support to create 3D landscapes. By adding embedded support to Java, JavaFX allows you to create the UI and user interaction for smart embedded devices. Using JavaFX in this way is as easy as developing a desktop application. You can even develop a media center because the API to play media files is part of JavaFX. As you can see, there is a lot of potential when using JavaFX as the UI toolkit to develop applications.
In reality, most of the applications that will be developed with JavaFX will be business applications, so this book will concentrate on the APIs and knowledge that you need to know to develop these kinds of applications. But even when developing data-centric applications, you can use the creative power of JavaFX. By using the JavaFX effects, animations, or multitouch input, you can create an application with an outstanding user experience.
JavaFX Compared to HTML5 and Web-Based Technologies
Today, a lot of applications that are created are web applications or rich Internet applications (RIAs), also called plain HTML apps, that run in a browser such as Firefox or Chrome. Most of these applications are written in HTML5, CSS, and JavaScript. Other technologies can also be used to create RIAs: Technologies such as Adobe Flash/Flex and Silverlight can be used to create applications that are running inside a browser with a browser plug-in.
These rich Internet applications could also be created with JavaFX. (Although you can integrate a JavaFX application as an applet in a web page, this workflow isn’t best practice anymore, as it will create some problems; therefore, it won’t be discussed in this book.) I discussed the non-HTML technologies earlier in the chapter, so now it’s time to take a deeper look at plain HTML RIAs and how they compare to applications created with JavaFX.
First, it’s hard to compare HTML with JavaFX because of some big differences: HTML runs inside a browser, and JavaFX applications are desktop applications running directly in the OS. Additionally, HTML is only a markup language, and you can’t define application logic with HTML. A developer needs to use a combination of HTML, JavaScript, and CSS to create an interactive application.
Here is the default structure of an HTML-based RIA: By using HTML, you define all components that appear on a web page and structure them. If you need application logic, you can use JavaScript to add the logic to your application. Additionally, in most applications, CSS is used to define special skins for the app and all components that are part of the application. This is a technology stack that is unusual for a desktop application; however, JavaFX provides a comparable set of technologies. Specifically, the layout of all views can be done by using FXML, which is an XML-based markup language for defining JavaFX views. For the skinning of an application, JavaFX supports CSS; it doesn’t use the same attributes that are used in HTML web applications, but the CSS syntax is the same. Instead of JavaScript, you can use Java to define the logic and interaction of a JavaFX application.
JavaFX offers all the benefits that a developer might know from HTML application development. For example, the structure of the views isn’t created in code; the markup language FXML is used to define the layout of all application dialogs. As a result, the layout of an application can be done by a designer who doesn’t need to understand Java code. Additionally, CSS is used to define custom skins of controls. By using CSS, it is easy to change the font of all buttons that are used in a JavaFX application, for example. There is another big benefit in JavaFX too: The APIs are ready for extensions. In HTML, you can’t use other tags than the defined ones, and CSS provides some default attributes and a set of additional ones that are browser-specific. With FXML, you can easily integrate any custom control, and you can define new CSS attributes with a Java API. As a result, you can easily add components to an application that are not part of the default framework.
HTML applications do have some advantages over JavaFX ones, however. HTML is always running in a browser, and a normal user doesn’t need to install anything to run web applications. By contrast, JavaFX applications mostly run on the desktop, and if they are not packaged as native applications, the user will need the Java runtime on the OS. And if a JavaFX application is running in a browser, the user will need the applet plug-in. JavaFX 8 fixes this issue by offering a tool that can package JavaFX applications as native ones and add the needed Java runtime to the package automatically. As a result, no additional software is needed on a client computer. Still, HTML applications are easier to administer because most users have a browser, but often cross-browser development is a necessity.
You could say that there is no final rule which of these two technologies should be used for application development. Both have benefits and are stronger in some areas. But JavaFX has learned a lot from HTML and has taken some of the best parts of it to offer a great infrastructure and ecosystem for application developers.
Java-Based Web Frameworks
In addition to creating plain HTML web applications, developers can use Java to develop web applications with frameworks such as JSF, Wicket, Play, or GWT. All these frameworks will create applications with views that are rendered as HTML views in a browser. Normally, the Java code is running on a server, and HTML views are created that will be sent to the client. In all these frameworks, Java can be used to define the application logic, and sometimes even the views can be created in Java. In the end, all the frameworks will create HTML and JavaScript. Because of this, it is often more complicated to create pixel-perfect applications with these frameworks. Comparing all these frameworks to JavaFX is beyond the scope of this book.
Summary
UI-related technology has become more important in the past few years because developers are creating more impressive UIs than ever before. JavaFX is the newest in a series of UI toolkits, and it supports all modern UI methods and patterns. Without a doubt, JavaFX will become the most important UI toolkit for Java applications in the next few years and will be used on various platforms. Therefore, it is important for every Java application developer to know and understand the core concepts of JavaFX. One of the most important parts of the framework is the controller API, a core focus of this book.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.