Design e implementazione di un applicazione Android per il riconoscimento e la localizzazione delle specie marine delle Maldive

Transcript

1 Università degli Studi di Milano Bicocca Dipartimento di Informatica, Sistemistica e Comunicazione Corso di Laurea in Informatica Design e implementazione di un applicazione Android per il riconoscimento e la localizzazione delle specie marine delle Maldive Relatore: Dott.ssa Daniela Micucci Co-relatore: Dott. Alessio Vertemati Relazione della prova finale di: Marco Taddei Matricola Anno Accademico

2 INDICE Indice 1 App mobile, perchè? 5 2 UI e UX, Material Design 6 3 Progettazione Componente database Componente server Componente client Implementazione Database centrale Server Client Sincronizzazione dei dati Guida tecnica alle funzionalità Ricerca delle specie marine Scheda dettagliata Creazione e visualizzazione degli avvistamenti Registrazione e Login Specie marine preferite e avvistamenti creati Guida utente alle funzionalità Ricerca delle specie marine Scheda dettagliata Registrazione e Login Creazione e visualizzazione degli avvistamenti Specie marine preferite e avvistamenti creati Future estensioni Dati multilingua App multilingua Sincronizzazione specie preferite Implementazione degli apprezzamenti (like) Raggruppamento marker Inserimento settings Altri sistemi di login

3 INDICE 7.8 Migliorare la significatività degli avvistamenti Proteggere API del Web Service Ricerca dicotomica Conclusioni 52 9 Ringraziamenti 55 2

4 INDICE Introduzione Nel 2009 l università di Milano-Bicocca ha aperto un Centro di Ricerca e Alta Formazione presso l isola di Magoodhoo alle Maldive (MaRHE Center). Le attività del centro riguardano gli ecosistemi tropicali e le barriere coralline, con una particolare attenzione allo studio dell impatto che il cambiamento climatico produce sull ambiente marino maldiviano. La sede di ricerca, nella persona del professor Paolo Galli, ha presentato al dipartimento di Informatica, Sistemistica e Comunicazione dell università di Milano-Bicocca l esigenza di creare una applicazione rivolta ai turisti che desiderino scoprire l ambiente marino delle Maldive. Per rispondere a quest esigenza, è stato avviato tale progetto di stage per lo sviluppo di un applicazione su piattaforma Android. Attraverso l ateneo, il quale ha siglato un accordo di collaborazione con Maldives Marketing & Public Relations Corporation, l applicazione verrà presentata con il nome di MalDiving a EXPO, che si terrà a Milano a partire dal mese di Maggio La collaborazione prevede la realizzazione di una serie di eventi scientifici e culturali che saranno svolti durante EXPO 2015 sia all interno dello spazio espositivo riservato alle Maldive, sia in altre sedi quali l Acquario Civico di Milano, la rete di Fattorie Didattiche Lombarde e l università di Milano-Bicocca. L applicazione in oggetto deve soddisfare nel suo complesso i seguenti requisiti funzionali: Divulgazione: mettere i turisti a conoscenza dell infinità di specie marine presenti nell area attraverso un elenco dei pesci e dei coralli, ed una scheda tecnica dettagliata per ognuno di essi. Supporto all esplorazione: informare i turisti della presenza di pesci e coralli in determinate aree creando uno storico degli avvistamenti, e permettendo di organizzare uscite alla scoperta delle specie marine presenti. Gli avvistamenti sono indicati direttamente dagli utenti dell applicazione. L applicazione risultante permetterà ai turisti di creare e condividere avvistamenti di specie marine, cercare una specie, vederne le immagini e leggerne la scheda tecnica. È inoltre consigliabile che l applicazione soddisfi dei requisiti non funzionali (di qualità) quali velocità, immediatezza di utilizzo, semplicità grafica, in altre parole che offra una buona esperienza utente. 3

5 INDICE Di seguito verrà presentato il processo che ha portato alla realizzazione di MalDiving. Nella Sezione 1 si spiega perchè si è scelto di utilizzare la piattaforma Android e nella Sezione 2 viene fatta un introduzione al design utilizzato (Material Design). Nella Sezione 3 viene spiegata la struttura principale del progetto, con una panoramica sulle componenti dell applicazione. I dettagli sulle componenti vengono mostrati nella Sezione 4, mentre la Sezione 5 è un riferimento per sviluppatori che mostra come sono legate le classi Android e i layout. È anche presente una guida utente alle funzionalità nella Sezione 6, mentre la Sezione 7 è riservata a una spiegazione sulle possibili funzionalità da aggiungere all applicazione, fornendo suggerimenti e spunti utili per la loro implementazione. Le Sezioni 8 e 9 mostrano le conclusioni e i ringraziamenti finali. 4

6 App mobile, perchè? 1 App mobile, perchè? La scelta di sviluppare un applicazione mobile deriva dalla necessità che l applicazione risulti sempre fruibile dai propri utilizzatori: i turisti delle Maldive. Un applicazione mobile risulta essere disponibile per l utente anche in mobilità, rendendo sempre possibile la condivisione degli avvistamenti e altre funzionalità. L applicativo è stato sviluppato in maniera nativa per smartphone e in particolare per la piattaforma Android, in quanto risulta la più diffusa sul mercato degli smartphone, il sistema operativo è interamente open source, il Software Development Kit e tutti gli strumenti necessari sono disponibili gratuitamente e il linguaggio di sviluppo è Java, che è il linguaggio usato nei nostri corsi di Programmazione. L applicazione è stata pensata per smartphone, ed è compatibile con i dispositivi da Android 4.0 fino ad Android L, versione del sistema operativo presentata in occasione del Google I/O di Giugno Come si può vedere dalla Figura 1, la diffusione delle versioni Android a partire dalla 4.0, nominata Ice Cream Sandwich, si attesta all 87.9% di mercato. Figura 1: Distribuzione percentuale di utilizzo delle versioni di Android [1]. 5

7 UI e UX, Material Design 2 UI e UX, Material Design L interazione che l utente ha con l applicazione, ossia la user experience (UX) e gli elementi dell interfaccia utente, in gergo user interface (UI), sono stati pensati e realizzati seguendo le linee guida del nuovo design Android introdotto in occasione del Google I/O 2014: Material Design. Di seguito vengono ripresi ed esplicitati i punti salienti del linguaggio visuale alla base del Material Design [2]: Un design uniforme su tutte le decine di servizi e piattaforme. La frammentazione dei dispositivi, dell interfaccia utente e dell esperienza utente dei vari prodotti Android è stato probabilmente il motivo per cui Google non è stata in grado di garantire aggiornamenti costanti per diversi vecchi dispositivi. Esperienza utente basata su principi unificanti. Tutte le applicazioni devono rifarsi a una stessa logica d interazione. Estetica riconoscibile e comprensibile. Un applicazione sviluppata secondo Material Design deve essere riconoscibile e i suoi principi d interazione devono essere facili e comprensibili. Estetica facile da interpretare. Non devono esserci orpelli o trasparenze inutili, l estetica deve essere funzionale e non deve dare adito a fraintendimenti nelle funzionalità che espone. Espressione della realtà tattile. Tutte le interazioni devono essere legate alla realtà tattile, il tocco scatena delle azioni, avvia delle funzionalità e il design deve rispecchiare questo principio. Autenticità del movimento. Tutte le animazioni o il movimento da un Activity a un altra devono essere significativi rispetto al tocco e alle azioni dell utente. Il material design è una metafora che sfrutta il principio secondo cui ogni elemento è posto su un foglio di carta, può avere una profondità e ha una fisicità. Questi fogli possono essere combinati, sovrapposti, anche parzialmente tra di loro. 6

8 UI e UX, Material Design Questo permette non solo di creare gerarchia tra gli elementi dell interfaccia e focalizzare l utente sul contenuto e non sull estesica generale, ma anche di poter sfruttare la terza dimensione, la profondità, in un ambiente notoriamente bidimensionale. Il risultato è il focus delle informazioni, qualcosa che accade in maniera naturale nel momento in cui a un utente vengono presentate delle informazioni, per citare Google: It s happening in the more primitive part of your brain[2]. Il Material Design ha anche come obiettivo quello di accelerare la comprensione dell interfaccia utente e delle funzionalità dell applicazione, cosa realizzabile dato che il material design si compone di superfici, elementi tangibili, a cui vengono associati movimenti autentici durante le interazioni (Figura 2). Figura 2: Superfici del Material Design Tutto si sposta con un senso, con un feedback di fluidità e concretezza rispetto alle azioni compiute: Motion provides meaning, and user actions are inflection points that initiate motion, transforming the whole design[2]. Nello specifico, dato che Android L al momento dell implementazione non era stato ancora rilasciato, non è stato possibile utilizzare Material Design, 7

