Like conventional Web browsers, the UP.Phone has a memory cache. It caches decks that the user has visited most recently, so it can quickly redisplay a deck without requesting it again from the UP.Link server. When the cache reaches the phone's memory limitations, the phone drops the oldest decks from it.
When the user navigates to a deck that is cached, the phone determines whether to retrieve the deck from its cache or to request it again from the UP.Link server. It does this by comparing the cache time specified in the deck's HDML to the time elapsed since it last requested the deck. If the elapsed time is greater than the specified cache time, the phone automatically requests the deck again. Otherwise, it just displays the cached deck.
You can set the cache time for a deck by setting the TTL option in its <HDML> statement. The TTL option specifies the time to cache the deck in seconds. If a deck is particularly time sensitive, set the cache time to 0 so that the phone requests the deck every time the user traverses it. If you don't set the TTL option for a deck, the phone uses the default cache time, 30 days.
To make sure a phone removes a deck from its cache and reloads it from the UP.Link server, you must use explicit cache operations. For more information, see Modifying UP.Phone caching.
If you know which URLs a phone is likely to request next, you can significantly improve performance by using the REL=NEXT option in <ACTION>, <A>, and <CE> statements. The REL=NEXT option instructs the UP.Phone to load a URL into cache while the user is viewing the current card. If the user subsequently requests the URL, the UP.Phone retrieves it directly from cache instead of requesting it from the Web server. The result is that the user experiences a much smaller delay when traversing from one URL to another. If you specify the REL=NEXT option for several actions on a card, the UP.Phone retrieves the URLs in the order in which they appear in the card definition. This process of preloading a URL is called a phone-originated prefetch and should not be confused with the service-originated prefetches described in Chapter 5.
The UP.Simulator emulates the caching behavior of real UP.Phones, which makes it useful for tuning your application's cache usage. There are two ways you can get information about the operation of the UP.Simulator cache:
As you navigate from URL to URL, the UP.Simulator displays messages in the Phone Information window indicating whether the URLs are retrieved from its cache or from the UP.Link server. For example, the UP.Simulator might print the following:
The first line indicates that the UP.Simulator retrieved the specified URL from the cache; the second line indicates that the UP.Simulator retrieved the URL from the UP.Link server. To get more detailed information on the contents of the UP.Simulator cache, use the Info>Cache command. For a complete description of the output from this command, see the UP.SDK Tools and APIs Reference.