2. 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.
3. I’m also British, if you hadn’t already guessed.
Photo: http://www.flickr.com/photos/beto_frota/3232254956
4. 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.
6. HARDWARE LIMITATIONS
Memory, 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.
7. DIFFERING BROWSER SUPPORT
WebAPIs, 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.
8. CHANGING SPECS
Some 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.
9. DIFFERING PERFORMANCE
Similar 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.
10. Average Average Lowest Highest
Device
Min FPS Max FPS FPS FPS
Otoro (Fx OS) 40.40 49.80 18.00 61.00
Otoro (Fennec) 19.38 31.75 4.00 46.00
SGS2 (Fx OS) 46.11 57.78 20.00 71.00
SGS2 (Fennec) 29.38 39.63 8.00 52.00
Unagi (Fx OS) 39.80 46.60 20.00 59.00
Nexus S (Fennec) 15.88 27.63 4.00 40.00
Nexus 7 (Fennec) 27.11 33.89 4.00 50.00
Nexus (Fennec) 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.
11. VIEWABLE SOURCE
Part 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.
12. APP MANIFEST QUIRKS
Simple 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
13. MIME-TYPE REQUIREMENT
application/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
14. SAME ORIGIN POLICY
Manifest and app served from same domain
Application manifests must be served from the same origin as the application they describe.
15. 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.
16. MIME-TYPE REQUIREMENT
text/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.
17. 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/
18. #1
FILES ALWAYS COME FROM THE
APPCACHE, EVEN IF YOU’RE
ONLINE
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.
19. #2
THE APPCACHE ONLY UPDATES IF
THE CONTENT OF THE MANIFEST
ITSELF HAS CHANGED
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.
20. CACHE MANIFEST
# 2012-12-05:v10
# Explicitly cached resources
CACHE:
appleicon.png
classlib.js
…
# Resources that require the user to be online.
NETWORK:
*
# Fallbacks if files cannot be found
FALLBACK:
21. #3
THE APPCACHE IS AN ADDITIONAL
CACHE, NOT AN ALTERNATIVE ONE
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.
22. #4
NEVER EVER EVER FAR-FUTURE
CACHE THE MANIFEST
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.
23. #5
NON-CACHED RESOURCES WILL
NOT LOAD ON A CACHED PAGE
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.
24. CACHE MANIFEST
# 2012-12-05:v10
# Explicitly cached resources
CACHE:
appleicon.png
classlib.js
…
# Resources that require the user to be online.
NETWORK:
*
# Fallbacks if files cannot be found
FALLBACK:
25. “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.
26. AppCache Facts is another great resource on the truths behind AppCache.
http://appcachefacts.info/
44. 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
67. HTML5 Rocks article on mobile performance
http://www.html5rocks.com/en/mobile/optimization-and-performance/
68. Sam Dutton’s talk on mobile Web app performance and optimisation
http://www.samdutton.com/velocity2012/
69. Tasneem Sayeed’s talk on improving mobile Web app experience
http://www.slideshare.net/tasneemsayeed/developer-pitfalls-strategies-for-improving-mobile-web-developer-
experience
70. Mobile Web app best practices from the W3C
http://www.w3.org/TR/mwabp/
