PITFALLS AND HELPERSMobile HTML5 Applications

My name is Rob Hawkes, I’m one of the Technical Evangelists at Mozilla.

My focus is games, most recently around Firefox OS and mobile.

I’m also British, if you hadn’t already guessed.

Photo: http://www.flickr.com/photos/beto_frota/3232254956

I’m not going to go into anything in too much detail, however I’ve included links within the slides where necessary so you can get further information.

The slides are on my Slideshare account. I’ll put the link up at the end.

WEB APP PITFALLS

HARDWARE LIMITATIONSMemory, GPU, battery…

One of the most obvious pitfalls is around device hardware limitations, things like memory, and GPU.

Now there aren’t any silver-bullet solutions here to improve memory consumption and GPU usage, but there are certainly ways to improve things in general.

For example, to make better use of limited hardware you could offload graphics to the GPU by using hardware-accelerated CSS calls instead of doing everything with the CPU.

There are also ways to save battery. For example, when animating you should use requestAnimationFrame instead of setTimeout as it puts the browser in control of when to draw things. If the application is in the background then nothing will draw, saving battery.

You can also use things like the Battery API to intelligently degrade functionality as energy levels decrease.

DIFFERING BROWSER SUPPORTWebAPIs, manifests, tooling…

Another obvious pitfall is around the huge differences between supported features in browsers.

Some prime examples at the moment include various WebAPIs not being supported in all browsers, and application manifests between different browsers being formatted slightly differently.

I won’t go into any more detail about specifics, but what I will say is that it’s always a good idea to use shims and feature detection when using functionality that may not be fully supported everywhere.

CHANGING SPECSSome APIs are in flux

Related to browser support is changing API specifications and implementation.

This is how Web technologies naturally develop and usually doesn’t result in anything catastrophic. However, it’s always a good idea to keep an eye on APIs and technologies that are known to be in a non-finalised state – they might change.

One recent example is WebSockets, around a year ago the WebSockets spec changed in a way that broke all existing implementations. It was necessary, but it meant that developers who didn’t update their code had their apps suddenly break when the browsers dropped support for the older WebSockets APIs.

DIFFERING PERFORMANCESimilar spec hardware, different results

If you are developing anything that is vaguely intensive, like a game, you’ll have noticed massive differences in performance on mobile, even between browsers on the same device.

In short, performance on similar mobile devices should not be assumed and instead should be tested and expected to differ.

Device Average Min FPS

Average Max FPS

Lowest FPS

Highest FPS

Otoro (Fx OS)

Otoro (Fennec)

SGS2 (Fx OS)

SGS2 (Fennec)

Unagi (Fx OS)

Nexus S (Fennec)

Nexus 7 (Fennec)

Nexus (Fennec)

40.40 49.80 18.00 61.00

19.38 31.75 4.00 46.00

46.11 57.78 20.00 71.00

29.38 39.63 8.00 52.00

39.80 46.60 20.00 59.00

15.88 27.63 4.00 40.00

27.11 33.89 4.00 50.00

25.75 34.13 6.00 46.00

I’ve been doing a lot of research in this area with games on Firefox OS and Fennec and it’s shown interesting results.

What we’re seeing is that the frame-rate on similarly-specced devices can differ by a significant amount when playing the same game in the same browser environment.

As a side-note; what we’re also seeing is that frame-rates are significantly better on Firefox OS than Fennec on an identical device – often in the range of 1.3 to 1.5x better.

VIEWABLE SOURCEPart of what makes the Web

A controversial potential pitfall is that of Web apps having an openly viewable source.

Viewable source on its own isn’t necessarily a pitfall, as it’s just the way the Web works, but what if you need to add some element of protection to your app assets?

There are some ways to implement types of ‘protection’, like compressing and obfuscating code, but they aren’t fool-proof.

One common technique, at least in games, is to defer protected logic to the server while embracing the openness of code on the client.

APP MANIFEST QUIRKSSimple once you know how

When using application manifests there are a few things to bear in mind.

https://developer.mozilla.org/en-US/docs/Apps/Manifest

