{"id":19440,"date":"2018-10-11T11:30:04","date_gmt":"2018-10-11T11:30:04","guid":{"rendered":"https:\/\/www.heartinternet.uk\/blog\/?p=19440"},"modified":"2018-10-11T11:30:04","modified_gmt":"2018-10-11T11:30:04","slug":"5-more-things-you-didnt-know-a-browser-could-do","status":"publish","type":"post","link":"https:\/\/www.heartinternet.uk\/blog\/5-more-things-you-didnt-know-a-browser-could-do\/","title":{"rendered":"5 more things you didn’t know a browser could do!"},"content":{"rendered":"

The web is an incredible place these days. New browser capabilities, paired with big improvements to the JavaScript language and advancements in development tools and frameworks, are changing the way we think about the web: from a place to read simple documents to a vast repository of great apps that rivals native platforms.\n<\/p>\n

\nIn fact, a lot of these new browser capabilities have to do with closing the gap between web and native apps, by providing new APIs that allow websites to do things like requesting geolocation information or sending push notifications, just like native apps do. Sam Bellen<\/a> already covered these examples and some more in a previous article<\/a>. In this one, we’re going to take a look at five more amazing things modern browsers can do.<\/p>\n

Payment Request<\/h2>\n

Unless you’re building wildly creative websites, online multimedia experiences or web-based games, some new browser APIs can feel like they’re super fun but not so much useful for your daily work. Sure, it’s pretty cool that you can connect a gamepad to your browser, as we’ll see later, but you might also think that’s not going to help driving up conversion rates for your clients’ ecommerce sites (unless, you know, you’re building wildly creative ecommerce sites!). However the new Payment Request API proves that’s not always the case, and it can in fact help with those conversion rates. Let’s see how.\n<\/p>\n

\nFirst-time users of ecommerce sites often face long and cumbersome checkout processes. These can be particularly painful in mobile devices, where typing is less comfortable and users’ attention is generally more divided. The Payment Request API allows developers to take advantage of a native user interface to ask for payment details, built into the browser itself. This not only provides a consistent experience to users, but can also make the process much easier and faster: users only need to enter their details once, and the browser will remember them for future payments, even for other sites. Moreover, it’s not unusual to find that a lot of the required information is already filled in in the first place, because browsers can extract it from previous form auto completion data.\n<\/p>\n

\nYou can see how this all looks in Chrome for desktop and Android in the screenshots below. If your browser supports this API (more about that later), you can check out the demo in my Magic Web web app<\/a>.\n<\/p>\n

\n\"The
Payment Request API example in Chrome for desktop<\/small><\/p>\n

\"A
Payment Request API example in Chrome for Android<\/small><\/p>\n

The basic usage of the API is very straightforward. First, we need a PaymentRequest<\/code> instance:<\/p>\n

const paymentRequest = new PaymentRequest(methods, details, options);<\/code><\/p>\n

As you can see, the constructor accepts three parameters (named as methods<\/code>, details<\/code> and options<\/code> variables in the example above). They hold all the information about the purchase, like a list of the things the user is going to pay for, total price and accepted payment methods:<\/p>\n

const methods = [{\n  supportedMethods: ['basic-card'],\n  data: {\n    supportedNetworks: ['visa', 'mastercard'],\n  },\n}];\nconst details = {\n  displayItems: [\n    {\n      label: 'Nice t-shirt',\n      amount: { currency: 'EUR', value: '35.00' },\n    },\n  ],\n  total: {\n    label: 'Total',\n    amount: { currency: 'EUR', value: '35.00' },\n  }\n};\nconst options = {\n  requestPayerName: true,\n  requestPayerEmail: true\n};<\/code><\/pre>\n
The API is very complete and there are a lot of optional keys in these objects, in order to ask for things like address or shipping options (and update prices accordingly on the fly). Please refer to the PaymentRequest documentation on MDN<\/a> for more information.<\/p>\n
Once our PaymentRequest<\/code> instance is created, all we need to do is call its show<\/code> method to let the browser know that it needs to display the payment UI. This returns a Promise<\/code> that resolves to an object with the payment information, plus a complete<\/code> method to tell the browser whether the payment was processed successfully, so that the UI can be updated:<\/p>\n
paymentRequest.show()\n  .then((result) => {\n    \/\/ User confirmed info in payment UI\n    callPaymentProvider(result).then(() => {\n      \/\/ Payment successful\n      result.complete('success');\n    }).catch(error => {\n      \/\/ Error processing payment\n      result.complete('fail');\n    });\n  }).catch(() => {\n    \/\/ User left payment UI\n    result.complete('fail');\n  });<\/code><\/pre>\n
Notice that the browser only takes care of collecting the payment information; the payment processing itself is up to you. In other words, you need to take that information and send it to your server or third party payment provider (think Stripe<\/a>, for example). This is represented in the code above as a callPaymentProvider<\/code> function.<\/p>\n
The future of the Payment Request API looks very bright at the time of writing: latest versions of Chrome, Edge and Safari already support it, and it’s currently in development for Firefox.<\/a><\/p>\n
Device Orientation<\/h2>\n
Wouldn’t it be cool if your page could react to a user shaking their device or rotating it? This is not only possible but actually quite easy to do thanks to DeviceMotion<\/code> and DeviceOrientation<\/code> events. Let’s see how they work.\n<\/p>\n
\nThese are events just like click<\/code> or load<\/code>, so we only need to add an event listener for them and handle the events whatever way we want. For example, to detect that the device is being shaken:\n<\/p>\n
const SHAKING_ACCEL = 30;\n\nwindow.addEventListener('devicemotion', event => {\n  const {acceleration} = event;\n  \n  if (acceleration.x > SHAKING_ACCEL && acceleration.y > SHAKING_ACCEL) {\n    console.log('Device being shaken');\n  }\n});<\/code><\/pre>\n
\nOr if we wanted to listen to the rotation of the device:\n<\/p>\n
window.addEventListener('deviceorientation', event => {\n  console.log(`Device rotated ${event.alpha} degrees`);\n});<\/code><\/pre>\n
\nTake a look at the deviceorientation<\/code> and devicemotion<\/code> events documentation on MDN<\/a> for additional details. Support for these events is very good, and they can be used confidently in all major mobile browsers.<\/p>\n
Gamepad<\/h2>\n
\nWe promised we’d see how to control the browser with a gamepad, and the time has come. The appropriately named Gamepad API allows us to do just that. The introduction of this browser capability opened the door for proper web-based games and other interactive experiences. Although it might be a little bit trickier to use than others, it’s still a nice API and you can get up and running with it in no time.\n<\/p>\n
\nFirst, we get all the gamepads connected to the device. Let’s say we want to use the first one for this example.\n<\/p>\n
const gamepads = navigator.getGamepads();\nconst gamepad = gamepads[0];<\/code><\/pre>\n
\nThe gamepad<\/code> variable is an object, the properties of which we can access to check what buttons are being pressed:\n<\/p>\n
const {buttons, axes} = gamepad;\n\nconst indexOfButtonPressed = buttons.findIndex(button => button.pressed);\n\nconst isUpPressed = axes.y === -1;\nconst isDownPressed = axes.y === 1;\nconst isLeftPressed = axes.x === -1;\nconst isRightPressed = axes.x === 1;<\/code><\/pre>\n
\nBut here’s the catch: if we want our page to react to button presses, we need to be constantly checking these properties, because there are no events for them. So how do we do that? The recommended and most performant way is to make use of requestAnimationFrame<\/code>:\n<\/p>\n
const logIfUpPressed = () => {\n  if (buttons.axes.y === -1) {\n    console.log('Up pressed');\n  }\n  \n  requestAnimationFrame(logIfUpPressed);\n};\n\nlogIfUpPressed();<\/code><\/pre>\n
\nThe code above will call the logIfUpPressed<\/code> function first, which will check whether the gamepad’s axis is pressed in the up direction. Then requestAnimationFrame<\/code> will be called with the same function, which will schedule the function to be run in the next frame. The process will be repeated indefinitely, effectively checking the state of the gamepad every frame.\n<\/p>\n
\nThere are also events that we can listen to in order to trigger an action when a gamepad is connected or disconnected:\n<\/p>\n
window.addEventListener('gamepadconnected', () => {\n  console.log('Gamepad connected');\n});\n\nwindow.addEventListener('gamepaddisconnected', () => {\n  console.log('Gamepad disconnected');\n});<\/code><\/pre>\n
\nAlthough it’s not so well-known, this API has been around for quite some time, so all major modern browsers support it<\/a>. There’s a basic demo in my Magic Web web app<\/a> if you want to try it for yourself.\n<\/p>\n
\"The
Connecting a gamepad in the Magic Web example<\/small><\/p>\n
Shape Detection<\/h2>\n
\nOne API that seems to have more creative uses at first sight is the Shape Detection API. It greatly simplifies the detection of faces in images in the browser, but it can also detect barcodes, so it really has some practical applications, too. This is something that can already be achieved with JavaScript (there are in fact some libraries that do it out there), but having an API for it means better performance and shipping less code to our users.\n<\/p>\n
\nThe Shape Detection API is extremely simple to use. First, we need an image:<\/p>\n
\nconst image = document.querySelector('img');<\/code>\n<\/p>\n
\nThen, we just instantiate a detector and call its detect<\/code> method with the image:\n<\/p>\n
const faceDetector = new FaceDetector();\n\nfaceDetector.detect(image).then(faces => {\n  console.log(`There are ${faces.length} faces`);\n});<\/code><\/pre>\n
As you can see, the detect<\/code> method returns a Promise<\/code> that resolves to an array of detected elements. Each of them is an object with information about the element detected, such as its boundaries, the eyes and the mouth position in the case of faces, or the code value for barcodes. Check the examples section in the Shape Detection API spec<\/a> for more information.\n<\/p>\n
\nThe bad news about the Shape Detection API is that only Chrome supports it<\/a> at the moment, and a feature flag needs to be activated for it. However, the API has been well received among developers, so there’s hope that it’ll be adopted by other browsers. If you want to try a simple demo, open Chrome and enable the feature flag by navigating to chrome:\/\/flags\/#enable-experimental-web-platform-features<\/code>, and then go to this demo in my Magic Web web app<\/a>.<\/p>\n
\"The
Testing the Shape Detection API in Magic Web<\/small><\/p>\n
Web Bluetooth<\/h2>\n
We’re finishing this article with a pretty surprising API. The Web Bluetooth API allows websites to communicate with Bluetooth devices. That’s right, browsers can now directly connect to wireless devices, no extra software needed. And once again, it’s easier to do than you might think.\n<\/p>\n
\nThis is how to connect to a Bluetooth device and read its battery level:<\/p>\n
navigator.bluetooth.requestDevice()\n  .then(device => {\n    console.log(`Selected device: ${device.name}`);\n    return device.gatt.connect();\n  })\n  .then(server => server.getPrimaryService('battery_service'))\n  .then(server => server.getCharacteristic('battery_level'))\n  .then(characteristic => characteristic.readValue())\n  .then(batteryLevel => {\n    console.log(`Battery level is ${batteryLevel}`);\n  });<\/code><\/pre>\n
When the requestDevice<\/code> method is called, the user is presented with a list of nearby Bluetooth devices, so that one can be selected. That’s why the method returns a Promise<\/code>, which resolves to the selected device. Then all that’s left to do is to connect to the device and get or set whatever values we want. There’s some jargon in the API coming from the Bluetooth specification, but you get the idea: the device values we want to read or write are called characteristics<\/em>, which are grouped by services<\/em>.\n<\/p>\n
\nThese are the basics of the API but there’s more to it; check out this article from Google’s Web Updates blog<\/a> for a more in-depth introduction.\n<\/p>\n
\nJust like the Shape Detection API, currently only Chrome supports the Web Bluetooth API<\/a> and the same feature flag needs to be activated, unless you’re on Android or a Mac. Edge is considering implementing it<\/a>, so better browser support might come in the future for this API.\n<\/p>\n
\nIf you happen to own a compatible Bluetooth light bulb, you can try a cool demo in my Magic Web web app<\/a> that combines the Web Bluetooth API with DeviceMotion events to let you turn on and off a light bulb by shaking the device. There’s also a recording of me performing this demo live<\/a> at a conference (in Spanish, but you can see the demo anyway).\n<\/p>\n