Thursday, 28 March 2013

Mobilize.js versus responsive web design (RWD)

Mobilize.js versus responsive web design (RWD)

Both mobilize.js and responsive web design offer solutions to having a mobile and desktop site from the same codebase.  This is a comparison and evaluation of the 2 approches

mobilize.js rendering
I previously blogged about mobilize.js and how it can be used to transform a website dynamically between a desktop and mobile-enabled site.  As a brief background, mobilize.js is a javascript library that detects if a mobile browser is being used and, using client-side javascript, and re-renders the page using predefined
mobile-optimised css.  However mobilize.js is no longer being developed - the developers now recommend using responsive web design instead.  In one of the comments to my original post I said I would check out the relative merits and report back - this is me reporting back

Responsive web design works by detecting the size of the display and rendering differently using css (css3) media queries.  The screen size can be set in the css (or different css files loaded) - this means that for small-screen devices a mobile-optimised css can be used, for larger screens a different css.  There can be multiple configurations for different sizes and configurations. The css for that configuration is the one that is loaded and therefore the site rendered using that css.  I found a really useful guide which formed the basis for my approach

responsive web design rendering
Since I had already transformed my own website using mobilize.js, I thought the best indicator of the approaches would be to transform the same website using responsive web design.  As it turned out the results and approach were very similar - I simply adapted the css I'd created for the mobilize.js solution to render the small screen size using responsive web design.  As you can see, the results are very similar

I was pleasantly surprised at how easy it was to adapt the site to use responsive web design, so I tried another one I'd created for Becky Whittaker Counselling.  This one was much more complicated - mostly, I feel, due to it being static-width whereas mine was elastic-width. However since a mobile css needs to be created in both cases, the resulting css would likely be the same for both approaches.  I did make a schoolboy error whilst doing this which is that I forgot about the viewport.  This is IMPORTANT as I discovered when I had weird varying results due to the viewport on any given devices
<meta name="viewport" content="width=device-width">


Before responsive web design
Attempting both approaches has led me to believe that they have their relative merits which I've grouped into 4 categories:

  •  Configurations
    • What types of configurations are available?
    • How many configurations can you create?
  •  How is the page rendered?
  •  Which technologies are used?
  •  How flexible is it for changing the page?


Configuration Type
After responsive web design

mobilize.js uses the brower's user agent to recognise if the page should be rendered as a mobile site or not - if a mobile user agent for example
Mozilla/5.0 (Linux; U; Android 4.0.3; en-gb; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
is detected then mobilize.js kicks in and renders the page using the mobile css.  This essentially means that a 10 inch tablet will render the same as 2 inch mobile phone

RWD uses resolution (in effect, screen size) to optimise the page regardless of what is being used, so a tablet with a larger resolution may render differently to a small mobile phone screen.  The user agent is ignored. This may mean that a large resolution phone renders the desktop site or that a small resolution netbook renders the mobile site

It might be that what you really want isn't to optimise for screen size but for touchscreen devices.  In this case mobilize.js might work, but there are probably better solutions for this particular case

Number of Configurations

mobilise.js has only 2 basic configurations - desktop or mobile.  As described above this is decided by the user agent

RWD has as many configurations as the creator decides - I don't know why you'd want to
but you could have hundreds if you wished. I've gone for 2 to most emulate what I did with mobilise.js
<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 767px)" href="" />

<link rel="stylesheet" type="text/css" media="screen and (min-device-width: 768px)" href="stylesheet.css" />
which cuts over to the desktop site at a width of 768 pixels.  However you could have a smaller one for really small screens for example, or a tablet sized one etc

I feel that RWD has the edge here - the idea behind mobile sites is to optimise them for smaller screens rather than being for mobile phones per se.  If you want to alter content based on user agent there are javascript libraries for that already (see for an example).  It also may mean that the javascript needs updating occasionally as user agents change

Edge: RWD


mobilize.js essentially loads the page, including the javascript which detects the browser and re-renders it using the mobile css if required.  This means that the page is potentially rendered twice including downloading content, such as images, which may not be required for the mobile site

RWD renders the page based on the required css which means it is only rendered once and only with the content required by the page and css.  So if the mobile css doesn't specify an image usually used in the desktop css it won't be loaded

Edge: RWD

Technology stack

mobilize.js utilises (according to the creator) HTML5 and javascript. This makes it heavier weight than RWD. There might be an occasion when this choice is forced due to the lack of CSS3, but realistically I can't see many occasions when HTML5 is available and not CSS3

RWD uses HTML5 and CSS3 making it lighter weight than mobilize.js since no javascript is required.  I'd also argue that performance is better since it doesn't rely on loading and running javascript nor re-rendering the page

Edge: RWD

Flexibility of design

As mobilize.js relies on you specifying the location of existing <div> tags it is pretty easy to reorder them and apply new styles.  This means that, if I so choose, I could display the footer <div> at the top or whatever as the page will be re-rendered.  This provides a lot of flexibility for creating a page that is optimised for small screens

RWD relies on the current markup and how flexibly this has been created. There is potentially limited flexibility on optimising the page.  For example if my desktop site has a side menu I might be able to alter the CSS styles to display it at the top - or then again I might not since the existing markup might prevent that.  This is probably possible with some less-intensive javascript, though I haven't tried it

Edge: mobilize.js


It is important to note that in both of the cases I tried I have been adapting an existing desktop site to render nicely on mobile devices.  If I were designing a new site I would certainly go with responsive web design and design it accordingly.  I feel this is more in the spirit of designing mobile sites which isn't specifically to create a site for mobile devices but to optimise for the screen size

