Anatomy of an HTML 5 mobile web app


Published on

Mobile applications Development - Lecture 8

Anatomy of an HTML 5 mobile web app


This presentation has been developed in the context of the Mobile Applications Development course at the Computer Science Department of the University of L’Aquila (Italy).

Published in: Education, Technology
  • Good Day I have an idea for a new application, just for Libya market and same time i have the buyer of it, but no knowledge how to build it. I would like to partner up with programmer or group to share everything to build a good apps. Libyan market needs and misses a lot of applications in numerous fields> As there is no competitor and the market is open We have a lot of experts in the Libyan market Contact: Amin Werfalli email: mobile: 00218925100860
    Are you sure you want to  Yes  No
    Your message goes here
  • good ppt
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Anatomy of an HTML 5 mobile web app

  1. 1. Mobile Web Apps Development Ivano Malavolta ivano.malavolta@univaq.it
  2. 2. Roadmap• Anatomy of a mobile web app• Classes of Mobile web apps• PhoneGap
  3. 3. What is a Web App?An application built with web technologies that is accessible via a mobile browser and not exclusively through an app storeThe browser may be either the standard device browser or an embedded browser (Hybrid app)
  4. 4. Anatomy of a Web App
  5. 5. Anatomy of a mobile web appThis is why HTML5 Mobile Apps are hard hard!In many cases you will need to create every part of this diagramIf you don’t create it, you still need to test and debug each piece
  6. 6. Setting up the ServerAs usual, it all starts with an http requestThen you need:• Data• A device detection mechanism [optional]• The app itself
  7. 7. DataUsually mobile apps do not talk directly with the database do not even think about JDBC, drivers, etc! They pass through an application server and communicate via: – standard HTTP requests for HTML content (eg PHP) – REST-full services (XML, JSON, etc.) – SOAP
  8. 8. Data 2• Data can be stored in any classical way: – Relational – Graph – Key-value – Document-based Latest trend: backend-as-a-service – Data storage, users management, security, big files storage, scalability, push notifications…
  9. 9. BaaS1. Developers build a visual model of their DB2. The service generates APIs and client-side libraries(compatible with iOS, Android, Windows Phone 7, etc.)3. The data produced/consumed in the app can be pushed/pulled to their DB – Communication is handled via REST or other protocols
  10. 10. Server-side device detectionAll devices are unique you have to know on which device your app is running the app can adapt to the device capabilitiesMany techniques, the most used are:• Andy Moore’s browser detector – Works for PHP pages only• Javascript if (navigator.userAgent.match(/AppleWebKit/i) && navigator.userAgent.match(/Mobile/i)) {• External APIs window.location.replace(/path/to/iphone/site/); – (DeviceAtlas, WURFL) @media screen and (max-width: 980px) {• CSS3 media queries }
  11. 11. The HTML5 appKeep code very semanticKeep all the logic in JavascriptKeep (most of) the presentation in CSS3Remember that the user may go offline• Offline data storage, cache manifestProgressive Enhancement Write all your markup first without any CSS or JavascriptThe resulting markup should always be perfectly usable in its lowest form.
  12. 12. Progressive EnhancementKey concept. Graceful degradation
  13. 13. Progressive Enhancement Techniques• Always code your markup semantically – ensure that the page is always usable, even with no stylesheet• Have a device plan – Know which device classes you intend to support before you start to code• Have both your LCD and high-end device designs before high- you begin to code – Try to visualize a way to create both versions from one code base.• Test on different mobile devices from the beginning – your incremental work must display correctly in the intended devices• If you plan to add a desktop layer, always create the mobile version first
  14. 14. Anatomy of a Web App
  15. 15. Cache ManifestProblem.Problem Browsers have their own caches but they are unreliable and heterogenousThe Application Cache allows a developer to specify which files the browser should cache and make available to offline users CACHE MANIFEST /main/features.js /main/settings/index.css http://files/images/scene.jpg http://files/images/world.jpg
  16. 16. Cache ManifestA cache manifest gives you the following benefits:• Offline browsing – users can navigate your full site when theyre offline• Speed – cached resources are local, and therefore load faster• Reduced server load – the browser will only download resources from the server that have changedThis solution does not cover dynamic data caching In that case you can use javascript to get your data
  17. 17. Javascript
  18. 18. Hybrid ScriptsThese scripts bridge the gap between your core scripts and the device SDK – A necessary step if you plan to ship your HTML5 app in a native wrapper like a standard iOS UIWebView or Cordova – They may need to be distinct for each platform you plan to support • For example, the cordova.js file for Android is subtly different from the iOS’s one
  19. 19. Core ScriptsThe common components of your app – they implement the internal logic that your app will require to assemble and render your HTML5 pages – they will be the same in every platform – examples of duties: • REST API access • Domain entities representation • … – they include also JS libraries like JQuery and other microframeworks
  20. 20. Device ScriptsThey work to emulate native behaviors of the device with Javascript – these scripts may be unique to each platform you plan to support – examples: • JQueryMobile (JS part) • JQTouch (JS part) • SenchaTouch (JS part) • iui-js
  21. 21. A note on Mobile Web FrameworksFrameworks like JQueryMobile, JQTouch are useful since they give you the standard visual language the user is accustom to out-of-the-boxHowever, evaluate carefully what framework you need, you may have issues about: – performance (the UI may get slow) – stability, debuggability – customization problems (you may be forced in doing everything the framework-way) – your app may look like many others
  22. 22. CSS3
  23. 23. Device ThemesThe presentation elements that will be required to mimic the platform aesthetic – it may be unique to each platform you plan to support – examples: • Sencha Touch (CSS) • JQueryMobile (CSS) • …
  24. 24. Core ThemesThe presentation elements you use independently from the app and platform – Keep presentation essentials as a unique stylesheet that will serve as your core theme – They are the elements that should always be the same regardless of what platform you use – Examples: • Resets • Toolbar colors • Layouts • Typography • …
  25. 25. App ThemesThe presentation elements that are specific to your app – Basically, they are similar to a core theme, but they are specific to an app – Examples: • Logos • Toolbar colors • Layouts • Typography • …
  26. 26. Roadmap• Anatomy of a mobile web app• Classes of Mobile web apps• PhoneGap
  27. 27. Classes of Mobile Web AppsA mobile web app will always be limited to the capabilities of the browser and device availableThis environment cannot be assured at the time of developmentThe following classes of development can help to prioritize design and development effort
  28. 28. Class 1It uses the latest innovations and capabilities present only in the iPhone (3GS and higher, iPod touch 4th Gen, iPad) and Android 4.0Examples: Facebook for iPhone Flipboard for iPhone
  29. 29. Class 1Advantages• Best possible mobile experience• Complex user interfaces, animations is possible• Limited access to device features is possible• The user experience can be very close, and in some cases on par with native iPhone apps• Fixed headers and footers are possible with JavascriptDisadvantages• They do not have backward compatibility and do not support other platforms• Complex Javascript is required for data integration and is difficult to debug
  30. 30. Class 2It supports high-end WebKit browsers with devices high- that have at least 1Ghz processorsIt supports all iOS devices,2.2+ Android devices, WP 7.5Example: Instagram for Android 2.3
  31. 31. Class 2Advantages• Complex user interfaces are possible• Support the majority of high-end smartphones on the marketplace• Has limited backward compatibilityDisadvantages• Use of animations are processor and battery intensive (Javascript-based animation needs to be used instead of CSS, or animations need to be omitted altogether)• Cannot use fixed footers and headers• Complex javascript can be required for data integration and is difficult to debug
  32. 32. Class 3It has the highest degree of smartphone device compatibility, compatibility provides high quality user experience, as well as supporting higher and lower classesIt supports all iOS devices, all Android devices, WP BlackBerry Torch
  33. 33. Class 3Advantages• Supports the majority of devices, but not all• Provides a quality user experience on more capable browsers, and degrades to lessor devicesDisadvantages• Cannot support animations or screen transitions• Cannot support fixed header or footer• Limited javascript support
  34. 34. Class 4It is designed with compatibility in mind, seeking to have the best possible user experience across the widest number of devices Any mobile web app looking to have the maximum cross platform support, should look no further support than a Class 4 experienceIt is more website than web app
  35. 35. Class 4Advantages• Support the largest number of handsets• Is simple to design and develop• Is simple to deployDisadvantages• Requires significant Quality Assurance time
  36. 36. Universal AppIt is an experience that is built for multiple device contexts, contexts but with a single source of contentSometimes referred to as Responsive Web DesignWarning. In this case the user experience is driven by technological constraints, not user needsWarning. This approach is something that has proven unsuccessful with most mobile platforms and applications
  37. 37. Universal AppAdvantages• Support mobile devices from a single code base• Based in web standards• Increases accessibility and Search Engine Optimization (SEO)• Data integration is very simpleDisadvantages• Must be designed for maximum device compatibility (Lower Common Denominator or LCD-based Design)• Does not address the users context• Most websites are not designed to be “universal” and need to be refactored from scratch
  38. 38. Browsers ClassesWe can look at mobile experiences also w.r.t. the browsers capabilities
  39. 39. Roadmap• Anatomy of a mobile web app• Classes of Mobile web apps• PhoneGap
  40. 40. PhoneGap• Conceptual Overview• Phonegap Development Guidelines
  41. 41. PhoneGap VS CordovaAdobe/Nitobi donated the PhoneGap codebase to the Apache foundation – wider audience and contributors Phonegap is a – Transparent governance distribution of • Better documentation Apache Cordova – Easier contributions for companies • Apache Licensing There was only one problem: trademark ambiguity CORDOVA
  42. 42. PhoneGap The UI layer is a web browser view – 100% width – 100% heightThis is a web browser Headless web browser instance – No URL bar – No chrome – No window decorations – No zooming – No text selection
  43. 43. PhoneGapYou develop your app using• HTML• CSS• JavascriptYou use the same web view of the native OS – iOS = UIWebView – Android = android.webkit.WebView
  44. 44. PhoneGap API Allows you to access native OS functionality using JavaScript you develop your app using web technologies and PhoneGap handles communication with the native OS
  45. 45. PhoneGap API API providerWebView app for Android API provider for iOS PhoneGap Javascript API provider for Windows Phone API provider for Blacberry PhoneGap
  46. 46. PhoneGap API
  47. 47. PhoneGap API on iOS - general idea1. the native web views have events/notifications whenever the url/address is changed2. cordova.js parses messages into strings and puts them as the source URL inside a hidden IFrame element3. This navigation action is intercepted on the native layer and converted to a native object, and the default navigation action is blocked4. The string is parsed and a native code operation is performed5. The native layer writes back to the web view layer by executing javascript strings
  48. 48. Recurrent App Architecture The app acts as a client for user interaction The app communicates with an application server to receive data The application server handles business logic and communicates with a back-end data repository back-
  49. 49. The AppIt generally uses the single-page application model single- • the application logic is inside a single HTML page • This page is never unloaded from memory • Data will be displayed by updating the HTML DOM • Ex. Using JQuery • data is retrieved from the application server using AJAX
  50. 50. The Application ServerIt is a classical web server – server-side scripting language such as Java, .NET, PHP, etc… server- – communication can be based on: • standard HTTP requests for HTML content • REST-ful services (XML, JSON, etc.) • SOAP – It performs business logic and generally gets or pushes logic, data from a separate data repository
  51. 51. The Back-end RepositoryIt may be: – a standard DB (usually deployed in the same machine of the application server) – an external API (see Both application server and back-end repository can be provided as a service BaaS
  52. 52. Features Coverage
  53. 53. PhoneGap Plugins Sometimes PhoneGap is not enough as is for our purposes • Unsupported feature • heavyweight data processing is faster in native code – ex. images manipulation • background processing is better handled natively – ex. Files sync • complex business logic You need to develop a PhoneGap plugin
  54. 54. PhoneGap PluginsPurpose.Purpose. To expose a Phone native functionality to the browserThis is done by developing – a Custom Native Component Different for each platform – a Custom Javascript API It should be always the same
  55. 55. PhoneGap Plugins
  56. 56. PhoneGap• Conceptual Overview• Phonegap Development Guidelines
  57. 57. Project Structure If your app gets complex, you may prefer to use the structure presented in the Anatomy of a HTML5 web app part of this lecture
  58. 58. Page Structure• Place all CSS stylesheets at the beginning – allows the page to render progressively – avoids flickering• Place all JS scripts that do not affect page layout at the end – every script must be parsed before it can be used – they block parallel downloads
  59. 59. Images and Style• First of all, avoid images when possible – you may use CSS gradiends, effects, etc.• Try to avoid advanced CSS properties – for example, text-shadow and box-shadow, opacity• Use touch events, instead of onClick – onClick may take up to 500ms to execute!
  60. 60. Text Management• If the input is numeric, open up only the numeric keyboard – The same holds for email, websites, ecc. <input type="text" pattern="[0-9]*" value="numeric" />• Disable user selection <style> *{ -webkit-touch-callout: none; -webkit-user-select: none; } </style>
  61. 61. CSS Hardware AccelerationWhen you use webkit- -webkit-transformyou have to use translate3d(x,y,z translate3d(x,y,z) x,y,z)instead of using translate(x,y)In iOS, the last instruction is not HW-accelerated
  62. 62. ScrollingI you want to scroll only a portion of your view, you should use this library – fixed header and footer, with scrollable content – scrollable sub-views with fixed description below
  63. 63. FrameworksJQueryMobile, JQuery, Backbone, etc. are beautiful tools…However they may impact the performance of your app Use a framework only when it is necessary – Don’t use JQuery only because of the $() syntax!Solution• build your own micro-framework• cut out PhoneGap plugins you do not use• use micro-frameworks (
  64. 64. References Chapters 11-12