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