Selecting a Platform

You might think at the outset that only desktop users need the Google Web Services application you create. In some cases, you might be right. Other kinds of users might not have a need to access your application in any way because the Google search engine is freely accessible online. However, it's surprising how many applications are seeing use on alternative platforms that many people would have considered impossible even a year or two ago. The problem for developers is seeing past preconceived ideas of how users will employ an application and deciding which platforms the user could use. Once you make that determination, you have to go further and decide which platforms you want to support. The economic benefit of supporting a platform must outweigh the cost of implementing it.

The following sections discuss several platform design options. You'll find recommendations on ways to optimize your platform design decisions. These sections also contain a few surprises ”things you might not have considered important. For example, the first section answers the question of whether you always need to implement a desktop application solution.

Writing Desktop Applications

Desktop applications can serve a variety of needs. You can use a desktop application for everything from a corporate library reference that incorporates information from Google Web Services to a special search engine for your Web site. If you think that no one searches the Web using a desktop application, consider the help files that Microsoft supplies with their applications. Each of these help files appears to be a desktop application, but they have an Internet connection for updates and new information.

One important consideration when using Google Web Services is that you can only search for public data. The public nature of the search engine isn't much of a problem when working with a browser-based application. However, it quickly becomes a problem when you want to create a combined local and remote search engine for your business. It's all too easy to forget that as good as Google is, you can't access any private links.

Tip  

One of the most important additions you can make to your applications (both desktop and Web based) is a survey form. The survey should ask users questions about the usability and information content of your site. In addition, you need to know what type of device the responder used to access your site, as well as the devices the responder would like to use to access your site. The "Adding Feedback to Your Application" section of Chapter 11 discusses this issue in greater detail.

The following sections describe three kinds of desktop applications. Obviously, you can write myriad application types for a desktop machine, but these three types work well with Google Web Services. Each application type has something special to offer in the way of flexibility, usability, performance, or compatibility. It's important to weigh your choices carefully , because even desktop machines aren't a one size fits all environment.

Using Standard Applications

