Create Desktop Applications with Java-Based Web Technologiesby Will Iverson, Mac OS X Conference speaker and author of Mac OS X for Java Geeks
So, you've mastered web application development, only to stumble into the decline and fall of web-based dot-com mania. To your chagrin, you've discovered that servers and bandwidth are a lot more expensive when you have to pay for them yourself instead of relying on your VC-funded IT department.
But you've still got the itch. You still want to build (and maybe even sell) great software. If you're a relatively new developer, it's likely that your skill set is focused on web technologies--things like HTTP and HTML, cookies, URLs, and forms. The next step, therefore, is to learn to create software that anyone can use (not just web server administrators). Instead of throwing out your skill set, why not learn to marry the concept of user-installable desktop applications with familiar web technologies? This union will provide opportunities to build a new class of applications--browser-based applications uniquely suited for this new age of browsers, wireless laptops, and 802.11-enabled PDAs. Some of the most interesting and innovative software out there is cropping up in this format.
Examples of Browser-Based Desktop Applications
Let's look at some examples of desktop applications where the primary interface is through a web browser:
Author conference session
A close look at how a Java-based web application can be converted to a desktop application for use on both Mac OS X and Windows systems. Particular emphasis will be paid toward understanding how to build complete packages that are easy for an end-user to install, plus solutions for technical and installation problems.
O'Reilly Mac OS X Conference
CUPS, the printing architecture of Mac OS X 10.2 (Jaguar)--from which comes the original printing user interface--is available right now for anyone using Jaguar. If you're running Jaguar, try it out.
Radio Userland, a web publishing tool, uses HTML as its primary user interface.
ZOË, a web application that runs in the background, grabbing and indexing all of your incoming and outgoing email, is one of the more innovative contenders. You do most of your work with your email client as normal, but you can also open up ZOË's web interface and plumb all of your email's associations.
You can download and install all of these applications onto your desktop computer, but you interact with them via your web browser. Variously, the tools above either expect to reside in a web server, bundle a server, or implement the server from scratch internally. Powerful, yes, but also exceedingly complicated.
This brings us to the heart of the problem we're addressing in this article: what does the (admittedly mythological) "typical user" want, and how can we create software for this user?
Developers or administrators working with a typical web application can be expected to perform the following tasks:
- Install (and configure) the web server
- Install (and configure) a database
- Install (and configure) your web application
Many technically savvy users can also perform these tasks, but it's way too much to ask for the typical user. Generally speaking, a typical user expects an experience like this:
- Run the installer
- Run the application
- Start playing around
I've named my efforts on this webtop project "Canteen." I've created an archive called canteen.zip, which has all of the source and various Tomcat libraries you'll need (approximate size: 3MB). You can also try out the resulting application and installer by visiting www.cascadetg.com/canteen/install.htm, and you can follow future improvements by visiting www.cascadetg.com/canteen.
In the remainder of this article, I will provide detailed, step-by-step instructions for building a simple, point-and-shoot installer for a basic web application using the Apache Jakarta Tomcat, a popular Java-based web application server (typically used for building JSP-based applications). Your users won't have to worry about virtual machines, web servers, or databases. I will use a combination of free tools and various Apache-license projects to build a user-installable version of this web application.
We'll be using the following materials to build this application and the installer:
The Tomcat binaries from the Apache Jakarta web site.
A bit of code from the SourceForge.net-hosted BrowserLauncher project, which will allow our application to easily launch the user's default web browser.
An example of embedded the Tomcat web server from another article on the OnJava web site by James Goodwill.
The ZeroG InstallAnywhere Now installer creator, the free version of the company's installation product.
As a blatant plug, I'll note that information on how to integrate Mac OS X Finder events into Java applications is provided in my book, Mac OS X for Java Geeks. You'll also find information there on how to "fix" the menu bar.
Easy to Use Is Hard to Build
Users expect an application to be easy to use. To create that experience takes a lot of work. When you have completed the steps in this article, however, a user will be able to go to a web site, run a simple installer, and have what feels like a native application installed. Running the application will be as easy as clicking on the application icon. Launching the application icon will automatically launch a browser pointing at the web application URL.
Traditional applications typically start with a
main() method, and Java is no different for standard desktop applications. On Mac OS X, additional interfaces are provided for handling different Finder events, such as a command to open a specific document, but in this instance we'll just be focusing on the cross-platform standard
main() entry point.
Web applications typically require a server to be installed first, and then they are dropped into the server (similar to how a plug-in works). The basic idea is that the web application is wrapped by the web container, which is managed by the system administrator. Tomcat, for example, provides some
command-line scripts for starting and stopping the server. In this case,
however, we need to provide a very simple graphical user interface with which the user
can start and stop the server, with our own
main() handling the start and stop of the web server.