9 UI e UX, Material Design ma comunque sono state implementate soluzioni grafiche ispirate ai principi del material design. In particolare, è stato possibile implementare il tutto grazie ad un preciso uso delle griglie, delle spaziature, della tipografia, dei colori e delle animazioni. Com è possibile vedere in Figura 3 tramite la rappresentazione della scheda di dettaglio di un pesce, l intero layout segue l utilizzo di griglie con spaziatura uniforme e precise dimensioni delle scritte per conferire una strutturazione gerarchica alle informazioni. Figura 3: spaziature Esempio di un activity che mostra l uso delle griglie e delle L obiettivo è soddisfare l utente durante l interazione, e questo è possibile solo quando ad ogni azione e ogni interazione con l applicazione corrispondono reazioni che avvengono in maniera perfettamente logica. Molta attenzione è posta anche alle icone, alla loro dimensione e proporzione. Quando possibile vengono riutilizzate le icone di sistema, per fornire un esperienza utente consistente. 8

10 Progettazione 3 Progettazione Per soddisfare appieno i requisiti (Sezione Introduzione) di divulgazione e supporto all esplorazione, l applicazione dovrà fornire le funzionalità basilari mostrate in Figura 4 attraverso l utilizzo di un diagramma dei casi d uso. In particolare, una ricerca di specie marine deve permettere di visualizzare una scheda dettagliata degli animali, così da favorire una migliore fruizione dell applicazione grazie all inserimento di un pesce tra i preferiti, di visualizzarne gli ultimi avvistamenti e di creare un nuovo avvistamento. Figura 4: Diagramma dei casi d uso. I casi d uso colorati di grigio scuro richiedono una registrazione/login dell utente. Da un punto di vista progettuale questo si è tradotto nell utilizzo di tre componenti componenti separate: (1) la componente database che permette la persistenza dei dati informativi dell applicazione e le personalizzazioni degli utenti, (2) il lato client, ovvero l applicazione Android, e (3) il lato server che permette l interazione tra i client e la componente database. 9

11 Progettazione La Figura 5 mostra, all interno del package Application, le componenti che formano l ecosistema applicativo. Ciascuna componente può essere più o meno complessa (cioè può contenere al proprio interno altre componenti) e può comunicare per mezzo di interfacce. La componente client si occupa di mostrare i contenuti all utente tramite un applicazione mobile. Ha un sistema di persistenza dati per l utilizzo offline e si sincronizza con la componente server per aggiornare i dati. La componente server riceve delle richieste di sincronizzazione dai client e instrada un opportuna gestione al fine di centralizzare le informazioni contenute nella componente database. L utilizzo delle componenti server e database permette di rendere l applicazione scalabile nell aggiornamento dei dati e permette, in un futuro, di supportare la parte mobile su altre piattaforme, come ios e Windows Phone. La componente database è spiegata nella Sezione 3.1, la componente server nella Sezione 3.2, mentre la componente client nella Sezione 3.3. Per l implementazione si vedano le Sezioni 4.2, 4.3. Figura 5: Diagramma delle componenti, componente client, server e database 10

12 3.1 Componente database 3.1 Componente database La componente database si occupa della persistenza e dell univocità dei dati provenienti e sincronizzati dai client. La sua struttura deve tenere conto di tutte le informazioni sulle specie marine e le relative descrizioni, derivanti da FishBase [6], la più grande banca dati sul web di specie marine, che fornisce informazioni come tassonomia, distribuzione geografica, la morfologia, il comportamento, l habitat, nomi comuni ecc. Il database deve mantenere le informazioni sulle specie in più lingue e contenere le informazioni degli utenti che inseriscono avvistamenti. 3.2 Componente server Per fornire una corretta e agile interazione con il database si è pensato di utilizzare un server. Questo per rendere l applicazione nel suo complesso anche più interattiva e dinamica grazie alla condivisione di avvistamenti tra gli utenti, permettendone un utilizzo sia online che offline attraverso una logica di sincronizzazione di avvistamenti che verrà spiegata più avanti (Sezione 4.4). Si richiede che la componente server gestisca l interazione con il database centrale e fornisca una Application Programming Interface (API) per permetterne l invocazione dall applicazione mobile, che ha necessità di comunicare con i dati sul server. Per questo è stato utilizzato un web service con cui far interfacciare l applicazione. La comunicazione tra le componenti Server e Client avviene tramite chiamate a web service sincrone. L Application Programming Interface (API) permette di astrarre l implementazione del database relazionale remoto, permettendo operazioni CRUD 1 sul database, ma anche l esecuzione di query più articolate che contengano della logica, e che siano eseguite sul server restando totalmente trasparenti per l applicazione mobile. 3.3 Componente client L applicazione mobile ha l obiettivo di rendere l informazione da mostrare il più possibile comprensibile e immediata, permettendo agli utenti di creare avvistamenti. Le informazioni devono essere aggiornate con il server, gli 1 CREATE, READ, UPDATE, DELETE, le quattro principali operazioni dei database relazionali. 11

13 3.3 Componente client utenti devono poter creare e condividere gli avvistamenti dei pesci, la ricerca delle specie marine deve essere agevolata e, possibilmente, guidata data la numerosità dei pesci delle Maldive. L applicazione Android fornisce, quindi, le funzionalità necessarie a soddisfare la divulgazione delle specie marine, permettendo di trovarle, scoprirne i dettagli, visualizzarne gli avvistamenti e crearne di nuovi. Inoltre, per consentire all utente di avere sotto controllo le informazioni di cui ha bisogno, è stata fornita la possibilità di aggiungere un pesce tra i preferiti, così da poterne visualizzare gli avvistamenti in maniera semplice e intuitiva. Le funzionalità personalizzabili o riferibili a un utente specifico, come la creazione di un avvistamento, la visualizzazione dei pesci preferiti o dei propri avvistamenti, sono possibili grazie a una funzionalità di login, che permette di tenere traccia degli utenti. Poichè l applicazione verrà utilizzata soprattutto dai turisti, per questioni di roaming il dispositivo spesso non sarà connesso alla rete. È stata quindi considerata una modalità online e una offline di utilizzo dell applicazione. Per garantire la persistenza dei dati durante l utilizzo offline, è stato predisposto un database locale che viene sincronizzato con il database presente sul server quando il telefono torna online. 12

14 Implementazione 4 Implementazione In questa sezione viene ripresa la struttura delle componenti esposte nelle Sezioni 3.1, 3.2 e 3.3, con un maggiore livello di dettagli. La parte database (introdotta nella Sezione 3.1) in questo capitolo è stata trattata all interno della componente server (Sezione 4.2), poichè la soluzione utilizzata per quest ultima ingloba e gestisce in autonomia il database generale. Vengono anche introdotte le principali difficoltà incontrate nello sviluppo e viene fornita una panoramica della struttura logica finale, per fornire un punto di riferimento per eventuali sviluppi futuri. 4.1 Database centrale Come spiegato nella Sezione 3.1, l applicazione necessita di un database per centralizzare le informazioni degli utenti, degli avvistamenti e fornire una gestione delle lingue. Per queste ragioni il database centrale è stato progettato per seguire la struttura mostrata in Figura 6, che di fatto utilizza delle tabelle diverse a seconda della lingua di riferimento. In questo modo, quando un client interrogherà il server per avere delle informazioni, dovrà specificare la propria lingua, e la componente server potrà interagire con il database fornendo così informazioni sulle specie marine coerentemente con la lingua del client. Le informazioni importanti degli utenti di cui il database tiene traccia sono username e , non è stato necessario tenere traccia di password in quanto l autenticazione avviene lato client con un token, rilasciato dall applicazione Google Plus e gestito in locale dall applicazione. Attualmente le informazioni sui pesci sono solo in inglese, ma un esempio di una possibile estensione per altre lingue è fornito nel diagramma ER in Figura 6. Come è possibile notare dal diagramma ER le informazioni comuni tra tutte le lingue vengono rappresentate una sola volta, mentre le informazioni caratteristiche e dipendenti dalla lingua sono separate in tabelle che hanno un prefisso corrispondente alla lingua in cui sono salvate. Il database andrà popolato con i dati estratti da FishBase [6], una banca dati molto estesa, con circa specie, 300mila nomi comuni in circa 300 linguaggi, fotografie e 800mila visite al mese 2. 2 Dati forniti da [6] 13

15 4.1 Database centrale Figura 6: Diagramma Entità-Relazione del database centrale con supporto per tre lingue 14

