5. What is a Web App?
A software built with web technologies that is accessible via a mobile browser
The browser may be either
the standard device browser
or an embedded browser
(Hybrid app)
7. Setting up the Server
As usual, it all starts with an HTTP request
Then you need:
• Data
• A device detection mechanism [optional]
• The app itself
8. Data
Usually 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
9. Data
• Data can be stored in any classical way:
• Relational
• Graph
• Key-value
• Document-based
Latest trend à backend-as-a-service
10. BaaS
1. Developers build a visual model of their DB
2. The service generates APIs and client-side
libraries(compatible with Android, Windows
Phone, etc.)
3. The data produced/consumed in the app can be
pushed/pulled to their DB
• Communication is handled via REST-based
APIs
11. Example of Baas software: BaasBox
Main features:
• User management
• ACL
• Friendships
• Authentication via Facebook and Google+
• Document-based data manegement (via OrientDB)
• Assets management (fotos, documents, or files)
• Push notifications
The “Box” in BaasBox means that all the features are
in a standalone server, just like a box.
No Application Server, no Database Server, just a
JVM and nothing more
Rest API
Web
dashboard
http://www.baasbox.com/
12. Ok, but what about mobile apps?
BROWSER
<html>
<head>
<script src=” ...” />
</head>
<body>
...
NATIVE
WRAPPER
<html>
<head>
<script src=” ...” />
</head>
<body>
...
PLATFORM APIs
NATIVE
APP
01010101010101101010
1010101011011010
010101010101011101
010101010101011010
PLATFORM APIs
Native
Web
Hybrid
13. Native
http://bit.ly/GWOaP1
PRO
• Lets you create apps with rich user interfaces and/or heavy graphics
CONS
• Development Time
• Development Cost
• Ongoing Maintenance
• No portability (apps cannot be used on other platforms)
PRO
CONS
14. Examples of native apps
http://www.ea.com/it/ipad/nfs
http://www.whatsapp.com/
15. Web
http://bit.ly/GWOaP1
PRO
• Offers fast development, simple maintenance, and full application portability
• One mobile web app works on any platform
CONS
• Can’t handle heavy graphics
• Can’t access camera or push notifications
PRO
CONS
17. Hybrid
http://bit.ly/GWOaP1
PRO
• Development speed of mobile web apps
• Device access and app store distribution of native apps
CONS
• Can’t handle heavy graphics
• Requires familiarity with a mobile framework
PRO
CONS
21. My vision
Mobile web seems to be the only long-term commercially viable platform for mobile
FRAGMENTATION
THE WEB
USER EXPECTATIONS
22. When you go native there are too many platforms to be supported
FRAGMENTATION
23. The web is the only platform that:
• works across devices
• apps share the same set of standards
• the same app can work also on a desktop
THE WEB
The web is an advanced technology:
• webGL
• Local storage management
• Positioning & mapping
• Real-time data
• ...
24. Users expect things to just work
à they don’t care about what platform they have
àthey simply expect that your app will be available for their device
à YOU HAVE TO BE CROSS-PLATFORM
USER EXPECTATIONS
25. PhoneGap
You develop your app using the usual three guys
You use the same web view of the native OS
• iOS = UIWebView
• Android = android.webkit.WebView
http://phonegap.com/blog/2013/06/20/coming-soon-phonegap30
26. What is PhoneGap?
The UI layer is a web browser view
• 100% width
• 100% height
Headless web browser
• No URL bar
• No decorations
• No zooming
• No text selection
27. It looks very similar to Apache Cordova…
Adobe/Nitobi donated the PhoneGap codebase to the Apache foundation
à
wider audience and contributors
à
transparent governance
Better documentation
à
easier contributions for companies
Apache Licensing
There was only one problem....
trademark ambiguity
à CORDOVA
PhoneGap is a distribution of
Apache Cordova
29. HTML 5
HTML5 will be the new standard for HTML
HTML5 is still a work in progress
W3C final recomendation: 2020
Top browsers support many (not all) of the new HTML5 elements
http://mobilehtml5.org
http://caniuse.com
32. New Structural Tags
Main Goal: separate presentation from content
• Poor accessibility
• Unnecessary complexity
• Larger document size
Most of the presentational features from earlier versions of HTML are no longer supported
New structural tags
33. New Structural Tags
<header> header region of a page or section
<footer> footer region of a page or section
<nav> navigation region of a page or section
<section> logical region of a page
<article> a complete piece of content
<aside> secondary or related content
http://bit.ly/JCnuQJ
34. Forms
Main Goal: reduce the Javascript for validation and format management
Example:
Form input types
35. Form Input Types
Form input types degrade gracefully
à
Unknown input types are treated as text-type
http://bit.ly/I65jai
36. Audio
<audio> : a standard way to embed an audio file on a web page
<audio controls>
<source src="song.ogg" type="audio/ogg" />
<source src="song.mp3" type="audio/mpeg" />
Not Supported
</audio>
Multiple sources à the browser will use the first recognized format
Audio
37. Audio Javascript API
HTML5 provides a set of Javascript APIs for interacting with an audio element
For example:
play() pause() load() currentTime ended volume…
à http://www.w3.org/wiki/HTML/Elements/audio
38. Video
<video> : a standard way to embed a video file on a web page
<video width="320" height="240" controls>
<source src="movie.mp4" type="video/mp4" />
<source src="movie.ogg" type="video/ogg" />
Not Supported
</video>
Multiple sources à the browser will use the first recognized format
Video
39. Accelerometer
There are 4 ways to store data locally in a web app:
• Web storage
• Local Storage
• Session Storage
• WebSQL
• Indexed DB
• File System Access
Local storage and file system access
Web storage, WebSQL, and IndexedDB
conform to W3C specifications and are
provided by the browser itself
File system access API conforms to its
corresponding W3C specification
40. Web Storage
LocalStorage
stores data in key/value pairs
persists across browser sessions
SessionStorage
stores data in key/value pairs
data is erased when a browser session ends
41. WebSQL
relational DB
support for tables creation, insert, update, …
transactional
persists across browser sessions
You can perform classical SQL queries
tx.executeSql("SELECT
*
FROM
User“,
[],
function(tx,
result)
{
//
callback
code
});
42. IndexedDB
• It tries to combine Web Storage and WebSQL
• You can save data as key/value pairs
• You can define multiple DBs
• Good Performance
data is indexed
asynchronous à it does not block the UI
You can see a store as a big SQL table with only key/value pairs
à you don’t need to define a schema upfront
43. Considerations
You will likely use more than one API in combination
à Use the right API for the right job
Local Storage
• it is not transactional à race conditions
• very simple API, no schema
• only String data à performance issues for complex data due to JSON serialization
• session storage will be cleared after the app is closed
• limited quota
44. Considerations
WebSQL
• SQL-based à fast and efficient
• transactional à more robust
• asynchronous à does not block the UI
• rigid data structure à data integrity vs agility
• limited quota
45. Considerations
IndexedDB
• simple data model à easy to use
• transactional à more robust
• asynchronous à does not block the UI
• good search performance à indexed data
• data is unstructured à integrity problems
• limited quota
• not supported by every platform (e.g., iOS)
46. Geolocalization
Gets Latitude and Longitude from the user’s browser
There is also a watchPosition method wich calls a JS function every time the user moves
Geolocalization
47. Example
function getLocation() {
if(navigator.geolocation) {
navigator.geolocation.getCurrentPosition(showPosition);
} else {
console.log(‘no geolocalization’);
}
}
function showPosition(position) {
console.log(position.coords.latitude);
console.log(position.coords.longitude);
}
48. WebSockets
Bidirectional, full-duplex communication between devices and server
Specifically suited for
chat, videogames, drawings sharing, real-time info
Requires a Web Socket Server to handle the protocol
Web sockets
49. WebSockets - Overview
1. Client notifies websocket server (EventMachine) of an event, giving ids of recipients
2. The server notifies all the active clients (subscribed to that type of event)
3. Clients process event
when given recipient Id
matches the client’s one
http://bit.ly/Ixcupi
50. Alternative - Polling via AJAX
+ Near real-time updates (not purely real-time)
+ easy to implement
+ no new technologies needed
- they are requested from the client and cause increased network traffic
- AJAX requests generally have a small payload and relatively high amount of http headers
(wasted bandwith)
51. Canvas
Canvas allows you to draw anything inside the browser
http://bit.ly/Ie4HKu
http://bit.ly/LUKXkr
http://bit.ly/LULa79
http://bit.ly/LC8AgY
Canvas
52. Canvas
It uses nothing more than JavaScript and HTML
à no external plugins, no libraries, etc.
You can create lines, use images, use text, apply transformations, etc.
http://bit.ly/KsKLv1
54. Web Workers
Javascript is a single-threaded language
à If a tasks take a lot of time, users have to wait
Web Workers provide background processing capabilities to web applications
They typically run on separate threads
à apps can take advantage of multicore CPUs
Web workers
55. Web Workers
Web Workers can be used to:
• prefetch data from the Web
• perform other ahead-of-time operations to provide a much more lively UI.
Precious on mobile Web applications because of the slow network speed
56. Web Workers
Any JS file can be launched as a worker
Example of Web Worker declaration:
var worker = new Worker(“worker.js”);
In order to be independent from other workers, each worker script cannot access the DOM
57. Web Workers
The main JS script can communicate with workers via postMessage() calls:
$(‘#button’).click(function(event) {
$(‘#output’).html(“starting”);
worker.postMessage(“start”);
});
worker.onmessage = function(event) {
$(‘#output’).html(event.data);
}
58. Web Workers
The web worker script can post back messages to the main script:
onmessage = function(event) {
if(event.data === “start”) {
var result;
// do something with result
postMessage(result);
}
}
60. The killer app!
• Check console
• Breakpoints
• Update the DOM at run-time
• Access to all local DBs
• Network profiling
• CPU and memory profiling
• Monitor event listeners
• Monitor elements’ rendering time
62. Desktop Browser
• very quick
• very handy functions
• see Chrome’s Web Development Tools
• Breakpoints
PRO
• browsers’ small differences and bugs
• cannot test all mobile-specific functionalities
• you need PhoneGap shims
CONS
64. Ripple
• very quick
• can use Chrome’s Web Development Tools
• You can test PhoneGap’s API from the Desktop
• browsers’ small differences and bugs
• cannot test the interaction with external apps
PRO
CONS
It is based on Ripple, a Chrome
plugin for mobile dev
from PhoneGap 3.0.0, you need to
use the Ripple available at Apache
npm
install
-‐g
ripple-‐emulator
ripple
emulate
65. Simulator
• Officially supported by platform vendors
• You use the “real” device’s browser
PRO
• device’s performance is not considered
• this is iOS-specific
• Android’s emulator is a joke
• device’s capabilities are only simulated
CONS
66. On device
• accurate
• still handy
• real performance tests
• real browser tests
PRO
• Deployment takes some time (~6 seconds for iOS)
CONS
67. Remote Debugging
From iOS 6, Apple provided Mobile Safari with a remote web inspector
à You can debug your app by using the classical web inspector of Desktop Safari
It can connect both to
• The iOS emulator
• The real device
Since Android 4.4, this feature is
available via Chrome’s web dev kit
68. Mobile debugging reference table
Make a favor to yourself,
don’t debug craftsman way:
console.log()
+
alert()
iOS
Android
Desktop Browser
Ripple
Device/emulator
Safari Web
Inspector
X
Chrome Web
Inspector
X
69. Roadmap
Anatomy of a web app
Debugging (mobile) web apps
HTML5
Maintainable web apps
71. Introduction
We are building apps, not web sites
If your code is not structured:
• it is extremely easy that your web app becomes a
big mess of HTML + CSS + JavaScript
• maintaining each part of your app asks for a
deep analysis of ALL its aspects (logic, presentation, etc.)
• you may waste a whole day due to a missing
<
72. What we want to avoid
Imagine yourself trying to change either:
• how a movie should be rendered in your app
• the REST API providing info about movies
78. Models
Models represent your data
Each model represents a data type in your app, together with the logic surrounding it, like:
• persistence
• conversions
• validation
• computed properties
• access control
MVC: Notify their observers about their
state using the Observer pattern
81. Collections
Collections are ordered sets of models
You can:
• bind change events to be notified when any model in the collection has been modified
• listen for add and remove events
• fetch the collection from the server (or other persistence layers)
• find models or filter collections themeselves
The model attribute of a collection represents the kind of model that can be stored in it
Any event that is triggered on a model in a collection
will also be triggered on the collection directly
MVC: Notify their observers
about state using the Observer
pattern (same as models)
84. Views
Views represent and manage the visible parts of your application
They are also used to
• listen to interaction events
• and react accordingly
views can be rendered at any time, and inserted into the DOM
you get high-performance UI rendering
with as few reflows and repaints as possible
MVC: observe models, and
update itself according to the
state of the models + manage
user inputs (it’s a controller, to
this sense)
85. Example of view
Events map
“event_name selector”: callback
Events callbacks
create the
DOM subtree
87. The router
Backbone.Router
provides methods for routing client-side pages,
and connecting them to actions and events
At a minimum, a router is composed of two main parts:
routes
an hash that pairs routes to actions
actions
JS functions triggered when certain routes are navigated
89. Backbone-based workflow
• You organize your interface into logical views backed by models
• Each view can be updated independently when the model changes,
without having to redraw the page
You can bind your view‘s
render() function to the
model‘s "change” event
à
now everywhere that
model data is displayed in the
UI, it is always up to date
91. Why Require JS
We are building apps, not website
We need well-specified and isolated JS files/modules
Code complexity grows as the app gets bigger
à we need some sort of #include/import/require
à ability to load nested dependencies
92. What we want to avoid
uncontrolled scripts
poor control flow understanding
93. Require JS
RequireJS is a JavaScript file and module loader
Using a modular script loader like Require JS will improve the modularity of your code:
à speed in implementing changes
à better undestanding of the code
Require JS allows modules to be loaded as fast as possible, even out of order, but evaluated in the
correct dependency order
It is built on the Module Pattern
JavaScript file and module loader
95. Module VS script files
A module is different from a traditional script file in that it defines a well-scoped object that avoids
polluting the global namespace à its retained objects can be deleted by the GC
It can explicitly list its dependencies and get a handle on those dependencies without needing to refer to
global objects, but instead receive the dependencies as arguments to the function that defines the
module
VS
96. Module definition
Required
modules (array)
References to required modules
Dependent module usage
This function is called when
zepto.js is loaded.
If zepto.js calls define(), then
this function is not fired until
also zepto’s dependencies
have loaded
97. Require JS under the hoods...
1. loads each dependency as a script tag, using head.appendChild() and waits for all dependencies to
load
2. computes the right order in which to call the functions that define the modules
3. calls the module definition functions of each dependency in the right order
main.js
jQuery
Backbone
SpinJS
MoviesCollection
MovieModel
MoviesView
1
2
3
4
5
6
7
99. Why Handlebars
We want to separate presentation from logic
TRANSLATE TO: we don’t want to put any HTML element into JavaScript code
separate logic from presentation
Imagine yourself trying to change how a movie should be rendered in
your app...
103. Handlebars summary
Each Template can contain Expressions and Helpers operating on them
The main helpers are:
• with
• each
• if
/
else
/unless
You can define your own Helpers that operate on expressions, they return HTML code
A template can be (pre)-compiled and must be executed with a context in order to return the
final HTML fragment
104. Example of built-in helper
It renders the block if its argument is not equal to false,
undefined,
null,
[]
If / Else
<div
class="entry“>
<h1>{{title}}</h1>
{{#if
author}}
<h2>By
{{firstName}}
{{lastName}}</h2>
{{#else}}
<h2>Unknown
author</h1>
{{/if}}
</div>
{
title:
"My
first
post!",
author:
undefined
}
}
<div
class="entry“>
<h1>My
first
post!</h1>
<h2>Unknown
author</h2>
</div>
106. Combining Backbone, Require, and Handlebars
Handlebars templates can be seen as special Require modules
So we can have the following:
• a separate HTML5 file for each template
• a Backbone view can have a dependency to each template
• the template can be executed by using a JSON object of the Backbone model as context
109. I implemented all best practices and advices in this
presentation in a generic app template available here:
https://github.com/iivanoo/cordovaboilerplate
110. Towards automation…
Towards a Collaborative Framework for the Design and Development of Data-
Intensive Mobile Applications. Mirco Franzago, Ivano Malavolta, Henry Muccini.
Proceedings of the 1st ACM International Conference on Mobile Software
Engineering and Systems, June 2-3, 2014 Hyderabad, India