Università degli Studi di Salerno Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Car Sharing Mobile v1.0 Android Daniele Cafaro 0622700020 Gianfranco Cerrato 0622700029 Antonello De Stefano 0622700018 Anno Accademico 2010/2011 Sistemi Operativi Prof. Pierluigi Ritrovato

Overview Android Sicurezza e Permessi Car Sharing Mobile Conclusioni Che cos’è? L’architettura I mattoni di base SDK & ADT Sicurezza e Permessi Certificate Permission URI Android Security Model Car Sharing Mobile L’applicazione L’architettura Il server REST Il client L’ambiente di Test Conclusioni

android Android è una piattaforma per dispositivi mobili che include il sistema operativo ed un vero e proprio stack di strumenti e librerie per la realizzazione di applicazioni mobili. Esso ha come obiettivo quello di fornire tutto ciò di cui un operatore, un vendor di dispositivi o uno sviluppatore hanno bisogno per raggiungere i propri obiettivi. Android ha la fondamentale caratteristica di essere open: è open in quanto utilizza, tecnologie open, prima fra tutte il kernel di Linux nella versione 2.6. è open in quanto utilizza librerie e API open

android Android ha la fondamentale caratteristica di essere open: è open in quanto utilizza, tecnologie open, prima fra tutte il kernel di Linux nella versione 2.6. è open in quanto utilizza librerie e API open è open in quanto il suo codice è open source, consultabile da chiunque possa contribuire a migliorarlo, lo voglia documentare o semplicemente voglia scoprirne il funzionamento. Ideato da , oggi lo sviluppo, promozione e distribuzione del sistema sono a carico di a cui afferiscono i maggiori produttori di hardware e software, nonché gli operatori telefonici.

Android & Java Android è basato su JAVA e fornisce un SDK in grado di facilitare lo sviluppo delle applicazioni. Android non esegue bytecode Java, per cui non ha bisogno di una JVM. Per ottimizzare al massimo l’utilizzo delle risorse dei dispositivi, Google ha adottato una propria VM che prende il nome di Dalvik VM sviluppata inizialmente da Dan Bornstein. Si tratta di una VM ottimizzata per l’esecuzione di applicazioni in dispositivi a risorse limitate la quale esegue codice contenuto all’interno di file di estensione .dex ottenuti a loro volta, in fase di building, a partire da file .class di bytecode Java.

