Offline Capable (Internet Explorer) AJAX Client

Why Is There a Need for an Offline Capable Client?
How Is the Proposed Application Different than Standard Web Applications and other AJAX Applications? The evolution of web applications… In a Standard web application: Client Server Reads user input Posts data Receives and stores data Waits Renders HTML (possibly by use of XSLT) Displays HTML In other AJAX applications: Client Server Reads user input Asynchronously posts data Receives and stores data Displays HTML Renders HTML (possibly by use of XSLT) In the proposed AJAX applications: Client Server Reads user input then save data locally Asynchronously posts data, at the same time rendering HTML Receives and stores data Displays HTML What Elements Are Necessary for a Successful Offline AJAX Application? Browser-based display/rendering: The sample code uses cached XSLT and performs the XSLT transformation in the browser: Use a sophisticated data store. The sample code uses the IE “userData store” that is a persistent data store. It replaces the need for cookies. The ability to tell whether the browser is in online/offline mode. Intelligent loading: Document/stylesheet caching Image pre-loading if necessary The SAMPLE The following section describes an offline capable (IE) AJAX client that has all of the required elements highlighted above. The compiled sample is available online at: http://www.wcg-itx.com/article/order.aspx. All client/ server files are attached to this article. Sample Code: Overview The sample program allows a user to create orders and send them to a processing center. The user has a user interface with three screens: “Create Order,” “Add items,” and “Pending Orders.” The User Interface Client Server The “Create Order” screen allows the user to create an order.Note: Only one open order is allowed at a given time. This order is saved locally in the “userData” store. This store is persistent and is not wiped out if the browser is closed or the machine is re-started (see Technology). No Activity The “Add items” screen allows the user to: Add items to the open order. When finished adding items, the user may click “close.” The added items are added to the order XML that is saved locally in the “userData” store. When “close” is clicked, the client will attempt to post the order asynchronously to the server. An asynchronous post implies that the browser will not “lock.” Meanwhile, the user is free to create a new order. If an acknowledgement from the server is received, a pop-up message will appear. If no acknowledgement is received from the server, the order will be marked “pending.” Sends back an acknowledgement of received orders. Pending orders can be viewed from the “Pending Orders” screen. Displays the orders the server did not acknowledge at the time they were closed and sent to the server (because of disrupted connectivity). Sample Code: Offline Capability The browser offline mode is achieved by checking “Work Offline” under the “File” tab. When working offline: The client application knows that there is no connectivity. Thus, it won’t try to send out orders to the server and the no-connectivity-warning message will not appear. The cached screens will appear and the user will be able to process orders as usual. All closed orders will remain in the pending state. When connectivity is restored, the user may uncheck “Work Offline.” At the next screen switch, all orders listed on the pending orders screen will be sent to the server. (Try it.) Detailed below are the different scenarios possible: BM = Browser mode. on = online, off = offline. C = Connectivity. P = present, A = absent Scenario BM C The User Interface Client Server The user opens a new browser window and logs onto the system (types “http://www.wcg-itx.com/article/order.aspx” in the address bar or accesses a bookmark). on P User will see the “create order” screen The client hits the server once to download and display the user interface. Sends back HTML on A Error page off P User will see the “create order” screen Client uses cached files to display the user interface off A User will see the “create order” screen Client uses cached files to display the user interface The user switches between screens on P New screen will be displayed. Switching between the screens is done on the client side without hitting the server. If pending orders exist, client will attempt to post them to server. If client posted order, server will acknowledge receipt or orders on A New screen will be displayed. If pending order exists, a connectivity warning message will appear (suggesting that the user select “Work offline” from the browser file menu) Switching between the screens is done on the client side without hitting the server. If pending orders exist, client will attempt to post them to server but will fail. off P New screen will be displayed Switching between the screens is done on the client side without hitting the server off A New screen will be displayed Switching between the screens is done on the client side without hitting the server The user closes an order P Create order screen will be displayed Client will attempt to post the closed orders (and any pending ones) to server. Server will acknowledge receipt or orders on A Create order screen will be displayed. A connectivity warning message will appear (suggesting that the user select “Work offline” from the browser file menu) Client will attempt to post the closed orders (and any pending ones) to server, but will fail. Order will be set to pending. off P Create order screen will be displayed Order will be set to pending. off A Create order screen will be displayed Order will be set to pending.
What Elements Are Necessary for a Successful Offline AJAX Application?
The SAMPLE
Sample Code: Offline Capability

Why Is There a Need for an Offline Capable Client?

A Web application serving a large number of clients can suffer bandwidth and server performance bottlenecks. From a business perspective, it makes sense to single out the pages that hit the server the most, and bring the server requests from these pages to a minimum.

An offline AJAX client accomplishes exactly that; it all but eliminates server roundtrips so that a single server can handle many more clients. In addition, an offline AJAX client improves reliability by allowing the client to continue using the application even if the server or the Internet connection is disrupted. Moreover, an offline AJAX client supports untethered users, allowing users who are on-the-go to continue working while away from an internet connection.

Ultimately, by addressing these issues, you can eliminate the two most prevalent problems with Web applications from a user’s perspective: speed and reliability.

How Is the Proposed Application Different than Standard Web Applications and other AJAX Applications?

The evolution of web applications…

In a Standard web application:

Client	Server
Reads user input
Posts data	Receives and stores data
Waits	Renders HTML (possibly by use of XSLT)
Displays HTML

In other AJAX applications:

Client	Server
Reads user input
Asynchronously posts data	Receives and stores data
Displays HTML	Renders HTML (possibly by use of XSLT)

In the proposed AJAX applications:

Client	Server
Reads user input then save data locally
Asynchronously posts data, at the same time rendering HTML	Receives and stores data
Displays HTML

What Elements Are Necessary for a Successful Offline AJAX Application?

Browser-based display/rendering:

The sample code uses cached XSLT and performs the XSLT transformation in the browser:

Use a sophisticated data store.

The sample code uses the IE “userData store” that is a persistent data store. It replaces the need for cookies.

The ability to tell whether the browser is in online/offline mode.
Intelligent loading:

Document/stylesheet caching
Image pre-loading if necessary

The SAMPLE

The following section describes an offline capable (IE) AJAX client that has all of the required elements highlighted above. The compiled sample is available online at: http://www.wcg-itx.com/article/order.aspx. All client/ server files are attached to this article.

Sample Code: Overview

The sample program allows a user to create orders and send them to a processing center. The user has a user interface with three screens: “Create Order,” “Add items,” and “Pending Orders.”

The User Interface	Client	Server
The “Create Order” screen allows the user to create an order. Note: Only one open order is allowed at a given time.	This order is saved locally in the “userData” store. This store is persistent and is not wiped out if the browser is closed or the machine is re-started (see Technology).	No Activity
The “Add items” screen allows the user to: Add items to the open order. When finished adding items, the user may click “close.”	The added items are added to the order XML that is saved locally in the “userData” store. When “close” is clicked, the client will attempt to post the order asynchronously to the server. An asynchronous post implies that the browser will not “lock.” Meanwhile, the user is free to create a new order. If an acknowledgement from the server is received, a pop-up message will appear. If no acknowledgement is received from the server, the order will be marked “pending.”	Sends back an acknowledgement of received orders.
Pending orders can be viewed from the “Pending Orders” screen.	Displays the orders the server did not acknowledge at the time they were closed and sent to the server (because of disrupted connectivity).

The User Interface

Client

Server

The “Create Order” screen allows the user to create an order.
Note: Only one open order is allowed at a given time.

This order is saved locally in the “userData” store. This store is persistent and is not wiped out if the browser is closed or the machine is re-started (see Technology).

No Activity

The “Add items” screen allows the user to:

Add items to the open order.
When finished adding items, the user may click “close.”

The added items are added to the order XML that is saved locally in the “userData” store.

When “close” is clicked, the client will attempt to post the order asynchronously to the server.

An asynchronous post implies that the browser will not “lock.” Meanwhile, the user is free to create a new order.

If an acknowledgement from the server is received, a pop-up message will appear. If no acknowledgement is received from the server, the order will be marked “pending.”

Sends back an acknowledgement of received orders.

Pending orders can be viewed from the “Pending Orders” screen.

Displays the orders the server did not acknowledge at the time they were closed and sent to the server (because of disrupted connectivity).

Sample Code: Offline Capability

The browser offline mode is achieved by checking “Work Offline” under the “File” tab. When working offline:

The client application knows that there is no connectivity. Thus, it won’t try to send out orders to the server and the no-connectivity-warning message will not appear.
The cached screens will appear and the user will be able to process orders as usual. All closed orders will remain in the pending state.
When connectivity is restored, the user may uncheck “Work Offline.” At the next screen switch, all orders listed on the pending orders screen will be sent to the server. (Try it.)

Detailed below are the different scenarios possible:

BM = Browser mode. on = online, off = offline.

C = Connectivity. P = present, A = absent

Scenario	BM	C	The User Interface	Client	Server
The user opens a new browser window and logs onto the system (types “http://www.wcg-itx.com/article/order.aspx” in the address bar or accesses a bookmark).	on	P	User will see the “create order” screen	The client hits the server once to download and display the user interface.	Sends back HTML
	on	A	Error page
	off	P	User will see the “create order” screen	Client uses cached files to display the user interface
	off	A	User will see the “create order” screen	Client uses cached files to display the user interface
The user switches between screens	on	P	New screen will be displayed.	Switching between the screens is done on the client side without hitting the server. If pending orders exist, client will attempt to post them to server.	If client posted order, server will acknowledge receipt or orders
	on	A	New screen will be displayed. If pending order exists, a connectivity warning message will appear (suggesting that the user select “Work offline” from the browser file menu)	Switching between the screens is done on the client side without hitting the server. If pending orders exist, client will attempt to post them to server but will fail.
	off	P	New screen will be displayed	Switching between the screens is done on the client side without hitting the server
	off	A	New screen will be displayed	Switching between the screens is done on the client side without hitting the server
The user closes an order		P	Create order screen will be displayed	Client will attempt to post the closed orders (and any pending ones) to server.	Server will acknowledge receipt or orders
	on	A	Create order screen will be displayed. A connectivity warning message will appear (suggesting that the user select “Work offline” from the browser file menu)	Client will attempt to post the closed orders (and any pending ones) to server, but will fail. Order will be set to pending.
	off	P	Create order screen will be displayed	Order will be set to pending.
	off	A	Create order screen will be displayed	Order will be set to pending.