Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mobile App Development - Pitfalls & Helpers


Published on

Published in: Technology
  • Be the first to comment

Mobile App Development - Pitfalls & Helpers

  1. 1. PITFALLS AND HELPERS Mobile HTML5 Applications
  2. 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. 3. I’m also British, if you hadn’t already guessed.Photo:
  4. 4. I’m not going to go into anything in too much detail, however I’ve included links within the slides where necessary soyou can get further information.The slides are on my Slideshare account. I’ll put the link up at the end.
  6. 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 arecertainly 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 ofsetTimeout as it puts the browser in control of when to draw things. If the application is in the background thennothing will draw, saving battery.You can also use things like the Battery API to intelligently degrade functionality as energy levels decrease.
  7. 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 applicationmanifests 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 andfeature detection when using functionality that may not be fully supported everywhere.
  8. 8. CHANGING SPECS Some APIs are in fluxRelated 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’salways a good idea to keep an eye on APIs and technologies that are known to be in a non-finalised state – theymight change.One recent example is WebSockets, around a year ago the WebSockets spec changed in a way that broke all existingimplementations. It was necessary, but it meant that developers who didn’t update their code had their appssuddenly break when the browsers dropped support for the older WebSockets APIs.
  9. 9. DIFFERING PERFORMANCE Similar spec hardware, different resultsIf you are developing anything that is vaguely intensive, like a game, you’ll have noticed massive differences inperformance 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 expectedto differ.
  10. 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.00I’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 playingthe 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 anidentical device – often in the range of 1.3 to 1.5x better.
  11. 11. VIEWABLE SOURCE Part of what makes the WebA 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 addsome element of protection to your app assets?There are some ways to implement types of ‘protection’, like compressing and obfuscating code, but they aren’tfool-proof.One common technique, at least in games, is to defer protected logic to the server while embracing the openness ofcode on the client.
  12. 12. APP MANIFEST QUIRKS Simple once you know howWhen using application manifests there are a few things to bear in mind.
  13. 13. MIME-TYPE REQUIREMENT application/x-web-app-manifest+jsonApp manifest files must be served with the application/x-web-app-manifest+json MIME-type for them to berecognised by the browser.We’ve worked with GitHub on this and application manifests hosted using GitHub pages are automatically served withthe correct type.
  14. 14. SAME ORIGIN POLICY Manifest and app served from same domainApplication manifests must be served from the same origin as the application they describe.
  15. 15. APPCACHE IS… Not quite as bad as some make it out to beAppCache 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. 16. MIME-TYPE REQUIREMENT text/cache-manifestOne 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 torecognise it.
  17. 17. Jake Archibald’s talk on AppCache quirks and workarounds is a fantastic resource on what to look out for with thetechnology.The following are a selection of his key observations…
  18. 18. #1 FILES ALWAYS COME FROM THE APPCACHE, EVEN IF YOU’RE ONLINEResources 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 thepage to see them.The updateready event is where you’ll listen if you want to prompt the user to reload the page when updates areready, otherwise they’ll naturally get the latest resources the next time they view your app, or the next time theynavigate around your app.
  19. 19. #2 THE APPCACHE ONLY UPDATES IF THE CONTENT OF THE MANIFEST ITSELF HAS CHANGEDAlthough 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 haveto 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 timestampevery time you change one of the files referenced in the AppCache.
  20. 20. 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:
  21. 21. #3 THE APPCACHE IS AN ADDITIONAL CACHE, NOT AN ALTERNATIVE ONEWhen the browser updates the AppCache it requests resources as it normally would, meaning that it obeys standardcache 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 themas no-cache if you’re testing a lot.
  22. 22. #4 NEVER EVER EVER FAR-FUTURE CACHE THE MANIFESTOne interesting quirk with AppCache is that you can get yourself into a lot of trouble if you mess around with thecaching 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 ofthe 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 manifestfile, 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. 23. #5 NON-CACHED RESOURCES WILL NOT LOAD ON A CACHED PAGEBy default, any resources that you don’t reference within the AppCache manifest won’t be displayed. This is thedefault behaviour of AppCache.To work around this, you can add a NETWORK section to the manifest with a * wildcard. This will make sure anythingnot cached will be requested from the network if online.
  24. 24. 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:
  25. 25. “I’M NOT SAYING THAT APPLICATIONCACHE SHOULD BE AVOIDED, IT’S EXTREMELY USEFUL.” Jake ArchibaldYou 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 fullpotential.
  26. 26. AppCache Facts is another great resource on the truths behind AppCache.
  28. 28. CROSS-PLATFORM SUPPORT Taking the sting out of thingsGeneral cross-platform support
  29. 29. Modernizr for feature detection
  30. 30. Can I Use? for compatibility charts
  31. 31. Mobile HTML5 for mobile-specific compatibility charts
  32. 32. WebSockets with Socket.ioAutomatically falls back to long-polling if necessary.
  33. 33. Lawnchair for reliable local storageAutomatically selects the best storage option for each platform.
  34. 34. APPCACHE GENERATORS Taking the pain out of manifestsAppCache generators
  35. 35. Manifested online generator
  36. 36. manifestR bookmarklet
  37. 37. Command-line approach using PhantomJS and confess.js
  38. 38. My own online AppCache generator built using confess.js on the server
  39. 39. TESTING APPCACHE Being sure that it actually worksTesting AppCache
  40. 40. Chrome appcache-internals pagechrome://appcache-internals
  41. 41. Firefox about:cacheClick on “Offline cache device” when you reach the about:cache page
  42. 42. Charles proxy
  43. 43. Chrome developer tools network paneLook for ‘(from cache)’ in the size column
  44. 44. Firefox developer tools ‘Net’ loggingSimply doesn’t display resources that have been loaded from the cacheThis also works with remote debugging so you can see network logs from a Firefox OS or Fennec device…
  45. 45. UI BUILDING BLOCKS Keeping a consistent style
  46. 46. Gaia UI Building Blocks
  47. 47. Twitter Bootstrap
  48. 48. jQuery Mobile
  49. 49. EASING APP DEVELOPMENT Templates and frameworks
  50. 50. Mortar is the recommend set of Web app templates for Firefox OS
  51. 51. BUILD TOOLSAutomating common tasks
  52. 52. Volo
  53. 53. Grunt
  54. 54. HTML5 Boilerplate build script (using Grunt)
  55. 55. PERFORMANCETools for analysing and optimisation
  56. 56. YSlow!
  57. 57. PageSpeed
  58. 58. Smush.it
  59. 59. Pngcrush
  60. 60. YUI Compressor
  61. 61. UglifyJS
  62. 62. FIREFOX OS SIMULATOR Perfect for testing Firefox OS appsFirefox OS Simulator
  64. 64. Apps area on MDN
  65. 65. Firefox Marketplace Developer Hub
  66. 66. HTML5 Rocks article on mobile performance
  67. 67. Sam Dutton’s talk on mobile Web app performance and optimisation
  68. 68. Tasneem Sayeed’s talk on improving mobile Web app experience
  69. 69. Mobile Web app best practices from the W3C