Something about the Quirky World of Mobile Web Apps

On a recent mobile-focused project we ran into a few challenges over getting what turned out to be a fairly complex layout working smoothly and responsively over a range of target devices. It also highlighted a number of real edge-case quirks in how different phones and browsers deal with modern web technologies such as the audio element, and even how ‘shake to undo’ can affect a form that the UI hid several transitions ago.

 

scr-300-a

(There was a time mobile phones were simpler... or not...)

 

Libraries

To help with the total payload of the project we chose to use the Zepto library rather than jQuery. This has an API very similar to jQuery’s and the advantage of size but is focussed on modern, mobile browsers so drops support for IE and - significantly - doesn’t cover Windows Phone. That wasn’t a problem on this particular project but worth bearing in mind for the future.

We found a couple of niggles in the Zepto API, mainly related to our own coding styles and the requirements of the project. We missed jQuery’s ability to set a hash of functions against AJAX http response codes, for example.

In the end, given the eventual size of the rest of the application’s payload, the filesize saving of Zepto over jQuery probably didn’t make a whole lot of difference.

 

How to be responsive

The biggest problem encountered while implementing a responsive layout with the given design was how the DOM flow needed to change depending on whether the screen is portrait or landscape. It would have been ideal if we’d had the option to change the design and eliminate the worst of the problems, but once we realised how complicated it would be it was already too late. So a lesson learned...

One of the big problems in trying to fit a fairly fixed size application design to a phone screen is orientation. Fine in a native app; you can just specify if the app fits to portrait or landscape, or both, but in a browser that level of control is not available.

Fitting the level of interaction we needed, responsively, into a landscape phone viewport meant quite a lot of juggling of DOM elements and events when switching from and to portrait layout. This was particularly tricky on iPhones as Safari in landscape orientation has three different possible sizes (address bar visible, address bar hidden, fullscreen) and generally smaller screen sizes than our target Android devices. The eventual experience in landscape wasn’t as satisfying as in portrait but we did manage to make it work.

Because of all the complexities that are not possible to handle only with CSS and media queries, we heavily depended on a Javascript layout manager to handle resize events and orientation changes, calculating available screen estate and rearranging elements.

A simpler way to get around this, although perhaps a cheeky one, would be to use the ‘orientationchange’ or window’s ‘resize’ event to effectively hide the main app with a “please turn your phone round” message. Unfortunately the ‘orientationchange’ event is not available on older Android devices.

 

Preloading

The procedure we used to preload assets for our single page web app was to have separate CSS files for the preloading/splash screen and for the main app.

The splash page was part of the app, so we didn’t want users to proceed from here and start using the main app until all the assets were loaded. To achieve this, we made one stylesheet for the splash screen with all the generic styles that didn’t require any images and another for the main app which referenced all images and assets (i.e. icons and background images) and only linked the splash stylesheet to the HTML page. We then used a Javascript preloader which requested all the image assets and the main stylesheet, attached this CSS file to the HTML page once everything was loaded and ready.

This method could also be used to load different stylesheets and assets depending on the screen size or device, if required.

 

Sounds

A new technology for us on this project was the Web Audio API which is a programmatic way of cuing and playing sound files rather than relying on a DOM element such as <audio>. Support is limited for now with only modern desktop browsers, and Safari in iOS 6, able to use it, but it looks to be a great way of adding spot effects to browser games and other interactions.

We used the Howler library to add sound to the application, with the expectation that we would use its fallback methods to increase support across devices and browsers. In the end due to other technical constraints (see ‘Device Quirks’ at the end of this post) we chose to only play sound through the Web Audio API, so if we were to refactor here we could have removed Howler (not that there’s anything wrong with it) and go direct to the API.

 

Jam off the boil

We’ve used the Jam package manager on a few projects now, and while it does have some advantages in dependency management and compilation it also uses its own module install system. So it relies on package owners keeping the versions that are published in Jam (rather than their main Github, etc, repo) up to date. We’ve had a few cases where the version of a library we needed isn’t available yet in Jam.

Jam interface with the browser is a modified version of Require, which we like for its clean module loading mechanism. So for future projects we’d look to dropping back to regular Require and find something else, perhaps a Grunt task, to handle the file concatenation and minification which Jam also offers.

 

App logic

The application logic required a fairly complex state to be maintained, and for these we used our old friend Knockout. We did consider lighter MV* libraries but ultimately felt that with Knockout’s very comprehensive view binding built-in we would save ourselves a lot of trouble. The other main aspect of the Javascript architecture was the use of a PubSub (publish-subscribe) library to communicate between the various parts of the app. So for example the AJAX API methods were fairly isolated - to enable their easy reuse - with their success states publishing the returned data for the viewmodels to pick up.

This decoupling did present a few edge case bugs around timing issues later on in development, but overall the ability to have communication, view state, preloading, sound and so on implemented independently and talking to each other via PubSub suited the Require modular loading we used as well as resulting in cleaner code.

This complexity of the application was borne out in the eventual size of the DOM, as we had several ‘pages’ within one document which were hidden and shown as required. For smoothness of experience this was useful, but retrospectively we’ve wondered if it might have been better to have a minimal HTML document with more extensive use of Javascript templating through Backbone or similar. Ultimately its hard to tell without implementing, but at least we have a steer for future iterations in this programme of projects.

 

Phonegap and other gotchas

It is well known that the performance of a web app wrapped in the Phonegap library is not as good as a native application.

Our previous Phonegap projects had a lot more DOM elements involved than this one so we hoped for better performance, but there were still a few performance issues on older iOS devices. Aside from that the Phonegap wrapping was pretty straightforward with minimal changes needed.

In the end perhaps the weirdest problem we discovered was that mobile service providers such as T-Mobile and Virgin appear to strip comments in HTML when sending data to mobile devices. This caused failures in our Knockout implementation, which used the library’s containerless control flow (i.e. specially formatted comments) to reduce the number of DOM elements - a very unexpected surprise. We ended up replacing all comment bindings with regular DOM bindings.

 

Device quirks - iOS[I] vs Android[A] vs Blackberry Z10[B]

- on-screen keyboard

[I] no viewport size change when hiding/showing the keyboard

[A, B] viewport size changes when keyboard is showing

[older A] even when the form page is hidden, the on-screen keyboard will not be dismissed unless the focus on the textfeld is forcibly removed.

- in-page scrolling

[A] even with overflow settings its still very buggy on the stock browser but Chrome doesn’t have problems.

- overflow: hidden

[older A] cannot interact with elements inside of “overflow: hidden” even if they are visible

- shake to undo (only on iOS)

[I] we found a filled-in form which was subsequently hidden triggered the iOS ‘shake to undo’ event. Unfortunately there was no known way for users to disable this feature easily but having an iframe somewhere in the DOM and changing its src (to anything) disables the “feature”. This hack doesn’t work if the app is wrapped in Phonegap but you can explicitly turn off shake to undo here.

- <audio> elements

[A] when a sound clip plays in an audio element it stops other background music from other apps

[B] the sound clip files are added to system playlist and so become accessible through its music player

- ‘devicemotion’ event

[A] on Android Chrome browser the ‘devicemotion’ event is not supported, although it is available on the stock browser. Future Chrome updates should add support.

- ‘orientationchange’ event

[older A] not supported

 

co-written by Stephen Fulljames