Understanding Mobile Device Limitations

Every device has limitations that you must consider. Whether those limits become a burden depends on what you plan to do with the device. The technique you use to perform a task is also a factor. Modern PCs have few limitations because vendors have increased their capabilities over the years . However, early PCs were so limited that developers worried about every byte of data. Mobile devices today are almost in the same position as early PCs ” vendors simply haven't created ways to overcome problems with these small devices yet. Some of these problems might never go away because they have more to do with the limits of the humans using the device than the device itself. For example, you can place entire books on the head of a pin, but who can read them? Likewise, make the display of a mobile device too small and you encounter usage problems. The following sections discuss mobile device limitations of all types as they relate to Google Web Services.

Special Add-ons

Most vendors design PDAs as electronic versions of the calendar, address book, and personal note taker. Early versions of these products didn't include the mini “word processors and spreadsheets you'll find in modern versions. In fact, you can extend many PDAs to double as cameras , scanners , and other devices now with special add-ons. Other mobile devices, such as cellular telephones, have followed suit, but to a lesser degree.

The PDA isn't exactly a standard device to begin with. There are many hardware implementations , more than a few operating systems, and even different capabilities to consider. When users start adding features to their PDA, you may find that it's nearly impossible to determine what features you can rely on finding. In short, when you create a Google Web Services application for your company, try to standardize the device configuration. On the other hand, when you create an application that users outside the company can access, you need to provide a list of specific device requirements to reduce the potential for compatibility problems.

Generally speaking, you don't need special add-on devices to work with Google. You can normally type the information you need into the device, select a search, and receive the results you need. However, add-on devices can work to your advantage in a number of situations. For example, you could scan words into the search form instead of typing them. Given the limited typing potential of most of these devices, you'll find scanning comes in quite handy.

Theoretically, you could also use add-on devices to extend the range of your application. The "Using Google Web Services and Amazon Web Services Together" section of Chapter 11 describes techniques for combining these two Web services. You might not think you could perform this task using a mobile device, but it's relatively easy to do with careful programming. With a combined application, you could scan a UPC, ask Amazon to tell you more about the product (and perhaps provide a price comparison), and then use the information Amazon provides to extend the search using Google. Such a mobile application could help you make good buying decisions while standing in the store holding your PDA.

Networking

Distributed application development relies on a connection between the client and the server. Because most mobile devices have limited processing capability, distributed applications are especially important in this situation. It's easy to create a connection when you're working with a desktop machine. If you can't create a direct connection using a LAN, there are always alternatives such as using dial-up support. However, networking with a mobile device can prove problematic .

The networking problems fall into three categories that can affect your Google Web Services session. The first problem is the limited networking potential of devices such as cellular telephones. These devices have good connectivity, but you'll find it difficult to run custom Web applications using them because it's tough to add any form of security. You can't reliably determine the identity of the caller, secure the application, or ensure the integrity of the connection. Consequently, cellular telephones are good for downloading noncritical information or performing nonsecure queries.

Newer PDAs have much better processing capability than any cellular telephone and include good connectivity through a wireless connection. It's possible to provide a reliable identity check with higher end systems such as the Pocket PC. In addition, you can provide some level of application security. Unfortunately, you still can't secure the communication path between server and Pocket PC easily, so critical data could become compromised. You can perform most Google Web Services tasks , but might not want to perform online ordering because there's a possibility that someone could intercept the credit card numbers and identifying information.

Warning  

Lest you think that hacking of the sort mentioned in this section falls into the urban legend category, hacking does happen regularly at the various Internet cafes such as Starbucks and McDonalds. In fact, hackers have standard tools to perform the task. Find out more in the Computerworld article at http://www.computerworld.com/mobiletopics/mobile/story/0,10801,87523,00.html?f=x68.

Older PDAs are far less capable than the newer products on the market. In some cases, you might not even have good networking capability. Some of these older models rely on an internal modem for communication. A few models I've see use an add-in card to provide a wired connection to the network. Although the wired connections of some older models are inconvenient for the user, they actually make it possible to create a very secure connection. A physical connection lets you secure the wire, the application, and provide full user credentials, but at the cost of user productivity. In general, you won't ever need to use one of these solutions with Google Web Services.

Operating System

