Interview: Demonstrating Web Apps at Mobile World Congress 2013

For 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 Group as a way to illustrate both the current capabilities and limitations of the Open Web Platform (OWP).

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 specs in the fall of 2012, shortly before a Coremob face-to-face meeting.

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 it)?

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 platforms.

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 interactions.

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 environment:

1. Put some sort of access control in front of the upload feature, where only selected users would be allowed to upload pictures, or
2. 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!