Architettura L’architettura di Android comprende tutto lo stack degli strumenti per la creazione di applicazioni mobili di ultima generazione, tra cui un sistema operativo, un insieme di librerie native per le funzionalità core della piattaforma, una implementazione della VM e un insieme di librerie Java. Architettura a layer, dove i livelli inferiori offrono servizi ai livelli superiori offrendo un più alto grado di astrazione. Android fornisce un set di applicazioni di base, che comprende un email client, un programma SMS, calendario, mappe, browser, contatti e altro. Tutte le applicazioni sono scritte in linguaggio Java. Gli sviluppatori hanno pieno accesso alle stesse framework API usate dalle applicazioni di base. L'architettura delle applicazioni è progettata per semplificare il riutilizzo dei componenti; ogni applicazione può rendere pubbliche le sue capacità e tutte le altre applicazioni possono quindi farne uso (sono soggette ai limiti imposti dalla sicurezza del framework). Questo stesso meccanismo consente all'utente di sostituire i componenti standard con versioni personalizzate. Android si appoggia sulla versione 2.6 di Linux per servizi del sistema centrale come sicurezza, gestione della memoria, esecuzione, network stack, e driver model. Il kernel funziona anche da abstraction layer tra l'hardware e il resto del software. Il cuore del sistema è basato sul kernel di Linux (versione 2.6) che costituisce il livello di astrazione di tutto l’hardware sottostante che può includere wi-fi, bluetooth, GPS, fotocamera, touchscreen… I produttori di telefoni possono quindi intervenire già a questo livello per personalizzare i driver di comunicazione con i propri dispositivi. Grazie all’astrazione dell’hardware, infatti, i livelli soprastanti non si accorgono dei cambiamenti hardware, permettendo una programmazione ad alto livello omogenea ed una user experience indipendente dal device. Perchè Linux? L’affidabilità è più importante delle prestazioni in un dispositivo mobile che deve principalmente garantire il servizio di telefonia: gli utenti si aspettano quindi tale affidabiltà, ma allo stesso tempo hanno bisogno di un dispositivo che possa garantire servizi più evoluti: Linux permette di raggiungere entrambi gli scopi. Il livello superiore riguarda l’equipaggiamento software costituito dalle librerie fondamentali che gestiscono per esempio la grafica 2D e 3D (OpenGL ES), browser con engine WebKit o il supporto al database (SQLite). L’ambiente di runtime è costituito invece da una libreria core e da una macchina virtuale (VM): insieme costituiscono la piattaforma di sviluppo per Android. La VM di Android è versione particolare della Java Virtual Machine (chiamata Dalvik), progettata e ottimizzata appositamente per girare su hardware non performanti, come quelli dei cellulari appunto. In realtà gli ultimi modelli che montano Android vantano processori dual core con 1 Gb di RAM per cui questa affermazione comincia già ad essere obsoleta. Il kernel di Linux di Android è un sistema multi-utente nel quale ogni applicazione è un utente differente. Il sistema infatti crea un unico user ID per ogni applicazione (sconosciuto ad essa) e imposta i permessi dei file dell’applicazione stessa in modo che solo quell’ID possa averne accesso. Inoltre, ogni applicazione sul telefono viene lanciata in un processo Linux a sè stante all’interno della propria istanza della JVM: questa archiettura a sandbox garantisce la stabilità del telefono nel caso in qui qualche applicazione crei problemi. In caso alcune applicazioni abbiano necessità di comunicare tra loro, il sistema non lo impedisce: permette anzi loro di condividere lo stesso user ID e la stessa JVM in modo da preservare la coerenza delle risorse di sistema. Al penultimo livello è possibile rintracciare i gestori e le applicazioni di base del sistema. Ci sono gestori per le risorse, per le applicazioni installate, per le telefonate, il file system e altro ancora. Al livello più alto risiedono le applicazioni utente. Le funzionalità base del sistema, come per esempio il telefono, non sono altro che applicazioni utente scritte in Java e che girano ognuna nella sua JVM. Da notare che non è la distribuzione Java ME quella che viene eseguita, ma una versione appositamente sviluppata per Dalvik: il codice Java infatti viene compilato e tradotto in byte code, dopodichè subisce una ulteriore trasformazione in un formato chiamato dex file. Questo ulteriore passaggio ha permesso a Google da un lato di ottimizzare il codice per la sua JVM, dall’altro di svincolarsi (o quasi!) da problemi legali con Oracle, nuova proprietaria di Java. Un set di librerie centrali che forniscono la maggior parte delle funzionalità disponibili nelle librerie di base del linguaggio di programmazione Java. Android comprende un set di librerie C/C++ usate da varie componenti del sistema di Android. Questi elementi sono presentati allo sviluppatore attraverso il framework per applicazioni di Android.

Application framework Alla base di ogni applicazione si trova un set di servizi e sistemi, tra cui: Un gruppo ricco ed estensibile di View che possono essere usate per costruire un'applicazione; contiene liste, caselle di testo, pulsanti, e addirittura un browser web integrato Dei Content Providers che permettono alle applicazioni di accedere a dati da altre applicazioni (come i Contatti), o di condividere i propri dati Un Manager delle risorse, che offre l'accesso a risorse non-code come strings localizzate, grafica, files di layout Un Manager delle notifiche, che permette a tutte le applicazioni di mostrare avvisi personalizzati nella status bar Un Manager delle attività, che gestisce il ciclo di vita delle applicazioni e fornisce un backstack di navigazione comune.

