Mobile developers spend countless hours working through the user experience so that their users will react in a positive manner. Is the app fast enough? Is it possible to shave another 100ms off the load time? It may not be possible to gauge the customer’s reaction to the resulting user experience, but AT&T’s free Application Resource Optimizer (ARO) can help developers satisfy the users’ need for speed.

Behind the scenes

Beyond speed, there are several issues that impact the user experience. Most developers don’t think about what their application is doing in the background. Mobile apps can run in the background and request data updates – for example, from the device (Is the screen on?), from the network (Has the Mariners game started?), and from the GPS (Is this phone in Dallas?). In fact, I recently counted over 20 different applications accessing the network from my Android device over a period of 12 hours – and if I hadn’t been looking, I wouldn’t have known.

Why does this matter? Because none of these connections are synced with the other applications, background activity can reduce battery life. If it is imperative that apps connect in the background, developers should take some time to figure out the best strategy to make these connections. Consider using Apple or Android’s messaging services rather than building from scratch.

Steps to better background behavior

To help developers give more thought to how their apps behave in the background, I’ve come up with some Bad Background Behaviors (BBBs) to avoid:

“The Stalker”

A “stalker” application checks your location with the GPS all the time (in this case, every three minutes). In ARO, active GPS is signaled in green:

In this example, the app will turn on the GPS 480 times each day. Apart from the creepy-stalker-privacy implications beyond the scope of this post, stalker-like activity can cause a huge drain on the battery (think 20-50 percent of a full charge) in 24 hours. This is a quick way to get uninstalled.

“Are We There Yet?”

The common and continuous refrain from children from the back seat of the car – “Are we there yet!?” – is an example of polling in the real world. Just as polling in the car is a very inefficient way to handle a parent’s patience, polling on a mobile device is an inefficient way to gather data, and a quick way to kill the battery. In this example, an application checks for updates every three minutes:

The ARO plot above shows 20 connections in 3600 seconds (1 hour). Notice that the throughput bar is large. ARO automatically scales the throughput to the largest connection in the trace. In this case, these periodic pings are 2 bytes each. In terms of data consumption, that is under 1 KB/day. But in terms of battery drain, this could represent 15-30 percent per day. With iOS and Android offering push messaging services for applications, polling should no longer be used. Take the free tools from the OS provider and save the user’s battery.

“The Slob”

There is nothing worse than inviting an application onto your phone and watching that app make a mess of the place. In this case, an application makes a connection in the background at 435 seconds, but neglects to close the connection. Some 240 seconds later, the server sends a packet back to the device, cleaning up the connection that was left open. Unfortunately, this causes the radio on the device to turn on again. This second cycle through the Radio Resource Control State Machine basically doubles the power drain on the user’s phone!

To avoid encounters with the “slob,” consider adding a queue for messages to send more data at one time. For Android developers, building a listener to background processes to piggyback on other connections from other apps can help. The following example shows the loading of an ad and an image when network activity is detected:

 

 if (Tel.getDataActivity() >0){
           if (Tel.getDataActivity() <4){
           //we found network activity-
           //download the image here using image getter
            imagegetter(counter, numberofimages);
         //and show the ad
                    AdRequest adRequest = new AdRequest();
                    adRequest.addTestDevice(AdRequest.TEST_EMULATOR);
                    adView.loadAd(adRequest);
                 // Initiate a generic request to load it with an ad
                    adView.loadAd(new AdRequest());
}}

 

Think about how your mobile app is coordinating with the server. Make sure that all the connections made in the background are REALLY needed, and you work to minimize the battery drain that they impose.

Can you think of other ways minimizing background activity can maximize the user experience? If so, share your thoughts in comments.

In conclusion, it is just as important to consider an application’s behavior in the background as it is in the foreground.