Been Interrupted lately?

One part of this column will be describing different aspects of wireless technologies and another will focus on how these properties impact the applications. One of the most important parts of wireless, and one that will be there even in the most advanced systems of the future, is temporary loss of connection, interruptions. As we get mobile we get more freedom, but we will also have to expect that the radio waves cannot reach us everywhere. The initial scenario pictures how this can affect us all, if we are not aware of how to overcome the potential difficulties.

This is something that not only can, but will happen if application developers do not have the properties of the wireless environment in mind when designing the applications. The issue is somewhat complicated, as there are numerous things that can prevent an application from reaching its server, apart from the many ways the radio conditions can affect it. Depending on what the condition is, the application might have some access to information about the current status of the network. Here I will, however, focus on generic ways of making the applications work well even when the wireless environment is being difficult.

The first wave of Mobile Internet will consist of mainly two things:

• WAP-like applications
• Applications that let the users to what they are doing on their PC’s today, wirelessly.

The second category is the one that is really at risk when it comes to interruptions and other properties that are typical for wireless network, but rare on the fixed Internet of today. After all, when did you last travel through a tunnel with your desktop PC? Even if you would (don’t ask me why/how), it is unlikely that it would affect the connection to the Internet. With wireless, it’s a totally different story. Even with extensive build-out of the networks you will, now and in the future, experience periods when your device cannot reach a server. WAP has built-in mechanisms to handle these things (WTP , suspend/resume etc), but even though WAP will be the mass market access technology in a foreseeable future, there will be other applications as well. As the ‘always online’ functionality becomes pervasive, more and more laptops will be constantly connected to the Net, enabling us to run whatever we are used to in the home/office environment on the go.

So, why do we get into trouble with interruptions and how can we get around it when not using WAP? Let’s start with looking at what happens when an application encounters an interruption. A client side task (in an application) that needs input/interaction with the server/Internet end will send a request and await an answer. In modern operating systems these requests are commonly implemented by separate threads, so that one request does not hog the entire application (or worse, the entire OS). You can, however, not just rely on the OS to solve the problem for you, but you must always think: What happens if it takes 30 seconds to get a response or if I don’t get a response at all? Also, it is crucial to have a feeling for how threads or Remote Procedure Calls are handled in the platform you have chosen. It is not an incredible hazard to overcome, but if your application, and maybe also the OS, has been designed for Internet access where interruptions are very uncommon, you will have to be careful.

Overcoming this problem is mainly done in two ways:

• Robustness
• Perceived performance

Some Operating Systems do not have concurrent threads, like Palm OS, but overcomes this by the implementation of a powerful mechanism by which the user can stop a transaction (request/response) without killing the entire application. If the user feels that he/she is in control, waiting for a delayed response is not too painful. It becomes a hassle, however, when you do not now when and if the application will recover, and you have no means to interfere. A successful application appreciates and utilizes the possibilities of having mobile, constant access to information, but knows the limitations of ‘constant’. If you know that there is a risk that the response will be delayed, will you put the entire application on hold while waiting?

The second remedy for loss of connection is to keep the user not only in control, but also informed. Compare watching your screen saying ‘Fetching your valuable data, 15 seconds to go’ or watching an hourglass. If the users know that progress is made, or get some indication why there is a delay/halt, he/she is much more likely to put up with it. Then combining this information with the previously described control, the screen will say ‘ Fetching data, currently slow progress the last 20 seconds. Wait some more or click Retry or Cancel.’ Still not good news, but the user is empowered and less likely to curse your application and rebooting the computer.

So, the application you are developing for use in a wireless environment will experience interruptions. Are you prepared for it?

About the author: Christoffer Andersson is Head of Technology for the Ericsson GPRS Applications Alliance, working in the Silicon Valley lab. In this position he and his global team helps application developers test their applications in wireless environments and to understand wireless networks and the Mobile Internet. His column focuses on wireless technologies and their impact on application development. Christoffer can be reached at christoffer@wirelessdevnet.com.