No native code should be used for this application.

The building blocks

The app is realized as a single-page web application using the popular JavaScript library Backbone.js with Handlebars.js for the templates. The map component was built with the powerful Bing Maps AJAX Control SDK.

The backend was created with our good old friend Ruby on Rails. ;)

Here are some stats:

Lines of code:

  • 3838 CoffeeScript
  • 4310 Javascript
  • 727 Template code

Size:

The JavaScript code was uglified to 272.63 KB of pure awesomeness.

The project diary

Backbone.js is a nice framework to build a client side web application. But don’t let all the built-in simplicity and goodness fool you! With frontend and backend combined your stack consists of MVC for the backend and MVC for the frontend… - that’s a pretty high stack! - Luckily, leveraging CoffeeScript, the code stays clear, readable and maintainable.

Initially, we started with Zepto.js which is a lightweight jQuery replacement but due to some complex UI components we had to switch to jQuery-UI. The switch to jQuery was very smooth. Everything that worked with Zepto.js worked perfectly fine with jQuery.

The first 80% of the application took 20% of the time, the last 20% took 80% of the time. The main reasons for that were the following:

  1. Opening Pandora’s box and unleashing everything that CSS3 has to offer brings some serious problems.
    For example, we are using a transition to show and hide most of the views, some of them containing different kinds of inputs. First we used the transform:translate(x,y) CSS attribute for that, because it performs very well on the mobile Safari. Unfortunately, on the Android browser the transition is not working correctly and the JavaScript hitboxes for buttons and inputs were not on the right position. We solved this issue by using CSS transitions for Android.
  2. Resizing DOM elements beyond screen size yields in an ugly render bug on the mobile Safari. Fortunately there is an easy fix for that. By touching some CSS attributes you can trigger a relayout of the page. Details can be found here.
  3. HTML5 is a wonderland in theory but in practice you will have to sniff operating system and browser to provide the best user experience. Depending on the iOS version we had to render either a HTML5 range input or the jQuery-UI range slider. Also we have slightly different CSS for iOS and Android browsers. For example on Android 2.3 box-shadow did not work at all and border radius looks butt ugly.
    We needed to do a lot of tweeking to deal with the fragmentation of browsers on the Android platform and we are happy to see that google is tackeling this problem by providing chrome for Android and decoupling the browser evolution from system updates.

Despite the problems we had developing this application it still was great fun. Again, we pushed the limits and saw once more that web and native are moving closer and closer.

Finally, we are very happy with the result and the users also seem to like it. In the first few weeks we already tracked up to 7.000 visits per day!