Detect network-state changes in a mobilized software application, and adapt appropriately. Remaining productive outside the office is a challenge. Recent platform advances meet many of these challenges head-on. Batteries last longer, new form factors are lighter and easier to carry, and integrated wireless network cards allow connection at any of the 20,000+ available U.S hotspots. Being able to connect practically anywhere raises new questions, however:

• Why are we doing the connecting? Five minutes spent manually releasing and renewing an IP address equates to five minutes of lost productivity.

• Why do most applications assume constant and infinite bandwidth? Applications that monitor bandwidth flux and adjust their behavior accordingly provide an improved user experience and increase productivity.

The necessity of considering whether or not one has a network connection in order to complete a given task negatively impacts productivity, and increasingly complex environments increase that impact. In the future, the number of networks available to mobile notebooks will grow, from two (wired Ethernet and Wi-Fi) to many (wired Ethernet, Wi-Fi, cellular, WiMax, UWB, Bluetooth*, GPS, etc.). Connectivity issues will necessitate additional user support from IT departments, increasing costs and further diminishing productivity.

Moreover, the challenges do not cease once a user acquires a network connection. Without malleable mobilized software applications that are able to monitor and adapt to changing network conditions, productivity loss worsens. Applications may hang as network connections come and go, forcing users to restart them. In such cases, critical data is prone to loss.

Implement mobile policy management. This concept lies at the heart of building flexible mobilized software applications that are able to adapt continually to bandwidth flux. Mobile policy management defines which data is most important. It also defines which data can be cached locally, which data should be transmitted and when, and on which types and speeds of networks it should be transmitted.

This can be as simple as using an algorithm that decides to use a local database when the network connection is less than 100 kbps and a network database when the connection is 100 kbps or greater. Such an algorithm would work well for certain types of applications without extensive data to exchange and no security concerns. Applications with more demanding networking needs, however, require sophisticated policy management algorithms.

In most products, it makes sense to localize the mobile policy management into a single object or component. Doing so makes it easy to differentiate the code that makes the policy decisions from the code that implements network data transfers. This practice also prepares code to increase the sophistication of the mobile policy easily over time.

In an application where a large amount of data needs to be shipped in a small period of time, data prioritization is essential. An application’s own data should not become an artificial barrier to the application’s ability to respond to the user. For example, in a simple e-mail application, the first priority should be to send the subject lines of the new messages to the email application, followed by the full text of the message the user is currently poised to read first. One would not want the application to wait for the full text of one long message before displaying the list of all messages. Failure to prioritize data properly can thus directly impact the perceived performance of the application.

There a re two ways to avoid deficits of this nature. The first is to prioritize the data properly. The priority of the data is a policy decision that the policy manager should make. The second technique to avoid a data blockage is to design the transport layer to be packet-based and to support multiple tasks. This type of architecture allows the policy manager to better respond to the user’s needs.

To make the best use of available network bandwidth, the application must avoid consuming that bandwidth with unnecessary data. There are four important characteristics to focus on when minimizing data transfer:

• Offline data stores: When a network connection is not available, having a local copy of the data is necessary to maintain an application’s functionality. A local copy of frequently used online data can dramatically improve the responsiveness of an application when it is online as well. When the system is connected to the network, having a local copy of data makes it possible to transfer only changes to data across the network. This shortens the time the user must wait for the complete data to be available.

• Differencing: To put it simply, one should not have to resend data that one has already sent successfully. If an application already has a copy of a record, file, email, image, etc., either from an offline data store or because the record was transferred earlier, that data does not need to be sent again. If the record was modified, only the differences between the old and the new record need to be exchanged over the network.

• Restarts: Connections are sometimes interrupted, and tasks are reprioritized. Whatever the cause, a data transfer may fail or be delayed, and the application must have the ability to restart the transmission while avoiding resending data that has already been sent.

• Compression: To maximize the use of available network bandwidth, data should be compressed when applicable. Not only will compressing data make the network connection faster, but it could also save the user money, as some types of network connections charge by the minute or megabyte, as with certain GPRS connections or public hot-spots.

This item is part of a series that is introduced in the item How to Mobilize Software Applications.

Discovering Mobilized Software

Comments (0)

Trackbacks (0)

Leave a comment