16 4.1 Database centrale Purtroppo questi dati non sono facilmente accessibili in quanto non esistono interfacce agili per interrogare questa base di conoscenza, che viene presentata come una tabella html di specie marine o, cliccando su una singola specie, una pagina html con i dettagli del pesce (Figura 7). Per recuperare questi dati è stato predisposto un crawler sviluppato da terzi che, analizzando tutte le specie marine delle Maldive, ha creato un file json con le informazioni presenti su FishBase. Così, ad esempio, la conoscenza relativa al pesce Abalistes stellaris viene rappresentata in questo modo: { "Name": "Starry triggerfish", "ScientificName": "Abalistes stellaris", "Classification": { "Kingdom": "Animalia", "Phylum": "Chordata", "Class": "Actinopterygii", "Order": "Tetraodontiformes", "Family": "Balistidae", "FamilyPage": "/FamilySummary.php?ID=445", "OrderPage": "/OrdersSummary.php?order=Tetraodontiformes" }, "Type": "Fish", "Language": 1, "MaxLength": { "Value": 60.0, "Unit": "cm" }, "MaxWeight": { "Value": , "Unit": "g" }, "Depth": null, "ExtintionRisk": "Not Evaluated", "DangerousLevel": "Harmless (Ref. 9770)", "MainFood": "mainly animals", "Ecology": "Marine; demersal;... " "Biology": "Inhabit coastal areas, usually found over", 15

17 4.1 Database centrale } "ShortDescription": "Dorsal spines(total): 3; Dorsal soft rays(total): 25-27; Analspines: 0; Analsoft rays: Scales enlarged above the pectoral fin base and just behind the gill slit to form a...", "FishBaseUri": null, "Images": [ { "Url": " "Attribution": "Randall, J.E." }, { "Url": " "Attribution": "Randall, J.E." },... ], "CommonNames": [ { "Name": "宽尾鳞鲀", "Country": "China", "Language": "Mandarin Chinese" },... ] Sono molte informazioni da gestire e, come è possibile vedere, non tutte sono immediatamente utilizzabili. Infatti i nomi comuni (CommonNames nello snippet) hanno un campo Name che contiene caratteri che vanno decodificati poichè il file json in uscita è in formato ASCII e quindi non supporta caratteri di lingue straniere, come il Mandarino, cosa che invece la codifica UTF-8 utilizzata dal lato del database è in grado di supportare. Attualmente, per ragioni che verranno esposte più avanti nella sezione di implementazione del client (Sezione 4.3), le informazioni sulle specie marine sono fornite in locale all interno dell applicazione e non sono disponibili dati su altre lingue al di fuori dell inglese. Man mano che queste informazioni saranno reperibili e disponibili in altre lingue, il database verrà popolato. 16

18 4.1 Database centrale Figura 7: Scheda dettagliata su FishBase 17

19 4.2 Server 4.2 Server Il server garantisce l univocità degli avvistamenti e degli utenti profilati, è in grado di fornire dei dati sincronizzati, il tutto con un livello di astrazione tale da permettere all applicazione mobile di non doversi preoccupare della persistenza dei dati in remoto. Per il lato server è stato realizzato un web service che segue il paradigma RESTful [3]. Tale paradigma è caratterizzato da: Usa esplicitamente metodi HTTP, in maniera consistente con la definizione del protocollo, utilizzando POST per creare una risorsa sul server, GET per recuperare una risorsa, PUT per cambiare lo stato di una risorsa o per aggiornarla, DELETE per rimuovere o eliminare una risorsa (RFC 2616 [4]). È stateless, cioè tratta ogni request come fosse una transazione indipendente da ogni qualunque precedente request, così che ogni comunicazione consista di coppie indipendenti request-response e il significato di ciascuna request sia comprensibile indipendentemente dal contesto. Trasferisce XML o JSON [9], cioè la response avviene tramite file json o xml. Per realizzare il web service RESTful è stato utilizzato un framework per creare applicazioni web (Laravel 4.2 [5]) che, tra le varie funzionalità, permette l instradamento delle richieste del client e ingloba al suo interno una componente Object Relational Mapping (ORM). Quest ultima componente, in particolare, è stata molto utile per gestire l accesso al database relazionale MySql, in quanto ci ha permesso di interagire con il database utilizzando un paradigma a oggetti (in questo caso il linguaggio usato è PHP), senza preoccuparci del database stesso. Laravel segue il pattern Model View Controller (MVC), un pattern architetturale che consiste di tre ruoli fondamentali [7]: Model, rappresenta le informazioni di dominio, ossia i dati importanti dal punto di vista dell applicazione. Controller, definisce il modo in cui l interfaccia utente reagisce agli input degli utenti. 18

20 4.2 Server View, è la parte di interfaccia utente che mostra le informazioni contenute nella parte di model e che sono elaborate dal controller. Il MVC nasce con l obiettivo di disaccoppiare la rappresentazione del modello di dominio (Model), l interfaccia utente (View) e il controllo dell interazione uomo-macchina. In questo modo, una view utilizza un istanza di un controller per implementare una particolare strategia di risposta e per implementare una strategia diversa basta rimpiazzare l istanza con un diverso controller. Allo stesso modo, vedendo il controller da un punto di vista più vicino al model, il controller raggruppa azioni/transazioni che possono essere effettuate sul modello, ed è del tutto indipendente da aspetti tecnologici legati all interfaccia grafica. Una volta installato e configurato Laravel, è stato necessario inserire nel file routes.php le API da esporre e il relativo metodo dei controller da richiamare per avviare l opportuna gestione. Ad esempio, le righe da inserire nel file routes.php sono nella forma: Route::HTTP METHOD( path, ControllerClass@controllerMethod ); dove il primo parametro path corrisponde alla parte di url che identifica l accesso all entità/risorsa, mentre il secondo parametro è il metodo del controller ControllerClass che la gestisce. Le API attualmente esposte, e quindi i path riconosciuti dal web service, sono: path /user /createuser /incrementusersightings /incrementuserscore /sighting /createsighting /getlastsightings /getlastanimalsightings /getusersightings /getlikerow /createlike Controllerclass@controllerMethod UserController@getUserRow UserController@createUser UserController@incrementUserSightings UserController@incrementUserScore SightingController@getSightingRow SightingController@createSighting SightingController@getLastSightings SightingController@getLastAnimalSightings SightingController@getUserSightings LikeController@getLikeRow LikeController@createLike 19

21 4.2 Server Dove: /user ritorna la riga dell utente presente sul database remoto. Parametri in ingresso: userid. /createuser se l utente esiste già ritorna la riga dell utente sul database, altrimenti lo crea e ritorna la riga creata. Parametri in ingresso: username, . /incrementusersightings se l utente esiste, incrementa il contatore dei suoi sighting. Parametri in ingresso: userid. /incrementuserscore se l utente esiste, incrementa il contatore del suo score. Parametri in ingresso: userid. /sighting permette di recuperare i dettagli di un avvistamento (sighting) dato il suo indentificativo. Parametri in ingresso: sightingid. /createsighting crea un nuovo avvistamento (sighting) sul database e risponde con la riga corrispondente, altrimenti se esiste già un sighting identico risponde con quello e non lo inserisce. Parametri in ingresso: userid, animalid, latitude, longitude, time. /getlastsightings permette di recuperare l elenco degli ultimi 100 avvistamenti disponibili. /getlastanimalsighting permette di recuperare l elenco degli ultimi avvistamenti di una specie marina. Parametri in ingresso: animalid, numsightings. /getusersightings risponde con i sighting dell utente presenti sul database remoto. Parametri in ingresso: username, . /createlike se l utente e l avvistamento esistono, incrementa la reputazione (score) dell utente che l ha creato. Parametri in ingresso: username, . 20

22 4.2 Server Le risposte del server sono in formato JSON[9]. Ad esempio richiedendo il sighting con id = 2 si ottiene una risposta simile alla seguente: HTTP/ OK Cache-Control: no-cache Content-Type: application/json Date: Tue, 23 Sep :20:20 GMT { "id":2, "user\_id":13, "animal\_id":111, "latitude":11.0, "longitude":22.0, "time":" %s11:11:11" } Laravel è risultato un sistema elegante e agile per gestire le chiamate di cui l applicazione aveva bisogno, velocizzando lo sviluppo e permettendo di dividere le problematiche derivanti dall interazione con il database remoto da quelle dell applicazione mobile, semplificando le logiche di persistenza dei dati. Per una migliore esperienza utente, e per aprire la strada a future funzionalità aggiuntive, si è scelto di utilizzare il sistema di autenticazione OAuth 2.0 [15], che semplifica le logiche di login e le interazioni con le API di Google. In questo modo infatti possiamo autorizzare l applicazione Android ad accedere ai dati memorizzati su un servizio online, senza richiedere username e password all utente. La Figura 8 mostra una generica interazione tra un client, un utente proprietario di una risorsa, un server che fornisce l autenticazione e un server che detiene la risorsa. Tutto si basa sul presupposto che l utente ha precedentemente fornito una risorsa (dei dati protetti) a un servizio, dopo essersi autenticato. Successivamente un applicazione client chiede all utente di avere accesso alla risorsa, l utente accetta e con quest autorizzazione il client chiede al server un token, così da poter accedere alla risorsa in questione. Nel caso specifico il client Android, interagendo con l applicazione Google+, propone all utente di fornire i propri dati dell account Google (Authorization Request). L utente, concedendo i permessi, fornisce all applicazione l Authorization Grant, che viene usato per comunicare con le API esposte dall Authorization Server di Google al fine di ottenere un token di autentica- 21

