Building Decks of Cards
Thus far, each WML file we have created has contained a single card. As I mentioned earlier (and as was explained in Chapter 2), WML files can contain multiple cards—these files are known as decks (as in a deck of cards).
Each card in a deck must be uniquely named (unique within that deck). Cards are named using the <card> tag's id attribute, and id values may contain text and numbers (but no special characters).
When a deck is loaded the browser processes and stores all the contained cards and then determines which card to display:
If a specific card id was requested and that id is present, that card is displayed.
If no card id is specified, or the requested id does not exist, the first card in the deck is displayed.
Listing 3.5 contains the code for a simple deck of three cards. A single pair of <wml> tags is present, and all three <card> tag sets are enclosed within it.
Listing 3.5 Displaying a Simple Deck
As you can see in Listing 3.5, each card is uniquely identified via the id attribute. So how do you actually specify the id of the card to be displayed? Here WAP again borrows syntax from HTML and uses the HTML bookmark character: the pound sign (#). If the following URL pointed to WML file
localhost/wap/deck1.wml
this URL would point to the card with the id of card2 within that deck:
localhost/wap/deck1.wml#card2
Figure 3.7 shows the card that would be displayed if no card id was specified, and Figure 3.8 shows the card that would be displayed if id was explicitly specified as card2.
Note
Within a deck, cards can be referred to simply as #id, so to refer to card2 in our example from within card1 or card3 you could simply refer to #card2.
Figure 3.7. By default, the first card in a deck is displayed.
Figure 3.8. Specific cards in a deck can be displayed by specifying that card's id.
Caution
Many device emulators cache requests that can cause older versions of pages to be displayed. If you experience this, you will need to clear the cache using the options provided by the emulator.
Why Use Decks
Decks of cards are extremely important in WAP application design. Consider the following example:
You provide a search screen that allows users to search for employees.
When a search is performed the results are listed with minimal information (perhaps just a name).
Each result can be selected for detailed information about the employee (including phone number and email address).
This is an example of the classic data drill-down user interface. Three types of cards being used here: the initial search card and two types of results cards, one for the list and one for the details.
Obviously, the search card must be sent to the device before the search can be performed. But after a search has yielded results, the user will likely drill down into multiple results to find the desired information.
A simple implementation (one that would work like an HTML implementation) would work as follows:
A results card is generated with the list of matches.
The user selects an entry from the list, and a request is sent back to the server for the desired information which is then displayed.
To view another entry the user goes back to the list (which will be cached on the device) and makes another selection, which in turn sends a request to the server for the desired information which is then displayed.
Step 3 is repeated as many times as needed, and each time a new request is sent to the server.
And while this is a workable solution, it is not an efficient one at all. Data is sent to devices in packets, and sending partially full packets takes as long as sending full packets. In other words, there is no real performance penalty for sending too much information (or information that is not needed yet in anticipation of it being needed).
So, a better way to handle the drill-down interface would be as follows:
A results deck is generated, the first card in the deck contains a list of matches, and an additional card is generated for every entry containing all the details for that entry.
To view another entry, the user goes back to the list (which will be cached on the device) and makes another selection, which in turn displays another card in the deck (again without needing a server request).
Step 3 is repeated as many times as needed, without ever needing another request to the server.
The advantage of this interface is that it allows you to anticipate and respond to your user's next requests. This results in a much faster and responsive application, and also eliminates unnecessary bandwidth use.
Tip
As will be explained later in this book, decks have maximum allowed sizes. But as long as the data being sent fits into the maximum size requirements, it takes just as long to send a deck of cards as it does to send a single card. As such, there is no downside to sending additional cards "just in case."
Digests
The UP.Link Server and browser (created by Phone.com>) support a mechanism for grouping multiple decks (or a single deck and other entities) into a single unit called a digest. Digests are designed to allow you to fully leverage the bandwidth and packet size used by the wireless network so as to make your applications more responsive. The reason this works is that every packet of data sent to the client has overhead, regardless of the size of the data being sent. As digests allow the transmission of multiple entities at once much of the overhead that would have been present for each entity can be eliminated.
As useful as digests are, they are not currently supported by any platform other than Phone.com's. For more information on digests see the Phone.com provided documentation.