HTML5, KnockoutJS, Phonegap VS

Sviluppo Nativo Quando si e quando no?

Sviluppare applicazioni per dispositivi mobili con particolare attenzione agli standard per l’interoperabilità

Ing. Davide Senatore [Microsoft MVP]

Ingenium s.a.s.

Wikisticker RELIVE YOUR TIME

Agenda

• Building on standard from the ground up

• Tools and HTML5: ubiquitous language?

• Javascript: dynamic and modern or ancient and cumbersome?

• KnockoutJS: MVVM Framework On-The-Web

• Phonegap AKA Cordova project: pack your app!

• Native development: big effort!

• Two apps: Healthcare Manager and Wikisticker

• Pros & Cons

• Closing and Q&A

Obiettivo

Consumer

Massima diffusione della nostra App

Business

Massima flessibilità della nostra App

Standard • Progettare un ottimo back-end per le

nostre app • È necessario per proteggere

l’investimento

• Si deve basare su tecnologie web standard • REST, JSON, HTTP

• L’approccio KISS resta il migliore • Oauth, integrazione con i grandi player (FB, Twitter, g+)

• Simple plain API • Riusabile – Semplice – Atomica - Interoperabile

soluzioni proprietarie possono rivelarsi sgradevoli…

Standard is better!

Tools & HTML5 • HTML5

• In DRAFT, ma sempre più diffuso

• Risultati a portata di mano

• Non è più un linguaggio web-only

• Tools

• Sempre più potenti

• Rispettano ed aiutano lo sviluppatore

• Qualunque sia la «provenienza» dello sviluppatore ci sono degli IDE di alto livello per sviluppare Mobile Apps in HTML5

L’uso di HTML5 ci assicura una portabilità delle interfacce su

più piattaforme client (Web, iPhone, Android, Windows Phone)

Javascript

• Javascript è un linguaggio • Potente

• Flessibile

• Standard

• È anche «odiato» da molti sviluppatori, in quanto in passato si è rivelato uno scoglio molto difficile, ma… • I tools sono migliorati

• Il debug è oggi possibile

• Un numero sempre maggiore di framework (server e client) sono sviluppati in javascript

• La programmazione web (client) è 100% Javascript

Conoscere Javascript è una necessità

MVVM: il fuoco dello sviluppo • Il pattern MVVM è un presentation

pattern • Permette di semplificare e

disaccoppiare lo sviluppo delle parti componenti un client

• KnockoutJS implementa MVVM con javascript

• KnockoutJS è un ottimo strumento perché:

• Può essere utilizzato nel web, in simbiosi con altri framework

• Può essere utilizzato nello sviluppo mobile, e si integra alla perfezione con framework complessi tipo JQueryMobile

• È *DAVVERO* multipiattaforma essendo basato su standard

MVVM: come funziona?

Presentation Layer (HTML5)

ViewModel Layer (Javascript)

Model Layer (Javascript)

SQLite Objects Web

services

Phonegap: pack your app!

• Sviluppare con un unico codebase

• Fare deploy su più piattaforme

• Impiegare un builder «in the cloud»

• Tutto questo è possibile, con Phonegap!

• Phonegap nasce per colmare il divario tra le varie piattaforme «mobile», uniformando lo sviluppo e permettendo

• Utilizzo di tools moderni per lo sviluppo (jquery/HTML5/KOJS/JQM)

• Riuso di conoscenze già acquisite nello sviluppo web

Write ONCE deploy EVERYWHERE…

…non va sempre così bene!

Bridge the Gap

• L’idea di PhoneGap:

• Sviluppare app in HTML5+JS

• Utilizzare una libreria specializzata per ogni piattaforma che faccia da «bridge» tra l’HTML5+CSS3+JS ed il dispositivo

• In pratica si tratta di un proxy

• Dal nostro codice JS, tramite questo proxy, abbiamo accesso a tutte (o quasi) le caratteristiche del nostro dispositivo

Native Development • Lo sviluppo nativo consiste nell’ uso

delle tecnologie e dei linguaggi di sviluppo proprietarie delle varie piattaforme

• iOS Objective-c

• Android Java

• Windows Phone C#

• Per che piattaforma la sviluppiamo? • Windows Phone 7, iPhone, Android, BlackBerry?

• Risposta: PER TUTTE LE PIATTAFORME • Strategia: armonizzare e standardizzare la parte «in comune» tra le

varie piattaforme, ovvero la parte dei servizi (almeno il 50% del valore del nostro investimento)

Se sviluppiamo in nativo avremo bisogno di un client diverso per ogni piattaforma!

The big effort of native dev • Per ottenere alcuni risultati

• È NECESSARIO andare in nativo!

• Ci sono determinate classi ci applicazioni che non conviene sviluppare in HTML5

• Un esempio fra tutti: applicazioni di realtà aumentata

• Necessitiamo di un «contatto» diretto con le funzionalità HW del dispositivo

• Dobbiamo ottimizzare le routine, per offrire un’esperienza migliore

• Questo può costare molto, in quanto ci costringe ad avere (minimo) tre team di sviluppo per ottenere risultati accettabili