23 4.3 Client zione. Una volta ottenuto il token, si può interrogare il server che detiene le risorse per recuperare le informazioni dell utente Google del dispositivo. Queste verranno poi inviate alla componente server attraverso l API /createuser, e verranno inserite sia nel database remoto che in quello locale. Figura 8: Flusso astratto che descrive l interazione tra i client, il proprietario della risorsa, il server di autorizzazione e il server che possiede fisicamente la risorsa. 4.3 Client In accordo con quanto detto in precedenza (Sezione 3.3), dal punto di vista architetturale, l applicazione mobile è stata progettata e implementata coerentemente con quanto consigliato dalle linee guida dettate da Google e dai vincoli imposti dalla piattaforma Android. In particolare, tutto il progetto è basato sul pattern Model-View-Controller ([7], [8]). In Android, inoltre, View e Controller sono quasi indistinguibili, in quanto non può esistere una View (un layout) senza un Controller (un Activity). Infatti è il Controller ad essere lanciato e alla sua creazione legarsi alla corrispondente View, questo mostrato in dettaglio nel seguente estratto di codice 22

24 4.3 Client dove il metodo setcontentview collega l Activity MyActivity con il layout MyActivityLayout: public class MyActivity extends Activity protected void oncreate(bundle savedinstancestate) { setcontentview(r.layout.myactivitylayout); } } Un altro ruolo importante dell architettura dell applicazione mobile è quello degli Adapter, che aiutano i Controller a non preoccuparsi delle interfacce dei sistemi con cui interagiscono (web service, database ecc). Uno degli obiettivi della componente client è permettere di cercare le specie marine e mostrarne le schede dettagliate e, per fare questo, bisogna avere una conoscenza iniziale sui pesci delle Maldive. L applicazione è dotata di un database locale per garantire persistenza dei dati anche per un utilizzo offline. Il database locale viene inizializzato durante il primo avvio dell applicazione e popolato con le informazioni sui pesci, sui loro nomi comuni e sulle loro immagini provenienti dal file json inserito nell apk e descritto nella Sezione 4.1. Il database utilizzato è Sqlite e il modello ER è quello mostrato in Figura 9. Questo database è una versione ridotta di quello che gestisce la componente server (si veda Sezione 4.1), in quanto ad esempio i nomi comuni e le descrizioni delle specie marine presenti nel database locale sono quelle della lingua del dispositivo, mentre sul server dovranno essere presenti i valori di tutte le lingue disponibili. Attualmente il file json 3 introdotto nella sezione 4.1, a partire da cui viene inizializzato il database, è inserito nell applicazione, questo per gestire il caso in cui l utente decida di avviare per la prima volta l applicazione offline. In questo modo l applicazione può essere avviata indistintamente online e offline e il database viene inizializzato e popolato correttamente. La tabella User contiene le informazioni sugli utenti, che possono essere di due tipi: utente locale dell applicazione: è l utente che ha fatto il login dell applicazione, in questo caso il campo token della sua riga sarà popolato. 3 un file di circa 12MB, che contiene dati di circa 1200 specie marine 23

25 4.3 Client Figura 9: Il modello ER del database locale sqlite 24

26 4.3 Client utente esterno: è un altro utente che a sua volta ha fatto login sulla sua applicazione. Viene inserito nel database locale perchè ha creato un avvistamento, quindi le informazioni principali su di lui (remote key, l identificativo remoto dell utente, username, ranking) devono essere disponibili a chi visualizza il suo avvistamento. La tabella Image è strategica per l applicazione, poichè grazie all url delle immagini queste vengono scaricate dal server e visualizzate tramite un Image Loader al primo utilizzo dell immagine stessa. Per garantire un utilizzo offline, è stata scaricata dal server fishbase la prima immagine di ciascun pesce. Le immagini sono state tutte ridimensionate, ritagliate e salvate, così da fornire all interno dell applicazione un immagine disponibile per ciascun pesce utilizzabile come thumbnail, anche offline. Con la creazione di uno script sono state elaborate circa 1200 immagini che, grazie alla loro leggerezza (pesano circa 8MB in totale, contro i 90MB iniziali), sono state inserite nell applicazione senza comprometterne il peso. Il resto delle immagini, circa in tutto, sono state processate, ottimizzate per smartphone e salvate sul server messo a disposizione dell app, in quanto fishbase.org risultava lento nel restituire l immagine richiesta. Oltre alla velocità nel caricamento delle immagini in questo modo è stato ottimizzato il consumo di traffico dati, dato che le immagini sono molto più leggere rispetto alle originali 4. Il processo che ha portato all ottimizzazione delle immagini è frutto di uno script PHP che, analizzando un file di testo preparato appositamente e contenente tutti gli URL (Uniform Resource Locator) delle immagini, verifica se la foto esiste e, successivamente, in base al formato dell immagine la scarica e la processa attraverso quattro funzioni PHP [16]: imagecreatefromjpeg (string $url) crea una nuova immagine da un file o da un URL. imagecreatetruecolor (int $width, int $height) crea un immagine delle dimensioni fornite nei parametri widtheheight. imagecopyresampled (resource $dst image, resource $src image, int $dst x, int $dst y, int $src x, int $src y, int $dst w, int $dst h, int $src w, int $src h) 4 ogni immagine scaricata pesa in media dai 5 KB ai 7 KB, contro i KB medi originali, passando così da un peso complessivo di 750 MB a uno di 80 MB. 25

27 4.3 Client ridimensiona l immagine sulla base dei parametri in input. imagejpeg (resource $dst image, string $filename, int $quality) elabora l immagine in base alla qualit specificata nel parametro $quality. Infine viene gestito il nome del file, questo è stato necessario in quanto su FishBase le immagini hanno spesso nomi uguali, cosa possibile perchè risiedono in cartelle diverse. Sulla base di questa caratteristica la scelta è stata di rinominare l immagine con il proprio URL elaborando tutta la stringa e rimuovendo caratteri speciali e spazi. Ad esempio: u7.jpg httpwwwfishbaseorgimagesspeciesabste u7jpg.jpg Le tabelle Animal, Fish e Common Name contengono le informazioni sui pesci derivanti dal file json. La tabella Coral è stata predisposta per quando si avranno le informazioni relative ai coralli. Per comprendere meglio l organizzazione dell applicazione, è necessario illustrare i quattro package fondamentali: com.disco.maldive.model: contiene le classi Java che rappresentano le entità del database (Animal, Fish, Coral ecc). Le classi implementano Parcelable, l Interface di Android che permette il passaggio (scrittura e recupero) di oggetti da un Activity ad un altra e performance migliori rispetto a Serializable. com.disco.maldive.adapter: contiene tutti gli adapter necessari, utilissimi per popolare liste di elementi (ListView) in maniera dinamica e per le interazioni con il Model cioè con il database. com.disco.maldive.ui: contiene Activity e Fragment, cioè le classi java che gestiscono le View, e che si interfacciano con il model per mezzo degli adapter (soprattutto DbAdapter e DbRemoteAdapter). Devono importare e gestire i layout xml. com.disco.maldive.util: contiene classi generiche di utilità come per esempio ParserJson, Strin- 26

28 4.3 Client gutils, MapUtils, una classe personalizzata di Log, AnimalComparator, Constants ecc. L esecuzione e l apertura dell applicazione avvia l Activity principale e, contestualmente, avviene l inizializzazione delle strutture dati che riflettono lo stato del database. È importante ricordarsi che un inserimento o una modifica in tali strutture dati non implica la modifica su database locale, quindi ad ogni modifica bisogna stare attenti ad aggiornare (inserire, modificare o eliminare) la relativa tupla sul database. Una classe importante, spesso usata dagli adapter del progetto, è Async- Task [10]. Tutte le interazioni con la rete, compresi i download degli avvistamenti e delle immagini, devono essere gestite come AsyncTask per non impattare sul thread principale e rallentare l applicazione. Un asynchronous task è definito come una computazione che si esegue su un thread in background e i cui risultati, al termine dell esecuzione, possono essere pubblicati su uno dei thread usati dall interfaccia grafica. Gli AsyncTask sono utili perchè, rispetto ai thread java, forniscono dei metodi che vengono richiamati in specifici momenti dell esecuzione del task: - doinbackground: all interno di questo metodo vanno inserite le istruzioni che devono essere eseguite in background; - onprogressupdate: in questo metodo bisogna inserire le istruzioni che mostrano sull interfaccia grafica gli avanzamenti eseguiti mentre continua la computazione del thread in background; - onpostexecute: contiene le istruzioni da eseguire quando termina l esecuzione del metodo doinbackground. I tipi principali di Adapter all interno dell applicazione sono: DbRemoteAdapter: si occupa delle comunicazione con il database remoto attraverso un WebService, fa un uso intensivo della rete e per questo ogni suo metodo implementa un AsyncTask con uno specifico onpostexecute(); DbAdapter: si occupa dell interazione con il database sqlite dell applicazione; ImagePagerAdapter: si occupa di scaricare le fotografie di un animale una volta che si apre la scheda dettagliata, così da mostrare una sorta di galleria che supporta lo swipe per spostarsi tra le foto. Dato che 27

