Making Mobile Apps Networkable

Developers want to rely on network services as confidently as they rely on utilities that have existed forever--those serving up electric power, for instance. But that's just not reality. Mobile applications in particular must be designed to work under a variety of network conditions, including situations where the network is virtually nonexistent.

Vive la Différence

Applications perform differently on different networks because of two principal network factors: delay and availability.

Delay stems from a variety of sources, but limited bandwidth, packet loss and backbone delay are the most difficult to engineer around. In bandwidth-starved environments, just getting packets on the wire can take time. And simply adding bandwidth doesn't necessarily solve the problem. You still have to suffer some backbone delay as those packets get across the cloud.

Most public backbones--the Internet and next-generation cellular networks, for instance--are highly latent, so no amount of extra bandwidth will improve the performance of a poorly written application. And because coverage on public backbones will always be limited, mobile applications must be designed to work in a disconnected environment, using the network only when it's available.To help developers factor the network environment into their application designs, consider four network dimensions: narrowband versus broadband, public versus private infrastructure, fixed versus mobile, and wired versus wireless.

First, consider the narrowband wired case. Narrowband application design best practices are well known, if not always followed. The fundamental tenets are: Keep bandwidth requests low, expect latency to be high, and piggyback network requests to avoid synchronous request/response activity.

Now, think about broadband. High-speed connections provide more bandwidth than dial-up services do, but sources of delay, including router hops and packet loss, still abound. Move from a private to a public network and the situation deteriorates even further, not only in terms of delay but in terms of availability. Internet reliability still hovers between 97 percent and 99.3 percent compared with the 99.9 percent reliability of a well-engineered LAN, according to Meta Group studies. So the application must be designed to work in disconnected mode, or at least in dial-up mode, because the public broadband pipe can fail.

Finally, think about the wireless scenario. This is much like a mobile dial-up connection but with potentially better persistence--but often lacking QoS mechanisms. You can't guarantee a quality mobile network unless you've built the network yourself. In a private warehouse, for example, an application can function seamlessly while the user moves about a Wi-Fi network. But move onto a public infrastructure and the problems associated with public wired infrastructure, including high latency and low reliability, crop up. Use a cellular network and you'll get better coverage, or so the theory goes, but delay will skyrocket. Our studies of new cellular networks, including WCDMA-based 3G services, show a base latency of about three quarters of a second, which has a huge effect on application performance.

Which brings us right back to where we started. If you want application reliability, don't make assumptions about network service quality.Post a comment or question on this story.