For an existing site mobilize.js has some advantages that may make you consider it, especially the ability to reorder the page.  I think your choice depends on how easy it is to adapt your website to be responsive - if it isn't possible then mobilize.js may provide your answer

Wednesday, 27 February 2013

Launch a website as a mobile app using PhoneGap/Apache Cordova

How to launch a website as a mobile app using PhoneGap/Apache Cordova

I spent some time recently trying to find out how to launch my website as a mobile app.  The information was available around the internet but since it took me a while, I thought I'd collate it here in one simple post for anyone who wants to do the same

I decided to use Apache Cordova since it gave me the framework for developing an HTML5 site as a mobile app already, meaning all I really needed to do was plug my website into it.  Their getting started guide has good information on how to create a Cordova project - I used Android but you can use whatever means you wish

A basic Cordova app gives you a way to launch the app with an HTML page that you use to display your app contents.  The trick then is make the page load your website which you can do in one of 3 ways:

1. Package your site inside the app. This means it loads fast and without an internet connection.  The downside is you have to update and re-release the app whenever your website changes. It also needs to use relative paths since the root directory will be the mobile device's root directly, not the root of your site
2. Point the page at your remote website, which means changes are picked up immediately.  The downside is that it won't work if the phone has no internet connection
3. Do both and fall back to the local site if there is no network connection

Option 1 - Package your website inside the app

If you want to do option 1 (package your site with the app) you simply copy your entire site into the assets > www directory which will load your homepage as a local page (I think PhoneGap Build insists this is index.html, but if you're loading from code you just launch Cordova with that page name). Simple. You need not read on unless you're interested in option 2 or 3

Option 2 - launch your external website inside the app

To load a remote site, you need to load your homepage (or any page) using javascript from the html page that Cordova will open in your app.  This is relatively simple using basic javascript

The recommended way to run javascript in a Cordova environment is to use Cordova's ondeviceready event which ensures it is loaded, which can be hooked into your page

document.addEventListener("deviceready", onDeviceReady, false); 
function onDeviceReady() {
    // Now safe to use the Codova API
window.location=""; }

This is probably not strictly necessary for this javascript call, which is not using the Cordova API.  However I am using because it is needed for option 3

You also need to tell Cordova that it is safe to load your website in the cordova.xml properties (you can remove the subdomains part if you don't have any)
<access origin="" subdomains="true"/>

At this point you are good to go!

Option 3 - launch your external website but fail back to local version

This option requires a little more work but gives you the advantage of displaying a set of files packaged with the app if there is no internet connection

Since you need the html page given by Cordova in assets > www you will need to copy your local site to a subdirectory (I've called it local), and do everything in option 2 to load the remote site

All you need then is to add some logic to decide whether there is an internet connection and act accordingly.  Fortunately Cordova gives us a solution to this

Firstly, add a javascript function to check the connection type

   function checkConnection() {
         var networkState =;
         var states = {};
         states[Connection.UNKNOWN]  = 'Unknown connection';
         states[Connection.ETHERNET] = 'Ethernet connection';
         states[Connection.WIFI]     = 'WiFi connection';
         states[Connection.CELL_2G]  = 'Cell 2G connection';
         states[Connection.CELL_3G]  = 'Cell 3G connection';
         states[Connection.CELL_4G]  = 'Cell 4G connection';
         states[Connection.NONE]     = 'No network connection';
         return networkState;

Then add some logic around the window.location call to load the appropriate site

   function onDeviceReady() {
   var networkState = checkConnection();
 /* load local files if there is not network connection */
                  if (networkState == Connection.NONE) {
                  } else {

Again, you're good to go!

As an alternative to option 2 or 3 (I'll call it option 2a) you could use the connection type logic to display an error message so you don't attempt to load the external site when there is no connection eg:

   function onDeviceReady() {
   var networkState = checkConnection();
 /* load local files if there is not network connection */
                  if (networkState == Connection.NONE) {
                  navigator.notification.alert('This app requires an internet connection');
                  } else {
I'm going to wrap a framework around this and release some instructions for non-developers to produce site launchers for mobile devices using PhoneGap build.  Watch this space

Tuesday, 26 February 2013

Android Daydream with Processing.js

How to create an Android Daydream with processing.js

I've spent some time working out how to get processing.js (a nice javascript graphics library ported from Processing) to display an Android Daydream (basically a screensaver that activates when the device is docked or charging)

I previously wrote about how to display an HTML page as a Daydream which forms the basis for this post.  Please see my earlier post for full details but to summarise you can load an HTML page in a webview like this

Processing.js allows you to display Processing code as javascript in a page, so all you need to do is either embed the processing.js code or load the Processing PDE file containing the code as explained on the processing.js site

I only had a couple of issues with it which were:

1. The js code seemed to run at a much higher frame rate than my native Processing code such that my animation looked insane. In the end I just reduced the frame rate to 8
 void setup() {

You might need to play with the rate for your particular animation

2. screen.width and screen.height didn't seem to work correctly and displayed my animation off the bottom of the screen.  Using window.innerWidth and window.innerHeight had the desired effect
    size(window.innerWidth, window.innerHeight);

You can test it in a local browser simply by loading the HTML page into Firefox/Chrome/whatever.  Once it's working, just follow the instructions from my earlier post to set it up as a Daydream and you're good to go :)

I've added this and released it with my Android app and will see what people think

As always, if you have any questions just let me know

Daydream running on my phone
Daydream installed