29 4.3 Client scarica le fotografie da un nostro server, necessita di una connessione di rete e quindi utilizza gli AsyncTask. ListViewAdapter: sono degli adapter che servono per popolare le List- View correttamente, richiedono che gli sia passato nel costruttore una lista di oggetti e definiscono quale deve essere la struttura di ogni riga della lista. In questo modo in automatico la ListView viene valorizzata con gli elementi della lista, cioè ciascun elemento del layout viene riempito con i valori di ogni elemento della lista. SightingInfoAdapter: si occupa di generare l Info Window di ogni marker nella mappa degli avvistamenti. Questo permette all utente di ottenere informazioni sul singolo avvistamento in modo rapido e diretto senza dover cambiare schermata. Una volta inizializzato il database locale dopo il parsing del Json e caricate le strutture dati in memoria tramite gli Adapter, vengono elaborati i Fragment, le Activity e i relativi layout (la componente View, di fatto). I layout sono inseriti in /res/layout/ e per collegare un layout a un Activity, quindi collegare una view con la relativa logica, basta richiamare il metodo setcontentview con il layout opportuno nel metodo oncreate dell activity: public class MyActivity extends Activity protected void oncreate(bundle savedinstancestate) { setcontentview(r.layout.myactivitylayout); } } Nel caso di cui sopra, la stringa R.layout.MyActivityLayout identifica in maniera univoca il file xml di layout inserito nel percorso res/layout/ dell applicazione. In altre parole, esisterà un file /res/layout/myactivitylayout.xml che verrà legato all activity MyActivity. I layout xml fanno parte della componente View nel MVC e sono principalmente Relative e Linear Layout. L unica differenza tra i due è che gli elementi di un Linear Layout vengono disposti su righe differenti (o colonne differenti, se l orientation è Horizontal), mentre un Relative Layout permette di disporre più elementi sulla stessa riga. Ciascun layout, Relative o Linear, può contenere degli elementi di tipo View: 28

30 4.3 Client TextView, ScrollView, EditView, ImageView ecc. Tutti questi elementi, così come i Layout, possono essere configurati sia da XML che in via programmativa, cioè dall activity che carica il layout. Addirittura è possibile definire, creare e aggiungere interi Fragment in maniera programmativa a un layout senza averli definiti nell XML, ma il contrario non é possibile (non è possibile, cioè, eliminare in via programmativa fragment definiti e creati nel layout XML). Ad esempio, la ListView row animal è un layout che definisce come devono posizionarsi gli elementi in ciascuna riga dell AnimalsList, e si presenta come un RelativeLayout con altri Layout e View all interno: <RelativeLayout xmlns:android=" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="5dip"> <LinearLayout android:id="@+id/thumbnail" android:layout_width="wrap_content" android:layout_height="wrap_content" android:padding="3dip" android:layout_alignparentleft="true" android:layout_marginright="5dip"> <ImageView android:id="@+id/list_image" android:layout_width="50dip" android:layout_height="50dip" android:contentdescription="@string/thumbnail" android:src="@drawable/ic_fish_default"/> </LinearLayout> <TextView android:id="@+id/textviewscientificname" android:layout_width="wrap_content" android:layout_height="wrap_content" 29

31 4.3 Client android:layout_marginright="20dp" android:text="" android:textcolor="#313131"/> <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="" android:textcolor="#959595"/> <ImageView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentright="true" android:layout_centervertical="true" </RelativeLayout> Una funzionalità ancora non implementata, ma che è stata comunque predisposta (Sezione 7.2), è la gestione delle lingue per quanto riguarda l interfaccia utente. Android permette di esportare tutte le stringhe dell interfaccia nel file /res/values/strings.xml, quindi è possibile creare localizzazioni dell applicazione traducendo le stringhe del file strings.xml. Da codice è possibile recuperare la lingua del dispositivo attraverso la primitiva: Locale.getDefault().getDisplayLanguage(); così da caricare manunalmente il file strings.xml, o eventuali altri file tradotti, in accordo con la lingua del dispositivo. La primitiva per trovare la lingua del dispositivo può essere utilizzata anche per selezionare i nomi comuni delle specie marine da leggere dal file JSON. Non è inusuale trovare pesci con 30 o 40 nomi comuni di cinque o 30

32 4.4 Sincronizzazione dei dati sei lingue diverse, quindi è utile selezionare subito quelli in accordo con la lingua del dispositivo onde evitare di inserire sul database locale dati inutili per l utente. 4.4 Sincronizzazione dei dati La logica di sincronizzazione si è resa necessaria per migliorare il coinvolgimento attivo dell utente, dandogli la possibilità di creare avvistamenti, condividerli, e ricevere avvistamenti da altri utenti. Ovviamente la logica di sincronizzazione degli avvistamenti richiede la comunicazione tra client e server, e il riconoscimento univoco dell utente locale (che ha fatto il login). Per l utente che non ha effettuato login è disponibile la sincronizzazione degli avvistamenti effettuati da altri utenti (che vengono scaricati in locale nell applicazione), mentre per chi ha fatto login è anche possibile creare avvistamenti, che vengono sincronizzati e inviati al server. Questo è reso possibile dal vincolo che ciascun utente deve avere un diversa, infatti una volta associato l utente locale a quello remoto grazie al campo , la componente server (Sezione 4.2) risponde con l identificativo univoco di quell utente che, come si vede in Figura 6 e in Figura 9, è un campo che appartiene a ciascun avvistamento. Come è possibile vedere nel diagramma in Figura 10, la sincronizzazione è attiva anche se l utente non è loggato né registrato, semplicemente riguarderà gli ultimi avvistamenti senza nessuna attenzione per i suoi (Scenario IV), in più non potrà creare nuovi avvistamenti da inviare al server, dato che per creare nuovi avvistamenti bisogna essere registrati (Scenari I, II, III). Ovviamente questa distinzione ha senso solo se il dispositivo è connesso, dato che in ogni caso non potremmo sincronizzare nulla in assenza di connettività. Le principali dinamiche di sincronizzazione sono quattro e presentano casistiche diverse a seconda che l utente sia connesso o meno: I - Creazione di un avvistamento (online) Scenario: Un utente loggato crea un avvistamento e lo conferma, viene invocata l API /createsighting della componente server, a cui viene fatta una request POST con i parametri dell avvistamento. I parametri da inviare al web service sono: id della specie marina, data e ora del- 31

33 4.4 Sincronizzazione dei dati l avvistamento, id utente remoto, latitudine e longitudine. Il dispositivo è connesso alla rete. Gestione: Se non esiste un avvistamento sul database remoto con questi stessi parametri, viene fatto un inserimento dell avvistamento, altrimenti esiste già e non viene inserito. La risposta del server comprende l id univoco dell avvistamento se questo è stato creato o esiste già, che viene inviato come file json al client, che inserisce l avvistamento in locale con l id remoto. Se accadono errori, ad esempio si verifica un eccezione o un errore di comunicazione, la risposta del server mostrerà l errore, il client se ne accorgerà e inserirà l avvistamento in locale (senza identificativo remoto) per tentare una sincronizzazione più avanti. II - Creazione di un avvistamento (offline) Scenario: Come Creazione di un avvistamento (online) (Scenario I), l unica differenza è che il dispositivo non è connesso alla rete. Gestione: L avvistamento non viene inviato al server, viene inserito nel database locale senza id remoto dell avvistamento. In questo modo verrà sincronizzato più avanti, quando sarà presente la connessione di rete, tramite Sincronizzazione di un avvistamento creato offline (Scenario III). III - Sincronizzazione di un avvistamento creato offline Questo scenario tratta la sincronizzazione degli avvistamenti locali in attesa di essere inviati sul server, creati offline da un utente loggato tramite lo Scenario II Creazione di un avvistamento (offline). La figura 10 descrive il processo di sincronizzazione. Scenario: alla prima apertura dell applicazione con connessione dati attiva e l utente loggato, ciascun avvistamento in attesa di essere sincronizzato viene recuperato dal database locale e viene inviato al server tramite l API /createsighting. Gestione: Una volta ricevuta la risposta dal server, il client analizza il json e capisce cosa è successo. Gli scenari principali sono tre: a. Avvistamento non inserito per errori Scenario: L avvistamento non è stato inserito in remoto in seguito a errori nei parametri passati o errori di rete. 32

34 4.4 Sincronizzazione dei dati Gestione: La sincronizzazione dell avvistamento in questione verrà ritentata più avanti. b. Avvistamento non inserito perchè esiste già Scenario: L avvistamento non è stato inserito in remoto perchè esiste già un avvistamento identico sul database remoto. Gestione: Il server risponde con un file json che contiene i campi dell avvistamento remoto, compreso l id univoco dell avvistamento. L avvistamento locale del client viene aggiornato con l id remoto dell avvistamento che esisteva già, perchè identico. c. Avvistamento inserito Scenario: L avvistamento è stato inserito correttamente. Gestione: L avvistamento locale viene aggiornato con l id remoto inviato nella response. IV - Download degli ultimi avvistamenti (online) Scenario: Il client si avvia e il dispositivo è connesso. Gestione: Vengono scaricati gli ultimi 100 avvistamenti dal server, tramite l API /getlastsightings esposta dal server e vengono inseriti nel database locale, per essere visualizzati anche offline dall utente. 33

35 4.4 Sincronizzazione dei dati Figura 10: BPMN che illustra il processo di sincronizzazione degli avvistamenti locali non ancora inviati al server 34

