Il documento descrive l'integrazione di WebKit all'interno di un'applicazione nativa per iPad, focalizzandosi sulla raccolta di dati tramite form HTML. Vengono presentati vari aspetti tecnici, come la gestione dei dati in locale usando SQLite, l'inserimento di JavaScript per funzionalità avanzate e il funzionamento offline. L'app, chiamata MobileAd, è progettata per la raccolta di lead e survey durante eventi, con una forte personalizzazione e funzionalità di sincronizzazione con un web service.

1. Webkit Meets Native Development
Integrazione tra il Webkit-engine ed una Applicazione nativa per iPad.
Relatori:
Nicholas Valbusa – nicholas.valbusa@intesys.it
Alessandro Maroldi – alessandro.maroldi@intesys.it

2. Presentazione
Presentazione 70 specialisti
Intesys 1 Società controllata + 1 Consociata

3. Presentazione
Premesse e features (1/2)
 Webkit: è un framework e motore di rendering (open-source), utilizzato in
Safari, Google Chrome e altre applicazioni.
 WebView: classe/object disponibile nell’SDK di iOS per gestire e
visualizzare contenuti web tramite Webkit.
 La nostra mission consiste nell’integrare all’interno di una applicazione
nativa per iPad delle form di raccolta dati realizzate in HTML.
 Istanzieremo quindi un browser all’interno della nostra applicazione, e
faremo credere ad esso che il nostro iPad sia il suo webserver di
riferimento.

4. Presentazione
Premesse e features (2/2)
 Il nostro iPad intercetterà le chiamate delle form e salverà in locale i dati
(quindi senza connettività) grazie a SQLite (nativo obj-c, non sqlite di
webkit).
 Faremo interagire le nostre form con Objective-C, iniettando dati
all’interno del browser.
 Interagiremo con diverse risorse locali già presenti sul device.
 L’applicazione fungendo da (quasi) widget con un cron schedulato,
si preoccuperà dellʼinvio dei dati raccolti ed altre funzionalità
aggiunte.

5. Presentazione
Perché nativo, perché Webkit
NATIVO WEBKIT
 Storage SQL persistente  Facilità di sviluppo form
 Criptaggio dei dati  Utilizzo standard web
 Cronjob  Plugin per autocompletamento
 Distribuzione su App Store  Alta personalizzazione grafica
 Possibilità di istanziare il Webkit-
engine
 Meno dati scambiati con il server

6. Presentazione
Schema di funzionamento generale
Gli utenti compileranno una form di profilazione su iPad ed i dati raccolti
verranno inviati ad un webservice centrale.

7. Presentazione
Panoramica architetturale
Il grafico descrive schematicamente come sarà l’architettura interna
della nostra applicazione.

8. Presentazione
Gli argomenti che andremo ad affrontare
 Realizzazione form
 To the iPad
 Rendering
 Playing with delegate
 Back to server
 Mobilead: dal test alla pratica

9. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Realizzazione form
 Creazione form HTML
 Deploy su webserver

10. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Prima fase: creiamo una semplice form HTML
Scriviamo una semplice form HTML senza preoccuparci di controlli, doctype,
dichiarazioni, ecc.. – si preoccuperà di tutto più avanti la nostra applicazione ;)
Siamo liberi di utilizzare anche HTML5 nella composizione della nostra form in quanto
WebKit lo renderizza senza problemi.

11. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Salviamo la nostra form sul webserver
Pubblichiamo la nostra form su un indirizzo che sia accessibile dalla nostra applicazione
per iPad.
(Un url pubblico andrà benissimo, es. www.example.org/mia_form.html).
Desktop rendering (lo spartano risultato ottenuto fino ad ora):

12. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
To the iPad
 Otteniamo la form su iPad
 Pre-rendering: head replace
 Rilevamento immagini e salvataggio locale

13. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Otteniamo via http la nostra form su iPad
In Objective-C, bastano poche righe per effettuare una chiamata http ed
ottenere il contenuto del nostro file sotto forma di stringa.
A questo punto, prima di renderizzare la form nel motore WebKit, “giocheremo” un po’
con la stringa che contiene l’HTML, aggiungendo dichiarazioni, controlli, e molte altre
cose lato client.

14. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Pre-rendering: Head replace
1) Sul nostro iPad, risiede un file chiamato intestazione_form.txt che useremo al posto
dell’head della form.
Il nostro file sarà così composto:
2) Leggiamo il file in Objective-C:
3) Infine, sostituiamo il nostro head a quello (vuoto) già presente nella form:

15. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Rileviamo le immagini e salviamole in locale
Uno dei requisiti della nostra applicazione prevede il funzionamento
anche in assenza di connettività.
Per questo motivo, andremo a trovare tutte le immagini a cui fa
riferimento la form e le salveremo in locale.
Quindi, aggiorneremo i riferimenti nei tag <img> di modo da far puntare
gli indirizzi al “nuovo” path locale della relativa immagine.
(non abbiate paura della quantità di codice della prossima slide – si commenta da solo!)

16. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Rileviamo le immagini e salviamole in locale (2a parte - codice)

17. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Rendering
 Rendering con UIWebView (Webkit)
 Il delegato di UIWebView
 Inclusione risorse esterne

18. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Renderizziamo la form tramite Webkit
1) Prima di tutto, creiamo un oggetto di tipo UIWebView, ovvero l’istanza del nostro
browser WebKit che useremo per renderizzare la form.
Nota: il nostro oggetto viene dichiarato come IBOutlet per consentire ad Interface
Builder (il software che si occupa della creazione delle interfacce) di collegare il nostro
oggetto dalla view al codice.

19. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Il nostro ViewController verrà dichiarato come delegato di tipo <UIWebViewDelegate>,
dato che dovrà ricevere gli eventi che la nostra WebView scatenerà durante la sua
esecuzione.
Più avanti tra qualche slide, avremo quindi a disposizione i seguenti metodi:
Segnaliamo quindi alla nostra WebView (il browser) che il suo delegato sarà il nostro
controller (in questo caso “self”, dato che il nostro delegato corrisponde alla classe
attuale.

20. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Carichiamo quindi la nostra form all’interno della WebView, impostando il baseURL
che utilizzerà il browser (ovvero la nostra directory che contiene le risorse – file
Javascript, CSS, immagini, ecc.):
Il path di base che verrà impostato nel nostro browser sarà quindi una stringa
simile a questa:
E verrà “appeso” ogni volta che useremo un puntamento relativo ad una
risorsa dalla nostro form, ad esempio:

21. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Verrà renderizzata la nostra form html.
Le risorse incluse nella nostra applicazione
verranno quindi utilizzate dalla form (stili css,
script javascript, immagini).
Il prossimo passaggio che affronteremo
consisterà nel leggere la lista dei comuni
italiani (precaricati sul DB della nostra
applicazione) e utilizzarli come
autocompletamento per uno qualsiasi dei
campi della form.

22. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Playing with delegate
 Da SQLite al browser, passando per Obj-C
 Javascript Injection
 UIWebViewDelegate
 Intercettiamo le chiamate del browser
 Un finto webserver
 Protocolli custom

23. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Da SQLite al Browser, passando per Obj-C
1) Estraiamo i dati dei comuni italiani dal DB SQLite della nostra applicazione, e
prepariamoci una stringa nel formato di un due array Javascript.

24. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Da SQLite al Browser, passando per Obj-C
Ecco quindi la nostra “stringa”
pronta per essere inviata al
browser.

25. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
JavaScript Injection
2) Passiamo i nostri array Javascript al browser “iniettandoli” via Objective-C con
una chiamata di tipo Javascript:
La funzione stringByEvaluatingJavascript invia del codice JS al browser, eseguendolo
come se fosse la pagina stessa a chiamare il codice.
Potremmo ad esempio dichiararci una funzione come stringa, ed inviarla al browser
per farla definire nel DOM, oppure iniettare delle chiamate jQuery come in questo
esempio:
Nel nostro caso, utilizziamo jQuery Autocomplete per agganciare il nostro array ad
un comodo autocompletamento durante la digitazione nel campo:

26. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Intercettiamo le chiamate del browser
Uno dei punti fondamentali della nostra applicazione, consiste nell’intercettare le
chiamate che il browser esegue, e manipolarle/estrarne dei dati.
Il nostro controller grazie alle funzionalità offerte da <UIWebViewDelegate> potrà
implementare il seguente metodo:
Questo metodo, verrà chiamato ogni volta che il nostro browser inizierà una chiamata, e
noi ci preoccuperemo di restituire TRUE/FALSE dicendo al browser se iniziare tale
chiamata o tralasciarla.
Nello specifico, il metodo verrà chiamato al submit della nostra form.
La variabile “request” conterrà tutte le informazioni che ci serviranno: url, header e
body della chiamata, dati GET/POST.

27. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
UIWebViewDelegate
Dalla documentazione ufficiale:

28. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Dentro al metodo, controlliamo prima di tutto se il body della chiamata è valorizzato
(ovvero se ci sono dei dati in POST) e poi recuperiamo i dati “postati” sotto forma di
stringa serializzata – formato standard con cui vengono inviati i dati nelle chiamate
HTTP.
Un’altra funzionalità che possiamo sfruttare con questo metodo, consiste nel
chiamare url particolari (con un protocollo personalizzato) dal nostro browser e
riconoscerli lato Obj-C, in modo da poterli gestire come desideriamo.

29. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Possiamo simulare delle chiamate AJAX verso un url fittizio, intercettarle tramite
Objective-C, effettuare le nostre operazioni ed iniettare del codice Javacript.
Un vero e proprio (finto) webserver locale!

30. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Siamo liberi di inventarci un nostro protocollo, e successivamente riconoscerlo
guardando lʼindirizzo dellʼURL della nostra variabile “request”.
Per esempio, riconosciamo un indirizzo e chiamiamo una funzione passandogli
come parametro i dati ricevuti dalla chiamata AJAX:

31. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Back to server
I dati ritornano all’ovile
 Scheduliamo un cron locale sul dispositivo
 Criptiamo i dati prima di inviarli
 Prepariamo una NSMutableURLRequest
 Settiamo i dati da inviare via POST
 Inviamo i dati ad un webservice e riceviamo una risposta

32. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Scheduliamo un cron (script) locale sul dispositivo
Il modo più semplice ed immediato per creare un cron sul nostro dispositivo,
consiste nel creare un timer che lanci un metodo ripetutamente ad intervalli
regolari.
Possiamo anche sfruttare alcuni metodi utili dell’AppDelegate per monitorare lo
stato della nostra applicazione:

33. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Criptaggio dei dati da inviare
I dati che stiamo raccogliendo sono sensibili, quindi abbiamo deciso di utilizzare un
algoritmo di tipo sha1 per inviare i dati al webservice in maniera criptata.
Esistono diverse librerie “light” ed open-source per effettuare la codifica delle
stringhe lato Obj-C.

34. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra<ca
Dopo aver raccolto i dati dalla form, tramite Objective-C effettuiamo una chiamata
http verso il nostro webservice inviando le informazioni sul server:

35. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra?ca
Mobilead: dal test alla pratica
 Presentazione
 Architettura
 Caratteristiche tecniche ulteriori
 Immagini dimostrative

36. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra?ca
Presentazione
MobiLead
Lead Generation and Survey
MobiLead è un’applicazione di
Intesys appositamente studiata per
raccogliere lead e interviste con la
massima facilità e accuratezza.
Provala ora!
App store > Mobilead
user: whymca
password: whymca

37. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra?ca
Caratteristiche tecniche ulteriori
A quanto descritto fino ad ora, si aggiungono
molte più caratteristiche e funzionalità:
 All’avvio, viene richiesto il login (associato ad un cliente
sul back-end via web) e viene scaricato e “parsato” un
file XML contenente la lista degli eventi attivi.
 Ogni evento contiene la form HTML e numerosi altri
dati tra cui la data di apertura/chiusura evento ed altre
personalizzazioni grafiche.
 La lista eventi + forms vengono salvate in locale sul
dispositivo, ed è presente una funzionalità di
sincronizzazione con il webservice.
 Il dispositivo mette a disposizione localmente i
framework di jQuery, jQuery UI e Cufon.

38. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra?ca
Accesso protetto Lista Eventi

39. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra?ca
Raccolta Lead o Survey
con maschere personalizzabili

40. Presentazione Realizzazione form To the iPad Rendering Playing with delegate Back to server MobiLead: dal test alla pra?ca
Intesys MobiLead
Cosa permette di fare?
 Raccogliere profili utenti
(anagrafica, indirizzo mail, contatti telefonici)
 Raccogliere survey/interviste
Su quali piattaforme funziona?
 iPad
 Android
Quando si usa?
 In occasione di stand, fiere, eventi e manifestazioni
 In tutte le occasioni che richiedono una raccolta
contatti veloce e puntuale

41. Grazie per la
vostra attenzione.
Any questions?
Nicholas Valbusa – nicholas.valbusa@intesys.it - twitter: @squallstar
Alessandro Maroldi – alessandro.maroldi@intesys.it - twitter: @alexmaroldi
Intesys
Via Roveggia, 122A - 37136 Verona
voice +39 045 503663 - fax +39 045 503604
info@intesys.it – www.intesys.it