NETWORK CONDITIONS AN IMPORTANT AREA TO TEST : MOBILE APPs

Imagine if your bank’s website were to display the following disclaimer on its homepage: “We do not guarantee the security of your personal data or your account information while transacting on our net-banking portal”. Will you still use it? Almost certainly not!

There are four things to consider in this area:

Support for different network channels: Mobile devices can communicate with the network on one or more channels such as SMS, USSD, WiFi, GPRS (2G/3G/4G), WAP, etc. Certain functions in your application may not perform well (or at all) on certain channels and protocols. If you wish to support only the high capacity channels such as WiFi, or 3G/4G/LTE, you will risk shutting out the vast majority of low-end devices which may not support these radios. On the other hand if you do not specify which are the required (or recommended) channels for your application, it may result in the users inadvertently trying your application’s high-bandwidth features on a low-bandwidth channel such as 2G, thereby frustrating themselves out of the application.

For a networked application, it is crucial that you evaluate each network-enabled feature of the application from the point of view of determining the channels that it is most likely to satisfy the minimum latency requirements on. For features such as streaming media you may want to require the user to switch on a high capacity channel such as WiFi or 3G. Alternately, you may design the feature to degrade or fail gracefully if the user operates it on a low-capacity channel. For example, you may want to serve the media in a low bandwidth format such as 3GP over a 2G/3G channel and in a high bandwidth format such as MP4 over a WiFi or 4G/LTE channel. A Twitter client, on the other hand can be written to work just as efficiently on a very low capacity channel such as SMS (assuming you have a SMS translation gateway in place that your application can talk to), or a high capacity channel such as WiFi. However, when operating over the SMS channel, you should turn off the transmission or receipt of anything that is not pure ASCII text, thereby ensuring a gracefully degradation.

Finally, be sure to inform the user if a particular feature is likely to degrade or not be available on a certain channel. Also inform them about additional usage charges if choosing to operate over certain channels such as SMS so as to prevent a billing surprise.

Signal drop or signal strength reduction: Be sure to evaluate each network-enabled feature in your application in the situation where the channel over which it is operating becomes unavailable or its signal strength reduces. Ensure that the feature is either network-fault tolerant or degrades or fails gracefully in such a situation. Conceptually this network situation isn’t any different from the scenario in which a network enabled desktop application encounters a loss of network or network congestion. The main difference with the mobile case is that a mobile application is more likely to encounter a network drop or signal strength reduction situation than the desktop version of the application due to the inherently mobile nature of the platform.

Network channel transition: This network condition deals with the mobile application’s behavior when the device transitions from one channel to another. A classic scenario is one where the user walks out of their office building and the device transitions from WiFi to 3G. If there is a transaction underway in the mobile application when this happens, how will the application react to such a transition? It is useful to evaluate the application’s functionality in such situations and design it for a seamless transition to the new channel or for a graceful degradation or failure.

Support for multiple channels: This network condition relates to the mobile application’s behavior when there are multiple network channels active at a time. Note that most smart phone OSes today automatically prefer WiFi if it is available over cellular data (2G/3G/4G/LTE).Android and iOS display this behavior. Windows Phone 7 had a bug that prevented WiFi from being given a preference but that appears to have been fixed now. In the older versions of Blackberry (definitely up to BB OS 6, one could programmatically specify that in one’s app that WiFi was desired.

In general you will not have this option today to chose a specific radio – Wifi or cellular – in your app.

However note that the SDKs of most major mobile platforms provide a means to register for listening to one or more network related events or notifications when a channel becomes available or unavailable or when the signal strength changes. You should register for such notifications and perform network condition handling inside the network listeners. Also code all network calls defensively via extensive use of exception blocks and return value checking so as to ensure a graceful degradation or failure.