Prima di scegliere il nativo, valutare se gli stessi risultati si possono raggiungere con un’app multipiattaforma

Alcuni esempi di App

• Come esempio possiamo parlare di quattro applicazioni, due sviluppate in HTML5, le altre in modalità nativa

• Healthcare manager (HTML5)

• Gymmit (HTML5+Nativa)

• Wikisticker (Nativa)

Healthcare Manager

• Healthcare Manager è un’app per tablet Android che serve per raccogliere dati di pazienti sul campo

• HTML5+Javascript+KnockoutJS+PhoneGap e DB SqlLite

• È stata sviluppata in multipiattaforma perché il committente aveva tablet Android, ma altri clienti potrebbero avere iPad

• L’app funziona in modalità offline e l’utilizzo di DB SQLite permette di essere ancora una volta multipiattaforma

• È un’app di tipo «gestionale» con menu, composizione di documenti, raccolta dati con lookup, selezione da liste, ricerche

Gymmit

• Gymmit, il social network dello sport e degli sportivi

• due app, che sono state sviluppate sullo stesso back end

• Una multipiattaforma, per iPhone e Android

• Una nativa, per Windows Phone

• Le app servono per trovare palestre, campi da tennis etc.

• Consultare i calendari corsi delle strutture

• Effettuare prenotazioni

Wikisticker

• Wikisticker è un’app di geo-messaging in realtà aumentata. Permette di lasciare dediche, messaggi o avvisi geolocalizzati, fruibili in realtà aumentata.

• In pratica consente di vedere questi avvisi come se ci fluttuassero attorno

• Nella versione 2.0 permette di lasciare anche foto ricordo o messaggi audio e di linkare contenuti direttamente nello spazio

• È stata sviluppata con

• Back-end multipiattaforma basato su standard

• Client nativo Windows Phone

• Client nativo Android (correntemente in sviluppo)

• Completamente multilingua

Interoperable back-end: Pro & Cons • Pro

• Scrivo il back end e lo riutilizzo su tutte le piattaforme

• Posso utilizzare qualunque linguaggio o piattaforma per crearlo, a patto di interloquire mediante standard

• Leggero e impegna poca banda, importante per servizi con grande traffico

• Contro

• Richiede uno sforzo progettuale maggiore

• È necessario pensarlo come scenario request-response con serializzazione di classi POCO/POJO

• Richiesto un Versioning rigoroso per accordare tutte le piattaforme

Multiplatform Client: Pro & Cons • Pro

• Strumenti di sviluppo allo stato dell’arte (VS2012, Dreamweaver,IntellijIDEA etc.)

• Sviluppo unificato, il limite è la fantasia dei grafici • Disponibilità di plugin di qualsiasi tipo (jQuery etc) • Molti framework disponibili (jQueryMobile) • Interfaccia condivisa tra le varie piattaforme • Costo ridotto (rispetto alle app native) • Qualunque developer WEB è un developer di Hybrid App

• Contro • Non sfrutta completamente le peculiarità di ogni device • Inadatte per CPU intensive app (performance) • Non rispettano le guidelines di ogni piattaforma (vedi Metro) • Dipendono essenzialmente dalla bontà del browser del device • Interfaccia unica per tutte le piattaforme, si perde la caratteristica di

ognuno

Native Client: Pro & Cons • Pro

• Performance

• Contatto con la piattaforma

• Rispetto delle linee guida grafiche e di design

• Uso di features tipiche della piattaforma o del sistema operativo

• Debug con strumenti integrati (VS, Intellij, Xcode…)

• Contro

• Conoscenza del dispositivo

• Conoscenza di un linguaggio tipico della piattaforma

• Se si vuole sviluppare per n piattaforme si devono creare n progetti, ciascuno diverso dall’altro

• Il rilascio delle versioni può diventare problematico

Conclusioni

• Sviluppare App Interoperabili e Multipiattaforma o Native:

• Per il back-end:

• Utilizzare standard per la comunicazione, REST e JSON

• Pensare e realizzare API flessibili ma mirate per risolvere i problemi del dominio applicativo

• Per il front-end multiplatform

• Conoscere HTML è garanzia di operatività immediata

• Nessun bisogno di imparare linguaggi nuovi

• Sviluppo unificato, ma performances che dipendono dai browser

• Per il front-end nativo

• Si deve conoscere bene il dispositivo dove si va a sviluppare

• Si possono rispettare le design guideline della piattaforma

• Ci si può avvalere di tutte le feature offerte dall’accoppiata device/sistema operativo

Link e riferimenti

• Alcuni link utili:

• PhoneGap

• http://phonegap.com

• KnockoutJS

• http://knockoutjs.com

• Jquery Mobile

• http://jquerymobile.com

• Mango Tools

• http://www.microsoft.com/download/en/details.aspx?id=27570

• Intellij IDEA

• http://www.jetbrains.com

• Android SDK

• http://developer.android.com/sdk/index.html

Contatti • Davide Senatore

blogs.ugidotnet.org/dsenatore

info@ingeniumsoft.com

www.ingeniumsoft.com

www.gymmit.com

Wikisticker RELIVE YOUR TIME

www.wikisticker.com

@davidesenatore