The operating system you use for a mobile device affects the device functionality and your ability to interact with Google Web Services. Generally, you don't have a choice of operating system when it comes to your cellular telephone. Even the Smartphone comes with a single operating system choice and that operating system really isn't capable of providing more than Web application access. (You can create certain classes of local applications using Visual Studio .NET with the Smartphone, and we'll explore the Google Web Services perspective in this chapter.)

PDA users do have some choices to make, especially if you have a Pocket PC device at your disposal. Early versions of the Pocket PC used Windows CE. However, you can now find devices that come loaded with compact versions of Windows 2000 or Windows XP. No, you can't create a full desktop application for these devices, but the newer the operating system and the greater the device functionality, the better your chances are of creating an application that can perform most (perhaps all) tasks locally. Even Windows CE users can rely on local applications that use SOAP to communicate with Google Web Services using JavaScript (one of the options considered in this chapter).

Tip  

Make sure you keep up-to-date with mobile device technologies by checking vendor sites often. For example, you can learn about updated capabilities for the Pocket PC and Smart-phone devices by visiting Microsoft's site at http://www.microsoft.com/windowsmobile/default.mspx. Visit the Web site for your particular cellular telephone vendor to obtain cellular telephone updates. Finally, make sure you visit the Palm site at http://www.palm.com/home.html.

Early versions of the Palm are extremely limited and any hopes you have of creating a local application are dim (unless you want to do the equivalent of assembly language programming). These early versions require that you use a Web application to communicate with Google Web Services. Newer versions of the Palm offer greater functionality, and you'll probably find a strong third party market for development tools as these versions gain support. In the meantime, you can use the developer resources provided directly by Palm at http://www.palmone.com/us/developers/ or rely on Web applications to access Google Web Services.

Screen Size

Many users have 17-inch or 19-inch monitors capable of a minimum of 1280 — 1024 resolution today. Developers have taken advantage of the screen real estate to create better applications that display more data at one time. Even Microsoft uses higher resolutions as a baseline for applications ”many of their application screens won't fit on an 800 — 600 display anymore.

Everything you want to do with your PDA has to fit within a small screen space (320 — 200 pixels if you're using a Pocket PC model like the Casio Cassiopeia). That's a lot smaller than the typical computer screen. Developers working on cellular telephone applications have even less screen real estate ”some models display just a few lines of information. In addition, some PDAs and most cellular telephones use black and white displays in place of color , so you can't even use the modern tricks to make the display look nicer. In short, mobile device screens tend to look a bit plain, and developers normally find themselves feverishly cutting their application screens down to size. However, with careful data sizing and information layout, you can create a perfectly acceptable display for Google Web Services requests and responses. The examples in this chapter demonstrate techniques for each device type.

Make sure you consider eXtensible Hypertext Markup Language (XHTML) for complex applications with many elements (http://www.w3.org/TR/xhtml1/). It helps you to display your application in segments with relative ease.

Other display options include using the Handheld Device Markup Language (HDML) (http://www.w3.org/TR/NOTE-Submission-HDML-spec.html) or Wireless Markup Language (WML) (http://www.oasis- open .org/cover/wap-wml.html). Both of these technologies use the concept of cards and decks to break up information into easily managed pieces. Of course, the mobile device you use has to provide support for these standards (most do) before you can use the tags within a document. Unfortunately, using any of these solutions normally prevents your Web application from appearing properly on a desktop machine.

Color

Developers have gotten used to seeing colors on their applications. Color dresses up a drab display and makes the application more fun to use. In addition, using color presents cues to the user. For example, many users associate green with a good condition and red with something bad. In short, most applications rely heavily on color today and with good reason.

Depending on the mobile device you use, you may not have any color at all. For example, many Palm models present the world in shades of gray. Many cellular telephones also represent all data using either black or white and don't even provide for shades of gray. (The newer picture cellular telephones are an exception to the rule and you might consider creating special software to accommodate them.) Even if a mobile device does provide color support akin to the Pocket PC, the developer still has to use color carefully .

The problem for mobile device users is that the screen is already small. If a user gets into an area with bright sunlight, seeing the screen might become impossible, especially if the screen contains colors that don't work well in such an environment. Fortunately, Google uses very little color and its Web page is somewhat plain ”making its Web site useful for some mobile device applications. Even so, your application can provide extended functionality, choice of color support, and better device support.

Using color to display icons or to convey a message is still a good idea, even in the world of the mobile device. For example, a red icon could signal danger or tell the user to wait without using up screen real estate for words. Of course, you need to explain the meaning of the color changes within a manual or help file (preferably both). Make sure the users of your application actually have a device capable of displaying color before you use color to signify anything in the application (some devices display only shades of gray). In addition, you must exercise care in using color because colorblind users might not be able to interpret the application correctly.

User Interface

Cellular telephone users commonly have just a keypad as an interface device. In some cases, the vendor will also supply some control keys, including an arrow keypad, but that's about it. If you want to create a Google Web Services application for a cellular telephone, you need to consider these limitations.

Most PDA users rely on a pointer to do all of their work. Sure, a few PDAs do offer a keyboard and mouse as separate items, but most of these offerings are bulky and difficult to use. Pointer use is one of the reasons that you want to keep your application on one screen, or use multiple screens when necessary. Scrolling on a PDA screen is less than intuitive and requires some level of skill to master.

No matter what type of mobile device development you do, be sure to include some pointer friendly features. For example, try to make as many tasks use a single pointer option or numeric keypad input as possible. The user should be able to point to what they want and allow the mobile device to complete the input for them.

Pointer friendly programs also make tasks yes or no propositions . Again, this allows the user to accomplish the task with a single click, rather than writing something down. The point is to make the PDA as efficient as possible so the user doesn't get frustrated trying to do something easy.