libraries Android comprende un set di librerie C/C++ usate da varie componenti del sistema. Questi elementi sono presentati allo sviluppatore attraverso il framework per applicazioni di Android. Queste sono alcune delle librerie principali: System C library: un'implementazione BSD-derived della libreria standard C system (libc), disegnata per dispositivi basati su Linux. WebKit: è un framework open source per applicazioni sviluppato dalla Apple ed è il motore di Safari e di altre applicazioni come Google Chrome. FreeType: rendering di bitmap e vector font SQLite: un motore di database relazionale potente e leggero disponibile per tutte le applicazioni

Android runtime Dalvik è una macchina virtuale ottimizzata per sfruttare la poca memoria presente nei dispositivi mobili, consente di far girare diverse istanze della macchina virtuale contemporaneamente e nasconde al sistema operativo sottostante la gestione della memoria e dei thread. Dalvik VS Java Virtual Machine Dimensioni ridotte. Sostanziale differenza con il bytecode Java. Ottimizzata per eseguire istanze multiple.

Dalvik vm La compilazione avviene tramite un compilatore standard java, successivamente il bytecode viene convertito tramite l’utility “dx” messa a disposizione da Google. Il risultato finale del processo è il pacchetto .apk che oltre alle classi compilate contiene anche tutte le risorse necessarie all’applicazione. .java .class .jar javac jar dx .apk .dex aapt

kernel Il cuore della piattaforma Android è il kernel Linux versione 2.6, responsabile per che riguarda: Driver dei dispositivi (Camera, WiFi, Memorie, Audio, etc..). Accesso alle risorse. Gestione della batteria. Comunicazione tra processi. Altre utilità del sistema. Il kernel è stato adattato in modo da essere efficiente sui dispositivi mobili, che presentano risorse limitate (soprattutto per quanto riguarda la memoria principale)

Applicazione android Le applicazioni Android sono formate da componenti essenziali che il sistema più instanziare quando necessario. Esistono 4 tipi di “mattoni di base” per le applicazioni: Activity: si presenta come un’interfaccia grafica per una azione che l’utente può intraprendere Service: non presenta un’interfaccia grafica, ma lavora in background per un tempo indefinito Broadcast Receiver: un componente che non fa nient’altro che attendere il verificarsi di un evento esterno comunicato in broadcast dal sistema o da altre applicazioni, e una volta ricevuto lo notifica all’applicazione Content Provider: gestisce e condivide dati tra le applicazioni

activity Le activity sono quei blocchi di un’applicazione che interagiscono con l’utente utilizzando lo schermo e i dispositivi di input messi a disposizione dallo smartphone. Comunemente fanno uso di componenti UI già pronti, come quelli presenti nel pacchetto android.widget, ma questa non è necessariamente la regola. Le attività sono probabilmente il modello più diffuso in Android, e si realizzano estendendo la classe base android.app.Activity.

Activity life cycle onCreate(): richiamato quando si crea per la prima volta l’activity onRestart(): richiamato quando l’activity deve ripartire subito uno stop onStart(): richiamato poco prima che l’activity diviene visibile all’utente onResume(): richiamato poco prima che l’attività inizi l’iterazione con l’utente onPause(): richiamato quando il sistema deve eseguire un’altra activity onStop(): richiamato quando l’activity non è visibile all’utente per molto tempo onDestroy(): richiamato dal sistema per ditruggere l’activity, in seguito a finish() o per liberare spazio

Activity stack Le activity seguono una logica a stack, infatti, android, per tutte le applicazioni, tiene traccia della sequenza di visualizzazione delle activity in uno stack. Ogni volta che una applicazione chiede di visualizzare una activity questa viene posta in cima allo stack e quella che era precedentemente visualizzata diventa la penultima. All’interno di una applicazione, il programmatore, fa navigare l’utente da una activity ad un’altra (della stessa applicazione) visualizzando quella che, di volta in volta serve in base alle esigenze dell’applicazione, ma non è detto che tutte le activity appartengono alla stessa applicazione, infatti lo stack è unico e condiviso.

