3 New JavaScript APIs You May Want to Follow

If you’re a frequent SitePoint reader and perhaps a follower of mine, you’re aware that I’ve written a lot of articles about HTML5 and JavaScript APIs. So far, I’ve published articles discussing APIs that you can start using today, even if with the use of a polyfill.

Today I’ll break this habit by giving you a preview of some APIs that are still at a very early stage. To give you an idea of how cutting edge these APIs are, consider that 2 out of 3 were announced just few days ago. Because of this, the bad news is that none of them can be used right now. However, if you’re interested in what they do, you may want to follow the development of the specifications and maybe provide your feedback.

Without further ado, let’s start!

Web Alarms API

The Web Alarms API provides access to the device alarm settings, which can schedule a notification or for an application to be started at a specific time. The typical use case for this API involves applications like alarms, calendars, or any other software that needs to perform an action at a specific time.

Starting from last year, this API is a W3C Working Draft. So, the specifications are at the first stage of the process to become a W3C Recommendation. This API is exposed through the alarms property of the window.navigator object. The alarms property offers three methods:

• getAll(): Retrieves all the alarms added to the device as an array of Alarm objects.
• add(): Registers an alarm based on a Date object and returns an AlarmRequest object.
• remove(): Removes a previously added alarm based on the unique ID (unique within the application origin).

Just to give you an idea of how you could ideally call these methods, here is an example that adds an alarm (remember that at the moment this code won’t work in any browser):

var alarmId;
var request = navigator.alarms.add(
    new Date("June 29, 2012 07:30:00"),
    "respectTimezone",
);

request.onsuccess = function (e) {
    alarmId = e.target.result;
};

request.onerror = function (e) {
    alert(e.target.error.name);
};

Then, if you want to remove the same alarm, you can write:

var request = navigator.alarms.remove(alarmId);

request.onsuccess = function (e) {
    alert("alarm removed");
};

request.onerror = function (e) {
    alert(e.target.error.name);
};

If you want to learn more about the Web Alarms API, take a look at the specification.

Presentation API

The aim of the Presentation API is to make secondary displays such as a projector or a connected TV available to the web, and takes into account displays that are attached using wired (HDMI, DVI or similar) and wireless technologies (MiraCast, Chromecast, DLNA, AirPlay or similar). What this API does is to enable an exchange of messages between a requesting page and a presentation page shown in the secondary display.

Please note that the specifications aren’t a W3C Standard, nor on the W3C Standards Track. This API is exposed through the presentation property of the window.navigator object. The property provides one method, called requestSession(), and two events, present and availablechange. requestSession() is used to launch or resume a presentation on a secondary screen. It returns a session object which represents a handle to the current presentation session. When the content denoted by the url passed to requestSession() is loaded, the page on the presentation screen receives the present event. Finally, availablechange is fired when the first secondary display becomes available or the last secondary display is removed.

An example, taken from the specifications, that employs this API is shown below:

<button disabled>Show</button>

<script>
var presentation = navigator.presentation,
    showButton = document.querySelector('button');
 
presentation.onavailablechange = function(e) {
  showButton.disabled = !e.available;
  showButton.onclick = show;
};
 
function show() {
  var session = presentation.requestSession('http://example.org/');
 
  session.onstatechange = function() {
    switch (session.state) {
      case 'connected':
        session.postMessage(/*...*/);
        session.onmessage = function() { /*...*/ };
        break;
      case 'disconnected':
        console.log('Disconnected.');
        break;
    }
  };
}
</script>

In case you want to learn more about the Presentation API, take a look at the final report.

Standby API

The Standby API allows you to request a screen wake lock on a top-level browsing context. This prevents the device from entering a power-saving state (e.g, turning off the screen). This ability is crucial for several web applications. For example, imagine you’re driving your car and you’re using a web-based navigator (not a native application) on your smartphone. If you don’t interact with the screen, unless otherwise specified in the settings, the screen of your device will turn off. In such cases, however, you do want your screen to stay awake. This is exactly where this API comes into play.

The Standby API is exposed through the wakeLock property of the window.navigator object. It provides two methods:

• request: Causes the underlying platform to keep the screen in active state.
• release: Releases the wake lock, so the screen will no longer be kept awake.

Both these methods accept just one argument that can be either "screen" or "system". The former is used to target the device screen, while the latter to target other device resources like the CPU or the radio (but not the screen).

An example that shows how to use this API to request the screen to stay awake is shown below:

navigator.wakeLock.request("screen").then(
    function successFunction() {
        // do something
    },
    function errorFunction() {
        // do something else
    }
);

To allow the screen to turn off, we can write the following statement:

navigator.wakeLock.release("display");

If you want to learn more about the Standby API, take a look at the unofficial draft.

Conclusions

In this article I’ve introduced you to some brand new JavaScript APIs. Once again I want to highlight that because they are all in a very early stage, no browsers support them. Therefore, we can’t play with them. However, being so new you have the chance to follow their development and even contribute to the specifications.

The future of web development is bright, be part of it!