Many users are unaware of the communication that goes on behind the scenes with many desktop applications today. The application could rely on standard desktop application controls ”the same controls that developers have always used for this kind of application. Most of the examples in Chapters 5 and 6 fall into the standard application category. (Chapter 6 does contain Web server examples that don't fall into this category.) This application doesn't look like it has any type of connectivity to the outside world, but it does use an Internet connection to retrieve data from Google Web Services.

Use standard desktop applications for corporate needs. In many cases, it isn't important that the user know the source of the information used to perform a task; they simply need to know that the information exists. This kind of application could pull data in from a number of sources in a way that helps the user perform a task quickly and with less frustration than using a number of independent applications to perform the same task. Data source hiding is an important development principle to keep in mind. Hiding the source of the data means you don't have to retrain users every time the source of the data changes.

Using Web-enabled Applications

Some developers use the term Web-enabled to mean any browser application that sits on the desktop. However, this description doesn't really fit today's application development products. You can easily create an application that looks like a standard desktop application, but uses a browser interface by adding one of many HTML controls to the application. The example in the "Choosing between Current and Cached Data" section of Chapter 10 falls into this category. It doesn't matter whether you use a high-end product such as Visual Studio or an Office product such as Word ”the interface still looks like a standard application, but the presentation is all HTML. Microsoft actually uses this technique for most help setups in their applications today.

This kind of application can work well when you need to combine local and remote sources. For example, a research firm likely has myriad papers and other local resources generated by the company. However, when a search for a particular piece of information from a local source isn't satisfied, the search application could automatically switch to Google Web Services.

A side benefit of this approach is that you can combine sources into one page. A research firm employee might see a single page that has a list of all resources for a particular topic. The resources could include mixed local and remote sources. The employee doesn't care, as long as the search results in valid information to use as the basis for new research. The page could include mixed data types as well. For example, a link might include an associated picture so the employee could see a representation of the kind of data the source includes.

Using Browser Applications

A browser application can reside on a desktop or anywhere else for that matter. The user clicks on a link that opens Internet Explorer and takes them to the location of the application. The application could reside on a local intranet or on the Internet. A desktop browser application is usually simple compared to other kinds of browser applications. At most, the application needs to determine what type of browser the user has so that it can account for any compatibility issues.

Tip  

Part of the answer for solving browser compatibility issues is to ensure you follow World Wide Web Consortium (W3C) guidelines and validate the resulting pages. However, validation doesn't replace good testing techniques using multiple browsers. You can find an archive of most common browsers (and many uncommon browsers) on the evolt.org site at http://browsers.evolt.org.

It's important to consider browser compatibility because you don't know which of the many browsers available a user will choose. However, getting the vendors to tell you the facts is nearly impossible. You can find various charts that show browser compatibility issues online. One of the better charts is the Webmonkey Browser Chart at http://hotwired.lycos.com/webmonkey/reference/browser_chart/index.html. The advantage of using this chart is that the owner updates it regularly to reflect new browsers. Figure 4.3 shows a typical example of this chart.

Figure 4.3: Always check the assumptions you make about browser compatibility against a reliable chart.

As you can see, the Webmonkey Browser Chart presents a wealth of information about the features that each browser supports. Note that this chart only supports Windows browsers ”Webmonkey also provides charts for the Macintosh (http://hotwired.lycos.com/webmonkey/reference/browser_chart/index_mac.html), Unix/Linux (http://hotwired.lycos.com/webmonkey/reference/browser_chart/index_nix.html), and other platforms (http://hotwired.lycos.com/webmonkey/reference/browser_chart/index_other.html). Make sure you consider Webmonkey's other offerings, such as a chart that shows how to create special characters and a JavaScript reference library.

Use browser applications when you think you might need to connect to other platforms. For example, using a browser application makes it much easier to move the application to the Pocket PC or even a cellular telephone. Browser applications do tend to face a variety of compatibility problems, and they're not very fast when compared to other application types, but they're the flexibility option of choice.

Writing Small Form Factor Applications

Many users now carry some type of small form factor device such as a Personal Digital Assistant (PDA). The PDA is the most popular form, but you could consider some types of notebook computers in this category too. The small form factor device is very portable, generally sees use on the road, and has limits in processing power, memory, and local storage. Notebooks and PDAs don't suffer quite the limitations of a cellular telephone, but you may still find it difficult to write a program that fits on most of these devices and delivers everything needed.

The following sections discuss two kinds of small form factor application: desktop and browser. The Pocket PC is one of the easiest and most powerful PDAs to program, so the first section discusses how you can create desktop applications for this platform. Most people use a Web application of some type for less capable devices, such as the Palm, because local storage and the difficulty of writing an application for these platforms becomes a factor.

Tip  

Google also provides a wireless service that you can use directly. The only problem is that the wireless service is hidden several layers down in the Web site hierarchy. Learn more about this service at http://www.google.com/options/wireless.html. It's important to note that this wireless service specifically excludes the Pocket PC. It does include instructions and support for many cellular telephones, the Palm, and the Handspring.

Using Pocket PC Applications

The Pocket PC provides a number of great programming options. For example, you can write directly to Windows CE or use the .NET Compact Framework. Developing a Pocket PC ”specific application has many of the same advantages of creating standard desktop application. (See the " Using Standard Applications" section for details.) One of the biggest benefits of the Pocket PC application is that you don't need a Web server to host it in most cases.

Tip  

It's possible to write a local application with a Web basis for the Pocket PC. For example, you can use products such as PocketSOAP (http://www.pocketsoap.com/) to write an application that relies on JavaScript to make a SOAP request locally. The PDA uses a Web interface, but it doesn't rely on contact with a server to make the request ”everything occurs locally. One of the benefits of using PocketSOAP is that the vendor also makes a compatible product for desktop machines so you can use the same code base for both platforms.

Currently, many businesses favor the programmability the Pocket PC provides for applications such as remote research or product lookups (such as in order fulfillment). The user has a need for a mobile device, a laptop or notebook won't work, and the user can carry a Pocket PC in a holster. The idea is to help the user locate information as the need arises, rather than force the user to go to a special area to perform the research.

Using Generic PDA Applications

All PDAs can use a Web interface, including the Palm and Pocket PC. When you create a generic PDA application, you normally need to host it on a Web server because you can't assume anything about the processing power of the client. A host can detect the type of mobile device and provide output for that device in the form of a Web page.

From a design perspective, you need to consider the devices you want to support at the outset of the project. Everything from screen design to coding technique must consider the devices you expect to use the application. In fact, you normally need to provide settings within the application that instruct the server how to react to specific devices. A Palm might require three pages to display a Web site, while a Pocket PC can display the same information in two pages. The information is the same, but the form factor of the device is different.

One of the biggest advantages of using this approach is that you can support any device. Many users find the advanced features of the Pocket PC less than useful and the larger size of the device annoying. An office manager doesn't want to carry a Pocket PC around in a holster all day. A Palm that fits in a pocket is much better because it stays out of the way until needed.

Writing Cellular Telephone Applications

Cellular telephones are here to stay. Some people try to use them for every communication need. As cellular telephones increase in capability, it becomes easier to write Web-based applications that really do make a difference. Imagine that you're in a meeting and the boss tells you to locate information about a new technology as the result of a conversation. With the proper Google Web Services application, you could locate the information immediately and present it while the meeting is still in progress.

Although cellular telephones are extremely convenient , they also have severe limitations. You don't want to try to build an industrial strength application with one because they simply don't have the processing speed, memory capacity, or communication speed to support such an application. In short, for development purposes, consider the cellular telephone as an option for shopping list, search, or other light applications.

Writing Mixed Environment Applications

It's important to consider the fact that you might not be able to support just one device and make your Google Web Services application work. Sometimes you need to support two or even three platforms to ensure that everyone who wants to work with the application can do so. You might think that this means writing separate applications for each device, but that's not necessary anymore as long as you consider the requirements of each device before you begin writing code.

Mixed environment applications commonly work on more than one device or environment (and sometimes both). In the past, you wrote mixed environment applications using Web programming techniques because the various platforms didn't offer much in the way of commonality . For example, you can write an ASP application that detects the device type (desktop browser version, PDA model, or cellular telephone model) and outputs a page specifically tailored for that device. The essential code doesn't change and you use a single code base for every device. Only the interface changes to meet the needs of a particular device.

Today, it isn't necessary to write your application as a Web application. For example, you can use Visual Studio .NET to write an application that works on a PDA or a desktop machine. Your code base remains the same, and you need to compile the application for each kind of device. In addition, you must work within the confines of the .NET Compact Framework, rather than assume the full resources of the .NET Framework are available.

The ability to write applications that work on more than one platform or in more than one environment is so compelling that other vendors will follow suit. Eventually, you might be able to write an application that works equally well on any device without much thought. Unfortunately, although the development environment is better today, it's still not perfect ”the goal of writing mixed environment applications that truly work everywhere with little effort on the developer's part is a long way off.