In mobile software development, we must always seek to balance commercial priorities – deadlines, features, target platforms – with engineering considerations – performance, stability, resource management.
There is no easy way to do this, and time crunches and marketing demands often dictate that features, look and feel take precedence over all else. Add to this the ease with which the average developer can create a basic networked app, and you have the potential for some very bad behavior that can have real-world effects on mobile networks.
Stories abound of signaling storms and unexpected demands, spiking around the release of a new popular phone. There is a continuing discussion about all-you-can-eat data versus data caps, the need for compression, caching and so on. Yet often enough the problems caused by mobile apps are not about bandwidth and data amount, but rather about signaling.
Not many developers are fully aware of the logic around radio states on mobile phones; about the internal rules that govern how the radio switches between idle and active states; about how LTE presents a subtly different story. Most importantly, we are not always aware of how the apps we write and how we connect to network resources can affect the phone radio and – just as critically – the surrounding mobile network.
Awareness of the problem is a good first step. Tools to monitor our own apps’ behavior, developer utilities and best practices can all help make our apps better citizens on the network and on the phone.
AT&T have some very helpful material online, and for Android have released an eye-opening diagnostic tool called ARO. More here.