36 Guida tecnica alle funzionalità 5 Guida tecnica alle funzionalità Per permettere una più chiara comprensione della struttura del progetto dell applicazione Android, delle classi e dei layout, di seguito vengono mostrate le funzionalità con le Activity e i layout correlati. In questo modo cercando una classe o un layout sarà possibile trovare la funzionalità e le risorse correlate. Per una panoramica grafica sulle interazioni, si veda lo sketch in Figura 11. activity animal details.xml Activity AnimalDetails.java activity animal search.xml Activity AnimalSearch.java activity animal sightings.xml Activity AnimalSightings.java activity insert animal.xml Activity InsertAnimal.java activity insert marker.xml Activity InsertMarker.java activity insert sighting.xml Activity insertsighting.java activity main.xml Activity Main.java drawer list item.xml NavDrawerItem.java fragment animal add sighting.xml Fragment AnimalAddSighting.java fragment animal description.xml Fragment AnimalDescription.java fragment animal images.xml Fragment AnimalImages.java fragment animals list.xml Fragment AnimalsList.java fragment credits.xml Fragment Credits.java fragment date picker.xml Fragment DatePicker.java fragment fish description.xml Fragment FishDescription.java fragment home favourites.xml Fragment HomeFavourites.java fragment home sightings.xml Fragment HomeSightings.java fragment login.xml Fragment Login.java fragment main.xml Fragment Main.java fragment map add sighting.xml Fragment Map InsertSighting.java fragment navigation drawer.xml Fragment NavigationDrawer.java fragment settings.xml Fragment Settings.java fragment sightings.xml Fragment Sightings.java fragment time picker.xml activity insert sighting.xml listview row animal insert.xml ListViewAdapter AnimalList Insert.java listview row animal.xml ListViewAdapter AnimalList.java listview row favorite.xml ListViewAdapter FavoriteList.java listview row mysightings.xml ListViewAdapter MySightingsList.java 35

37 5.1 Ricerca delle specie marine selector home favorite.xml selector navigation drawer.xml sighting info.xml view pager.xml listview row favorite.xml fragment navigation drawer.xml fragment sightings.xml Fragment AnimalImages.java Figura 11: Sketch che mostra le principali interazioni tra le activity. Ciascuna interazione e identificata dal colore del cursore (l immagine della manina) e dal colore della freccia uscente dalla schermata. 5.1 Ricerca delle specie marine Caso d uso: l utente, selezionando l elenco delle specie dal menu a scomparsa, puo fare delle ricerche per trovare la specie marina desi36

38 5.2 Scheda dettagliata derata. Viene fornito un elenco con i pesci e vengono forniti i nomi comuni, il nome scientifico e una thumbnail di ciascun pesce. L utente ha la possibilità di filtrare la lista dei pesci scrivendo l iniziale di un nome (comune o scientifico). Risorse Activity: Activity Main, Fragment AnimalsList Adapter: ListViewAdapter AnimalList Altro: IndexableListView Layout: activity main.xml (Activity Main), fragment animals list.xml (Fragment AnimalsList), listview row animal.xml (ListViewAdapter AnimalList) Spiegazione: Activity Main alla prima apertura dell applicazione recupera dal database locale la lista dei pesci e altre informazioni, così da renderle disponibili successivamente. Activity Main contiene, tra i vari fragment del navigation drawer (il menu a scomparsa dell applicazione), Fragment AnimalsList. Fragment AnimalsList fa uso di una listview per mostrare la lista di pesci, che viene popolata tramite l adapter ListViewAdapter AnimalList. La listview è filtrabile grazie alla classe IndexableListView. Il layout di ciascun elemento della listview è definito da listview row animal.xml, e il tocco sull elemento porta alla scheda dettagliata della specie marina selezionata. 5.2 Scheda dettagliata Caso d uso: dall elenco dei pesci presenti nella lista delle specie marine (Sezione 5.1), l utente può selezionare il pesce desiderato e visualizzare la scheda tecnica della specie. La scheda dettagliata deve mostrare il nome scientifico, i nomi comuni, una descrizione, la classificazione scientifica, e altri dettagli della specie marina. Dalla scheda dettagliata è possibile visualizzare gli ultimi avvistamenti del pesce e crearne di nuovi (Sezione 5.3). È inoltre possibile inserire il pesce tra i preferiti cliccando sulla stella in alto a destra (Sezione 5.5). Risorse Activity: Activity AnimalDetails, Fragment AnimalImages, Fragment AnimalDescription, Fragment FishDescription 37

39 5.3 Creazione e visualizzazione degli avvistamenti Adapter: ImagePagerAdapter Layout: activity animal details.xml (Activity AnimalDetails), fragment animal images.xml (Fragment AnimalImages), fragment animal description.xml (Fragment AnimalDescription), fragment fish description.xml (Fragment FishDescription), view pager.xml (ImagePagerAdapter) Spiegazione: Activity AnimalDetails contiene tutte le informazioni sul pesce desiderato. Fragment AnimalImages contiene le immagini del pesce, che sono sfogliabili come una galleria grazie all ImagePagerAdapter che le scarica man mano che vengono richieste utilizzando una libreria che fornisce funzionalità di ImageLoader. Fragment AnimalDescription contiene i campi di classificazione scientifica e i nomi comuni, mentre Fragment FishDescription contiene le informazioni specifiche del pesce. Cliccando sulla stella in alto a destra il pesce verrà inserito tra le specie preferite, mentre cliccando sul Position Marker vengono visualizzati i suoi ultimi avvistamenti. 5.3 Creazione e visualizzazione degli avvistamenti Caso d uso: dalla scheda tecnica del pesce (Sezione 5.2), l utente può premere il tasto con l icona del Position Marker sulla destra e aprire così la mappa con gli avvistamenti di quella determinata specie. Da lì può passare alla creazione dell avvistamento, inserendo la data e posizionando il Position Marker per selezionare la posizione. Ogni avvistamento creato viene condiviso con gli altri utilizzatori dell applicazione. L utente ha anche la possibilità di visualizzare gli ultimi 100 avvistamenti, senza distinzione di specie. Dal menu principale deve selezionare Sightings, e avrà la possibilità di creare un nuovo avvistamento inserendo data, ora, posizione e specie marina. Per creare un avvistamento bisogna essere registrati (Sezione 5.4). Risorse Activity: Activity AnimalSightings, Activity InsertAnimal, Activity InsertMarker, Activity insertsighting, Fragment AnimalAddSighting, Fragment DatePicker, 38

40 5.4 Registrazione e Login Fragment Map InsertSighting, Fragment Sightings, Fragment TimePicker Adapter: DbAdapter, ListViewAdapter AnimalList Insert, Indexable- ListView, DbRemoteAdapter, Layout: activity animal sightings.xml (Activity AnimalSightings), activity insert animal.xml (Activity InsertAnimal), activity insert marker.xml (Activity InsertMarker), activity insert sighting.xml (Activity insertsighting), fragment animal add sighting.xml (Fragment AnimalAddSighting), fragment date picker.xml (Fragment DatePicker), fragment map add sighting.xml (Fragment Map InsertSighting), fragment sightings.xml (Fragment Sightings), fragment time picker.xml (Fragment TimePicker) Spiegazione: La visualizzazione degli avvistamenti è possibile grazie a un fragment contenente una mappa (MapFragment, fornita da Google). È possibile visualizzare un MapFragment dalla scheda tecnica del pesce (Activity AnimalSightings) toccando sul Position Marker sulla destra, e dal fragment Sightings (Fragment Sightings) del Navigation Drawer (il menu a scomparsa dell applicazione). In entrambi i casi, toccando sull icona in basso a destra si può inserire un nuovo avvistamento. L activity di inserimento degli avvistamenti è Activity InsertSightings, che contiene principalmente quattro fragment, uno per i parametri da inserire: - Fragment DatePicker (per inserire la data); - Fragment TimePicker (per inserire l ora); - Fragment AnimalAddSighting che mostra la specie marina selezionata attraverso Activity InsertAnimal (la selezione avviene grazie all adapter ListViewAdapter AnimalList Insert); - Fragment Map InsertSighting che mostra la posizione selezionata attraverso Activity Insert Marker. La creazione dell avvistamento sul server è possibile tramite la classe DbRemoteAdapter, mentre l inserimento locale avviene attraverso il DbAdapter. 5.4 Registrazione e Login Caso d uso: L utente può accedere alla funzionalità di login dal menu principale, selezionando la voce Login. A questo punto cliccando sul 39