Service Un servizio è un componente di un’applicazione di Android. Rappresenta una operazione che deve essere effettuata per un lungo periodo anche quando l’applicazione non è in primo piano. Ogni servizio deve avere una corrispondenza nel manifesto con il tag <service> In genere un servizio in esecuzione non crea né nuovi processi per la sua esecuzione né nuovi thread. Pertanto deve essere gestito in modo adeguato dallo sviluppatore.

Broadcast receiver Per consentire la comunicazione tra Activity e Service, Android fornisce un meccanismo asincrono basato su scambi di messaggi, alla base di questo ci sono i broadcast receiver. I Service inviano la notifica degli eventi in broadcast; le Activity interessate devono registrarsi al servizio e specificare un oggetto di tipo Broadcast Receiver che gestisce l’evento. Service DALVIK Activity

Es. content://com.android.contacts/contacts Content provider In genere sia i file che i database sono di esclusiva proprietà dell’applicazione che li genera. I content provider consentono di rendere disponibili i dati ad altre applicazioni Ogni applicazione può definire una tipologia di dati e rendere disponibili tali informazioni esponendo uno o più content provider. Il content provider viene identificato mediante un URI cioè un indirizzo univoco. Es. content://com.android.contacts/contacts

Application resources In qualsiasi applicazione bisognerebbe sempre separare i dati dalla logica dell’applicazione e dal’interfaccia grafica, in modo da rendere più manutenibile il software (MVC). Android offre “gratis” questa pratica a patto che si seguano delle regole. Inoltre è possibile creare applicazioni multilingue inserendo le opportune risorse sotto cartelle che portano la sigla della nazione.

Application resources Un’altra tecnica consiste nello specificare il comportamento dei componenti grafici a seconda dall’orientamento dello schermo, del tipo di display, etc... I componenti grafici da visualizzare quando lo schermo è in posizione verticale vanno messi nella cartella res/layout e in res/layout-land nel caso lo schermo risulti ruotato in posizione orizzontale.

SQLite Il database è un componente fondamentale di qualsiasi applicazione software. Sqlite è una libreria software scritta in linguaggio C che implementa un DBMS SQL. Android incorpora nativamente questa libreria Le principali caratteristiche di SQLite sono: Compattezza (meno di 500K) Velocità E’ in grado di interpretare stringhe MySQL Codice sorgente disponibile e modificabile

Ogni applicazione deve avere un file xml denominato Android Manifest Ogni applicazione deve avere un file xml denominato Android Manifest. Il manifesto presenta informazioni essenziali che devono essere note prima dell’esecuzione dell’applicazione: Nome del package dell’attività principale Descrizione dei componenti dell’applicazione Permessi necessari all’applicazione e le eventuali librerie utilizzate Permessi che le altre applicazioni devono avere per poter interagire con i componenti dell’applicazione La minima versione richiesta dalle Android API.

Android Manifest

Android sdk Per sviluppare applicazioni in grado di girare su sistemi Android è necessario installare sul proprio PC un apposito kit di sviluppo (SDK), che fornisce librerie, documentazione, emulatore e DDMS necessari per la creazione di nuove applicazioni. Eclipse Plugin Android Dev Tools (ADT): permette la compilazione e creazione del pacchetto in automatico, in oltre mette a disposizione degli strumenti per effettuare il debug lanciando l’emulatore in debugging mode.

Best pratices Android è progettato per girare su una vasta gamma di dispositivi mobile; per gli sviluppatori ciò aumenta il potenziale numero di utenti della propria applicazione ma nel contempo pone numerosi ostacoli relativi alla compatibilità con l’hardware dei diversi device. indica una serie di best pratices per garantire la compatibilità: UI Guidelines (dimensioni display, elegance, etc..) Optimizing App Designing for Accessibility, Performance, Responsiveness, Seamlessness

