Andre Bandarra's Blog

Best practices for using the Wake Lock API.

The Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running.

I used an earlier version of the API on the Rowing Monitor project and the final version more recently for doom-fire.

Those two applications have slightly different implementations from a user perspective, which made me think of a couple of best practices:

Be mindful of the user's battery life

This is part of the Wake Lock documentation, but it's never much to repeat: There's a good reason on why devices will dimm or turn off the screen after a few seconds - a device's display is one of the components that draws the largest amount of power from the battery.

This means that, to avoid wasting battery, applications should only request a wake lock when there's a clear benefit to the user.

Before implementing the API, a good question to ask is: Does the user really need the device to stay awake? Here are some things consider that may help answering this question:

Avoid making users think about Wake Lock (when possible)

On the rowing monitor application, it's clear that the user will want to keep track of their exercise on the screen once they start and while they are busy doing the exercise.

This gives us a hint that we can request the Wake Lock when the user starts the exercise and release it when they stop. The device will stay awake while we know the user needs it, and only while they need it. But the user never has to think about keeping the device awake!

A good question to ask is:

However, this is not always possible. In doom-fire, for example, there's no natural way to tell when the user wants to keep the screen awake, so a padlock is used as a control for the user to to request/release the Wake Lock.

← Home