The introduction of an accelerometer in smart phones has created a world of opportunities for developers to create applications that are engaging, creative, innovative, and convenient.
The accelerometer allows the device to be aware of its physical orientation, so that an application can respond when the orientation is changed. A common example of this is when an application changes the display on the device screen when it is moved from a vertical to a horizontal position. If screen rotation is not managed efficiently in an application, however, it can cause issues.
With some mobile apps, switching screen orientation immediately initiates network activity, which may turn on the radio just for that purpose. This wastes energy and consumes network resources, when it could be avoided.
This Best Practice Deep Dive looks at how accelerometers are used in mobile apps, describes the issues involved in managing screen rotation, and provides a recommendation for how to manage screen rotation more efficiently.
Most new mobile phones contain an accelerometer or tilt sensor that allows the device to know when it is tilted on its side. This sensor can be used for automatic image rotation, motion-sensitive mini-games, and to correct shake when taking photographs.
An accelerometer is an electromechanical device on the phone that measures acceleration forces. By measuring the amount of static acceleration, it can determine the angle at which the device is tilted or rotated. By sensing the amount of dynamic acceleration, the accelerometer can analyze the way the device is moving.
Developers have been able to add many useful features using accelerometers, for example:
Tracking changes in screen rotation in order to apply new styles to the user's view that better matches the horizontal or vertical screen. Tracking the rotation of the device and sending back analytics information to better study the user's behavior.
However, these features can impact response time and power usage if they are not managed efficiently.
Many applications are written so that the device pings the server and reloads the page every time the user rotates the screen. This is often done even when there is no change to the contents of the page. In such a situation, pages do not need to be reloaded.
The following image (figure 1) is taken from the Trace chart in the Diagnostics tab of the AT&T Application Resource Optimizer (ARO) diagnostic tool. The AT&T ARO tool collects trace data from an application, evaluates it against recommended best practices, and generates analytical results.
The Trace chart in figure 1 illustrates the issue of an application reloading a page every time the screen orientation is changed.
Figure 1: Trace results from an application showing bursts when the screen orientation is changed.
In this example, every time the user changes the screen orientation from landscape to portrait, a 43 byte packet is requested from the server.
Another scenario that can cause inefficiency is when an application gathers information based on the rotation of the screen, and sends the information back to the server. If this information is sent too often and is not bundled with other data, the application may be unnecessarily opening a radio connection, wasting energy and creating network congestion.
Best Practice Recommendation
The Best Practice Recommendation is to track the orientation in the application locally, and send information at scheduled intervals, bundled with another activity. This approach would save energy for each unnecessary transfer of data that is eliminated.
As illustrated by the example in figure 1, it would have saved energy and speeded up the application's response if the continuous messages to the server based on screen rotation had been managed more efficiently.