Il dp prende come riferimento un display medium mdpi. Best pratices Nella definizione delle UI si raccomanda di non utilizzare unità di misura come i pixel, mm, etc… ma di usare la density-indipendet pixel: sp per il testo dp per tutti gli altri oggetti grafici Inoltre sono stati definiti 4 valori generalizzati per le densità e dimensioni del display: small, medium, large, xlarge - DIMENSIONI ldpi (low), mdpi (medium), hdpi (high), xhdpi (extra high) - DENSITA’ Il dp prende come riferimento un display medium mdpi.

publishing Android richiede che tutte le applicazioni installate siano firmate digitalmente attraverso un certificato, la cui chiave private è custodita dallo sviluppatore dell’applicazione. Android non permette l’installazione o l’esecuzione di applicazioni non certificate e non esiste un’autorità centrale che decide sulla pubblicazione o meno dell’applicazione. SDK di Android include tutti gli strumenti necessari per il rilascio dell’applicazione: Keytool e Jarsisgner da linea di comando In alternativa ADT mette a disposizione dello sviluppatore una procedura di export in grado di generare un file .apk firmato digitalmente. Un’applicazione firmata può essere pubblicata sull’

Security & permission Perché utilizzare un certificato? Identificare il team di sviluppo per consentire ad Android di stabilire se concedere o meno i permessi richiesti dall’applicazione (meccanismo basato anche sui Feedback) Una nuova versione di un’applicazione può essere rilasciata soltanto dallo stesso team di sviluppo. Bisogna quindi utilizzare certificati con scadenza tale da permettere pieno supporto al suo ciclo di vita

Security & permission No Run-Time Permission I permessi devono essere concessi all’atto dell’installazione dell’applicazione sul proprio device. I permessi richiesti dall’applicazione sono dichiarati nel file AndroidManifest.xml. E’ possibile esplicitarli anche per ogni singolo “mattone”. Se un’applicazione cerca di accedere ad una risorsa per cui non è stata autorizzata potrà sollevare un’eccezione

Security & permission Il Manifesto prevede delle particolari sezioni in cui dichiarare: Le librerie utilizzate Le features utilizzate (es. hardware: fotocamera, etc…) I permessi richiesti (es. uso Camera, GPS, etc…) <uses-library android:name="com.google.android.maps" /> <uses-feature android:name="android.hardware.camera" /> <uses-feature android:name="android.hardware.camera.autofocus" /> <uses-permission android:name="android.permission.STATUS_BAR" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> Non sempre viene garantito l’utilizzo delle risorse specificate nel manifesto

Security & permission E’ possibile definire permessi custom che altre applicazioni posso utilizzare per accedere alle nostre attività. Un’applicazione può concedere un proprio permesso ad un’altra che non lo detiene mediante il meccanismo per-URI Permission. Esempio: un’applicazione (A) per la gestione delle mail vorrebbe visualizzare una img allegata ma l’applicazione (B) per la visualizzazione delle img non detiene i permessi per accedere agli allegati delle mail. Sarà allora A a passare tramite l’oggetto Intent il permesso corrispondente mediante una URI.

Security & permission La piattaforma Android è costruita sul kernel Linux 2.6 e sfrutta il suo sistema integrato di sicurezza come parte dell’Android Security Model. Ogni applicazione gira sotto un UID (User ID) univoco definito all’atto dell’installazione a cui sono associati i permessi dell’applicazione. Ciò definisce i confini in cui l’applicazione può muoversi e previene che altre applicazioni possano accedere direttamente ai dati di questa (e viceversa). Un’applicazione Android può accedere ai propri dati privati (database, file, etc…) senza alcun permesso speciale; per accedere invece a dati condivisi bisogna dichiarare tali permessi nel Manifesto.

Security & permission

