Would you like to tell us how we are doing?

You bet No thanks

Battery life recommendations

When you develop an app, you should consider whether it's efficient. An efficient app doesn't consume unnecessary resources and minimally impacts the life of the device battery. When your app adheres to these standards, it's considered to be a good citizen. Being conservative with power consumption and having a great user experience aren't mutually exclusive concepts. In fact, being conservative with power usage might increase your user's satisfaction with your app.

The sections below discuss how you can make your app a good citizen.

Monitor the battery and charging state

It's a good idea to consider the impact of running app updates. Performing updates while a device is charging causes minimal battery drain, so you can create your app to maximize its update rate when the device is charging. You can also conserve battery life by reducing the update rate when the device is not connected.

You can use BatteryManager to monitor battery and charging details. BatteryManager triggers an event whenever your device is connected to or disconnected from power. You can use these events to decide how often to start your app in a background state.

To monitor changes in the charging state, you can register a BroadcastReceiver in your app manifest to listen for these events by defining ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED. Generally, only battery changes that are significant should be monitored. You can use intents to monitor significant battery changes. Some significant battery changes include ACTION_BATTERY_LOW and ACTION_BATTERY_OKAY. You can use these event to determine when to disable background updates.

For a tutorial, see Monitoring the Battery Level and Charging State.

A problem with using a BroadcastReceiver is that your app wakes up each time any of the receivers are triggered. However, you can disable or enable the broadcast receivers at runtime. You can use system events to trigger the receivers that you declared in the manifest, and only when necessary. Use the PackageManager to toggle the enabled state on any component defined in the manifest.

If your app determines that connectivity has been lost, it can disable all of the receivers except android.net.conn.CONNECTIVITY_CHANGE, which informs your app of changes in the status of its Internet connectivity. Use this technique to delay large file downloads by enabling a broadcast receiver that initiates file downloads only when the device is connected to Wi-Fi.

For a full tutorial, see Manipulating Broadcast Receivers On Demand.

Stop animations when they're not needed

Although animations are important to the look and feel of most apps, they can affect the life of the device battery. Generally, animations should be stopped when they're not needed.

For example, consider an app that frequently requests remote data, or performs intensive operations, such as running SQL queries. Although it's important to provide a visual cue indicating that some process is underway, you must consider how often that animation runs. An example of such an animation could be a ProgressBar or your own animation. If the animation is constantly running, you might want to reconsider how you present this information to your users.

In most cases, you can replace an animation with a static image that the user recognizes and associates with a particular process. For example, in a mapping app, an image of a compass rose or an arrow might indicate that the app is receiving location updates. Using these techniques can reduce the impact that animations have on the life of the device battery.

For more information about animations, see Animations.

Be conservative with location requests

Your app should be conservative with how often it sends location requests. Frequent location requests are needed when your app constantly needs to know the device's precise geographic coordinates, for example, when used in a mapping or navigation app. Otherwise, frequent location updates should not be used.

Consider a social networking app that tags updates with a user's current location, or a restaurant finder app that's designed to search for restaurants near the user's current location. For these apps, it's probably sufficient to make one location request, when needed. While it might seem useful to have the user's precise location always available, this requirement can cause a significant drain on the device battery.

For information about how you can retrieve the location of the device, see Retrieving the Current Location.

Push data to your apps

In BlackBerry 10, the preferred approach for receiving remote data is to use the Push Service. Push technology allows a server-side app to notify a client app when new data is available by pushing a notification with a small payload to the device.

Using this approach, you can conserve processor power and network usage because the client app sends requests only when it knows there's data available. The result is an app that not only conserves battery power, but also has the added benefit of near real-time updates.

For more information about using the Push Service with Android, see Creating Push-enabled Android apps.



Got questions about leaving a comment? Get answers from our Disqus FAQ.

comments powered by Disqus