MIME-TYPE REQUIREMENTapplication/x-web-app-manifest+json

App manifest files must be served with the application/x-web-app-manifest+json MIME-type for them to be recognised by the browser.

We’ve worked with GitHub on this and application manifests hosted using GitHub pages are automatically served with the correct type.

https://developer.mozilla.org/en-US/docs/HTML/Using_the_application_cache#Structure_of_a_cache_manifest_file

SAME ORIGIN POLICYManifest and app served from same domain

Application manifests must be served from the same origin as the application they describe.

APPCACHE IS…Not quite as bad as some make it out to be

AppCache is another technology that gets quite a bad press around perceived issues and difficulties.

I don’t believe it’s quite as bad as we make out.

MIME-TYPE REQUIREMENTtext/cache-manifest

One of the basic things that can trip people up is the MIME-type requirement for AppCache manifest files.

The manifest can have any extension but must be served with the text/cache-manifest MIME-type for the browser to recognise it.

Jake Archibald’s talk on AppCache quirks and workarounds is a fantastic resource on what to look out for with the technology.

The following are a selection of his key observations…

http://www.alistapart.com/articles/application-cache-is-a-douchebag/

FILES ALWAYS COME FROM THE APPCACHE, EVEN IF YOU’RE

ONLINE

#1

Resources in the AppCache will always be pulled from the cache, even if you’re online.

When the cached resources are updated AppCache will fire an updateready event, though you’ll need to refresh the page to see them.

The updateready event is where you’ll listen if you want to prompt the user to reload the page when updates are ready, otherwise they’ll naturally get the latest resources the next time they view your app, or the next time they navigate around your app.

THE APPCACHE ONLY UPDATES IF THE CONTENT OF THE MANIFEST

ITSELF HAS CHANGED

#2

Although AppCache lets you know when updates are ready, these updates may not work in the way you’re expecting.

What happens is that the AppCache won’t update unless the AppCache manifest itself is updated.

The reasoning for this is that the browser would otherwise have no idea which files needed updating and would have to check every single file referenced within the manifest.

The most common way to force an update to the manifest is by using a commented version number or timestamp every time you change one of the files referenced in the AppCache.

CACHE MANIFEST# 2012-12-05:v10

# Explicitly cached resourcesCACHE:appleicon.pngclasslib.js…

# Resources that require the user to be online.NETWORK:*

# Fallbacks if files cannot be foundFALLBACK:

THE APPCACHE IS AN ADDITIONAL CACHE, NOT AN ALTERNATIVE ONE

#3

When the browser updates the AppCache it requests resources as it normally would, meaning that it obeys standard cache headers.

One way this can catch you out is if you don’t serve cache headers with your resources then the browser may ‘guess’ that the resource doesn’t need to be updated and won’t request it.

Jake’s recommended workaround for this is to serve cache headers with your resources, perhaps even setting them as no-cache if you’re testing a lot.

NEVER EVER EVER FAR-FUTURE CACHE THE MANIFEST

#4

One interesting quirk with AppCache is that you can get yourself into a lot of trouble if you mess around with the caching of the manifest itself.

For example, if you set a cache header on the manifest file for it not to update in a long time, then change the URL of the manifest in your HTML document to try and force an update, then nothing will update. Ever.

The reason for this is that the user will be seeing the cached HTML document which is referencing the old manifest file, which is exactly the same as it was last time it checked, so nothing changes.

How to avoid this? Don’t rename the manifest file unless you know what you’re doing.

NON-CACHED RESOURCES WILL NOT LOAD ON A CACHED PAGE

#5

By default, any resources that you don’t reference within the AppCache manifest won’t be displayed. This is the default behaviour of AppCache.

To work around this, you can add a NETWORK section to the manifest with a * wildcard. This will make sure anything not cached will be requested from the network if online.

CACHE MANIFEST# 2012-12-05:v10

# Explicitly cached resourcesCACHE:appleicon.pngclasslib.js…

# Resources that require the user to be online.NETWORK:*

# Fallbacks if files cannot be foundFALLBACK:

“I’M NOT SAYING THAT APPLICATIONCACHE SHOULD BE

