BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Chrome Updates Experimental Wake Lock API Support

Chrome Updates Experimental Wake Lock API Support

The Wake Lock API prevents some aspect of a device from entering a power-saving state, a feature currently only available to native applications. Chrome 79 Beta updates its experimental support for this feature, adding promises and wake lock types.

Under development since 2015, the Wake Lock API is one of many APIs that strives to give web app developers feature parity with native applications. Most mobile devices quickly sleep when idle to prevent apps from draining a device's battery. This behavior is generally preferred, but some applications need to keep the device or screen awake to be useful. Use cases include using web apps as audio tours, recipe applications, boarding passes, kiosks, and presentations.

The newest update to the Wake Lock API proposal expands the scope beyond keeping the screen on and resolves potential issues with security and privacy.

To use the Wake Lock API, developers need to enable the #enable-experimental-web-platform-features flag in chrome://flags. To see the Wake Lock API in action, enable the feature in Chrome and visit the Wake Lock Demo and view the Wake Lock Demo source code.

The Wake Lock API offers two wake lock types, screen, and system. While somewhat independent, a screen wake lock necessitates that the app continues running. As implied by their names, the screen wake lock prevents the screen from sleeping, whereas the system wake lock prevents the CPU from entering standby mode.

The Wake Lock API was recently updated to support promises and async functions. The WakeLock API is sensitive to page visibility and full-screen mode, and the Wake Lock API provides visibilitychange and fullscreenchange events to help developers offer a seamless experience.

Developers are encouraged to consider whether their application requires the Wake Lock API when options that are less performance-intensive exist for certain use cases. For example, an appl with long-running downloads should instead use background fetch, and applications synchronizing data from an external server should instead use background sync.

The Wake Lock API team is looking for feedback. Contributions are welcome via the Web Lock GitHub repo and should follow the W3C contribution guidelines.

Rate this Article

Adoption
Style

BT