Mobile World Congress
2013, W3C worked with several developers including Tomomi Imura
(Nokia), Steren Giannini (Joshfire), and Dominique (Dom)
Hazaël-Massieux (W3C) on two Web applications to demonstrate some
of the new capabilities of HTML5 and related technology. I asked
some of them about their experiences creating a camera app, a photo
gallery app, and the server-side technology to stitch them
together. The resulting demo worked as follows:
- The camera app takes pictures, displays them on the camera, and
can post them to various sites, including W3C's own server.
- The W3C server receives the photos and publishes a feed that is
updated as new photos arrive.
- The gallery app reads the feed and displays the photos useful
on a variety of devices, in our case: smartphone, tablet,
television, and laptop.
The camera project began in the
Core Mobile Web
(Coremob) Community Groupas a way to illustrate both the
current capabilities and limitations of the Open Web Platform
Ian: Tomomi, when did this project start?
Tomomi: Originally, the app was nothing more than a prototype I
wrote for fun. John Kneeland, from Nokia also wanted to work an app
that would showcase the capabilities of the OWP. The Coremob CG
seemed like the right venue, and we developed
the specsin the fall of 2012, shortly before a Coremob
Ian: The Open Web Platform intends to lower the cost of
cross-device development (see the related
interview with Todd Anglin on the Kendo UI survey). As you
built the camera app, what did you find was relatively easy to make
work across devices? What was difficult (and how did you solve
Tomomi: Creating a user interface that is platform independent
is one of the keys to cross-platform development. When I created
the UI for the camera app, I designed it to be independent of the
platform's look-and-feel, so a common CSS was all I needed.
Non-trivial CSS works fine on all targeted smartphone browsers so I
can say that designing the UI was the easiest part. Also, canvas
works as expected on most browsers so I did not need extra
workaround to support cross-platform.
However, to be honest, it was not as easy to make it
cross-platform as I initially expected. A big reason is that the
app was meant to showcase new features, which means it relies on
new Web technologies that are in the early phases of
standardization and not yet broadly interoperable. I found there
was no browser that implemented correctly all the APIs I used in
the app. In particular, I struggled to use IndexedDB to write
photos to local storage. At the time I was coding, only Firefox and
IE10 had implemented IndexedDB according to specification. Chrome
18 (was the released version at that time. Now, finally Chrome 25
is out of beta) supports basic IndexedDB, but was using an older
version of the specification with no blob support for the database.
I had to write extra code to make the demo work on Chrome.
Beside the workaround code, I used PhoneGap for Windows Phone 8
because IE10 for mobile lacks HTML Media Capture capability,
although all other features worked fine. This is a hybrid app that,
I think, is useful for illustrating how to work with HTML5 in a
transitional mode where features not yet available on certain
Ian: What would you like to do next with the camera app? It's an
open source project - are you looking for help from the community
on specific aspects?
Tomomi: We have a bunch of things in the pipeline, notably
writing tutorials on all aspects of building this app (like
providing camera access using HTML media capture, storing pics in
IndexedDB, etc.). We also have a nice table with all the key
features required to build this app and how well (or poorly) they
are supported in different browsers. I definitely want to share our
experience in more detail with developers. Before doing that, I
plan to simplify some of the code (to remove some hacks). This will
cause more browser incompatibility, but my goal is not to promote
hacks and tricks, but rather working with Web standards.
Ian: Steren, Joshfire volunteered to be part of this project
because you already had a Web-based gallery app. What has been your
experience so far (generally) getting your app to work across
different devices? In particular, the app works on some
televisions. What has been your experience so far with Web
technology on televisions?
Steren: Joshfire is creating tools to build applications for
today's devices and the ones coming tomorrow. For us, Web
technologies are the logical solution to build a multi-device
application that is sharing the same codebase on all these devices.
The Web Gallery was developed under this model: 80% of the code is
shared by all the versions of the app, and the remaining 20% is
just for layout adaptation, view hierarchies, and user
Web technologies have been selected by TV manufacturers as the
official tool to build applications for connected TV. That's a good
thing and their browsers are now getting better. It was not the
case in 2011, where some TV browsers had critical bugs and suffered
from major performance issues. Today, it is more easy to develop
for TV, I would say it is similar to mobile web development.
Ian: From your perspective, what are the priority features of
the Open Web Platform where you think we need to make progress in
order to close the gap with native platforms?
Steren: I think developers need features, frameworks and
documentation that will help them to build rich client side
applications more easily. And to close the gap with native
platforms, they also need to be able to access device specific
sensors and features (as enabled by projects like Phonegap). Native
platforms have application ecosystems that are more than simple
URLs: they ask permissions, install locally and auto-update in
background. I think the Open Web Platform should provide the same
mechanisms. An important priority is also to identify browser
problems in the implementation of the specifications. Today,
developers notice too many implementation differences that do not
appear to be a priority for browser manufacturers.
Ian: Dom, you built the server that hosted the camera and the
gallery apps. What were your priorities in building the server?
What solutions did you adopt?
Dom: As in any other project, my priority was to do as little as
needed. In this case, the server mostly had to act as a go-between
for the camera and gallery apps, receiving pictures from the former
to display with with the latter.
I chose to develop a node.js-based solution, since I was
confident it would let me assemble the various pieces I needed
easily; also, one of the features that we were likely to use,
Server-Sent-Events, is much easier to implement in an asynchronous
environment such as the one provided by node.js.
Ian: We set up this apps to run in a local environment (that is,
not on the Web). If we wanted to make available a Web version of
these apps, what would you have to change in the server
configuration? How would you deal with security? Privacy? Flooding
our server with photos?
Dom: There are two options for having the app run in an open
- Put some sort of access control in front of the upload feature,
where only selected users would be allowed to upload pictures,
- Put some sort of moderation in place so that any picture would
need to be validated before being pushed to the gallery.
The first approach would require some changes in the camera app
and the server-side component. The second would require a new
client-side component, and would also benefit from different kinds
of Denial of Service attack protection (e.g., rate limiting the
number of pictures that can be uploaded, using techniques to avoid
robot-based submissions, etc.).
I would probably handle privacy issues at a different layer. We
would need a policy and a process to determine when and how a given
picture can be posted (e.g., asking the submitted to vouch they're
not posting a picture of someone without their agreement), and how
pictures could be taken down.
Ian: Thank you all for the insights, and good luck with the
evolution of these apps!