The carrier today put out a new white paper -- which it swears doesn't read like a traditional white paper -- about how to develop network-friendly applications.
Some of the company's less obvious suggestions (besides default to Wi-Fi) include:
- If an app transmits and receives data frequently, leave it open. It'll use fewer network resources than turning it on and off.
- But design apps to close sessions that aren't actively being used.
- Schedule some partial updates to the display rather than wait for all the data to download. For example, display four out of 50 emails before moving on to download the rest.
- Bundle several updates to send to the phone at once and wait for an off-peak time, but if the user has a tiered data plan, consider allowing them to decide when to update versus doing it automatically.
I can feel the dissenter storm brewing as I write this, but to me, it seems developers should at least give the guidelines a read as they build their apps. I realize most only care about building the coolest, most monetizable app they can. But chatty, resource-hogging apps can cripple, even crash, the network, and that can also hurt the developer. (See Mu's Quadrant of Miscreant Apps and MWC 2011: Developers: Network Allies.)
A slow, buggy user experience or one that causes a user to bust through a data cap or chew up battery life doesn't reflect poorly on the operator, but on the app. Yes, the responsibility for building app-aware networks so this doesn't happen falls most heavily on the wireless operators, but working together benefits everyone. (See Docomo Counts Cost of Signaling Storm , Operators Accept Support Act Role and Operators Urge Action Against Chatty Apps .)
So why be a pain in the app when you can play nice? Let's give it some thought...
— Sarah Reedy, Senior Reporter, Light Reading Mobile