AVOIDED, IT’S EXTREMELY USEFUL.”

Jake Archibald

You may be under the assumption that AppCache isn’t ready, or is too quirky for prime-time.

I think Jake’s final words on the matter sum up how you should view his criticism of the technology.

His main point is that you should be aware of the quirks and limitations of AppCache so you can use it to it’s full potential.

AppCache Facts is another great resource on the truths behind AppCache.

http://appcachefacts.info/

WEB APP HELPERS

CROSS-PLATFORM SUPPORTTaking the sting out of things

General cross-platform support

Modernizr for feature detection

http://modernizr.com

Can I Use? for compatibility charts

http://caniuse.com

Mobile HTML5 for mobile-specific compatibility charts

http://mobilehtml5.org

WebSockets with Socket.io

Automatically falls back to long-polling if necessary.

http://socket.io/

Lawnchair for reliable local storage

Automatically selects the best storage option for each platform.

http://brian.io/lawnchair/

APPCACHE GENERATORSTaking the pain out of manifests

AppCache generators

Manifested online generator

http://manifested.dregsoft.com

manifestR bookmarklet

http://westciv.com/tools/manifestR/

Command-line approach using PhantomJS and confess.js

https://github.com/jamesgpearce/confess

My own online AppCache generator built using confess.js on the server

http://appcache.rawkes.com

TESTING APPCACHEBeing sure that it actually works

Testing AppCache

Chrome appcache-internals page

chrome://appcache-internals

Firefox about:cache

Click on “Offline cache device” when you reach the about:cache page

Charles proxy

http://www.charlesproxy.com/

Chrome developer tools network pane

Look for ‘(from cache)’ in the size column

Firefox developer tools ‘Net’ logging

Simply doesn’t display resources that have been loaded from the cache

This also works with remote debugging so you can see network logs from a Firefox OS or Fennec device…

https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko/Debugging_on_Boot_to_Gecko/Setting_up

UI BUILDING BLOCKSKeeping a consistent style

Gaia UI Building Blocks

https://github.com/mozilla-b2g/Gaia-UI-Building-Blocks

Twitter Bootstrap

http://twitter.github.com/bootstrap/

jQuery Mobile

http://jquerymobile.com/

EASING APP DEVELOPMENTTemplates and frameworks

Mortar is the recommend set of Web app templates for Firefox OS

https://github.com/mozilla/mortar

BUILD TOOLSAutomating common tasks

Volo

https://github.com/volojs/volo

Grunt

http://gruntjs.com/

HTML5 Boilerplate build script (using Grunt)

https://github.com/h5bp/node-build-script

PERFORMANCETools for analysing and optimisation

YSlow!

http://developer.yahoo.com/yslow/

PageSpeed

https://developers.google.com/speed/pagespeed/

Smush.it

http://www.smushit.com/ysmush.it/

Pngcrush

http://pmt.sourceforge.net/pngcrush/

YUI Compressor

http://developer.yahoo.com/yui/compressor/http://refresh-sf.com/yui/

UglifyJS

http://marijnhaverbeke.nl/uglifyjs

FIREFOX OS SIMULATORPerfect for testing Firefox OS apps

Firefox OS Simulator

https://addons.mozilla.org/en-US/firefox/addon/firefox-os-simulator/

FURTHER RESOURCES

Apps area on MDN

https://developer.mozilla.org/en-US/docs/Apps

Firefox Marketplace Developer Hub

https://marketplace.firefox.com/developers/

HTML5 Rocks article on mobile performance

http://www.html5rocks.com/en/mobile/optimization-and-performance/

Sam Dutton’s talk on mobile Web app performance and optimisation

http://www.samdutton.com/velocity2012/

Tasneem Sayeed’s talk on improving mobile Web app experience

http://www.slideshare.net/tasneemsayeed/developer-pitfalls-strategies-for-improving-mobile-web-developer-experience

Mobile Web app best practices from the W3C

http://www.w3.org/TR/mwabp/

@ROBHAWKES

SLIDESHARE.NET/ROBHAWKES