Car sharing mobile Il Car Sharing (o Car Pooling) è una modalità di trasporto che consiste nella condivisione di automobili private tra un gruppo di persone, con il fine principale di ridurre i costi. Diffusa in ambienti lavorativi o universitari, dove diversi soggetti, che percorrono la medesima tratta nella stessa fascia oraria, spontaneamente si accordano per viaggiare insieme. CarSharingMobilev1.0 per dispositivi mobili Android fornisce supporto all’utente nell’organizzazione di un viaggio sia come autista che passeggero.

Use case - csm Registrazione Login Gestisce Account Aggrega Passaggio Utente non registrato Gestisce Account Aggrega Passaggio <<extends>> Gestisce Auto Ricerca Passaggio <<extends>> Utente registrato <<extends>> <<extends>> Visualizza Mappa Invia Feedback Gestisce Passaggi Offre Passaggio

Car Sharing Server JAVA JAX-RS ARCHITETTURA - CSM INTERNET Car Sharing Server JAVA JAX-RS Car Sharing Mobile v1.0 Map API

Rest Il paradigma REST è basato su un protocollo di comunicazione stateless, client-server, chacheable e scalabile, basato su HTTP. Elementi fondamentali di un Web Services basato sulla architettura REST: Risorse Rappresentazione delle risorse Operazioni sulle risorse

Risorse Un servizio RESTful gestisce un insieme di risorse Esempio: nel nostro sistema di carSharing le risorse potranno essere gli utenti le auto, i viaggi Una risorsa può rappresentare una “collezione” di altre risorse Esempio: una risorsa potrà essere un insieme di viaggi che corrispondono a un criterio di ricerca

Insieme auto di un utente Risorse Ogni risorsa è identificata attraverso un URL specifico Esempi: http://CarSharing.com/Car/List/{userId}/{first}/{last} Insieme auto di un utente http://CarSharing.com/Car/{carId} Singola auto

rappresentazioni Ciascuna risorsa può avere più rappresentazioni diverse Ad esempio la nostra applicazione potrebbe fornire una rappresentazione di un auto: in formato HTML per la visualizzazione da parte di una pagina web pdf per la stampa json per essere utilizzata da un altra applicazione.

operazioni Nell’approccio REST si usa un numero limitato di operazioni per leggere o modificare lo stato delle risorse. Le operazioni corrispondono ai “metodi” definiti nel protocollo HTTP e non tutte le operazioni sono disponibili su tutte le risorse. Operazione Metodo Http Creazione nuova risorsa Idempotente: Sostituzione risorsa esistente PUT Modifica (valori) risorsa preesistente POST Cancellazione risorsa DELETE Accesso (visualizzazione, etc…) alla risorsa GET

RICHIESTA HTTP Una richiesta HTTP contiene: l’URL della risorsa a cui è riferita l’operazione da effettuare (es. GET) informazioni aggiuntive (headers), ad esempio per indicare il tipo di rappresentazione richiesta per alcune operazioni, un “corpo” della richiesta (body); in particolare il body è presente nelle operazioni PUT e POST User-Agent: Mozilla/5.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate

RISPOSTA HTTP Una risposta HTTP contiene: un codice numerico che indica l’esito dell’operazione (status) informazioni aggiuntive (headers); ad esempio, il tipo di rappresentazione restituito per alcune operazioni, un “corpo” della risposta (body) HTTP/1.1 200 OK X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA Content-Type: text/html <head> <title>JBoss RESTEasy Project</title> </head> <body> <h1>JBoss RESTEasy</h1>

STATUS HTTP Lo status è codificato su 3 cifre e la prima cifra indica l'esito generale: 2xx: operazione eseguita con successo 3xx: redirezione (la risorsa desiderata si trova su altro indirizzo) 4xx: errore da parte del client 5xx: errore interno al server