41 5.5 Specie marine preferite e avvistamenti creati pulsante di login con l icona di Google Plus, e accettando di concedere i permessi all applicazione, l utente risulterà loggato e sull applicazione verrà salvato un token rilasciato da Google. A questo punto l utente potrà creare avvistamenti 5.3, e aggiungere le specie marine tra quelle preferite 5.5. Risorse Activity: Activity Main, Fragment Login Adapter: DbRemoteAdapter, DbAdapter Layout: activity main.xml (Activity Main), fragment login.xml (Fragment Login) Spiegazione: Cliccando sulla sezione Login nel Navigation Drawer si accede a Fragment Login, che mostra un bottone che consente di loggarsi con Google Plus. L interazione con il server è realizzabile tramite i metodi in DbDremoteAdapter e l inserimento locale dell utente viene fatto tramite il DbAdapter. 5.5 Specie marine preferite e avvistamenti creati Caso d uso: L utente loggato (Sezione 5.4) dopo aver creato un avvistamento (Sezione 5.3), potrà trovarlo anche nella schermata principale (Home) nella scheda Your Sightings. Inoltre l utente può aggiungere un pesce alle specie marine preferite dalla scheda tecnica (Sezione 5.2) e ritrovarlo nella Home nella tab Your Favorites. Risorse Activity: Fragment Main, Fragment HomeFavourites, Fragment HomeSightings Adapter: ListViewAdapter FavoriteList, ListViewAdapter MySightingsList Layout: fragment main.xml (Fragment Main), fragment home favourites.xml (Fragment HomeFavourites), fragment home sightings.xml (Fragment HomeSightings) Spiegazione: All apertura del Fragment Main vengono caricati due fragment (Fragment HomeFavourites e Fragment HomeSightings), che 40

42 5.5 Specie marine preferite e avvistamenti creati mostrano all utente registrato rispettivamente le sue specie marine preferite e gli avvistamenti fatti da lui. Per popolare questi fragment in maniera dinamica sono stati utilizzati degli adapter (ListViewAdapter FavoriteList e ListViewAdapter MySightingsList) che vanno a valorizzare due listview. 41

43 Guida utente alle funzionalità 6 Guida utente alle funzionalità Le funzionalità derivanti dai requisiti presentati nelle precedenti sezioni sono le seguenti: Ricerca delle specie marine (6.1); Visualizzazione schede dettagliate e immagini delle specie marine (6.2); Creazione e visualizzazione degli avvistamenti (6.4); Registrazione e Login (6.3); Visualizzazione delle specie preferite e degli avvistamenti creati (6.5); User interface e User experience (2); 6.1 Ricerca delle specie marine La ricerca delle specie marine è un elenco di pesci in ordine alfabetico filtrabile per nome scientifico e per tutti i nomi comuni nella lingua di sistema del dispositivo. Poiché le specie marine sono molte (solo i pesci sono circa 1200), per rendere i contenuti fruibili è stata prevista anche una modalità di scorrimento rapido dell elenco di specie (vedi Figura 12): 42

44 6.2 Scheda dettagliata Figura 12: Funzionalità di ricerca delle specie marine (activity AnimalsList) Per ciascuna specie è stata predisposta una thumbnail, che viene scaricata insieme all applicazione e quindi è sempre disponibile anche durante l utilizzo offline, così da rendere più facile l identificazione di una specie. 6.2 Scheda dettagliata La scheda di dettaglio di ciascuna specie marina contiene informazioni divise in cinque macro sezioni: Intestazione, mostra il nome scientifico latino della specie. Galleria immagini, mostra le immagini della specie marina. Descrizione, contiene informazioni come i nomi comuni, il numero di spine dorsali, il numero di pinne, il numero totale di raggi e il colore in vita. Classificazione biologica, contiene i campi Famiglia, Ordine, Classe, Phylum, Genere. 43

45 6.2 Scheda dettagliata Dettagli della specie marina, contiene indicazioni sulla lunghezza e il peso massimo del pesce, il rischio di estinzione, la pericolosità per l uomo, l ambiente in cui vive (profondità e intervallo di coordinate), una spiegazione sulla biologia e il comportamento. La scheda dettagliata è raggiungibile attraverso la ricerca delle specie (Sezione 6.1). Un esempio di scheda dettagliata è mostrata in Figura 13, dove è possibile vedere la specie Gerres Iongirostris che non è tra le specie preferite, con il nome comune e la descrizione. Figura 13: Funzionalità di visualizzazione della scheda dettagliata di una specie marina (activity AnimalDetails) Scorrendo da destra verso sinistra con un dito nella sezione delle immagini del pesce verranno scaricate le fotografie da un apposito server e verranno mostrate in automatico nell applicazione. Toccando la stella in alto si può aggiungere l animale tra i preferiti così da poterlo vedere nella home (Sez. 6.5), mentre toccando l icona situata sulla destra subito sotto l immagine, rappresentata mediante il Position Marker, si apre un activity che mostra gli ultimi avvistamenti di quella specie e in 44

46 6.3 Registrazione e Login cui sarà possibile inserire un nuovo avvistamento specificando data, specie marina e posizione (vedi Figura 14, Sezione 6.4). 6.3 Registrazione e Login Un altra funzionalità è la registrazione, che viene effettuata attraverso social network e attualmente solo con Google Plus, sfruttando il fatto che ogni utente Android possiede anche un profilo Google (e quindi anche Google Plus). 6.4 Creazione e visualizzazione degli avvistamenti Figura 14: Inserimento di un nuovo avvistamento In Figura 14 viene mostrato uno degli accessi all altra principale funzionalità dell applicazione: la creazione e visualizzazione degli avvistamenti, che supporta i turisti durante l esplorazione. Per garantire una maggiore 45

47 6.5 Specie marine preferite e avvistamenti creati affidabilità degli avvistamenti e per motivi di profilazione, l inserimento di un sighting è stato predisposto solo per gli utenti registrati 5. Un avvistamento può essere inserito da punti diversi: o a partire dalla scheda dettagliata dell animale, dopo aver quindi già identificato la specie marina, o a partire dalla visualizzazione degli ultimi avvistamenti, raggiungibili attraverso il menu a scomparsa posto sul lato sinistro (tale menu è chiamato Navigation Drawer). 6.5 Specie marine preferite e avvistamenti creati Tra le varie funzionalità vi è anche la visualizzazione dei Favorite e Sightings creati dall utente nella home dell applicazione. Qui l utente registrato potrà visualizzare le proprie specie preferite e gli avvistamenti che lui ha creato. Attualmente gli avvistamenti vengono scaricati subito dopo il login e ogni volta che si accede all activity di visualizzazione degli avvistamenti (vedi Figura 15). Toccando su ciascun elemento è possibile visualizzare la scheda dettagliata della specie marina in questione, da cui si possono visualizzare gli ultimi avvistamenti e crearne di nuovi. 5 La registrazione avviene attraverso Google+, applicazione preinstallata in Android a cui ogni utente Google è iscritto (si veda la Sezione 6.3). 46

48 6.5 Specie marine preferite e avvistamenti creati Figura 15: Schermate di visualizzazione dei pesci preferiti e degli avvistamenti dell utente 47

49 Future estensioni 7 Future estensioni 7.1 Dati multilingua Attualmente il file json discusso nella Sezione 4.3 presenta solo le informazioni delle specie marine in inglese, in quanto il crawler di cui si è parlato nella Sezione Client ha recuperato solo le informazioni di FishBase in lingua inglese. Nel momento in cui il crawler verrà predisposto per scaricare le informazioni in altre lingue, queste dovranno essere poi inserite nel database remoto seguendo la struttura esposta nella Sezione 4.1 (in particolare si veda l esempio mostrato in Figura 6). Inoltre la componente server dovrà gestire le richieste in più lingue, e per farlo bisognerà aggiungere un parametro nella request (Sezione 4.3, classe DbRemoteAdapter), così che i controller di Laravel possano recuperare i dati tradotti. 7.2 App multilingua Per tradurre l applicazione Android, cioè tutte le etichette presenti nei menu, bottoni ecc, bisogna localizzare il file /res/values/strings.xml introdotto alla fine della Sezione 4.3 e inserirlo nel percorso appropriato (ad esempio res/values-fr/strings.xml per il francese e così via). Sono state seguite tutte le best practices possibili per agevolare un futuro processo di traduzione [11]. 7.3 Sincronizzazione specie preferite Attualmente le specie preferite di un utente registrato non vengono sincronizzate. Per introdurre questa funzionalità basta seguire gli scenari di sincronizzazione esposti per gli avvistamenti (Sezione 4.4). Andrà aggiunta una tabella favorite al database mostrato in Figura 6, andranno aggiunte delle API a quelle già esistenti su laravel (Sezione 4.2) e andrà creato un opportuno controller. Le API da esporre saranno all incirca 2: /createfavorite, che farà uso del metodo HTTP POST, inserirà una riga nella tabella favorite sapendo l id dell utente e quello della specie marina. 48

