Periodic Refreshing for the Browser-Server Dialogue
The first part of this series of articles dealing with browser-server information flow discussed call tracking. This one covers periodic refreshing. The second of a multi-part series, this article is excerpted from chapter 10 of the book Ajax Design Patterns, written by Michael Mahemoff (O'Reilly, 2006; ISBN: 0596101805).
Periodic Refreshing for the Browser-Server Dialogue - Real-World Examples of Periodic Refresh (Page 3 of 4 )
Lace Chat
Instant messaging (or "online chat") applications pre-date the Web, and, unlike email and other services, web interfaces have never quite worked out, partly due to the fact that people don't enjoy frequent full-page refreshes. Ajax makes it possible to avoid a complete refresh by pulling down messages with an XMLHttpRequest Call (Chapter 6). Only the new messages need to be sent in each periodic response. In fact, there are several applications under development. Lace Chat (http://socket7.net/lace/), for example, is only a proof-of-concept, but provides good evidence that web-based chat is feasible. Every few seconds the messages update to show any new messages other users may have entered. When you post a message, it's also handled as an XMLHttpRequest Call.
Magnetic Poetry
Like a wiki, Magnetic Poetry (http://www.broken-notebook.com/magnetic/) involves a shared workspace (Figure 10-3). In this case, users move tiles through the space, and the application updates once a second to reflect the new space. As of version 1.7, the entire tile set is sent each time, but there's the potential to compress the information by sending only recent tile positions. This enables two users to work on the area simultaneously, and one can even see a tile being dragged by a different user, like a low-frequency animation.
Figure 1-3.Magnetic Poetry
Claude Hussenet's portal
Portals, by definition, display various kinds of information. And often that information is of a dynamic nature, requiring periodic updates. Claude Hussenet's portal (http://www.claudehussenet.com/portal/Welcome.do) contains several portlets:
World news headlines (taken from Moreover--see http://moreover.com--and Yahoo! News--see http://news.yahoo.com). The server appears to generate these from an RSS feed.
New online articles appearing on TheServerSide.com and DevX.com. Again, these are taken from RSS feeds.
Customized stock portal. The server appears to maintain a record of all current stock prices and is capable of delivering those requested by the browser.
In each case, the information is volatile and needs to be periodically updated, as is typical for many portlets. Also characteristic of portal applications is the relatively long refresh period, 15 minutes in this case. Each portlet contains a manual refresh too, for immediate results.
Code Examples
Lace
Lace Chat (http://socket7.net/lace/) handles Periodic Refreshes to show all users' chat messages.
The timer is set on startup to periodically call the get() function, which initiates the XMLHttpRequest Call (Chapter 6) for new messages:
var thisObj = this; this.httpGetObj.onreadystatechange = function () { thisObj.handleGet(system); }; this.httpGetObj.send(param);
If the server has changed at all, the entire contents are returned. How does Lace know if the server has changed? Each time the server responds, it generates a hash for the contents. And when the browser next calls for a refresh, it includes the last hash as a parameter to the call. The server sends a full response only if the current hash differs from that specified by the browser:
[lib_lace.php] function getMessageHash() { ... return md5(implode(file(LACE_FILE))); }
[lace.php] $_hash = getMessageHash(); if ($_hash == $hash) exit; // no change exit($_hash. '||||'.getFileContentsRaw());
Code Refactoring: AjaxPatterns Periodic Time
The Basic Time Demo (http://ajaxify.com/run/time) requires the user to manually update the time display by clicking a button. We'll perform a quick refactoring to re-fetch the time from the server every five seconds (http://ajaxify.com/run/time/periodicRefresh).
First, we'll create the function that initiates the server calls. Here, we already have two functions like that, one for each display. So, let's ensure we call both of those periodically:
function requestBothTimes() { requestDefaultTime(); requestCustomTime(); }
Then, the Periodic Refresh is simply a matter of running the request every five seconds:
function onLoad() { ... setInterval(requestBothTimes, 5000); ... }
One more nicety: the function in setTimeout begins to run only after the initial delay period. So we're left with empty time displays for five seconds. To rectify that, requestBothTimes is also called on startup:
function onLoad() { ... requestBothTimes(); setInterval(requestBothTimes, 5000); ... }
Now, the user sees the time almost as soon as the page is loaded.