Formato json JSON (JavaScript Object Notation) è un semplice formato per lo scambio di dati. Basato su due strutture: Un insieme di coppie nome/valore Un elenco ordinato di valori. Nella maggior parte dei linguaggi questo si realizza con un array, un vettore, un elenco o una sequenza. Queste sono strutture di dati universali. Virtualmente tutti i linguaggi di programmazione moderni li supportano in entrambe le forme.

Formato json I tipi di dato supportati sono: Booleani { "type": "menu", "value": "File", "items": [ {"value": "New", "action": "CreateNewDoc"}, {"value": "Open", "action": "OpenDoc"}, {"value": "Close", "action": "CloseDoc"} ] } I tipi di dato supportati sono: Booleani Interi, reali, virgola mobile Stringhe Array Null Inoltre è consentito l’uso di strutture formate dai parametri supportati.

Json VS XML Semplicità Json ha una grammatica molto più piccola di xml Ridondanza XML ha una ridondanza maggiore di JSON con conseguente aumento di peso Interoperabilità Json e Xml hanno lo stesso potenziale di interoperabilità. Xml attualmente è molto utilizzato ma Json inizia a farsi conoscere grazie alla facilità di conversione da Xml a Json e la presenza di librerie di parsing nella maggior parte dei linguaggi di programmazione.

ARCHITETTURA SERVER Il server dell'applicazione Car Sharing Mobile è basato sulla tecnologia REST ed è implementato mediante il framework Jersey che aderisce alla JAX-RS. JAX-RS che definisce i servizi mediante l'uso di annotazioni. Annotazione Descrizione @Path Definisce il path della risorsa @GET, @PUT, @DELETE Specifica il tipo di richiesta http @Producer Specifica il tipo di risposta definita secondo MIME media types @Consumer Specifica il formato accettato definito secondo MIME media types @PathParam Associa i parametri al path @CookieParam Associa i parametri ai cookie @DefaultValue Definisce un valore di default in caso il parametro risulti assente.

Architettura SERVER DAO Service Bean Utility Configuration ConnectionManager DataAccessObject Service User/ Car/ Trip/ Notification/ NotificationService TripService CarService UserService Bean Car City Lift Trip User Feedback Notification Utility Base64 DateUtility ImageUtility

Contiene le risorse fornite agli utenti, tra le principali: service Contiene le risorse fornite agli utenti, tra le principali: Risorsa Descrizione User/ Rappresenta un utente User/Feedback Rappresenta un feedback Trip/ Rappresenta un viaggio Trip/Passenger Rappresenta un passeggero di un trip Trip/List Rappresenta un acollezione di viaggi Car Rappresenta un auto Car/List Rappresenta una collezione di auto Notification Rappresenta una collezione di notifiche

DAO Si occupa dell'interfacciamento e della gestione del db: ConnectionManager Si occupa della gestione delle connessioni al DB, implementando il riciclo delle stesse tramite un pool di connessioni libere. Utilizza il pattern singleton. DataAccessObject Realizza le query verso il DB , utilizzando una connessione richiesta al connectionManager.

database

Altri package Package Bean In questo package sono contenute classi definite come contenitori di dati. Package Utility Offre i servizi di supporto all'applicazione, gestione delle date, codifica/decodifica delle immagini, gestione della memoria, etc.. Package Configuration Riporta informazioni sulla configurazione del server.

progetto android La struttura classica di un progetto Android è costituita da un albero di directory: Directory Scopo Src Contiene tutti i sorgenti dell’applicazione Res/Assets Ospitano risorse esterne necessarie all’applicazione (drawable, layout, values) Gen Package utile per accedere in modo automatico e veloce alle risorse AndroidManifest.xml Descrittore dell’applicazione

LAYOUT La UI dell’applicazione è stata interamente disegnata utilizzando i file xml di layout. Per una maggiore compatibilità con le diverse dimensioni degli schermi dei dispositivi mobili è stata utilizzata soltanto le unità di misura dp e sp. Anche l’Option Menu ed i vari Context Menu sono stati definiti mediante file xml.

