Features/Camera

The ability to take pictures, store them and upload them to a remote server is one of the key features missing from mobile phones today.

This feature is one the key features the web versions of the Facebook and Twitter app are missing to have the same capabilities as their native counterparts.

Camera access would also enable applications such as Instagram or Path to be built using web technology.

Enabling Camera Access

There are a number of specs which give different level of access to the device's camera.

While lower level specs like getUserMedia open up whole new category of applications such as augmented reality apps, QR code scanners, etc., they are are far from complete, and they come burdened with complex permissioning issues.

It also turns out that there isn't that much demand for such apps from end consumers. Unsurprisingly, the biggest use of the camera on a mobile device is still to… take pictures!

Therefore, a solution that relies on the built-in camera application is perfectly acceptable for the uses cases we are interested in. There are other benefits to this approach. For example, it enables using a physical shutter button or saving the pictures being taken to the devices photo gallery.

Despite a rather unsavory API, the HTML Media Capture spec fits the bill perfectly. What's more, it's permissioning model based on the tried and true File Upload model avoids all of the pitfalls of low-level access. No need to prompt the user for permission to take a picture, the user's permission is implicit as the interface to the camera is provided by the operating system and cannot be accessed by application code.

Finally, HTML Media Capture is already supported by Android 3.0 and above, and the Chrome and Firefox browsers.

Main spec

HTML Media Capture.

Dependencies

Being able to take a picture isn't enough, you also need to be able to (asynchronously) upload it to a remote server, and store it on the device should the connection be sketchy, metered or what not.

Having camera access therefore implies being able to:

• access the file returned by the camera through the FileAPI,
• transfer it to a WebWorker's and
• asynchronously upload it using XMLHttpRequest's recently added support for multipart upload, or
• store it locally using the upcoming blob support in IndexedDB.

ToDos

• Investigate blob support in WebWorkers and IndexedDB.
• Are there other, simpler options to store and retrieve files?
• Some use cases (asynchronous upload of a stored file from a WebWorker with a subsequent write in IndexedDB) seem to warrant synchronous IndexedDB APIs. Are there ways around this?