Anatomy of an HTML 5 mobile web app
Upcoming SlideShare
Loading in...5
×
 

Anatomy of an HTML 5 mobile web app

on

  • 3,948 views

Mobile applications Development - Lecture 8 ...

Mobile applications Development - Lecture 8

Anatomy of an HTML 5 mobile web app

PhoneGap

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).

http://www.di.univaq.it/malavolta

Statistics

Views

Total Views
3,948
Views on SlideShare
3,947
Embed Views
1

Actions

Likes
5
Downloads
187
Comments
1

1 Embed 1

http://us-w1.rockmelt.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • good ppt
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Anatomy of an HTML 5 mobile web app Anatomy of an HTML 5 mobile web app Presentation Transcript

  • Mobile Web Apps Development Ivano Malavolta ivano.malavolta@univaq.ithttp://www.di.univaq.it/malavolta
  • Roadmap• Anatomy of a mobile web app• Classes of Mobile web apps• PhoneGap
  • 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)
  • Anatomy of a Web App
  • 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
  • Setting up the ServerAs usual, it all starts with an http requestThen you need:• Data• A device detection mechanism [optional]• The app itself
  • 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
  • Data 2• Data can be stored in any classical way: – Relational – Graph – Key-value – Document-based www.parse.com www.kinvey.com Latest trend: backend-as-a-service – Data storage, users management, security, big files storage, scalability, push notifications…
  • 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
  • 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 }
  • 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.
  • Progressive EnhancementKey concept. Graceful degradation
  • 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
  • Anatomy of a Web App
  • 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
  • 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
  • Javascript
  • 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
  • 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
  • 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
  • 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
  • CSS3
  • 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) • …
  • 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 • …
  • 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 • …
  • Roadmap• Anatomy of a mobile web app• Classes of Mobile web apps• PhoneGap
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Class 4Advantages• Support the largest number of handsets• Is simple to design and develop• Is simple to deployDisadvantages• Requires significant Quality Assurance time
  • 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
  • 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
  • Browsers ClassesWe can look at mobile experiences also w.r.t. the browsers capabilities
  • Roadmap• Anatomy of a mobile web app• Classes of Mobile web apps• PhoneGap
  • PhoneGap• Conceptual Overview• Phonegap Development Guidelines
  • 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
  • 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
  • PhoneGapYou develop your app using• HTML• CSS• JavascriptYou use the same web view of the native OS – iOS = UIWebView – Android = android.webkit.WebView
  • 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 OShttp://bit.ly/HBPPY5
  • PhoneGap API API providerWebView app for Android API provider for iOS PhoneGap Javascript API provider for Windows Phone API provider for Blacberry PhoneGap
  • PhoneGap API
  • 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
  • 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-http://bit.ly/HBPPY5
  • 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
  • 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
  • The Back-end RepositoryIt may be: – a standard DB (usually deployed in the same machine of the application server) – an external API (see www.programmableweb.com) Both application server and back-end repository can be provided as a service BaaS
  • Features Coverage
  • 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 pluginhttp://wiki.phonegap.com/w/page/36752779/PhoneGap%20Plugins
  • 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
  • PhoneGap Plugins
  • PhoneGap• Conceptual Overview• Phonegap Development Guidelines
  • 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
  • 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
  • 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!
  • 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>
  • 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
  • ScrollingI you want to scroll only a portion of your view, you should use this library http://cubiq.org/iscrollExamples: – fixed header and footer, with scrollable content – scrollable sub-views with fixed description below
  • 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 (http://microjs.com)
  • Referenceshttp://www.tricedesigns.com/http://pinchzoom.com/http://hiediutley.com/ Chapters 11-12