50 7.4 Implementazione degli apprezzamenti (like) /getuserfavorites, che farà uso del metodo HTTP GET e si occuperà di recuperare le specie preferite dato l id utente. 7.4 Implementazione degli apprezzamenti (like) Seguendo la struttura di package esposta nella sezione 4.3 e la spiegazione delle classi in sezione 5, per implementare i like (cioè gli apprezzamenti degli avvistamenti) bisogna inserire nelle Activity che mostrano gli avvistamenti su una mappa un listener per gestire il click sul pulsante like. Poi andrà creato un metodo nella classe DbRemoteAdapter che comunicherà con il WebService. La comunicazione andrà gestita tramite AsyncThread e andrà richiamato il web service su delle apposite API come fatto per altre funzioni nella Sezione 4.2. Le API dovranno permettere di inserire il like ad un avvistamento e di rimuoverlo. Andrà controllato che un utente non possa inserire più volte il like allo stesso avvistamento. Una volta inserito un like ad un avvistamento, viene incrementato un contatore nel profilo dell utente che l ha creato, così da creare anche una reputazione per gli utenti che creano gli avvistamenti migliori. La reputazione degli utenti si calcola dividendo il contatore degli avvistamenti dell utente per il numero di avvistamenti che l utente ha creato, fornendo così un indice di affidabilità. 7.5 Raggruppamento marker Una funzionalità utile potrebbe essere quella di raggruppare i marker relativi ad avvistamenti molto vicini. Dal punto di vista semantico questa funzionalità ha senso solo se la specie marina avvistata è la medesima. È sensato aggiungere una feature di questo tipo perchè la quantità di marker realmente distinguibili sulla mappa dipende dallo zoom che l utente applica, e se due avvistamenti della stessa specie vengono fatti esattamente nello stesso posto (o molto vicini tra loro) non ha senso inserire due marker di cui ne visualizzerò sempre e solo uno (quello che sta sopra). Per implementare questa funzionalità vanno modificate le classi che mostrano gli avvistamenti (si veda la Sezione 5 per una panoramica delle classi). Nello specifico, nel momento in cui vengono caricati i marker sulla mappa bisogna inserire nello stesso InfoWindow (la finestra che si apre cliccando su un marker, detto anche snippet) le informazioni dei due o più avvistamenti e caricarle sullo stesso marker. Questo comporta anche la creazione di un 49

51 7.6 Inserimento settings layout specifico per gli snippet raggruppati, che andrà creato in /res/layout. Se si vuole raggruppare anche molti avvistamenti, si renderà necessaria la creazione di un Adapter (da inserire nel package adapter, come spiegato nella Sezione 4.3) per popolare la ListView degli snippet. 7.6 Inserimento settings L inserimento di un fragment per la gestione delle impostazioni va fatto all interno del Fragment Settings. Alcune funzionalità interessanti da inserire potrebbero essere, ad esempio: La selezione del numero di avvistamenti da scaricare (i getlastsightings, che vengono visualizzati nella schermata Fragment Sightings). La selezione del numero di avvistamenti da visualizzare nella scheda dettagliata della specie marina (Activity AnimalDetails). La selezione del range di date di cui si vogliono scaricare gli ultimi avvitamenti. 7.7 Altri sistemi di login In futuro si potrebbe scegliere di implementare altri sistemi di login con i social network come Facebook o Twitter, come anche una registrazione e un login standard. Sarebbe utile per aggiungere funzionalità di condivisione sui social network per gli avvistamenti migliori o dei pesci preferiti. Per gestire la login e registrazione occorre andare a modificare il Fragment Login, che attualmente implementa il login solo con Google Plus, come è possibile vedere nella sezione Migliorare la significatività degli avvistamenti Per aumentare la qualità e la significatività degli avvistamenti, si dovrebbe controllare che, durante la creazione degli avvistamenti (funzionalità 6.4, classe Activity InsertSighting), il marker sia posizionabile esattamente nella regione delle Maldive e in corrispondenza di coordinate a cui è associata una superficie acquatica. La classe che si occupa di inserire il marker, permettendone il posizionamento sulla mappa è Activity InsertMarker. 50

52 7.9 Proteggere API del Web Service Per ulteriori approfondimenti si faccia riferimento all argomento Google Maps Reverse Geocoding, con particolare attenzione al campo type della response json ritornata da Google [12] [13]. 7.9 Proteggere API del Web Service Attualmente non è stato predisposto alcun modo per proteggere le API del Web Service. Implementando una nuova classe di Registrazione, si potrebbe utilizzare un sistema di token con il server, creando un nuovo metodo nel DbRemoteAdapter (Sezione 4.3). In questo caso si legga la documentazione di Laravel, e in particolare la sezione Security [14]. Nella futura implementazione andrà sicuramente preso in considerazione il fatto che non tutte le parti devono prevedere autenticazione. Ad esempio il download degli ultimi avvistamenti possono non avere autenticazione, mentre altre potrebbero prevedere una Http basic authentication. In questo modo il client può mandare le credenziali dell utente e queste vengono verificate lato server. Il tutto poi dovrebbe prevedere connessioni HTTPS, per evitare le credenziali vengano trasmesse in chiaro Ricerca dicotomica L applicazione attualmente è dotata di una ricerca testuale per nome scientifico e i nomi comuni, ma l idea iniziale era quella di fornire una ricerca basata su vari parametri (colore, grandezza, forma ecc) così da poter identificare anche specie di cui non si conosce il nome. Un alternativa potrebbe essere la ricerca di che permette di partire dalle classi più generiche di classificazione, facendo scegliere all utente via via la classificazione più specifica del pesce basandosi su confronti con immagini stilizzate. Questi sistemi di ricerca non sono stati implementati perchè soffrono di lacune importanti e non si sa come potrebbero essere colmate. Ad esempio manca una base di conoscenza da usare per trovare i pesci basandosi su parametri morfologici come colore o grandezza (fishbase non contiene tutte le informazioni per tutti i pesci). Anche la ricerca di fishbase.org è lacunosa, spesso richiede confronti tra decine e decine di immagini molto simili tra loro, che riducono l efficacia della ricerca portando facilmente a errori. Per una spiegazione dettagliata dei tentativi fatti da cui prendere spunto per lo sviluppo di una ricerca dicotomica si veda la Sezione 8. 51

53 Conclusioni 8 Conclusioni Il lavoro di stage è consistito nella creazione di un applicazione chiamata MalDiving, i cui obiettivi sono quelli di rendere possibile la creazione e la condivisione di avvistamenti di specie marine, migliorando la divulgazione dei pesci e dei coralli delle Maldive. Per far si che i turisti riescano agilmente a creare nuovi avvistamenti di pesci o specie marine che hanno visto durante un immersione, abbiamo sfruttato le mappe di Google integrate in Android, tra i vari Google Play Services, che permettono la compatibilità con tutti i dispositivi Android presenti e futuri con mappe sempre aggiornate. La progettazione e l implementazione dell applicazione è stata completata, la maggior parte degli scenari sono stati presi in considerazione. Sia il lato Android che il lato server sono stati sviluppati, anche l interazione tra i due (la logica di sincronizzazione) è stata implementata. Altri scenari di sincronizzazione, come il ranking o l aggiunta di un like a degli avvistamenti, sono solo stati abbozzati, ma seguendo i ragionamenti discussi e argomentati nella presente tesi potranno essere integrati senza problemi, prendendo spunto dagli scenari di sincronizzazione degli avvistamenti ampiamente discussi e dalle estensioni proposte. Inizialmente era stata predisposta una ricerca morfologica così da poter identificare anche le specie di cui non si conosce il nome. Purtroppo quest idea è stata presto abbandonata dopo aver osservato che non esiste attualmente un informazione riguardante i colori delle specie marine, nè questa è facilmente recuperabile. Una soluzione poteva essere quella di fare delle analisi sulle immagini per recuperare i colori dell animale, ma questo non è stato possibile. Le fotografie in nostro possesso sono amatoriali e derivanti da avvistamenti, quindi il pesce non è mai fotografato dalla stessa prospettiva e questo ne rende difficile l isolamento rispetto allo sfondo (che spesso è un branco o una roccia, non un colore uniforme). In più i colori dipendono dalle condizioni di luce e dallo strumento, e spesso i pesci cambiano tonalità di colore durante la propria vita. È stata anche pensata una ricerca morfologica basata sulla forma dell esemplare marino così come implementata su fishbase.org. Essa prevede quattro passi, ognuno dei quali, attraverso la scelta di un illustrazione stilizzata di un pesce o di un gruppo di pesci, indirizza l utente verso una una classificazione più specifica. Per l esattezza questi passi individuano nell ordine: Classe, Ordine, Famiglia ed infine la Specie arrivando, con quest ultima, al pesce ricercato. Un esempio concettuale di questo tipo di ricerca è rappresentato 52

54 Conclusioni in Figura 16. L idea si è rivelata non realizzabile. È stato chiesto a cinque Figura 16: Ricerca avanzata di fishbase.org persone di scegliere un pesce e visualizzarne un ottima fotografia, per poi cercarlo seguendo questa ricerca. Il risultato è stato che 4 su 5 (l 80%) non sono stati in grado di identificare la specie marina, mentre uno solo ce l ha fatta. C è anche da considerare che non si tratta di uno scenario reale: un turista che cerca un pesce dopo averlo visto di sfuggita durante un immersione. Inoltre il problema di questa strategia di ricerca è che avrebbe portato a scegliere tra circa 300 immagini stilizzate, alcune delle quali molto simili tra loro ma molto significative da un punto di vista della ricerca, dato che una qualunque scelta errata avrebbe fatto imboccare un percorso di ricerca sbagliato, portando sicuramente a scartare l animale cercato. Grazie all Ateneo e a Maldives Marketing & Public Relations Corporation- MMPRC, MalDiving verrà presentata a EXPO 2015 che si terrà a Milano a partire dal mese di Maggio. La collaborazione prevede la realizzazione di una 53