HTML5 APIs: An Overview
A brief summary of the HTML5 APIs available for use in your assignment 3 project.
Service Workers
Chrome only. Consider falling back on older AppCache manifest for iOS.
This is the big one. Service workers is a broad set of APIs that can acts as client-side proxies servers that intercepts requests to the server. You are also required to consider using them to enable offline access as part of the assignment 3 milestones. Uses of service workers include
- Allowing web apps to continuing functioning offline
- Caching assets locally to reduce server load and improve user experience
- Handle push notification from server
- Store a backlog of actions done locally when the device is offline and sync them when the device regains Internet access
If you’re using WebPack, consider using the offline-plugin package, which supports both ServiceWorker and AppCache as a fallback.
Notifications
Requires user permission
Allows your app to create native notifications. This is obviously useful in a wide variety of situations, but unless combined with a service worker, the page can only create notifications as long as it is active. This is fine on desktop, but on mobile where the browser will actively kill inactive tabs, this API hasn’t been very useful until web/service workers came along.
Remember to prime the user before attempting to ask for permission, as the browser’s permissions dialog box is very intrusive (intentionally so, for security reasons).
IndexedDB
Since ServiceWorkers run off a separate thread from the main browser window thread, you cannot use any of the traditional synchronous data storage techniques, like localStorage
inside your ServiceWorker thread. Instead, you need to use IndexedDb, a client side transactional key-value store with an async API. Since the API is fairly low level, the use of a library like Dexie.js is recommended.
WebSockets
A protocol for maintaining a persistent two-way communication channel between the server and the browser. This is a much cleaner and more efficient solution than using Ajax polling or long-polling to accomplish the same result. Websockets allows the real-time updating of website content pushed from the server, for example for showing new items on a feed, updating vote counts, etc. Since websocket connections are lightweight, a server can handle hundreds of thousands of simultaneous connections without consuming a lot of resources.
Since websockets is a low level API, it is recommended to use a library like Socket.io to work with websockets.
Canvas
Allows client-side JavaScript to draw arbitrary shapes on the webpage via the <canvas>
HTML5 element. This is a relatively low-level API, but there are many libraries out there that make use of this, such as the Phaser game framework. Applications that make use of this API include:
- Games, using canvas to render the playing area
- Drawing application, using
<canvas>
as a, uh, canvas for the user to draw on - WebGL, which also uses the same
<canvas>
element to render output - Most applications that uses the camera, since the camera output is typically drawn onto a
<canvas>
element
Camera and microphone
Requires user permission. Live camera/microphone streams are available in Chrome only.
Web applications can access the device’s native camera(s) and microphone. This is useful for a wide variety of purposes, including:
- QR code scanning, using a library like quaggaJS
- Photo annotation when combined with canvas
- Client-side audio manipulation and distortion when combined with the Web Audio API
- Audio and video chatting when combined with WebRTC
Geolocation
Requires user permission
Provides the user’s precise location (or at least as precise as the device will allow for). This API will return the location in lat-long format, and so it is up to you to decide how to use that information. Possible uses include:
- Showing the user’s location on a map
- Providing location-based information to the user
- Tracking the user’s movement across a period of time.
It’s better to think of this API as a convenient alternative to entering their location manually rather than the only way for the user to provide their location. Remember that not all devices support the same level of precision, and be careful of coordinates that appear more precise than they actually are. If you only need a user’s rough location, such as the country they live in for localization purposes, try using their IP address or checking the request’s headers instead.
Like the notifications API, this too requires the user’s permission. And just like that API, remember to prime the user for this, otherwise they will likely reject the request. Whatever you do, do not let the first thing the user see of your app be a large permissions dialog box.
Device Orientation and Motion
Webapps can now access the client’s compass, gyroscope and accelerometer data. This is useful for:
- Creating motion based games that use tilt or shake as control
- Tracking the position of the phone to render VR scenery
WebRTC
Chrome only.
RTC stands for Real-Time Communication, and WebRTC a protocol for web applications to allow peer-to-peer steaming of audio, video and text data without a intermediary server. This can be used to create video and audio chat/conferencing applications.
Vibration
Requires user permission
Activates the device’s vibration motors. So far I’ve only seen this used by phishing sites mimicking native OS notifications (poorly). One actual use case for this would be in games, where you need to provide haptic feedback to the user.
Others
There are even more experimental APIs you can tap into if you want to build something cool:
- Web Audio - Client-side audio processing
- WebGL - OpenGL ported to the web
- Battery - Check the client’s battery status
- Web Speech - Client side text-to-speech and speech recognition
Remember to check compatibility against http://caniuse.com/ when deciding on using an API.
Comments