LAYOUT (Esempio) Nel file xml vengono definiti i layout ed i vari widget grafici mediante opportuni tag xml. Attiva lo scroller sul display se necessario Contenitore principale Widget: pulsante con immagine

MENU Per i menu dell’applicazione è stata realizzata una classe TemplateMenuActivity, estesa da ogni altra attività localizzando così in un unico punto il codice di gestione degli stessi. Context Menu Contiene le voci per la gestione di un singolo elemento della lista Option Menu Nelle classi che visualizzano liste di elementi presenta altre voci per l’aggiornamento e gestione delle liste

CarSharingUrlAndCodes Architettura client View CarListActivity EditCarActivity EditTripActivity LoginActivity MainMenuActivity MyTripTab SearchLiftActivity ShowMapActivity ShowTripActivity TripListActivity Services CarSharing CarSharingUrlAndCodes UserDB UserSession Utility Base64 CameraView DateUtility ImageUtility Bean Car City Lift Trip User Feedback Notification NotificationService

VIEW View CarListActivity EditCarActivity EditTripActivity LoginActivity MainMenuActivity MyTripTab SearchLiftActivity ShowMapActivity ShowTripActivity TripListActivity Ciascuna attività rappresenta una finestra mostrata all’utente e contiene il codice di controllo dei widget grafici. Per evitare di bloccare l’UI tutte le comunicazioni verso il server sono gestite tramite opportuni Thread e Handler. Gli handler sono necessari per aggiornare l’UI e mostrare all’utente il risultato delle operazioni eseguite.

CarSharingUrlAndCodes Model Carsharing consente di richiedere i servizi (WS) al server CarsharingUrlAndCodes è una interfaccia di supporto utile per la definizione di costanti e URL usate nel progetto. Services CarSharing CarSharingUrlAndCodes UserDB UserSession UserSession tiene traccia della sessione dell’utente. Inoltre offre dei metodi utili in fase di login UserDB è una classe che consente di avere accesso al database locale del dispositivo. Nella fattispecie si sono create due tabelle (user, notification). La prima utile in fase di login, la seconda per tenere traccia delle notifiche dell’utente.

Camera Android permette di usare la fotocamera in maniera versatile semplicemente usando il package android.camera richiamando la classe Camera contenuta all’interno. Mediante l’impostazione dei parametri di preview è possibile mostrare all’utente l’inquadratura corrente della fotocamera L’uso della fotocamera deve essere dichiarato nel manifesto dell’applicazione

Google MAPS ws api Google mette a disposizione una vasta gamma di interfacce utili per usufruire dei servizi di Geolocalizzazione. Le 3 famiglie più importanti sono: Geocoding API Places API Elevation API Es. Geocoding Request http://maps.googleapis.com/maps/api/geocode/json?address=Ponte+don+melillo+fisciano&sensor=false Es. Geocoding Response

GPS Il dispositivo GPS presente sulla maggior parte degli smartphone permette di rilevare la posizione dell’utente in termini di latitudine e longitudine. Queste quantità vengono elaborate mediante le api di google maps permettendo di ricavare l’indirizzo della zona indicata a partire dalle coordinate. Nel caso in cui il servizio GPS non risulti disponibile Android permette di reperire la posizione dell’utente mediante l’uso delle reti Wi-Fi.

Status bar La status bar viene usata nell’applicazione per tenere traccia delle notifiche che vengono inviate all’utente. In particolare viene inviata una notifica all’utente quando: Il viaggio viene aggiornato Il viaggio viene cancellato Un utente fa una richiesta di aggiungersi ad un viaggio Conferma aggiunta passeggero Rifiuto aggiunta passeggero Il passeggero si elimina dal viaggio L’autista elimina un passeggero Nuove notifiche

Ambiente di test DNS INTERNET

conclusioni Vantaggi Svantaggi Semplicità Supporto JAVA Hardware Dependent Open Source

Grazie per l’attenzione!