Downloaded 37 times
Uploaded byRobin Hawkes
Mobile App Development - Pitfalls & Helpers
Rob Hawkes discusses various pitfalls and helpers for mobile HTML5 applications. Some key pitfalls include hardware limitations on mobile devices, differing browser support for web APIs and manifests, changing specifications, and differing performance across devices. Helpers include tools for cross-platform support like Modernizr, Can I Use?, and Socket.io, AppCache generators, UI frameworks like Gaia and Bootstrap, build tools like Grunt and Volo, and performance tools like YSlow and PageSpeed. The Firefox OS simulator can help with testing apps on Firefox OS.
More Related Content
Similar to Mobile App Development - Pitfalls & Helpers
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Mobile App Development - Pitfalls & Helpers
- 1. PITFALLS AND HELPERS Mobile HTML5 Applications
- 2. My name isRob 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 goingto 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.
- 5.
- 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 talkon 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 SAYINGTHAT 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 isanother great resource on the truths behind AppCache. http://appcachefacts.info/
- 27.
- 28. CROSS-PLATFORM SUPPORT Taking the sting out of things General cross-platform support
- 29. Modernizr for featuredetection http://modernizr.com
- 30. Can I Use?for compatibility charts http://caniuse.com
- 31. Mobile HTML5 formobile-specific compatibility charts http://mobilehtml5.org
- 32. WebSockets with Socket.io Automaticallyfalls back to long-polling if necessary. http://socket.io/
- 33. Lawnchair for reliablelocal storage Automatically selects the best storage option for each platform. http://brian.io/lawnchair/
- 34. APPCACHE GENERATORS Taking the pain out of manifests AppCache generators
- 35.
- 36.
- 37. Command-line approach usingPhantomJS and confess.js https://github.com/jamesgpearce/confess
- 38. My own onlineAppCache generator built using confess.js on the server http://appcache.rawkes.com
- 39. TESTING APPCACHE Being sure that it actually works Testing AppCache
- 40.
- 41. Firefox about:cache Click on“Offline cache device” when you reach the about:cache page
- 42.
- 43. Chrome developer toolsnetwork pane Look for ‘(from cache)’ in the size column
- 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
- 45. UI BUILDING BLOCKS Keeping a consistent style
- 46. Gaia UI BuildingBlocks https://github.com/mozilla-b2g/Gaia-UI-Building-Blocks
- 47.
- 48.
- 49. EASING APP DEVELOPMENT Templates and frameworks
- 50. Mortar is therecommend set of Web app templates for Firefox OS https://github.com/mozilla/mortar
- 51.
- 52.
- 53.
- 54. HTML5 Boilerplate buildscript (using Grunt) https://github.com/h5bp/node-build-script
- 55. PERFORMANCE Tools for analysingand optimisation
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62. FIREFOX OS SIMULATOR Perfect for testing Firefox OS apps Firefox OS Simulator https://addons.mozilla.org/en-US/firefox/addon/firefox-os-simulator/
- 64.
- 65. Apps area onMDN https://developer.mozilla.org/en-US/docs/Apps
- 66. Firefox Marketplace DeveloperHub https://marketplace.firefox.com/developers/
- 67. HTML5 Rocks articleon mobile performance http://www.html5rocks.com/en/mobile/optimization-and-performance/
- 68. Sam Dutton’s talkon mobile Web app performance and optimisation http://www.samdutton.com/velocity2012/
- 69. Tasneem Sayeed’s talkon improving mobile Web app experience http://www.slideshare.net/tasneemsayeed/developer-pitfalls-strategies-for-improving-mobile-web-developer- experience
- 70. Mobile Web appbest practices from the W3C http://www.w3.org/TR/mwabp/
- 71.