Post on 05-Dec-2014
description
ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNASCUOLA DI INGEGNERIA E ARCHITETTURA
Dipartimento di Informatica - Scienza e IngegneriaCorso di Laurea in Ingegneria Informatica
Tesi Di Laurea in Tecnologie Web T
Framework di Supporto allo Sviluppo di Applicazioni Georeferenziate su Android
- Collaborazione presso Mobile Activity -
CANDIDATO RELATORE Massimiliano Leone Prof. Ing. Paolo Bellavista
CORRELATORE
Dott. Giuseppe Ventura
Anno Accademico 2012-2013Sessione III
Le motivazioni dello sviluppo (1)● In seno alla collaborazione con Mobile Activity del Dott. Ventura,
si vuole realizzare un'applicazione Android per la ricerca georeferenziata di dati:
– Progetto “Aperò”, per la ricerca di bar/cafè per l'aperitivo– Altri progetti similari, per tipi differenti di ricerca: “OnYourTips”, “Mandovai”
Prima applicazione sperimentale, quale modello per successivi progetti:– Responsiva– Estendibile– Agevole mantenimento futuro– Parti comuni riutilizzabili
● Gli obiettivi fissati trovano ostacolo in alcune inefficienzedi Android standard:
– Difficoltà, in alcuni casi, nell'ottenere la geoposizione (latenza/triangolazione poco accurata)
– Assenza di un modello strutturato come MVC, indispensabile in progetti complessi
– Framework troppo focalizzato sulla UI– Implementazione onerosa per qualsivoglia attività
1
Le motivazioni dello sviluppo (2)
● L'applicazione viene generalizzata in un insieme di Framework:– Modello MVC più strutturato, alternativo all'uso di Activity quale
Controller– “Dividi et impera” - ogni componente risolve problematiche specifiche:
● retrieve della geolocation● interrogazione alla fonte di dati● persistenza
– Astrazione di onerose implementazioni tramite Command e Facade– Possibilità di facile riutilizzo in applicazioni di differente natura
● Strumenti utilizzati:– Debian Gnu/Linux– Eclipse, SDK Android, Emulatore QEMU, DDMS. Git– Samsung S5570, single core 600 Mhz
2
I lifecycle di Activity e Service
3
I Framework Sviluppati (1)
● Hermes:– implementa un MVC più strutturato della modalità standard Android,
reinterprentando l'uso dei due principali componenti, Activity e Service:● il primo avrà solo onere della gestione della vista● il secondo sarà utilizzato come contenitore del codice di business
– permette anche di svincolarsi dall'uso di Parcelable
● Diane: – rappresenta la business logic, e utilizza meccanismi “awareness” per
l'esecuzione delle ricerche geolocalizzate dei dati d'interesse– è generics-based
● Socrates:– è un helper per l'interrogazione della fonte remota (Google Places)– traduce la response JSON in oggetti Java
4
I Framework Sviluppati (2)
● Ulysses: – è una specializzazione di Diane – utilizza Socrates e fornisce ulteriori classi di comodo per gestire alcune View
● Polaris/Kusor: – wrapper per gli statement necessari al retrieve della geolocation– applica algoritmi più evoluti per ridurre la latenza del retrieve
5
L'implementazione (1)● Hermes: pattern “Service as Controller Container”
– Il Service mantiene l'istanza del Controller– La classe Connector incapsula gli statement di bind al Service,
e fornisce l'accesso all'istanza suddetta– I client (Activity/Fragment) ottengono un'istanza di Connector (Singleton),
dal quale accedono agli oggetti della la business logic@Inject Connector<MyService,MyController> conn;conn.getController().doSomething();
● Diane: logiche “aware” incapsulate nel Controller– Check della “usefulness” della fresh location prima di avviare
un nuovo task di ricerca– Garanzia del risultato: in assenza di rete uso di cache locale– Situazioni “failure” gestite con stati di ritorno o gerarchia di eccezioni
public Void search(Void... nop) throws LocationNotSoUsefulException, //.. { boolean locationUseful =locationAwareSupplier.isNewLocationUseful();
if (locationUseful) return doSearch();//..throw new LocationTooNearException(); // if false
}
6
L'implementazione (2)
● Socrates: utilizza Google Http Java Client, di cui sfrutta il sistema di binding JSON/Java, effettuato tramite annotations e reflection
@Inject Searcher searcher;SearchResponse searchResponse = searcher.search( newFreshLocation );List<Place> places = searchResponse.getStatus()
.handleStatusAndGetData(searchResponse);
● Polaris/Kusor:utilizza Novocation, che sfrutta il PendingIntent in luogo di LocationListener, nonché il Passive_Provider
@Inject Locator locator;locator.startLocationUpdates(); / locator.stopLocationUpdates();Location location = locator.getLocation();
● Uso globale dell'Inversion of Control tramite RoboGuice
7
Demo Application “Ratafìa” (1): main
8
Demo Application “Ratafìa” (2): search
9
Demo Application “Ratafìa” (3): result
10
Demo Application “Ratafìa” (4): list
11
Demo Application “Ratafìa” (5): map
12
Test e risultati sperimentali● L'applicazione finale Ratafìa impiega ~2,3 sec ● Ricerca dei esaurita in ~16,3 sec● Spazio occupato: ~1,1MB, di cui
~900kB (post dexing) per i jars da includere ● Memoria occupata:
– Complessiva: ~7,4MB per View leggere (List); ~12,4MB per MapView
– Heap (post garbage collection degli oggetti della View): ~4,2 MB ● Tempi impiegati per i controlli “aware”: ~0,032ms
13
Conclusioni e estensioni future
● Le soluzioni proposte, alla luce dei test, risultano funzionalie pienamente utilizzabili in fase di produzione
● Tempi brevi per lo sviluppo dell'applicazione demo “Ratafìa”,a dimostrazione della facile integrazione dei framework illustrati
● Applicazioni dagli intenti similari, di cui i progetti all'inizio - ma non solo - possono giovare della bontà dei componenti, e focalizzare l'impegno per proprie specifiche funzionalità
Intenti futuri● Diane:
implementare un sistema di cache (NoSQL o SQLite+ORM)● Ratafìa:
estrapolando parti significative, astrarre ad un framework per la gestione dell'interfaccia grafica, utilizzando efficienti UI pattern (ActionBar, Drawer Navigation, etc.)
14