The UP.Link platform includes the following components:
Figure 2-1 summarizes a typical interaction between these components.
FIGURE 2-1. High-level view of UP.Link platform components
The following sections describe each component of the UP.Link platform.
An UP.Phone is a data-capable handheld device that runs the UP.Browser. The UP.Browser is a software module that enables the handheld device to interpret HDML and communicate with the UP.Link server. A variety of handheld devices can be UP.Link-enabled. For a list of models and capabilities, see the Unwired Planet Web pages at:
http://www.uplanet.com
Because the UP.Link platform supports a variety of device models, this manual uses the concept of an abstract UP.Phone, which has the minimal set of capabilities that most UP.Browser-enabled devices share. HDML syntax descriptions and examples in this manual refer to this abstract phone. The abstract phone is described in the HDML Language Reference.
Many examples in UP.SDK documentation include example phone displays similar to the one in Figure 2-2. These displays assume the abstract phone. The ACCEPT key label appears in the lower-left corner and the first softkey (SOFT1) label appears in the lower-right corner. The default label for the ACCEPT key is OK; the default label for the SOFT1 key is nothing. The PREV, SEND, and DELETE keys, and non-programmable keys (such as the arrow and the numeric keys) are not shown in the examples because their labels are not programmable; they appear on the keys themselves and not the phone display.
FIGURE 2-2. The ACCEPT and SOFT1 softkey labels
The UP.Browser behaves much like a conventional Web browser. Its interface (the text it displays and the input options it presents to the user) is controlled by the sets of commands it loads. For a Web browser, the presentation language is HTML; for the UP.Browser, it is HDML--a language optimized for the constraints of small handheld device displays and limited keypads. For a Web browser, the sets of commands are called Web pages, for an UP.Phone, they are called cards. The user navigates with the UP.Phone by pressing keys on the keypad. As the user navigates to different locations, the phone loads different cards, which change the display and the input options.
The HDML language provides a set of commands or statements that specify how an UP.Phone interacts with a user. HDML statements display information on a phone, provide input options for the user, and specify how the phone responds when the user presses keys. For example, an HDML statement can instruct an UP.Phone to display a prompt and allow the user to enter text.
The fundamental unit of HDML is a card, which specifies a single interaction between the phone and the user. HDML currently supports the following types of cards:
The smallest unit of HDML a service can send to a phone is a deck. A deck contains one or more cards. When a phone receives a deck, it goes to the first card in the deck. It displays the information the card provides and allows the user to respond to it. Depending on the card type, the user can respond by entering text or choosing an option, and then pressing a function key.
The following HDML statements define a simple HDML deck containing a single display card (see Figure 2-3):1
1
<HDML VERSION="3.0"> <DISPLAY> Hello Unwired World! </DISPLAY></HDML>
Line Step 1 is the deck header. VERSION is a deck option, specifying the HDML version number.
Lines Step 2-Step 4 define a display card. They instruct the phone to display the text: Hello Unwired World!
Line Step 5 is the deck footer. The phone treats everything between the deck header and the deck footer as a single HDML deck.
FIGURE 2-3. An HDML deck with a display card
The UP.Link server is the backbone of the UP.Link platform. The UP.Link server maintains a database of phone subscribers, which it uses to route UP.Phone requests to HDML services and the HDML services' responses back to phones. For an UP.Phone to work with an UP.Link server, it must be registered in the UP.Link's database.
HDML services are Web server applications that return HDML and other content in response to HTTP requests. An HDML service can consist of only static HDML decks. However, services that dynamically generate HDML can better take advantage of the small size and portability of UP.Phones. Therefore, HDML services are typically Common Gateway Interface (CGI) or Web server API applications. Some examples of HDML services are:
An HDML service can dynamically generate HDML in the same way conventional CGI scripts generate HTML--for example, by querying databases or other external data sources. You can easily develop an HDML service that generates (or "scrapes") HDML from existing HTML content on the Web.
You can implement an HDML service to support both "pull" transactions, in which the service responds to UP.Phone requests, and "push" transactions, in which the service asynchronously sends alerts and content to the UP.Phone.
