Università degli Studi di Padova

FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI

Corso di Laurea in Informatica

Tesi di laurea triennale

Sviluppo di un’applicazione di Time Management per tablet Android

Relatore: Candidato:

Dott.ssa Francesca Rossi Nicola Gonzo (594890)

......

Anno Accademico 2010-2011

1 di 91 2 di 91 Ai miei genitori per avermi sostenuto durante questi 3 anni

3 di 91 Sommario Il presente documento si prefigge come scopo la discussione del lavoro svolto durante lo stage realizzato dal candidato. Verranno presentati gli strumenti utilizzati, le fasi di analisi, progettazione, codifica e verifica che hanno permesso la realizzazione del progetto. I termini presenti nel Glossario, reperibile nelle appendici, sono riportati in italico alla loro prima occorrenza.

4 di 91 Indice

1 Introduzione9 1.1 Descrizione obbiettivo di stage ...... 9 1.2 Descrizione dell’azienda ...... 10

2 Time/system 13 2.1 Analisi di Time/system ...... 13 2.1.1 Vista giornaliera ...... 14 2.1.2 Progetti...... 15 2.1.3 Note...... 15 2.1.4 Contatti...... 16 2.2 Limiti di Time/system...... 16

3 Analisi dei Requisiti 19 3.1 Use cases ...... 19 3.1.1 UC1: use case generale...... 19 3.1.2 UC1.1: apertura programma ...... 20 3.1.3 UC1.2: selezione tipo visualizzazione...... 21 3.1.4 UC1.3: sincronizzazione con il calendario di ...... 21 3.2 Requisiti...... 22 3.2.1 Requisiti funzionali...... 23 3.2.2 Requisiti di Vincolo ...... 25 3.2.3 Requisiti Prestazionali...... 25 3.3 Analisi competitors...... 25

4 Strumenti Utilizzati 29 4.1 Android...... 29 4.2 Strumenti per lo sviluppo ...... 31 4.2.1 Repository ...... 31 4.2.2 ADT...... 32 4.2.3 ...... 32 4.3 Strumenti per la documentazione...... 34 4.3.1 Latex ...... 34 4.3.2 Texmaker...... 35 4.3.3 Bouml...... 35 4.3.4 Dia...... 35

5 Progettazione 37 5.1 Progettazione del ...... 37 5.2 Progettazione dei packages e delle classi...... 40 5.2.1 package agenda...... 41 5.2.2 package agenda.model e agenda.controller ...... 43 5.2.3 package agenda.view.create ...... 43

5 INDICE

5.2.4 package agenda.view.leftFramgent ...... 46 5.2.5 package agenda.view.rightFragment ...... 47 5.2.6 pacakge agenda.sync ...... 48

6 Realizzazione 51 6.1 Norme utilizzate ...... 51 6.2 Definizione di prodotto...... 52 6.2.1 Realizzazione del package agenda ...... 52 6.2.2 Realizzazione del package agenda.view.create ...... 55 6.2.3 Realizzazione del package agenda.view.leftFragment ...... 59 6.2.4 Realizzazione del package agenda.view.rightFragment ...... 62 6.2.5 Realizzazione del package agenda.sync ...... 63 6.2.6 Realizzazione del package agenda.sync.model ...... 64 6.2.7 Realizzazione dei package agenda.model e agenda.controller . . . 65 6.3 Realizzazione della sincronizzazione...... 65 6.4 Verifica ...... 66 6.4.1 Tracciamento requisiti-componenti...... 68

7 Consuntivo 71

8 Conclusioni 75

A Manuale Utente 77 A.1 Introduzione...... 77 A.2 Descrizione del prodotto...... 77 A.3 Istruzioni per l’uso...... 78

B Glossario 85

C Bibliografia 91

6 di 91 Elenco delle figure

2.1 Vista giornaliera del sistema Time/system...... 14 2.2 Vista di un singolo progetto...... 15

3.1 UC1: che mostra le diverse funzioni offerte dal sistema all’utente...... 19 3.2 UC1.1: mostra le diverse operazioni che l’utente può intraprendere quando apre l’applicazione ...... 20 3.3 UC1.2: in questo use case si mostrano i diversi tipi di visualizzazione offerti dal sistema...... 21 3.4 UC1.3: mostra le azioni che vengono eseguite quando l’utente decide di sincronizzare l’applicazione ...... 22

4.1 Strati che costituiscono l’architettura di Android...... 31 4.2 Editor Xml incluso nel plugin ADT...... 33

5.1 Diagramma relazionale del database realizzato...... 38 5.2 Diagramma dei packages sviluppati...... 41 5.3 Diagramma delle classi del package com.ceremit.agenda...... 42 5.4 Diagramma delle classi del package com.ceremit.agenda.view.create. . . . 44 5.5 Diagramma delle classi del package com.ceremit.agenda.view.leftFragment. 46 5.6 Diagramma delle classi del package com.ceremit.agenda.view.rightFragment. 47 5.7 Diagramma delle classi del package com.ceremit.agenda.sync...... 50

6.1 Diagramma di sequenza che mostra come funziona il processo di sincroniz- zazione...... 67

7.1 Raffronto tra le ore preventivate e quelle a consuntivo...... 73

A.1 Attività mostrata all’apertura dell’applicazione...... 78 A.2 Attività che mostra il riassunto di una giornata...... 80 A.3 Figura che mostra come visualizzare il menu contestuale di un appuntamento. 80 A.4 Figura che mostra come creare un nuovo appuntamento...... 81 A.5 Figura che mostra come creare una nuova nota...... 82 A.6 Figura che mostra come selezionare un progetto...... 82

7 Elenco delle tabelle

3.1 Tabella che illustra i diversi tipi di requisiti...... 23 3.2 Tabella che illustra la diversa importanza tra i requisiti...... 23 3.3 Tabella con tutti i requisiti funzionali...... 24 3.4 Tabella che illustra i requisiti di vincolo individuati...... 25 3.5 Tabella che illustra i requisiti prestazionali individuati...... 25

6.1 Tabella dove ogni requisito viene associato alle classi che lo realizzano . . 69

7.1 Ore consuntivate per le varie sotto-attività...... 72

8 Capitolo 1

Introduzione

1.1 Descrizione obbiettivo di stage

L’attività di stage è stata svolta presso l’azienda Ceremit srl da metà aprile a metà giugno. Sono state impiegate 320 ore di tempo equivalenti a 8 settimane lavorative per completare il progetto. L’applicativo realizzato lavora su tablet che sfruttano il sistema operativo Android nella versione 3.0 Honeycomb o superiore. Sono stati scelti questi dispositivi in quanto offrono una grande comodità derivante dalle loro dimensioni compatte e da una notevole durata della batteria. Importante è anche la loro facilità d’uso che li ha resi sempre più popolari offrendo quindi un mercato di potenziali clienti molto vasto. L’applicazione consiste in un’agenda attraverso la quale l’utente può organizzare il suo tempo. Essa non si limita a gestire semplicemente gli appuntamenti che hanno un’ora d’inizio e di fine ben precisa, bensì vengono gestite anche le seguenti attività: eventi, contact task e standard task. I primi occupano l’intera giornata e di conse- guenza non hanno un particolare orario. I contact task rappresentano invece delle comunicazioni che devono essere effettuate durante il giorno. Esse sono costituite da una persona che deve essere chiamata e da una durata. È possibile specificare con quale mezzo contattare la persona: email, telefono, chat, skype. Gli standard task sono invece delle attività da svolgere durante la giornata senza un’ora precisa, ma con una durata definita. Essi non sono quindi né appuntamenti (che hanno un preciso orario) né eventi (che invece sono all day long). Lo scopo degli standard task è dunque quello di creare delle attività come ‘‘preparare l’esame di Ingegneria del software’’ che richieda 325 ore in totale da dividere in 4 ore di studio al giorno per i prossimi mesi. In questo modo l’applicazione indicherà che ogni giorno l’utente ha 4 ore di studio a cui adempiere. Per migliorare la gestione degli appuntamenti è stata inserita anche la gestione del trasporto: è possibile inserire per quanto tempo è necessario spostarsi prima e/o dopo l’appuntamento. È presente un’apposita vista nella quale si può vedere il riassunto di tutto ciò che deve essere svolto in un giorno, nonché inserire, modificare e cancellare le attività da svolgere. Per facilitare la creazione di appuntamenti ed eventi è possibile inserire delle ripetizioni ad esempio ripetere l’appuntamento ‘‘lezione di Sistemi Operativi’’ dalle 10.00 alle 12.00 ogni giorno esclusi i weekend fino ad una certa data. L’applicativo non si limita però ad una semplice agenda: vengono gestiti anche i progetti. Essi vengono inseriti mediante un’apposita finestra nella quale è possibile specificare un responsabile, una data d’inizio ed una deadline entro cui devono essere finiti i lavori. È possibile associare un progetto a tutte le attività definite preceden- temente. In questo modo nella sua finestra di riassunto è possibile visualizzare tutti gli appuntamenti, gli eventi, i contact task e gli standard task che sono stati fatti

9 CAPITOLO 1. INTRODUZIONE

durante il progetto. È inoltre possibile definire dei figli per un progetto così da creare una gerarchia. Ad esempio il progetto ‘‘aumentare la qualità del servizio della rete ferroviaria’’ potrebbe avere due figli: ‘‘migliorare la rete dei binari’’ e ‘‘migliorare la flotta dei treni’’, ognuno dei quali può avere altri sotto-progetti. Per potenziare la gestione dei progetti è inoltre possibile associare ad ognuno di essi delle note. Esse sono visualizzabili in un’apposita schermata. Caratteristica dell’applicativo che ha richiesto un considerevole sforzo è stata la realizzazione della sincronizzazione con . Essa funziona sia in pull che in push mode: tutto ciò che avviene sul servizio di Google viene scaricato nel- l’applicativo e ciò che avviene in esso viene caricato sul servizio offerto dalla casa di Mountain View. Si precisa che vengono sincronizzati solo gli appuntamenti e gli eventi, Google Calendar infatti non gestisce progetti, contact task e standard task. Per rendere l’applicazione facile da utilizzare si è cercato di creare una grafica sem- plice ed intuitiva. È stato inoltre inserito un menu per le impostazioni nel quale si possono modificare alcuni parametri come il colore di sfondo degli eventi, la durata di default degli appuntamenti e così via. È inoltre possibile inserire una password che viene richiesta all’apertura dell’applicazione. Altra caratteristica del programma riguarda la prima schermata che viene visua- lizzata alla sua apertura. In essa viene mostrata una breve indicazione di quanto sia impegnativa la giornata odierna. In essa si mostrano infatti quanti minuti di trasporto, di appuntamenti e di contact task sono previsti. Il progetto realizzato ha permesso allo stagista di apprendere varie tecnologie tra le quali spicca ovviamente la piattaforma Android sempre più famosa e utilizzata. Inoltre è stata approfondito lo studio dei database con l’apprendimento di SQLite3.

1.2 Descrizione dell’azienda

L’azienda Ceremit srl è una piccola realtà del vicentino con siede a Thiene che offre servizi di Consulting Engineering. Molto variegata è l’offerta dei prodotti. Essi spaziano dalla consulenza edile a quella nel settore IT. Per questo secondo settore, i prodotti principali vengono realizzati per clienti di varia importanza e riguardano diversi ambiti come la sicurezza. Proprio in quest’ultimo contesto è stato sviluppato un software che consente di avere un livello di privacy molto elevato per i propri documenti: Confidace. Questo software offre un sistema di back-up online e condivisione dei documenti molto avanzato. Esso si basa infatti su un solido metodo di criptazione garantendo un alto livello di sicurezza e riservatezza. Le informazioni vengono criptate in locale grazie ad un programma che funziona su una chiavetta usb. Quindi esse vengono caricate in appositi server. Come algoritmi di cifratura si utilizzano AES 256 e BlueFish seguendo lo standard FIPS 197. Interessante è la possibilità di utilizzare una chat integrata nel sistema che cifra qualunque messaggio ed allegato inviato. Tra le aziende che stanno utilizzando questo sistema spiccano Valentino ed Electrolux. Il sito ufficiale di Confidace è: http://www.confidace.it/ Recentemente l’azienda è anche entrata nel mondo mobile con applicazioni per An- droid. Nonostante ciò il principale ambito d’interesse è il marketing tra cui spicca quello virale. Questo è un tipo di pubblicità per cui si inventa qualcosa di particolare che poi viene diffuso attraverso i social network. L’originalità e la simpatia del mes- saggio spesso porta gli utenti a condividere tale pubblicità con gli amici veicolando così il messaggio stesso e diffondendolo a masse molto grandi.

10 di 91 1.2. DESCRIZIONE DELL’AZIENDA

L’ambiente di lavoro si è rivelato sereno e accogliente favorendo gli incontri e il proseguimento dello stage. L’unico aspetto che ritengo negativo è stato l’aver svolto il progetto da solo e non in gruppo. La presenza di un team di sviluppo infatti permette di avere un maggior numero di idee e quindi trovare una soluzione migliore al problema. Inoltre lavorando in gruppo si può spartire il lavoro ottenendo quindi un prodotto finale qualitativamente migliore.

11 di 91 CAPITOLO 1. INTRODUZIONE

12 di 91 Capitolo 2

Time/system

Per poter realizzare il progetto, ho prima studiato Time/system. Si tratta di un prodotto di time management esclusivamente cartaceo di grande successo. Esso viene venduto da oltre vent’anni in tutto il mondo ed è tradotto in dieci lingue con oltre un milione di clienti. Il cuore di Time/system sono i goal ovvero gli scopi che l’utente si prefigge di raggiungere. È possibile definire degli obiettivi per il breve medio e lungo termine, in modo da avere sempre una chiara visione di ciò per cui si sta lavorando. Non esistono però soltanto i goal. Time/system si configura anche come un’agenda: si possono indicare appuntamenti, task, eventi, meeting ed attività. Grazie a ciò si può organizzare con precisione il proprio tempo, sia quello lavorativo che quello libero. La forza di questo prodotto risiede nella vasta gamma di strumenti offerti per la gestione professionale del proprio tempo. Esistono varie schede ognuna delle quali ha uno scopo ben preciso. Alcune di esse sono dedicate alla gestione degli appuntamenti che possono essere visualizzati attraverso molte viste:

• vista giornaliera.

• vista settimanale.

• vista mensile.

• vista annuale.

Altro strumento molto comodo è la scheda per la gestione dei progetti. Qui, oltre a varie informazioni sul progetto, è possibile reperire anche quali siano le attività, i meeting e le persone da contattare per portarlo a compimento. Lo scopo principale di questo sistema è dunque quello di permettere una pianificazione completa delle varie attività da svolgere. In questo modo si è più padroni del proprio tempo e si raggiungono gli obiettivi prefissati con maggior sicurezza. Il sito ufficiale di Time/system è: http://www.timesystem.com/index.php

2.1 Analisi di Time/system

Prima di procedere con la parte di analisi dei requisiti, ritengo opportuno esporre brevemente quali siano le potenzialità e gli strumenti messi a di disposizione da Time/system.

13 CAPITOLO 2. TIME/SYSTEM

Figura 2.1: Vista giornaliera del sistema Time/system.

2.1.1 Vista giornaliera

Questa è stata la vista più studiata per poterla implementare con maggior precisione all’interno dell’applicativo. Ne viene presentato un esempio in figura 2.1 tratto dal sito ufficiale. La vista giornaliera offre svariate funzionalità e comodità che permettono all’utente una semplice gestione della sua giornata. In particolare è possibile vedere:

1. la lista degli appuntamenti giornalieri.

2. la lista degli obiettivi della giornata.

3. la lista delle attività.

4. la lista delle persone da contattare.

5. la lista delle note.

La struttura di questa vista si presenta molto semplice, ma offre grandi potenzialità come indicare se qualcosa è stato completato, associare delle priorità e dare degli oggetti alle note. Nella lista delle persone da contattare è possibile indicare anche il tipo di comunicazione che potrebbe essere: T = Telefono, E = E-Mail, F = Fax, L = Lettera. Gran parte di ciò che è possibile fare in questa vista è stata riportata nella vista giornaliera dell’applicativo realizzato.

14 di 91 2.1. ANALISI DI TIME/SYSTEM

Figura 2.2: Vista di un singolo progetto.

2.1.2 Progetti

In questa vista (visibile in figura 2.2) è possibile visualizzare tutte le informazioni relative ad un progetto. Oltre alla data d’inizio e di fine si possono associare dei goal in modo da esplicitare quali siano gli scopi del progetto. Ad esso sono inoltre associabili delle risorse che possono essere persone o cose utili per portarlo a compimento. La cosa veramente innovativa è la possibilità di associare le attività da svolgere al progetto, in modo da controllare costantemente come stanno procedendo i lavori. Per ogni attività è infatti associabile una priorità nonché delegarla a qualcuno. Per garantire una miglior organizzazione del progetto, si possono individuare delle milestone, annotabili nell’apposito spazio. Infine, una volta completato il progetto, bisogna attribuire delle valutazioni allo stesso, in modo da comprendere meglio quali siano stati i fattori di debolezza incontrati durante lo sviluppo, così da imparare dai propri errori. Nell’applicativo finale è stata realizzata questa vista, includendo la maggior parte delle funzionalità sopra esposte.

2.1.3 Note

Anche le note sono un aspetto importante per Time/system. Esse vengono gestite in un’apposita sezione. Ogni nota può avere un titolo ed una data. Vengono offerti vari tipi di fogli per poter prendere delle semplici note testuali oppure per poter disegnare un grafico in un foglio quadrettato. Nell’applicativo realizzato è stato inserito un semplice sistema di gestione delle note che permette l’inserimento di semplice testo.

15 di 91 CAPITOLO 2. TIME/SYSTEM

2.1.4 Contatti

Altro aspetto essenziale di Time/system sono i contatti. Questi vengono gestiti in una sezione apposita. Ad essi si possono delegare progetti, attività o quant’altro non ricada sotto la nostra diretta responsabilità.

2.2 Limiti di Time/system

Time/system è dunque un prodotto ricco e potente, ma ha il difetto di essere molto verboso: per mantenere la consistenza di un’informazione è necessario replicarla più volte. Ad esempio l’inserimento di un nuovo appuntamento dovrebbe essere riportato nella vista giornaliera del giorno in cui avviene, quindi in quella settimanale ed infine in quella mensile. Inoltre, nel caso l’appuntamento in questione sia relativo ad un progetto, lo si dovrebbe riportare anche nella lista degli eventi associati a quel progetto. Tutto ciò è molto limitativo soprattutto perché - trattandosi di un prodotto cartaceo - non offre alcuna automazione: l’utente deve gestire in toto la sua agenda. Esistono alcune applicazioni che hanno preso spunto da Time/system emulandone la filosofia. Tra di esse la più importante è TaskTimer 10 sviluppata da MobiPro. Essa è un’applicazione molto potente. Offre infatti un gran numero di funzioni estremamente ben fatte. Grazie a questo programma si possono gestire praticamente tutte le cose che sono presenti in Time/system. Il limite di TaskTimer10 risiede nel fatto di essere completamente un prodotto a se stante. Non offre infatti la sincronizzazione con Google Calendar, inoltre esso è disponibile esclusivamente per Windows. Questi due fattori sono molto limitanti. La mancanza di sincronizzazione obbliga l’utente a ricreare il suo calendario da capo senza poterlo già popolare al primo avvio con tutti i suoi eventi. Essere un programma per computer e pc portatili vincola l’utente nei limiti di questi sistemi. Bisogna precisare che Task Timer offre la possibilità di visualizzare la propria agenda anche su dispositivi mobili, ma non mediante un’applicazione dedicata, bensì attraverso il browser. Ciò da una parte offre l’indipendenza dalla piattaforma, ma dall’altro obbliga l’utente ad avere sempre una connessione attiva. Ciò è ovviamente molto restrittivo soprattutto per le zone con poca copertura. Difficilmente è quindi possibile utilizzabile Task Timer senza un computer. Ai nostri giorni inoltre esistono altre piattaforme più consone per essere utilizzate come agende: i tablet. Essi hanno i seguenti vantaggi:

• offrono una comodità d’utilizzo maggiore dei computer portatili. Quest’ultimi sono infatti molto più lenti soprattutto in fase di avvio, anche nel caso vengano lasciati in stand-by.

• la durata della batteria dei tablet è nettamente superiore a quella dei pc, per questo sono sempre più utilizzati.

• i tablet sono estremamente semplici da usare, in particolare l’installazione di un nuovo prodotto software si riduce a pochi semplici tap.

• il mondo delle applicazioni per dispositivi mobili è il mercato del futuro e del presente.

• i tablet sono più piccoli dei pc portatili e quindi è più semplice portarli con sé. Tale aspetto è essenziale per un’agenda: è necessario averla sempre a portata di mano per poterla consultare al volo.

16 di 91 2.2. LIMITI DI TIME/SYSTEM

Un altro vincolo molto pesante per TaskTimer10 è la complessità dell’interfaccia grafica. Essa è molto ricca di funzionalità, tasti e altro che indubbiamente dimostra le potenzialità del software, ma rischia di portare al sovraccarico cognitivo l’utente, causando confusione soprattutto a chi è nuovo all’applicativo. Task Timer viene offerto in svariati piani, ognuno dei quali ha un target diverso: dal singolo utente che può desiderare una semplice agenda personale, ad un’azienda che invece vuole poter gestire progetti e calendari lavorativi per tutti i suoi dipendenti. Purtroppo questi hanno costi eccessivi, in particolare per le singole persone. A ciò bisogna aggiungere che l’utilizzo del servizio online per dispositivi mobili viene offerto separatamente.

Per tutte queste ragioni l’azienda Ceremit Srl ha pensato di sviluppare un’ap- plicazione per tablet Android che renda più comodo, contemporaneo ed economico Time/system. Per fare ciò ci si è basati solo sulla filosofia di questo sistema cartaceo cercando di prenderne i punti salienti e di tradurli in software. Si è quindi creato un progetto ex novo. Essendo lo stage limitato a poche settimane nelle quali è necessario anche formarsi su nuove tecnologie e capire il dominio del discorso, ciò che alla fine si è ottenuto è un prototipo che svolge le funzionalità principali offerte da Time/system. Tra esse ci sono la gestione dell’agenda, dei progetti e delle note nonché la visualizza- zione giornaliera. Quest’ultima risulta essere praticamente uguale a Time/system offrendo l’inserimento di appuntamenti eventi e contact task. Mancano ancora varie funzionalità offerte dal sistema cartaceo. In primis non sono state sviluppate le viste settimanale, mensile ed annuale degli appuntamenti. Ciò è indubbiamente il primo incremento da svolgere in quanto esse permettono di comprendere meglio la disposizione degli impegni e quindi aumenterebbero notevolmente le potenzialità dell’applicazione. Un altro aspetto di Time/system che è stato evitato è la gestione dei contatti. Ciò è stato volutamente tolto in quanto ci si può basare senza problemi su quella effettuata egregiamente da Google all’interno dei suoi servizi come Android o Google Calendar. Anche la gestione delle note è stata semplificata rispetto Time/system. Esso, trat- tandosi di un prodotto cartaceo, permette di creare note con semplice testo su fogli a righe, mentre su appositi fogli a quadretti offre la possibilità di creare grafici e disegni. Ciò risulta molto difficile da ottenere per via software soprattutto se viene realizzata da zero. In un futuro incremento dell’applicazione è possibile collegarla con altre applicazioni di terze parti che offrono una gestione delle note molto professionale. Android offre infatti la possibilità di cooperazione tra diversi programmi mettendo in comune i dati. Una delle migliori applicazioni per gestire le note è EverNote reperibile all’indirizzo http://www.evernote.com/. Essa è disponibile per varie piattaforme quindi le note create con essa diverrebbero accessibili anche su altri dispositivi. Una funzionalità che invece è stato possibile inserire nell’applicativo non presente in Time/system è la sincronizzazione con Google Calendar.

17 di 91 CAPITOLO 2. TIME/SYSTEM

18 di 91 Capitolo 3

Analisi dei Requisiti

3.1 Use cases

3.1.1 UC1: use case generale

UC1: use case generale

UC1.1: apre applicativo

UC1.2: scelta tipo visualizzazione utente

UC1.3: sincronizzazione con google calendar

UC1.4: modifica impostazioni

Figura 3.1: UC1: che mostra le diverse funzioni offerte dal sistema all’utente.

Attore principale: utente.

Precondizioni: l’utente si appresta ad interagire con l’applicativo.

Postcondizioni: il sistema ha eseguito ciò che è stato richiesto dall’utente.

Descrizione: questo use case mostra le azioni che un utente può intraprendere tramite il programma. Egli una volta aperta l’applicazione (UC1.1) può interagire con essa scegliendo il tipo di visualizzazione (UC1.2), modificando le impostazioni (UC1.4) o effettuando la sincronizzazione con il calendario di Google (UC1.3). Per ulteriori informazioni sul tipo di visualizzazione si guardi la sezione 3.1.3

Scenario principale:

19 CAPITOLO 3. ANALISI DEI REQUISITI

1. l’utente apre l’applicativo. 2. l’utente visualizza le possibili operazioni che può eseguire. 3. l’utente seleziona l’attività richiesta.

3.1.2 UC1.1: apertura programma

UC1.1 apertura applicativo

UC1.1.1: apre applicativo

Extension Points

<> UC1.1.2: inserimento password utente è presente una password è il primo avvio dell'applicazione

<>

<> UC1.1.3: Verifica password

UC1.1.4: l'utente associa all'applicativo un account google l'utente può anche decidere di non associare alcun calendario google all'applicativo

Figura 3.2: UC1.1: mostra le diverse operazioni che l’utente può intraprendere quando apre l’applicazione

Attore principale: utente.

Precondizioni: l’utente ha eseguito un tap sull’icona del menu per aprire il programma.

Postcondizioni: l’utente ha aperto il programma

Descrizione: Questo use case mostra cosa avviene all’apertura dell’applicazione. Nel caso si tratti del primo avvio della stessa, viene proposta all’utente una scherma- ta nella quale è possibile associare un calendario Google con cui sincronizzarla (UC1.1.4). L’utente in questa fase può anche decidere di utilizzare il programma senza associarlo a servizi di terze parti. Se l’utente ha impostato una password allora per entrare deve inserirla (UC1.1.2). Questa operazione include la verifica di tale credenziale d’accesso (UC1.1.3). Scenario principale:

1. l’utente clicca sull’icona del programma ed entra immediatamente. Scenario secondario:

A. l’utente è al primo avvio dell’applicazione. • l’utente clicca sull’icona del programma. • l’utente associa un account Google all’applicativo. • l’utente entra nel programma.

B. l’utente ha impostato una password. • l’utente clicca sull’icona del programma.

20 di 91 3.1. USE CASES

• l’utente inserisce la password. • l’utente entra nel programma se la password inserita è corretta, altrimenti deve reinserirla.

3.1.3 UC1.2: selezione tipo visualizzazione

UC1.2 scelta tipo visualizzazione

UC1.2.1 visualizzazione calendario

UC1.2.2: visualizzazione note utente

UC1.2.3: visualizzazione progetti

Figura 3.3: UC1.2: in questo use case si mostrano i diversi tipi di visualizzazione offerti dal sistema

Attore principale: utente.

Precondizioni: l’utente è entrato nell’applicativo.

Postcondizioni: l’utente visualizza ciò che ha richiesto

Descrizione: Esistono tre tipi diversi di visualizzazione offerti dal sistema: calendario : qui l’utente può visualizzare tutte le informazioni relative ad una singola giornata. Appena viene aperta, questa visualizzazione si posiziona sul giorno odierno. Qui l’utente può trovare gli appuntamenti e le attività da svolgere nel giorno selezionato. Si possono creare, modificare e cancellare questi eventi, nonché cambiare giorno attraverso un apposito calendario. note : mostra tutte le note inserite dall’utente, tappando su una nota ne viene visualizzato il contenuto. progetti : si visualizzano i progetti inseriti, tappando su un singolo progetto se ne visualizzano i figli e le informazioni ad esso relative. Scenario principale:

1. l’utente seleziona il tipo di visualizzazione richiesto. 2. vengono visualizzate le informazioni.

3.1.4 UC1.3: sincronizzazione con il calendario di Google Attore principale: utente.

Attore secondario: Google Calendar.

21 di 91 CAPITOLO 3. ANALISI DEI REQUISITI

UC1.3: sincronizzazione con google calendar

UC1.3.1: Avvio sincronizzazione

Extension Points

utente non è stato ancora selezionato un account google

<>

UC1.3.2: selezione account google

UC1.3.3: ottenimento informazioni in pull mode

GoogleCalendar

UC1.3.4: invio informazioni in push mode

Figura 3.4: UC1.3: mostra le azioni che vengono eseguite quando l’utente decide di sincronizzare l’applicazione

Precondizioni: l’utente è entrato nell’applicazione. Postcondizioni: sincronizzazione completata. Descrizione: l’utente avvia la sincronizzazione. Nel caso in cui egli non abbia scelto di aggiungere un account Google al primo avvio dell’applicazione, gli viene richiesto di farlo (UC1.3.2), quindi parte la sincronizzazione. Essa lavora con l’attore esterno Google Calendar in due modi distinti: vengono prima scaricate le informazioni presenti su di esso (pull mode) quindi si caricano le modifiche locali salvate nel dispositivo (push mode). Scenario principale:

1. l’utente avvia la sincronizzazione. 2. essa viene completata correttamente Scenario secondario:

A. l’utente non ha ancora associato un account Google all’applicativo. • l’utente avvia la sincronizzazione. • gli viene chiesto di associare un account Google. • una volta associato tale account la sincronizzazione viene iniziata e completata.

3.2 Requisiti

In questa sezione si elencano tutti i requisiti che sono stati trovati durante la fase di analisi. Essi vengono identificati in modo univoco così che risulti semplice riferirsi

22 di 91 3.2. REQUISITI

ad essi. Sarà quindi utilizzata la seguente sigla: X_Y_Z Dove

• X: indica il tipo di requisito che si va ad identificare. Si possono individuare le categorie di requisito nella tabella 3.1.

• Y: indica quanto sia importante il requisito nel contesto dell’applicativo. In tabella 3.2 si trovano i diversi livelli d’importanza.

• Z: è un numero progressivo che ha può avere dei figli. Per cui potranno esistere i requisiti X_Y_1 e X_Y_1.1.

Acronimo Significato F Funzionale P Prestazionale V Vincolo

Tabella 3.1: Tabella che illustra i diversi tipi di requisiti.

Acronimo Significato OB OBbligatorio D Desiderabile OP Opzionale

Tabella 3.2: Tabella che illustra la diversa importanza tra i requisiti.

3.2.1 Requisiti funzionali

Id Requisito Descrizione F_OB_1 l’applicazione gestisce dei Progetti. F_OB_1.1 ogni progetto è costituito da numerose informazioni quali titolo, descri- zione, data d’inizio e di fine, responsabile, goal, status (on track, not started, critical, done) e se si tratta di una milestone. F_OB_1.2 ogni progetto può avere dei figli. F_OB_1.3 ad ogni progetto sono associabili delle note, Standard Task, Contact Task ed appuntamenti.. F_OB_2 l’applicazione gestisce Standard Task. F_OB_2.1 ogni Standard Task contiene varie informazioni come priorità, percen- tuale di completamento, data d’inizio e di fine, durata complessiva in ore. F_OB_2.2 un task può anche non essere associato ad un progetto. F_OB_2.3 le ore necessarie per fare il task possono essere suddivise in più giorni. F_OB_3 vengono gestiti anche Appuntamenti F_OB_3.1 un appuntamento è composto da informazioni quali titolo, descrizione, località, giorno in cui si svolge, ora d’inizio e di fine, tempo di trasporto per l’andata e per il ritorno. F_OB_3.2 un appuntamento può anche non essere associato ad un progetto.

23 di 91 CAPITOLO 3. ANALISI DEI REQUISITI

F_OB_3.3 è possibile ripetere un appuntamento F_OB_3.3.1 quando si vuole cancellare o modificare un appuntamento ripetuto si chiede all’utente se vuole agire solo su quello selezionato, su tutte le sue ripetizioni, solo su quelle passate o solo su quelle future. F_OB_4 il sistema gestisce anche Contact Task che rappresentano delle comunicazioni da svolgere F_OB_4.1 ogni contact task contiene diverse informazioni come la persona da contattare, la tipologia (chat, email, telefonata, skype), data ed ora di d’inizio, la durata stimata. F_OB_5 il sistema offrirà la gestione di un singolo calendario F_OB_5.1 il sistema offrirà una programmazione a breve termine attraverso una daily view F_OB_5.2 la vista giornaliera permette di vedere gli appuntamenti, i task e le persone da contattare in quel giorno. F_OB_5.3 se gli appuntamenti hanno un tempo di trasporto prima e dopo esso viene visualizzato chiaramente. F_OB_5.4 è possibile indicare se sono stati completati i contact task e i task. F_OB_5.5 è possibile raggiungere velocemente il giorno odierno. F_OB_6 è presente un menu di preferenze F_OB_6.1 l’utente nella visualizzazione giornaliera può decidere con che salto visualizzare i diversi eventi (mezz’ora, un quarto d’ora, dieci minuti ) F_OB_6.2 l’utente può selezionare il colore con cui viene visualizzato il trasporto nella daily view F_OB_6.3 l’utente può dare una durata di default al trasporto e agli appuntamenti F_OB_6.4 si può dare un colore particolare agli appuntamenti che non sono associati ad un calendario Goolge F_OB_6.5 si può inserire una password per accedere all’applicativo F_OB_7 è possibile sincronizzare l’applicativo con Goolge calendar F_OB_7.1 la sincronizzazione avviene quando vuole l’utente cliccando un apposito tasto F_OB_7.2 la sincronizzazione funziona sia in pull mode che in push mode F_OB_8 quando viene aperta l’applicazione si mostra una schermata dove si visualizza un riassunto per il giorno corrente nel quale si mostrano i minuti di appuntamenti, di contact task e di standard task che l’utente deve svolgere F_OB_9 è possibile visualizzare l’elenco di tutte le note inserite F_OB_9.1 è possibile selezionare una nota visualizzando quindi il suo contenuto, la data in cui è stata creata e il progetto a cui si riferisce F_OB_9.2 è possibile modificare e/o cancellare la nota selezionata F_OB_10 è possibile visualizzare l’elenco di tutti i progetti F_OB_10.1 per ogni progetto si visualizzano i progetti figli e le informazioni ad esso relative F_OB_10.2 per un progetto selezionato vengono visualizzate le note ad esso associate F_D_1 è facile poter modificare il livello di completamento di un task F_D_2 è facile poter navigare tra i giorni vicini a quello correntemente visualizzato nella vista giornaliera F_OP_1 è possibile associare note anche ad eventi, contact task e standard task F_OP_2 la sincronizzazione avviene in automatico Tabella 3.3: Tabella con tutti i requisiti funzionali.

24 di 91 3.3. ANALISI COMPETITORS

3.2.2 Requisiti di Vincolo

id requisito Descrizione V_OB_1 si deve utilizzare il sistema Android HoneyComb (versione 3.0) V_OB_2 come database si utilizza SQlite V_OB_3 si devono supportare diverse risoluzioni dello schermo a partire da 1024*600

Tabella 3.4: Tabella che illustra i requisiti di vincolo individuati.

3.2.3 Requisiti Prestazionali

id requisito Descrizione P_OB_1 la sincronizzazione non deve impiegare troppo tempo per essere completata. P_OB_2 l’applicativo deve essere abbastanza veloce nell’utilizzo quotidiano.

Tabella 3.5: Tabella che illustra i requisiti prestazionali individuati.

3.3 Analisi competitors

Durante la fase di analisi, l’azienda ceremit srl, mi ha anche richiesto di cercare brevemente i competitors che un’applicazione di time management potrebbe avere. Per effettuare tale analisi ho semplicemente cercato in rete delle informazioni per le diverse applicazioni che hanno dei punti in comune con quanto dovevo realizzare. Non ho avuto la possibilità di acquistare le app. Ciò può infatti essere fatto in un secondo momento nel caso l’azienda decidesse seriamente di proseguire con la messa in produzione del progetto. La piattaforma principale su cui ho ricercato dei possibili competitors è stata Android. Ho preso in considerazione sia il mercato dei tablet che quello degli . Di seguito si espongono le applicazioni che ho ritenuto particolarmente interessanti.

ActionComplete Pro Si tratta di un progetto molto completo che offre numerose funzionalità. Oltre all’applicazione per Android è anche presente un’interfaccia web. È possibile dividere le cose da fare in 4 diversi gruppi: Actions, Waits, Projects ed Ideas. In questo modo si può applicare la filosofia GTD. I contatti vengono sincronizzati con quelli di Goolge, inoltre si utilizza Goolge Maps per trovare le località dove prendono luogo gli appuntamenti. Per inserire gli eventi è possibile utilizzare la voce, cosa che si rivela molto comoda e pratica in particolare in certe situazioni come ad esempio in macchina. È inoltre presente un widget per la home screen, ciò permette di avere tutto sotto controllo senza dover aprire il programma. prezzo 3,46e installazioni 1.000 - 5.000 Android market https://market.android.com/details?id=com.actioncomplete. android.pro

25 di 91 CAPITOLO 3. ANALISI DEI REQUISITI

CalenGoo È un’applicazione che offre diverse viste tra cui quella giornaliera, men- sile e settimanale. Offre la possibilità di spostare gli appuntamenti con un semplice drag and drop. Permette di sincronizzarsi con il calendario di Goolge e con quello di Microsoft Exchange. Anche questa applicazione offre un widget per la home screen. Si può ricercare all’interno degli appuntamenti una certa stringa di testo. prezzo 4,53e installazioni 10.000 - 50.000 Android market https://market.android.com/details?id=com.calengoo.android

DueToday Tra quelle che ho provato questa è quella che più in assoluto offre delle funzionalità simili a quelle che il progetto di stage si prefigge. Permette di gestire progetti e sotto-progetti definendo per essi dei task. Si possono inserire appuntamenti e note. Utilizza la filosofia GTD suddividendo in modo chiaro ciò che manca ancora da fare rispetto a ciò che è stato completato. l’applicazione è ottimizzata sia per che per tablet. prezzo 2,07e installazioni 5.000 - 10.000 Android market https://market.android.com/details?id=com.lakeridge.DueToday

Cozi Family Organizer Premium È un’applicazione che si discosta rispetto a quello che vorrebbe fare il progetto di stage, nonostante ciò ritengono utile citarla in quanto essa si presenta molto innovativa ed originale. Si tratta di un calendario per la famiglia. Permette la sincronizzazione tra diversi devices al calendario ospitato nei server del produttore. Ad esempio si possono fare delle liste per la spesa condivi- dendole con la propria famiglia. Quando un membro della stessa adempie a questa lista la segna come completata all’interno dell’applicazione. Questa si preoccuperà di sincronizzare tutte le liste presenti nei dispositivi degli altri famigliari attraverso la rete. In questo modo è semplice capire - ad esempio - se qualcuno è già andato al supermercato. prezzo gratis installazioni 100.000 - 500.000 Android market https://market.android.com/details?id=com.cozi.androidfree

Pocket Informant Si tratta di un’applicazione ricche di potenzialità. È un calen- dario che adotta la filosofia GTD. Offre numerose viste tra qui quella giornaliera, mensile e settimanale. Le impostazioni sono molto varie garantendo un elevato grado di personalizzazione. È possibile mettere delle categorie alle quali associare gli appuntamenti. Interessante la gestione dei tasks. Una versione molto più completa è presente per iOS sia per iPhone che per iPad. In essa è presente la sincronizzazione con Goolge Calendar e con Outlook, assente nella versione per Android. prezzo € 6,88 installazioni 10.000 - 50.000 Android market https://market.android.com/details?id=net.webis.pocketinformant

Conclusioni sull’analisi dei competitors La breve analisi che ho condotto ha permesso di capire che il mercato in questione non è molto ampio, infatti sono state trovate ben poche applicazioni simili a ciò che l’azienda ha in mente di fare. Nonostante ciò esse si dimostrano ben sviluppate e ricche di funzionalità. L’analisi ha inoltre permesso di capire quali siano le caratteristiche che maggiormente sono ricercate dagli utenti:

26 di 91 3.3. ANALISI COMPETITORS

• sincronizzazione con altri calendari, in particolare con Goolge Calendar. In modo saltuario è richiesta anche quella con i prodotti Microsoft (Outlook specialmente).

• possibilità di personalizzare l’applicazione in particolare nei colori utilizzati per mostrare gli eventi.

• gestione non solo degli appuntamenti, ma anche di task e progetti.

• localizzazione in diverse lingue.

• widget per la home screen.

Per quanto possibile, nei limiti temporali dello stage, si è cercato di realizzare buona parte di queste funzionalità. Altro aspetto su cui l’analisi dei competitors fa riflettere sono i prezzi. Le applicazioni non possono costare una cifra troppo elevata. Per applicazioni di questo spessore, se ben fatte, si può indicare un costo medio che varia dai 3 ai 4 euro.

27 di 91 CAPITOLO 3. ANALISI DEI REQUISITI

28 di 91 Capitolo 4

Strumenti Utilizzati

Durante lo stage ho usufruito di un discreto numero di strumenti. Tutti quelli utilizzati li ho scelti personalmente io: l’azienda mi ha infatti lasciato la completa libertà di costruirmi il mio ambiente di sviluppo. L’unico vincolo che ho dovuto tener in considerazione è stato l’utilizzo della piattaforma Android. La prima scelta che ho fatto è stata se sviluppare su Linux oppure su Windows. Ho preferito il primo sistema per svariate ragioni: • maggiore leggerezza del sistema e quindi maggior disponibilità di risorse per l’emulatore Android spesso avido di memoria RAM e CPU.

• maggior offerta di programmi open source come GIMP, Inkscape, BoUML e molti altri utilizzati per le immagini da inserire nella relazione.

• facilità d’installazione del software. A differenza di Windows, ogni distribuzione Linux ha i suoi repository nei quali ricercare ed installare programmi con pochi semplici click. Nel mio caso ho utilizzato archlinux e Pacman come software per la gestione dei pacchetti.

• console molto potente che mi è tornata spesso utile per accedere all’emulatore senza problemi. In questo modo ho avuto la possibilità di controllare bene il database individuando bug in fase di test.

4.1 Android

L’ è un gruppo di ben 83 aziende tecnologiche che si sono riunite con lo scopo di sviluppare una piattaforma per dispositivi mobile: Android. Molte sono le realtà che partecipano a questa iniziativa. I membri più importanti sono Google, Intel, Qualcomm, numerosi brand produttori di cellulari come HTC, Samsung, LG e Sony Ericsson, enti di telefonia come Spirit, Vodafone e Telecom Italia.

Android è scritto in Java, nonostante ciò non utilizza la JVM bensì la Virtual Machine, una macchina virtuale appositamente sviluppata per essere più leggera e quindi più veloce su dispositivi non sempre potenti come gli smartphone e i tablet. In particolare con Dalvik si vuole cercare di diminuire il consumo di batteria e limitare, per quanto possibile, l’utilizzo della cpu. Un’importante differenza con la JVM sta nel fatto che Dalvik non utilizza bitecode java, ma un particolare formato .dex (Dalvik Executable). Esso viene prodotto partendo da file .class rego- larmente ottenuti con il compilatore java mediante uno strumento integrato nelle SDK Android: dx. I programmi android non hanno quindi l’estensione .jar ma .dex. Essi vengono poi compressi nel formato finale .apk (Android PacKage). Elemento

29 CAPITOLO 4. STRUMENTI UTILIZZATI particolare di Dalvik è la sua capacità di eseguire più istanze contemporaneamente. In questo è possibile avere una macchina virtuale aperta per ogni applicazione in esecuzione. L’architettura su cui si basa Android è visibile in figura 4.1. Il tutto è costruito sul kernel linux versione 2.6. Ciò garantisce numerose funzionalità come memory e process managment, networking e molto altro. Aver scelto linux è una garanzia in quanto essendo molto utilizzato a livello globale esso risulta un progetto molto sicuro e ben testato, inoltre essendo open-source è sempre possibile ispezionare il codice per individuare dei bug o proporre delle migliorie. Sopra a questo strato è presente una serie di librerie su cui si basta Android. Queste sono scritte in /C++. Tra quelle offerte le più importanti sono il surface manager che gestisce le finestre e quindi i che vengono visualizzati sullo schermo. Ci sono delle librerie grafiche (opengl/es ed SGL) che offrono sia una vista 3D che 2D: una stessa applicazione può utilizzarle entrambe. La libreria media framwork contiene tutti i codec necessari per riprodurre i video e l’audio. quelli più importanti sono: mp3, acc, mp4 e H256. È inoltre presente webkit, un open source broswer engine utilizzato anche da safari. Infine citiamo SQLite spesso utilizzato su dispositivi mobili per la sua leggerezza. Le core libraries contengono tutte le librerie presenti in java6. Esse sono quindi utilizzabili da qualunque sviluppatore. Risalendo nella gerarchia dell’architettura incontriamo l’application framework: queste sono le API offerte da android. ogni applicazione sia quelle di sistema (home screen ecc..) che quelle di terze parti possono utilizzarle. Tra queste sottolineiamo la presenza del content provider che permette ad un’applicazione di condividere qualcosa con altre app. Questo è molto comodo in particolare perché ciò vale anche per il sistema android: possono essere condivise con le applicazioni informazioni come i contatti, la rubrica e altro. Infine nello strato più elevato della gerarchia incontriamo lo strato Application che contiene tutte le app installate sul dispositivo sia quelle di sistema che quelle di terze parti.

Per ogni applicazioni vengono definite delle attività. Esse sono schermate che permettono all’utente di fare qualcosa, da scrivere un sms a giocare. Ogni attività può avviarne altre creando così il flusso d’esecuzione del programma. Molto interessante è il riuso di queste attività. Quando un applicativo necessita di qualcosa, ad esempio prendere una foto dalla galleria personale dell’utente, è possibile avviare un’apposita attività per ottenere la foto desiderata. Questa attività può essere create ex novo dallo sviluppatore, oppure può essere demandata ad altre applicazioni. La cosa innovativa è che, nel secondo caso, l’utente stesso può decidere quale applicazione utilizzare tra quelle che permettono di assolvere al compito desiderato (nel nostro caso navigare nella galleria). Ciò offre due importanti vantaggi: 1. l’utente può personalizzare al massimo il suo dispositivo installando non solo applicazioni aggiuntive, ma anche servizi che svolgono le funzionalità già presenti sul telefono. Ad esempio è possibile modificare il dialer (ovvero la gestione del tastierino per effettuare chiamate), l’applicazione per gestire gli sms, la galleria, la tastiera ecc... 2. gli sviluppatori possono incrementare il riuso di componenti già esistenti e integrare meglio la loro applicazione all’interno del dispositivo. Nel caso del progetto di stage, avevo bisogno di permettere all’utente di selezionare un contatto dalla rubrica. Senza dover programmare appositamente l’accesso e la navigazione all’interno di essa, mi è bastato invocare un’attività che permetta di fare ciò.

30 di 91 4.2. STRUMENTI PER LO SVILUPPO

Figura 4.1: Strati che costituiscono l’architettura di Android.

4.2 Strumenti per lo sviluppo

4.2.1 Repository Avendo la completa libertà su che strumenti utilizzare ho scelto di appoggiarmi su un repository. L’utilizzo di tale strumento può sembrare una sovrastruttura avendo sviluppato il progetto da solo e quindi non appartenendo ad un team. Tuttavia i software di controllo e versionamento non sono utili solo per lavorare in team, ma anche da soli. Il motivo principale per cui ho adottato un repository è stata la sua affidabilità: con pochi semplici comandi da terminale è possibile caricare le modifiche apportate nel corso della sessione di lavoro nel repository online garantendo una copia di sicurezza dell’intero progetto nel caso sorgano problemi nella macchina di lavoro. Altro motivo non meno importante è la possibilità di mantenere una cronologia delle diverse modifiche fatte. In questo modo non è solo possibile ricostruire la storia del progetto, ma anche tornare indietro a versioni precedenti del codice nel caso siano state effettuate delle modifiche errate compromettendone la stabilità. Ciò è possibile attraverso un’operazione di checkout. Per il mantenimento del repository online ho scelto di appoggiarmi al servizio offerto da http://www.assembla.com/. Ho utilizzato un comodo piano gratuito per progetti di piccole dimensioni evitando così degli oneri all’azienda. Il sito offre un livello di sicurezza con SSL e di backup, inoltre ho già utilizzato con successo tale servizio per altri progetti universitari, senza mai riscontrare ritardi o perdite di prestazioni. Come software per il repository ho utilizzato git in quanto offre buone prestazioni

31 di 91 CAPITOLO 4. STRUMENTI UTILIZZATI

al crescere delle dimensioni del progetto. Viene inoltre offerta una gestione delle diramazioni di un progetto dal suo master branch. Tale funzionalità non è stata utilizzata nel corso dello stage, però nel caso di futuri sviluppi essa potrà essere utilizzata senza problemi. Come interfaccia grafica ho usato gitk. Il sito ufficiale di git è: http://git-scm.com/

4.2.2 ADT Per lo sviluppo su piattaforma Android, Google fornisce il plugin ADT (Android Development Tools) disponibile per i più importanti IDE attualmente in uso. Esso offre un ambiente integrato ricco di funzionalità, alcune delle quali sono state utilizzate durante lo stage.

LogCat : è un semplice debugger che permette di controllare i log che la virtual machine sta producendo. Risulta molto comodo in quanto permette di filtrare tali messaggi mostrando i warning, i messaggi d’errore o semplicemente tutti i log generati. Altra caratteristica peculiare è la possibilità di associare ad un log generato dal proprio progetto una keyword e poi filtrare i log in base ad essa.

Hierarchy Viewer permette di creare un albero in cui vengono mostrati tutti i componenti grafici e le loro relazioni usati all’interno del progetto. Ciò si rivela estremamente comodo in particolare per individuare dei problemi all’interno del layout. Tra le informazioni offerte da questo tool, interessante è un indicatore a tre colori (rosso, giallo e verde) che per ogni componente grafico indica quanto pesante sia il suo render all’interno della grafica. In questo modo è possibile individuare quali siano le componenti più pesanti e agire di conseguenza per migliorare le performance dell’applicativo.

Android Layout Editor Questo strumento è molto potente e permette di creare il layout attraverso un semplice drag and drop di elementi, facilitando la realizzazione della grafica dell’applicativo. Attraverso questo tool è inoltre possibile esplorare tutte le componenti grafiche e le loro proprietà offerte dalla piattaforma Android. In figura 4.2 si può vedere un esempio di questo tool. A sinistra è presente l’elenco di tutti i componenti grafici supportati mentre al centro dell’immagine si può vedere la preview della grafica. Questa è composta dai componenti elencati nella outline in modo gerarchico. Grazie al menu Proprieties (visibile a destra nella figura) è possibile selezionare un componente della grafica della outline, modificare alcune delle sue numerose caratteristiche e vederne subito il risultato nella preview. Bisogna precisare che mediante questo editor è possibile realizzare solo la parte statica della grafica, il comportamento dei singoli componenti deve infatti essere programmato in java.

Altre possibilità offerte da ADT sono la firma dell’eseguibile finale per la pubblica- zione sull’android market, la realizzazione di un nuovo progetto e la possibilità di visualizzare i thread che stanno eseguendo nelle Dalvik Virtual Machine.

4.2.3 Eclipse ADT è disponibile per vari IDE nonostante ciò quello maggiormente mantenuto e per questo consigliato dall’android dev team è il plugin per Eclipse. Questo è il motivo

32 di 91 4.2. STRUMENTI PER LO SVILUPPO

Figura 4.2: Editor Xml incluso nel plugin ADT. principale per cui ho optato per tale IDE. Esso offre però numerosi altri vantaggi quali un’ampia scelta di software di terze parti che ne incrementano le potenzialità e l’esperienza d’uso. Altre ragioni per cui si è scelto Eclipse sono state:

• semplice e veloce gestione dei progetti attraverso la vista Project Explorer

• intellisense ben sviluppata che permette di incrementare la velocità di programma- zione

• Outline del file aperto con tutte le informazioni sul suo contenuto. Qui si possono vedere tutte le classi, i metodi e le variabili in esso dichiarate.

• possibilità di modificare le perspectives adattando il layout di ognuna alle proprie esigenze. Molto comode sono quelle di default che permettono di avere tutto sotto controllo nel caso si programmi oppure si faccia debug.

• formattazione automatica del codice. Tale funzionalità si rivela molto comoda e diminuisce il tempo perso per la programmazione.

• Eclipse è nato per programmare in java, ovvero lo stesso linguaggio che usa Android per sviluppare le applicazioni.

• possibilità di creare classi, package e progetti molto velocemente.

Eclipse nonostante tutti questi vantaggi ha anche degli aspetti negativi. Primo fra tutti la reattività, a volte infatti tende ad essere lento. Ciò è dovuto principalmente al fatto di essere programmato in java.

Nel corso del progetto sono stati utilizzati i seguenti plugin per Eclipse:

33 di 91 CAPITOLO 4. STRUMENTI UTILIZZATI

• JAutodoc sito web: http://jautodoc.sourceforge.net/ Consente di inserire automaticamente i javadoc attraverso un apposito template adattabile alle esigenze del progetto. Tale strumento permette anche di aggiungere gli header ai file. In questo modo è possibile indicare autore, modulo di riferimento e data di creazione di ogni file. A discrezione del programmatore agli header è inoltre possibile aggiungere un registro delle modifiche per mostrare l’evoluzione del file in oggetto. Durante lo stage questo plugin è stato principalmente utilizzato per inserire i javadoc, velocizzando quindi la procedura di commento del codice. Tra le tante funzionalità offerte da questo sistema c’è la possibilità di aggiungere i javadoc solo a ciò che ancora non è stato commentato, filtrare ciò che deve essere commentato (ad esempio si possono commentare solo i metodi e non le variabili di classe) e aggiungere i TODO dei commenti autogenerati così da ricordarsi di sistemarli.

• Metrics sito web:http://metrics.sourceforge.net/ Questo strumento permette di calcolare varie statistiche sul progetto in corso. In particolare esso offre informazioni circa il numero totale di righe di codice e la complessità ciclomatica. Molto comodo risulta la visione di questi dati non solo per l’intero progetto, ma anche per tutti i package e le classi al suo interno. Altro strumento molto comodo offerto sempre da Metrics è un analizzatore grafico delle dipendenze. Esso funziona esclusivamente quando si prende in considerazione un intero progetto e mostra le dipendenze tra i vari packages. In questo modo è possibile trovare anche i cicli tra package. Indice ricco di informazioni è il lack of cohesion. Esso indica quanto una classe sia veramente coesa al suo interno e quindi un valore molto alto (vicino ad 1) è indice di una classe poco coesa: essa potrebbe essere divisa in più classi.

• ADT sito web: http://developer.android.com/sdk/eclipse-adt.html già esposto nella sezione 4.2.2

4.3 Strumenti per la documentazione

4.3.1 Latex

LATEX è un linguaggio di markup che permette di ottenere dei documenti di testo attraverso il paradigma WYSIWYM. In questo modo si ha il completo controllo su cosa si stia davvero scrivendo, cosa non possibile adottando programmi come Microsoft Word oppure OpenOffice. La potenza di questo strumento risiede nella sua portabilità: essendo open source esistono dei porting per la maggior parte dei sistemi operativi da Windows a Linux. Il motivo principale per cui ho utilizzato LATEXè la sua versatilità. Esistono molti pacchetti aggiuntivi che offrono ricchi strumenti per l’editing dei propri documenti garantendo una soluzione per qualunque problema tipografico. Un grosso vantaggio di utilizzare questo linguaggio è il versionamento che può essere fatto senza problemi sui file che vengono man mano codificati per redigere il documento finale. In questo modo ho avuto la possibilità di utilizzare il repository anche per scrivere la tesi, garantendomi tutti i vantaggi già esposti nella sezione 4.2.1.

34 di 91 4.3. STRUMENTI PER LA DOCUMENTAZIONE

4.3.2 Texmaker

Per la scrittura in LATEX ho usato questo software reperibile al sito: http://www.xm1math.net/texmaker/ Esso mi ha permesso di velocizzare la scrittura del presente documento in quanto offre numerose scorciatoie per inserire i più comuni comandi LATEX. Molto comoda risulta una piccola guida per questo linguaggio integrata proprio nell’applicativo. Come in Eclipse anche qui è stata implementata una semplice intellisense per agevolare la scrittura del codice. Per migliore la grammatica del documento in scrittura ho usato aspell facilmente integrabile in Texmaker. In questo modo si può infatti avere un controllo in real time del testo che si sta scrivendo. Altra utile funzionalità offerta da questo software è la visione gerarchica delle sezioni di cui è composto il file aperto. Ciò si rivela molto comodo in quanto cliccando sul nome di una sezione si viene portati correttamente al suo inizio all’interno del file. Viene inoltre fornito un piccolo wizard per creare le tabelle.

4.3.3 Bouml Questo programma permette di generare degli UML in modo molto professionale. Il sito ufficiale è: http://bouml.free.fr/index.html Il motivo principe per cui ho utilizzato questo programma è la sua buona aderenza allo standard UML 2.0. Esso può generare vari tipi di diagrammi come use cases, diagrammi di attività, di sequenza, delle classi e dei packages. Vengono inoltre forniti vari tool molto comodi come la possibilità di esportare le immagini in svg, formato molto comodo per essere convertito in pdf al fine di avere diagrammi UML in vettoriale.

4.3.4 Dia Questo programma permette di disegnare vari tipi di diagrammi. Tra questi ci sono anche quelli relazionali che ho utilizzato per disegnare lo schema del database. Esisto- no molte valide alternative a questo software, come ad esempio MySQL Workbench. Esso offre potenzialità molto superiori a Dia, si tratta però di un applicativo più complicato che ho preferito evitare in quanto le caratteristiche offerte da Dia mi sono state più che sufficienti per i diagrammi fatti. Dia è reperibile all’indirizzo http://projects.gnome.org/dia/

35 di 91 CAPITOLO 4. STRUMENTI UTILIZZATI

36 di 91 Capitolo 5

Progettazione

5.1 Progettazione del database

Per realizzare l’applicativo ho dovuto sviluppare anche un database che gestisca tutte le informazioni emerse in sede d’analisi. Come già esposto precedentemente, ho utilizzato il DBMS SQLite3 in quanto esso viene integrato nel framework Android. In figura 5.1 è presente il modello relazionale del database sviluppato. In esso vengono sottolineate e grassettate le chiavi primarie, mentre vengono indicate attraverso l’acronimo FK (Foreign Key) le chiavi esterne. Per la realizzazione del database ho mantenuto queste convezioni:

• il nome delle tabelle è stato scritto in CamelCase con la prima lettera maiuscola.

• il nome degli attributi viene scritto in CamelCase, ma la prima lettera è minuscola.

• al nome delle chiavi (sia primarie che esterne) viene aggiunto il prefisso id.

• quando è necessario inserire una data che richieda di ricordare solo giorno, mese ed anno, viene inserito un campo intero che indica il numero di giorni trascorsi dal 1-01-1970. Ad esempio invece di salvare la stringa 24-07-2011 viene semplicemente inserito il valore 15179. In questo modo è possibile risparmiare spazio e velocizzare le query di confronto per trovare, ad esempio, gli eventi di un certo giorno.

• non ho utilizzato campi boolean in quanto essi non sono disponibili in SQLite3. Essi vengono sostituiti da campi interi dove il valore 1 corrisponde a true, 0 a false.

• per i campi string ho utilizzato il valore TEXT come indicato nel reference di SQLite3.

• Per la realizzazione delle chiavi primarie ho utilizzato attributi sintetici. Ovvero per quasi tutte le tabelle ho indicato un id numerico che si auto incrementa come chiave primaria. In questo modo ho evitato l’utilizzo di altri campi o insiemi degli stessi come chiave semplificando così la gestione dei record e delle chiavi esterne.

Importante è la gestione dei contatti. In un primo momento si era pensato di introdurre una serie di tabelle per la gestione degli stessi. Ciò avrebbe richiesto un buon numero di ore di programmazione in particolare per sviluppare le interfacce grafiche per la gestione di questi contatti. Analizzando meglio la gestione dei contatti propria di Google ci siamo però accorti che essa era esattamente quello che serviva all’applicazione. Si è quindi deciso con il tutor aziendale, di eliminare dal database dell’applicativo la gestione dei contatti, sfruttando quella che viene offerta da Google e dalla rubrica di Android. In particolare essa associa ad ogni contatto un id univoco.

37 CAPITOLO 5. PROGETTAZIONE

Figura 5.1: Diagramma relazionale del database realizzato.

38 di 91 5.1. PROGETTAZIONE DEL DATABASE

Ciò ha permesso, all’interno del database progettato, di riferirsi ai contatti posseduti dall’utente nel suo account Google semplicemente utilizzando questo id. In questo modo si è aumentato riuso dell’applicazione e la sua integrazione con la piattaforma Android.

Nel database sono presenti varie tabelle, ognuna delle quali ha uno scopo preciso. Il cuore di tutto è la tabella GeneralToDo. Essa indica qualcosa che deve essere fatto e contiene informazioni molto generiche come titolo e descrizione. È stata quindi creata una gerarchia di tabelle derivanti da GeneralToDo. Essa si è ottenuta tramite un partizionamento verticale: gli attributi presenti dentro a GeneralToDo possono essere ottenuti a partire da queste tabelle in quanto la loro chiave primaria è anche una chiave esterna verso GeneralToDo. Le altre tabelle presenti nel database vengono descritte nel seguito.

ContactTask è una tabella che rappresenta i contatti con cui è necessario comuni- care. Essi vengono salvati nel campo idContactToCall che indica l’identificativo del contatto da chiamare all’interno della rubrica di Android. Dal momento che esistono vari strumenti di comunicazione è stata realizzata un’ulteriore tabella ContactTa- skType nella quale inserire ad esempio email, telefono, chat, e altro a discrezione dell’utente. Il campo duration contiene quanto duri la comunicazione. Esso viene espresso in minuti totali (incluse le ore), così non è necessario salvare in due cam- pi distinti le ore e i minuti effettivi. Importante è notare che un ContactTask è associabile ad un progetto grazie ad una chiave esterna appositamente creata.

Project in questa tabella sono inserite varie informazioni circa un singolo progetto. In particolare si fa notare la chiave esterna idFatherProject verso la stessa tabella Project. Ciò è stato fatto in quanto si vuole gestire la possibilità di avere una gerarchia di progetti. Per semplificare la gestione di quest’ultima invece di salvare i progetti figli di un progetto, se ne salva il padre. Questo perché di figli ce ne possono essere molti, al contrario esistendo un solo padre (che può essere nullo) basta un solo campo. La gestione diretta dei figli di un progetto avrebbe richiesto una tabella in più complicando inutilmente la struttura del database. Per ottenere i figli di un progetto basta quindi una query che cerchi i progetti per cui il padre è quello desiderato.

MyGoogleCalendar Dato che l’applicativo offre la sincronizzazione con Google Calendar è necessario inserire nel database a quale calendario un evento appartenga. Ciò viene fatto in quanto nel servizio offerto da Google si possono definire vari calendari, ad esempio uno per il lavoro, un calendario personale e così via. È quindi possibile inserire un evento nel giusto calendario. Per gestire correttamente questa funzionalità è stata creata questa apposita tabella nella quale si inseriscono i calendari che l’utente ha nell’account Google associato all’applicativo. In questa tabella oltre al titolo del calendario si salvano anche due campi essenziali uno per l’esperienza utente, ed uno per la sincronizzazione. Il primo è il campo color: in questo modo anche all’interno dell’applicativo l’utente può visualizzare gli eventi associati ad un calendario con lo stesso colore ad esso associato all’interno di Google Calendar. Il secondo campo è updated: esso indica, in millisecondi dall’epoch time, l’istante in cui è avvenuta l’ultima sincronizzazione per quel calendario.

Event Qui vengono inseriti gli eventi che avvengono in uno o più giorni. Un evento contiene solo informazioni generiche come l’id associatogli da Google (GoogleID),

39 di 91 CAPITOLO 5. PROGETTAZIONE

l’istante della sua ultima sincronizzazione (updated) e il progetto a cui è riferito. La chiave esterna GoogleCalendarID indica a quale calendario esso appartenga. Moltre altre informazioni vengono gesitite per gli eventi, ma esse risideono nella tabella SingleRepeat.

SingleRepeat Qui vengono gestiti vari campi che riguardano una singola occor- renza di un evento. Ogni istanza di questa tabella deve infatti essere associata ad un Event. La presente tabella contiene giorno ed ora d’inizio e di fine, località, tempo di trasporto prima e dopo e altri campi. Ho preferito scindere queste informazioni dalla tabella Event in quanto un evento può essere ripetuto e quindi può avere più SingleRepeat che lo referenziano grazie ad un’apposita chiave esterna. Dentro a SingleRepeat è presente il campo appointmentOrEvent. Esso è stato inserito per una miglior gestione della vista giornaliera. In essa vengono mostrati gli appuntamenti che hanno un’ora d’inizio e di fine all’interno di una griglia con tutte le ore della giornata, quindi in un apposito spazio si mostrano gli eventi che durano per tutto il giorno e quindi occuperebbero spazio per nulla nella griglia con tutte le ore. Per fare ciò è però necessario distinguere chiaramente quali siano gli eventi e gli appuntamenti: a questo serve il campo appointmentOrEvent. Il campo editLink è utile in fase di sincronizzazione in quanto è il link offerto da Google per modificare o cancellare il SingleRepeat in questione.

StandardTask Questi sono dei compiti che devono essere svolti durante uno o più giorni. Essi possono avere una durata e possono essere associati ad un progetto. Dal momento che un task può durare molti giorni, è necessario poter spartire le ore necessarie per completarlo tra più giorni: a questo serve la tabella EffortStdTask.

Note qui si possono inserire delle note con un titolo, una data di creazione e, ovviamente, un contenuto. Importante è sottolineare che una nota può essere associata ad un GeneralToDo. In questo modo è possibile associarla ad ogni entità presente nel database come eventi, progetti, standard task, contact task in quanto essi - come esposto in precedenza - sono proprio dei GeneralToDo.

5.2 Progettazione dei packages e delle classi

Il Design Pattern architetturale che sta alla base di tutto l’applicativo è MVC.I packages individuati e le relazioni tra essi sono visibili in figura 5.2

• com.ceremit.agenda è il package generale. Contiene alcune classi di pubblica utilità che permettono di avviare l’applicazione o che contengono funzioni utili per gli altri packages che compongo il programma. Essi vengono elencati di seguito.

• model è il package che contiene la definizione di tutte le entità presenti nel database. Esso offre anche una classe Façade per accedervi. • view contiene la definizione di tutte le varie attività che permettono all’utente di interagire con il programma. In particolare la grafica è stata divisa in modo tale che lo schermo del tablet abbia due aree nelle quali l’utente può utilizzare l’applicativo. Per suddividere al meglio la struttura dei packages ho deciso di crearne uno per ognuna delle suddette aree. Infine ho aggiunto un terzo package per gestire la grafica che permette all’utente di interagire con il database. I sotto-packages di view sono dunque i seguenti:

40 di 91 5.2. PROGETTAZIONE DEI PACKAGES E DELLE CLASSI

• leftFragment: in esso sono presenti le classi che permettono di visualiz- zare l’area di sinistra. In essa viene offerto un menu generico che permette di visualizzare il calendario, la lista dei progetti e la lista delle note. • rightFragment: qui si trova la definizione degli elementi della parte destra dello schermo. In essa l’utente può visualizzare la vista giornaliera con indicati gli appuntamenti, oppure una vista con i dettagli di un singolo progetto. • create: in questo package sono presenti le attività per creare o modificare delle entità che poi verrano inserite nel database come eventi, progetti, note ecc... • controller: package che fa da ponte tra il model e la view. • sync package che offre delle funzionalità per gestire la sincronizzazione con Google calendar. • sync.model: in esso sono presenti delle classi utili per gestire i dati che vengono inviati/ricevuti da Google Calendar.

com.ceremit.agenda

model controller

sync view view.create sync.model

view.leftFragment

view.rightFragment

Figura 5.2: Diagramma dei packages sviluppati.

5.2.1 package agenda. Questo è il package generale che contiene alcune classi di pubblica utilità. Esse sono visibili in figura 5.3.

WelcomeActivity Quest’attività viene lanciata all’apertura dell’applicazione e mostra un breve riassunto della giornata odierna. In particolare si indicano i minuti di appuntamenti, di contact task, di standard task e di trasporto che l’utente deve assolvere. È quindi presente un tasto per entrare veramente. Nel caso l’utente abbia impostato la password è necessario inserirla prima di procedere.

41 di 91 CAPITOLO 5. PROGETTAZIONE

android::app

+ Activity + TabActivity com::ceremit::agenda

+ WelcomeActivity + AgendaPreferences Singleton -enterButton : Button -PASSWORD_PREF : String -passwordEditText : EditText -PREF_GOOGLE_ACCOUNT_KEY : String -contactTaskMinuteTextView : TextView -NO_GOOGLE_ACCOUNT_KEY : String -appointmentMinuteTextView : TextView -PREF_AUTH_TOKEN : String -transportMinuteTextView : TextView -PREF_GSESSIONID : String -stdTaskMinuteTextView : TextView -LAST_SYNC_EPOCH : String -todayTextView : TextView -MINUTE_FOR_APPOINTMENTS : String -passwordLayout : LinearLayout -TRANSPORT_COLOR : String -mDbHelper : DatabaseSchema -NO_GOOGLE_CALENDAR_COLOR : String -enterLayout : LinearLayout -APPOINTMENT_DURATION : String -TRANSPORT_DURATION : String #onCreate(savedInstanceState : Bundle) : void -FIRST_SYNC_START_DAY : String -FIRST_SYNC_END_DAY : String + Utils -instance : AgendaPreferences +getInstace() : AgendaPreferences +formatMinute(minute : int) : String -AgendaPreferences() +getEpoch(datePicker : DatePicker) : int +getName(id : Long) : String + Agenda +setEventOrAppointment(singleRepeat : SingleRepeat) : void +daysSinceEpoch(requestedDate : GregorianCalendar) : int +onCreate(savedInstanceState : Bundle) : void +formatDate(millisecondsSinceEpoch : Long,setTime : boolean) : String +onCreateOptionsMenu(menu : Menu) : boolean +getTimeZone() : String +onOptionsItemSelected(item : MenuItem) : boolean +createSha1(text : String) : String -settings() : void

Figura 5.3: Diagramma delle classi del package com.ceremit.agenda.

Agenda È la classe principale dell’applicazione. Al primo avvio della stessa chiede all’utente se vuole associare un account Google per la sincronizzazione del calendario. Il metodo settings() permette di gestire il menu del programma come:

• inserimento e modifica della password.

• colore di sfondo per gli eventi ed il trasporto.

• avvio della sincronizzazione.

• chiusura dell’applicazione.

• valori di default.

AgendaPreferences In questa classe vengono salvate le preferenze dell’applica- zione. Android offre infatti la possibilità di salvare semplici stringhe di testo in modo persistente secondo la logica chiave-valore senza dover appoggiarsi al database. Ciò si rivela molto comodo per la semplicità d’uso. Tra le varie informazioni salvate in questo modo ci sono le impostazioni dell’utente come l’istante in millisecondi dall’epoch time in cui è stata fatta l’ultima sincronizzazione, il nome dell’account Google associato all’applicazione, i colori scelti come quello per il trasporto e così via. La classe offre numerosi metodi getter e setter che sono stati omessi per semplificare l’immagine. In essa ogni campo sottolineato rappresenta un campo statico che è la chiave di una preferenza salvata all’interno del dispositivo. Dal momento che questa classe non ha uno status interno in quanto il suo scopo è semplicemente quello di gestire le chiavi, ho adottato il pattern Singleton. In questo modo risulta semplice utilizzarla, basta infatti richiamare il metodo statico getInstance().

42 di 91 5.2. PROGETTAZIONE DEI PACKAGES E DELLE CLASSI

Utils Questa classe offre numerosi metodi statici di pubblica utilità. In particolare sono presenti delle funzionalità per gestire i tempi, i fusi orari o per ottenere l’hash di una stringa.

5.2.2 package agenda.model e agenda.controller Il package model rappresenta il database. Di esso non viene fornita in questa sede il diagramma UML in quanto la sua struttura è molto semplice e ricalca esattamente quella del modello relazionale in figura 5.1. In particolare per ogni tabella presente in essa, è stata creata una classe nel package model. In esso ho definito una classe Façade DatabaseSchema che si occupa di svolgere tutte le operazioni necessarie sul database. In particolare vengono offerti metodi per:

• interrogare il database. Questi metodi risultano particolarmente utili per il package view in quanto permettono di richiedere delle informazioni alla base di dati senza dover passare per il package controller.

• inserire nuove entità nel database.

• aggiornare entità già presenti. Nel caso si richieda questa funzionalità per qualcosa che non è inserito l’aggiornamento non andrà a buon fine e si ritornerà false, viceversa si ritorna true.

• cancellare entità già presenti. Anche in questo caso ci si comporta esattamente come al punto precedente.

Inoltre al primo avvio dell’applicazione questa classe si occupa anche di creare il database, generando tutte le tabelle necessarie ed effettuando un piccolo popolamento di prova. Esso si è rivelato molto comodo durante lo sviluppo e il test del database. Anche del package controller non viene fornito un diagramma uml, il suo contenuto è infatti molto elementare. Sono presenti delle classi che emulano il database permettendo lo scambio dati tra i vari packages. Ogni classe offre dei metodi getter e setter per ottenere o modificare i suoi attributi. In questo modo si garantisce l’information hiding. Questo package ha anche il compito di assicurare la correttezza dei dati che vengono inseriti o aggiornati nel database.

5.2.3 package agenda.view.create Questo package contiene la definizione delle attività che permettono la creazione di una nuova entità. Si possono creare eventi, appuntamenti, progetti note ecc... Ogni classe offre un’interfaccia grafica appositamente definita in un file separatamente sviluppato. Il diagramma delle classi di tale package è visibile in figura 5.4.

ChangePassword Questa classe permette di gestire la password. Di default non ne è associata alcuna all’applicativo, tramite le impostazioni è però possibile settarla e successivamente modificarla. Le password vengono salvate attraverso una funzione di hashing (SHA) al fine di incrementare la sicurezza dell’applicativo.

CreateAppointmentActivity Questa attività permette di creare un appunta- mento o un evento da inserire nell’agenda. In questo momento l’utente può anche decidere se ripetere il nuovo evento: per fare ciò viene creata un’istanza della classe SelectRepeatDateActivity. Altra particolarità di questa classe è la possibilità di

43 di 91 CAPITOLO 5. PROGETTAZIONE

android::app

+ Activity

com::ceremit::agenda::view::create

+ CreateStdTaskActivity + ChangePassword + DivideStdTaskEffortActivity -saveButton : Button -oldPwdEditText : EditText -titleTaskEditText : EditText -finishButton : Button -newPwdEditText : EditText -descriptionTaskEditText : EditText -typeRepeatitionSpinner : Spinner -repeatedPwdEditText : EditText -priorityRadioGroup : RadioGroup -everyNumberPicker : NumberPicker -oldPwdTableRow : TableRow -startDatePicker : DatePicker -includeWeekendCheckBox : CheckBox -saveButton : Button -endDatePicker : DatePicker -singleEffortTimePicker : TimePicker -rootLayout : TableLayout -hourPicker : NumberPicker +EFFORT_EVERY_NUMBER : String #onCreate(savedInstanceState : Bundle) : void -minutePicker : NumberPicker +REPEATED_TYPE : String -alertUser(message : String,closeChangePwdActivity : boolean) : void -selectProjectCheckBox : CheckBox +EFFORT_INCLUDE_WEEKEND : String -selectedProjectTitleTextView : TextView +MINUTE_PER_EFFORT : String -compeleteSeekBar : SeekBar -singleEffort : Integer + CreateAppointmentActivity -completeTextView : TextView -every : Integer -mDBHelper : DatabaseSchema -divideEffortButton : Button -typeRepetition : String -saveButton : Button -SELECT_PROJECT : int -includeWeekend : Boolean -repeatCheckBox : CheckBox -referencedProjectTitle : String #onCreate(savedInstanceState : Bundle) : void -titleApponitmentEditText : EditText -referencedProjectId : Long -descriptionApponitmentEditText : EditText -DIVIDE_EFFORT : int -typeApponitmentRadioGroup : RadioGroup -singleEffort : Integer + NoteEditor -travelHourNumberPicker : NumberPicker -every : Integer -note_ : Note -travelMinuteNumberPicker : NumberPicker -typeRepetition : String -saveNoteButton_ : Button -localityEditText : EditText -includeWeekend : Boolean -cancelNoteButton_ : Button -startTimePicker : TimePicker -maxWeekendNumber : int -associateNoteButton_ : Button -durationHourNumberPicker : NumberPicker #onCreate(savedInstanceState : Bundle) : void -titleNoteEditText_ : EditText -durationMinuteNumberPicker : NumberPicker -saveStdTask() : void -contentNoteEditText_ : EditText -transportBeforeCheckbox : CheckBox -generateDivisionEffor(newStdTask : StdTask) : void -associatedTextView_ : TextView -transportReturnCheckbox : CheckBox #onActivityResult(requestCode : int,resultCode : int,data : Intent) : void +PROJECT_ASSOCIATION : String -allDayCheckbox : CheckBox +ID_NOTE : String -calendarSpinner : Spinner + CreateProjectActivity +PROJECT_ID : String -startDatePicker : DatePicker -mDbHelper : DatabaseSchema -selectProjectCheckBox : CheckBox -PICK_CONTACT : int -referencedProjectTitle : String -SELECT_FATHER : int #onCreate(savedInstanceState : Bundle) : void -referencedProjectId : Long -titleEditText : EditText #onActivityResult(requestCode : int,resultCode : int,data : Intent) : void -selectedProjectTitleTextView : TextView -descriptionEditText : EditText +onBackPressed() : void -rightTableLayout : TableLayout -selectResponsibileButton : Button -saveNote() : void -typeRepetition : String -selectedResponsibileNameTextView : TextView -every : Integer -startDatePicker : DatePicker -finishEpoch : Long -endDatePicker : DatePicker -REPEAT_DATE : int -statusRadioGroup : RadioGroup -SELECT_PROJECT : int -goalEditText : EditText + CreateContactTaskActivity -NO_CALENDAR : String -milestoneCheckbox : CheckBox +EVENT_ID : String -saveButton : Button -datePicker : DatePicker +SINGLE_REPEAT_ID : String -selectFatherButton : Button -priorityRadioGroup : RadioGroup +REPEATED_EVENT : String -idResponsible : Long -tipologyRadioGroup : RadioGroup +ONLY_THIS_REPETITION : String -fatherProject : Project -hourPicker : NumberPicker +ONLY_FUTURE_REPETITIONS : String -titleString : String -minutePicker : NumberPicker +ALL_REPETITIONS : String -descriptionString : String -startTimePicker : TimePicker -idEventToUpdate : Long -responsibleNameString : String -finishButton : Button -idSingleRepeatToUpdate : Long -startDateInteger : Integer -selectContactButton : Button -repeated : Boolean -endDateInteger : Integer -selectProjectCheckBox : CheckBox -changeOnlyThis : Boolean -goalString : String -contactNameTextView : TextView -changeOnlyFuture : Boolean -milestoneBoolean : Boolean -titleSelectedProjectTextView : TextView -changeAll : Boolean -statusRadioButtonSelected : ProjectStatus -PICK_CONTACT : int -eventToModify : Event -mDBHelper : DatabaseSchema -SELECT_PROJECT : int +PROJECT_ID : String -idContact : Long #onCreate(savedInstanceState : Bundle) : void -idEditProject : Long -nameContact : String #onActivityResult(requestCode : int,resultCode : int,data : Intent) : void -idProject : Long -saveEvent() : void +onCreate(savedInstanceState : Bundle) : void -mDbHelper : DatabaseSchema +onActivityResult(reqCode : int,resultCode : int,data : Intent) : void -contactTypeArrayList : ArrayList +1 -saveProject() : void #onCreate(savedInstanceState : Bundle) : void + SelectProjectActivity +onActivityResult(reqCode : int,resultCode : int,data : Intent) : void + SelectRepeatDateActivity -mDbHelper : DatabaseSchema -context_ : Context -finishSelectRepeatButton : Button -projectListLayout_ : LinearLayout -finishDateDatePicker : DatePicker +SELECTED_ID : String -typeRepeatitionSpinner : Spinner +SELECTED_TITLE : String -everyNumberPicker : NumberPicker -projectHistory : ArrayList +REPEATED_EVERY_NUMBER : String -okButton : Button +REPEATED_TYPE : String -backButton : Button +REPEATED_FINISH_EPOCH_MILLISECONDS : String -projectTitle : TextView -typeRepetition : String -every : Integer #onCreate(savedInstanceState : Bundle) : void -finishEpoch : Long -setProjectItems(project : Project) : void +REPEATED_DATE : String +selectedProject(project : Project) : void #onCreate(savedInstanceState : Bundle) : void

Figura 5.4: Diagramma delle classi del package com.ceremit.agenda.view.create.

44 di 91 5.2. PROGETTAZIONE DEI PACKAGES E DELLE CLASSI scegliere a che calendario associare il nuovo evento grazie ad un menu a tendina (calendarSpinner). In alternativa è anche possibile lasciare vuoto questo campo: il nuovo evento non sarà sincronizzato con Google calendar. È possibile dare un’ora d’inizio, di fine e indicare il tempo di trasporto prima e/o dopo l’appuntamento. Ciò però vale solo se l’evento non dura tutto il giorno. Se così fosse basta spuntare un’apposita checkbox (allDayCheckbox) che disabiliterà i campi sopra citati. Ovvia- mente se viene deselezionata verranno riabilitati i campi per selezionare gli orari dell’appuntamento.

CreateStdTaskActivity Questa attività permette di create uno standard Task. L’utente può decidere di dare una durata a tale compito, una data d’inizio ed una di fine. In tal caso si può dividere tale sforzo in diversi giorni grazie alla classe DivideStdTaskEffort. Se tale suddivisione delle ore dovesse portare ad una data di fine successiva a quella impostata l’applicativo avvisa l’utente con un pop-up proponendogli di cambiare la data di fine o di modificare la suddivisione delle ore in cui svolgere lo standard task. Anche gli standard task possono essere associati ad un progetto allo stesso modo degli appuntamenti.

DivideStdTaskEffort Come esposto nel paragrafo precedente, con questa classe si può suddividere un totale di ore da svolgere in diversi giorni. In particolare si può selezionare quanti minuti si vogliano lavorare ogni quanto tempo. Ad esempio si può indicare di voler lavorare 3 ore ogni 2 giorni a quel particolare task.

CreateProjectActivity Con questa attività è possibile creare un nuovo progetto o modificarne uno già inserito. È possibile inserire un responsabile scegliendolo dalla ru- brica del proprio dispositivo Android, indicare una data d’inizio e di fine e selezionare un progetto padre attraverso un’istanza della classe SelectProjectActivity.

NoteEditor Questa attività crea una semplice finestra nella quale è possibile creare una nota inserendo un titolo ed un contenuto. Essa permette di salvare la nota e cancellarla. Nel primo caso se il salvataggio è andato a buon fine viene avvisato l’utente con una Dialog appositamente creata, nel secondo si chiede all’utente se vuole veramente cancellare la nota.

SelectRepeateDateActivity Tale classe è utile nel momento in cui si crea un evento. È infatti possibile dire ogni quanto tale evento ricorre. Per la selezione della cadenza si è optato per uno stile molto simile a quello offerto da Google Calendar che si rivela estremamente semplice ed efficace. È quindi possibile indicare ogni quanti giorni/mesi/anni/settimane si deve ripete l’evento fino ad una certa data di fine .

SelectProjectActivity Questa classe viene usata ogni qual volta sia necessario scegliere un progetto. Viene quindi utilizzata quando si deve indicare il padre del progetto che si sta creando oppure quando si vuole associare uno standard task, un contact task un evento o una nota ad un progetto. All’apertura la finestra mostra i progetti che non hanno padre, selezionandone uno vengono mostrati i suoi figli. Attraverso un taso è possibile tornare al livello superiore mentre con un altro si può selezionare il progetto correntemente visualizzato.

45 di 91 CAPITOLO 5. PROGETTAZIONE

CreateContactTaskActivity Permette di creare un nuova nuova comunicazione. Attraverso un radiogroup è possibile scegliere a che tipologia essa appartenga (chat, telefonata, skype...), il giorno e l’ora e dare una durata stimata. La selezione contatto avviene navigando nella rubrica presente nel dispositivo, proprio come si seleziona un responsabile per il progetto.

5.2.4 package agenda.view.leftFramgent

android::widget android::app

+ Fragment + RelativeLayout

com::ceremit::agenda::view::leftFragment

+ MenuFragment -rootLayout : LinearLayout -context : Context +onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View +stackRightPanelFragment(panel : RightPanelFragment) : void

+ MenuNotesListFragment + MenuProjectFragment -context_ : Context -context_ : Context -createNoteButton : Button -createProjectButton : Button -CREATE_NOTE : int -CREATE_PROJECT : int -notesLayout_ : LinearLayout -mDbHelper : DatabaseSchema -notesArrayList_ : ArrayList -projectListLayout_ : LinearLayout -mDbHelper : DatabaseSchema -backButton : Button -projectHistory : ArrayList +onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View +onActivityResult(requestCode : int,resultCode : int,data : Intent) : void +onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View +updateListNote() : void +onActivityResult(requestCode : int,resultCode : int,data : Intent) : void -setProjectItems() : void +setSonsItems(currentProject : Project) : void 1 +addProjectHistory(project : Project) : void 0..* 1 + MenuItemNote

-note_ : Note 0..* -titleNoteTextView : TextView -menuFragment_ : MenuFragment + MenuItemProject <> +MenuItemNote(context : Context,note : Note,menuPanel : MenuFragment) -project_ : Project -menuFragment_ : MenuProjectFragment + CalendarViewFragment -titleTextView_ : TextView +CREATE_STDTASK : int <> +MenuItemProject(context : Context,project : Project,menuPanel : MenuProjectFragment) +CREATE_APPOINTMENT : int +CREATE_CONTACT_TASK : int -createTask : Button -createAppointment : Button -createContactTask : Button -datePicker : DatePicker

+onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View +onActivityResult(requestCode : int,resultCode : int,data : Intent) : void +setDateOnCalendar(calendar : GregorianCalendar) : void

Figura 5.5: Diagramma delle classi del package com.ceremit.agenda.view.leftFragment.

In questo package, il cui diagramma delle classi è visibile in figura 5.5, vengono definiti dei Frammenti che vengono utilizzati per creare il Layout dell’applicazione. Un Frammento non è altro che una porzione dello schermo che viene riempita in modo autonomo come fosse una finestra a sé stante. In particolare in questo package sono presenti dei frammenti per la parte sinistra dello schermo che corrisponde ad un menu. Le classi più importanti sono CalendarViewFragment, MenuNote- ListFragment e MenuProjectFragment in quanto creano i 3 menu principali dell’applicazione che gestiscono rispettivamente il calendario e quindi l’agenda, la lista delle note e quella dei progetti.

MenuFragment Questa è la classe generica da cui derivano altre classi di questo package. Essa permette molto semplicemente di generare un frammento in quanto deriva dall’apposita classe Fragment di Android che si occupa anche di questo. Inoltre viene aggiunto un metodo stackRightPanelFragment(RightPanelFragment ) che permette di sostituire il pannello di destra - ovvero quello in cui è presente il contenuto vero e proprio - con quello che gli viene passato come parametro

CalendarViewFragment Questo frammento permette all’utente di vedere un calendario nel quale si possono selezionare i giorni, appena viene tappato su uno di essi viene modificato il pannello di destra mostrando il riassunto del giorno selezionato.

46 di 91 5.2. PROGETTAZIONE DEI PACKAGES E DELLE CLASSI

In particolare viene creata un’istanza della classe DailyViewFragment che viene inserita nel pannello di destra. Sempre in questo frammento sono presenti dei tasti per creare un appuntamento, uno standard Task o un contact Task. Per fare ciò viene avviata la corrispondente attività del package create.

MenuNoteListFragment e MenuProjectFragment Queste classi generano un pannello con le liste delle note e dei progetti inseriti nel database. Tappando su uno di essi ne viene visualizzato il contenuto nel frammento di destra.

MenuItemNote e MenuItemProject Queste due classi sono state create per semplificare la gestione della lista delle note e dei progetti: è infatti necessario un elemento che rappresenti in modo generico una nota o un progetto. MenuNote- ListFragment e MenuProjectFragment creeranno quindi delle liste di questi item.

5.2.5 package agenda.view.rightFragment

android::app

+ Fragment

com::ceremit::agenda::view::rightFragment

+ RightPanelFragment + NoteView -rootLayout : LinearLayout -EDIT_NOTE : int -context : Context -titleNoteTextView_ : TextView -creationDateTextView_ : TextView +onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View -referredToTitleTextView_ : TextView +stackRightPanelFragment(panel : RightPanelFragment) : void -contentNoteTextView_ : TextView -editNoteButton_ : Button -cancelNoteButton_ : Button + DailyViewFragment -context_ : Context -noteView_ : View -context : Context -note_ : Note -eventsLayout : LinearLayout -notesListFragment : MenuFragment -hourssLayout : LinearLayout -mDBHelper : DatabaseSchema -appointmentsLayout : RelativeLayout -contactLayout : TableLayout <> +NoteView(note : Note,notesListFragment : MenuFragment) -taskLayout : TableLayout +onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View -eventArrayList : ArrayList +onActivityResult(requestCode : int,resultCode : int,data : Intent) : void -appointmentArrayList : ArrayList -updateNote() : void -contactTaskArrayList : ArrayList -setInfo() : void -mDbHelper : DatabaseSchema -yesterdayButton : Button + SingleProjectView -tomorrowButton : Button -currentDayEpoch : int -project_ : Project -year_ : int -context_ : Context -month_ : int -projectView_ : View -day_ : int -titleTextView : TextView -dayTextView_ : TextView -descriptionTextView : TextView -dailyView_ : View -responsibileNameTextView : TextView -leftFragment : CalendarViewFragment -startDateTextView : TextView -hoursScrollView : ScrollView -endDateTextView : TextView -currentHourTextView : TextView -statusTextView : TextView -minutes_per_piece : int -goalTextView : TextView -PIXEL_PER_PIECE : int -milestoneTextView : TextView -APPOINTMENTS_WIDTH : int -appointmentsLayout : TableLayout -APPOINTMENTS_RIGHT_MARGIN : int -notesLayout : LinearLayout #EDIT_EVENT : int -stdTaskLayout : TableLayout -editButton : Button <> +DailyViewFragment(year : int,month : int,day : int,leftFragment : CalendarViewFragment) -addNoteButton : Button +onCreate(savedInstanceState : Bundle) : void -mDbHelper : DatabaseSchema +onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View -menuFragment_ : MenuFragment -setCurrentHourLine() : void -contactTaskLayout : TableLayout -setStdTask() : void -CREATE_NOTE : int -setAppointments() : void -EDIT_PROJECT : int -setEvents() : void -setContactTask() : void <> +SingleProjectView(project : Project,menuFragment : MenuFragment) +upadteStdTask() : void +onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle) : View +upadteEvents() : void -setAppointment() : void +upadteAppointments() : void -setStdTaskList() : void +upadteContactTask() : void -setContactTask() : void +deleteEvent(event : Event) : void +onActivityResult(requestCode : int,resultCode : int,data : Intent) : void +editEvent(event : Event) : void +setNoteList() : void +onActivityResult(requestCode : int,resultCode : int,data : Intent) : void +setInfo() : void -drawHours() : void -createCompleteDialog(task : StdTask) : void +updateHours() : void +updateStdTask() : void

Figura 5.6: Diagramma delle classi del package com.ceremit.agenda.view.rightFragment.

In questo package visibile in figura 5.6 vengono definite le classi che si riferiscono alla parte destra dello schermo. Anche in questo caso esse derivano dalla classe Fragment di Android.

RightPanelFragment Contiene la definizione di un frammento per la parte destra dello schermo. È presente un metodo che permette di modificare il pannello destro sostituendolo con uno di nuovo.

47 di 91 CAPITOLO 5. PROGETTAZIONE

DailyViewFragment Questo frammento permette di avere un riassunto della giornata selezionata. In alto esso offre tre tasti per andare al giorno precedente (yesterdayButton) e a quello successivo (tomorrowButton) rispetto a quello selezionato e uno per andare al giorno corrente (dayTextView). Quindi vengono definite 4 aree distinte:

• area appuntamenti: qui viene creata una griglia con tutte le ore della giornata (hoursLayout). Sopra ad essa vengono inseriti tutti gli appuntamenti della giornata che hanno un’ora d’inizio e di fine (appointmentsLayout). Nel caso ci sia anche un trasporto esso viene aggiunto prima e/o dopo l’appuntamento. Se ci sono appuntamenti che si sovrappongono essi vengono visualizzati uno accanto all’altro finché c’è spazio. Per semplificare la visualizzazione degli appuntamenti ho inserito una linea rossa che viene tracciata sull’ora corrente in modo da fa capire velocemente all’utente quale sia il prossimo appuntamento: currentHourTextView.

• area eventi qui si mostrano gli appuntamenti che durano tutto il giorno. Se essi sono associati ad un calendario Google, l’etichetta con il nome dell’evento avrà come colore di sfondo quello del suo calendario d’appartenenza. Ciò vale anche per l’area appuntamenti.

• area contactTask è una tabella che contiene varie informazioni sulle persone da contattare nel giorno selezionato. Si mostrano il nome della persona l’ora e la durata prevista. È inoltre presente una colonna che indica se un certo contact task è stato eseguito. Una x indica che esso deve ancora essere svolto, tappando su di essa il task viene segnato come completato e la x viene sostituita con un tic che indica appunto l’adempimento del task.

• area standardTask come l’area del punto precedente, ma relativa ai task che vengono svolti in giorni diversi.

Per ognuna di queste aree eseguendo un long tap su un elemento viene aperta una dialog contestuale nella quale l’utente può eseguire particolare azioni come cancellare o modificare l’elemento selezionato. In questa classe si definisco anche dei metodi di aggiornamento (updateAppointments (), updateEvents() ...) al fine di poter ricreare una certa area nel caso venga inserito o modificato qualcosa. Così non è necessario ricreare tutto il frammento della vista giornaliera, ma solo l’area che lo necessita velocizzando l’applicativo.

NoteView Si tratta di una vista molto semplice che permette di vedere i dettagli di una nota come la data di creazione, il titolo ed il contenuto. Sono presenti due tasti che permettono di cancellare la nota (cancelNoteButton) e di modificarla (editNoteButton). Nel caso si clicchi sul primo viene chiesto all’utente se è veramente sicuro di cancellare la nota, se si clicca sul secondo viene aperta un’istanza della classe NoteEditor.

SingleProjectView Qui si visualizzano tutte le informazioni su un progetto come il suo responsabile, le note, gli eventi, i contact task e gli standard task ad esso associati. È possibile modificare il progetto attraverso un apposito tasto.

5.2.6 pacakge agenda.sync

Grazie a questo package, visibile in figura 5.7 è possibile effettuare la sincronizza- zione con il calendario Google. Appena l’utente ha cliccato sul tasto ’sincronizza’,

48 di 91 5.2. PROGETTAZIONE DEI PACKAGES E DELLE CLASSI

è necessario ottenere un’autenticazione per il suo account Google. Ciò avviene in automatico a patto che l’applicazione abbia i permessi per accedere al calendario. Questo permesso viene dato dall’utente in fase d’istallazione. Nel caso non vengano concessi l’applicazione non potrà autenticarsi e di conseguenza la sincronizzazio- ne fallirà lanciando un’AutenticationException. Viceversa essa può effettuare l’autenticazione attraverso il protocollo OAuth2. Esso ritornerà due stringhe: un token di autenticazione e un id di sessione. Fornendo tali informazioni negli header HTTP che vengono inviati a Google l’applicazione ha accesso in lettura e scrittura al calendario dell’utente. La classe che si occupa di tutto ciò è CalendarSync grazie al metodo autenticate(). La realizzazione della sincronizzazione avviene grazie alla classse DoSync che deriva da Thread. Le informazioni che vengono condivise con Google sono in formato XML inserite in richieste e risposte HTTP. Per gestirle agevolmente ho creato un sottopackage sync.model nel quale ho inserito delle classi dove ogni attributo è una chiave. Grazie alle funzionalità offerte dalla libreria Google--java-client è possibile effettuare il parsing di questi file xml ottenendo le corrispondenti istanze delle classi. Ciò si rivela estremamente comodo e semplifica di molto la lettura delle informazioni. In esso sono presenti principalmente queste classi:

Entry Rappresenta una generica entità che viene ritornata dal calendario di Google. Esistono due tipi di Entry che dunque derivano da essa:

• EventEntry è un evento. Di esso è necessario poter ottenere giorno ed ora d’inizio e di fine, località e Status (cancelled o confirmed). Per fare ciò sono state create delle apposite classi. Ognuna di esse deve ricalcare la struttura dei nodi presenti nell’XML affinché sia possibile effettuare il parsing del documento e ottenerne quindi una rappresentazione ad oggetti. Per questo sono presenti le classi Where e Status sebbene esse contengano solo un attributo: nel file XML è presente un nodo Event che contiene tra gli altri un nodo per la località e uno per quando avviene l’evento i quali hanno degli attributi che vengono letti appunto grazie alle due classi Where e Status. La regola dunque è che le chiavi di una classe permettono di accedere ai valori dei figli e degli attributi del nodo a cui la classe si riferisce. Non è permesso un contenuto misto: un nodo o ha figli o ha testo. Si fornisce di seguito un breve esempio per comprendere meglio il funzionamento. Supponiamo che l’xml di cui vogliamo una trasposizione ad oggetti sia così composto: http://www.Google.com/calendar/feeds/nicola.gonzo%40 .com/private/full/ _b19ija38562qd9l60rjid9o6ksiqdpi6oo3ee1n70qiqc9j6ssjecpl68 2011-05-30T20:12:27.000Z 2011-06-29T20:33:02.000Z Esame di Tecnologie Web

Il risultato finale sarà un’istanza della classe Entry (in quanto il nodo principale si chiama entry) che avrà come valori delle chiavi id, published, updated e title il contenuto di tali nodi. Al contrario la chiave when avrà associata un’istanza di un’apposita classe When dove gli attributi endTime e startTime avranno il valore degli attributi del nodo when presente nell’xml.

49 di 91 CAPITOLO 5. PROGETTAZIONE

• CalendarEntry è un calendario che l’utente ha aperto in Google calendar. Tra le informazioni che vengono gestite c’è l’id, il colore e il fuso orario ad esso associato. Essenziale è poter ottenere il feed degli eventi di quel calendario. Di questo si occupa il metodo getEventFeedLink().

Feed Rappresenta un insieme di dati dello stesso tipo. Importante è avere il link che punta a quel feed per poterlo richiedere. Esistono due derivazioni di questa classe: EventFeed ed CalendarFeed. Il primo rappresenta un insieme di EventEntry, il secondo di CalendarEntry.

java::lang

Entry -> Cloneable <> + Thread + Exception <> + Cloneable

com::ceremit::agenda::sync

model + CalendarEntry + Entry + EventFeed + Feed +id : String +summary : String +eventsList : List +color : GColor +links : List +title : String +timeZone : GTimeZone +updated : String +updated : String +links : List +getEventFeedLink() : String +getNextLink() : String +clone() : CalendarEntry +getBatchLink() : String #clone() : Entry +getEditLink() : String + When 1 +endTime : String + CalendarFeed + EventEntry +startTime : String +calendars : List +published : String +id : String + CalendarClient +when : When 1 +content : String + Where -requestFactory : HttpRequestFactory +where : Where +whereString : String <> +CalendarClient(requestFactory : HttpRequestFactory) +status : Status +executeDelete(entry : Entry) : void +visibility : Visibility 1 +executeUpdate(event : EventEntry) : void + Status +executeInsert(entry : Entry,url : CalendarUrl) : Entry +executeGetCalendarFeed(url : CalendarUrl) : CalendarFeed +statusString : String +executeGetEventFeed(url : CalendarUrl) : EventFeed

+ CalendarSync +AUTH_TOKEN_TYPE : String + DoSync -authToken : String -mDbHelper : DatabaseSchema -gsessionid : String -client : CalendarClient -accountManager : AccountManager -GOOGLE_STATUS_CANCELED : String -context : Context -calendarSync : CalendarSync -activity : Agenda -client : CalendarClient <> +DoSync(client : CalendarClient,calendarSync : CalendarSync) -transport : HttpTransport +run() : void +ACCOUNT_LOST : String -downloadEvents(lastSync : Long,pushedEvents : ArrayList) : void +SYNCH_ERROR : String -pushEvents(lastSync : Long) : ArrayList +SYNCH_IS_FINISHED : String <> +CalendarSync(activity : Agenda) +showMessage(message : String) : void +firstSync() : void + AutenticationException +autenticate() : void

Figura 5.7: Diagramma delle classi del package com.ceremit.agenda.sync.

50 di 91 Capitolo 6

Realizzazione

La codifica dell’applicazione è stata la fase che ha richiesto lo sforzo maggiore. Ho adottato uno sviluppo incrementale realizzando le varie funzionalità in modo trasversale. Per aggiungerne una implementavo in ordine i metodi e classi del Model, quindi quelle del Controller infine mi occupavo della grafica. Ciò mi ha permesso di aver sin da subito un applicativo funzionante, sebbene con pochissime potenzialità. I principali incrementi che ho svolto sono stati:

• realizzazione dell’inserimento e della visualizzazione di appuntamenti, eventi, contact task, standard task e progetti.

• sincronizzazione con Google Calendar.

• inserimento delle preferenze.

6.1 Norme utilizzate

L’utilizzo di norme è essenziale per realizzare un buon progetto software in quanto esse permettono di rendere il codice molto più leggibile. Ciò è importante poiché esso verrà preso in mano non solo dal suo autore ma anche da altre persone che possono partecipare al progetto. Esse risultano ancora più importanti nel caso in cui si realizzi un prodotto finito, infatti la manutenzione a cui esso sarà sottoposto occuperà gran parte del suo ciclo di vita. In questo periodo le revisioni del codice saranno numerose, quindi è utile che esso sia scritto con la maggior chiarezza possibile. Per la stesura del codice ho quindi seguito le seguenti norme, tra le quali la maggior parte sono ispirate alle convenzioni java.

• il nome delle classi sono stati scritti in CamelCase con la prima lettera maiuscola.

• il nome delle variabili e dei metodi è anch’esso in CamelCase, ma con la prima lettera minuscola.

• le costanti e i campi dati statici sono scritti tutti in maiuscolo e con l’uso dell’un- derscore.

• il nome dei package inizia con la lettera minuscola.

• la ricorsione è stata evitata per creare un codice più semplice da capire, in particolare in sede d’analisi statica.

• il codice viene scritto in lingua inglese.

• i commenti sono redatti in italiano.

51 CAPITOLO 6. REALIZZAZIONE

• per semplificare la lettura del codice, ogni variabile grafica termina con il suo tipo. Ad esempio un Button si potrebbe chiamare saveButton.

• per indentare il codice si utilizzano 4 spazi e non le tabulazioni, così da favorire la lettura anche su altri ambienti di sviluppo.

• la lunghezza massima di una riga di codice è di 80 colonne.

• il nome delle variabili deve essere significativo.

• si adotta una dichiarazione per linea, quindi

int level; int size;

va bene, mentre è da evitare

int level, size;

Ho inoltre adottato le seguenti norme per la gestione del repository:

• i nomi dei file non devono contenere spazi ne lettere accentate.

• il codice viene mantenuto nella directory Code.

• i documenti sono presenti nella directory Docs.

Per automatizzare l’utilizzo di buona parte delle suddette norme mi sono affidato all’IDE Eclipse. In particolare ho impostato che ad ogni formattazione del codice, esso venga adattato ad alcune delle norme sopra citate come la lunghezza massima di una riga o l’utilizzo dell’indentazione con gli spazi.

6.2 Definizione di prodotto

In questa sezione vengono esposte le classi più importanti che compongono l’applica- zione. In particolare si adotterà un grado di dettaglio superiore a quello utilizzato nel capitolo della progettazione. L’esposizione di ogni classe seguirà il seguente schema:

• Tipo, obiettivo e funzione del componente qui si richiamerà concisamente lo scopo della classe già esposto nel capitolo sulla progettazione.

• Deriva verranno di seguito elencate le classi da cui deriva il componente in questione.

• Campi dati per ogni campo dati importante se ne spiegherà lo scopo. Dal momento che l’applicazione utilizza molti campi dati dovuti alla grafica, in particolare per il package view, si mostreranno solo gli attributi non banali.

• Metodi ogni metodo rilevante troverà qui una chiara spiegazione.

6.2.1 Realizzazione del package agenda Tale package è quello principale di tutta l’applicazione, si faccia riferimento alla Figura 5.3 per un diagramma delle classi.

52 di 91 6.2. DEFINIZIONE DI PRODOTTO

Classe Agenda

Tipo, obiettivo e funzione del componente: questa classe è il cuore dell’appli- cazione in quanto ne consente l’avvio e la gestione delle funzionalità essenziali. Deriva: deriva da TabActivity, classe del framework Android. Essa permette di gestire delle attività che utilizzano tab per dividere i loro contenuti. Campi dati: non sono presenti campi dati. Metodi

+ onCreate(savedInstanceState : Bundle): void questo metodo permette di creare la struttura di base della grafica dell’applicazione. In particolare vengono create le 3 tabs che permettono all’utente di navigare tra il calendario, le note ed i progetti.

+ onCreateOptionsMenu(menu : Menu): boolean tale metodo permette di creare il menu opzioni presente nell’applicazione.

- onOptionsItemSelected(item : MenuItem): boolean questo metodo è privato in quanto viene richiamato solo dalla classe stessa nel momento in cui l’utente seleziona un’opzione del menu. Tra di esse citiamo la possibilità di sincronizzare l’applicazione e di gestire le preferenze.

- settings(): void con questo metodo vengono gestite tutte le preferenze dell’applicazione.

Classe Utils

Tipo, obiettivo e funzione del componente: questa classe offre dei metodi di pubblica utilità a tutti gli altri packages. Deriva: questa classe non deriva da alcuna classe. Campi dati: non ci sono campi dati. Metodi

+ formatMinute(minute : int): String data un’ora espressa come minuti dalla mezzanotte ritorna una stringa del tipo HH:MM. Ciò si rivela utile in quanto all’interno di tutta l’applicazione non si salvano le ore ed i minuti, ma si gestiscono entrambi con un unico campo. Il metodo torna comodo quando è necessario mostrare all’utente un’ora.

+ getEpoch(datePicker : DatePicker): int Dato un DatePicker (Widget offerto da Android per selezionare una data), ritorna i giorni trascorsi dal 1-1-1970.

+ getName(id : Long): String Dato l’id di un contatto presente nella rubrica dell’u- tente ne ritorna il nome ed il cognome.

+ setEventOrAppointment(singleRepeat : SingleRepeat): void a seconda di quando avvenga un singleRepeat ne setta il tipo. Si tratta di un evento se dura più giorni. Stiamo parlando di un evento giornaliero se invece accade solo in una giornata. Si tratta infine di un appuntamento se avviene in un giorno e si conosce data ed ora di fine.

+ daysSinceEpoch(requestedDate : GregorianCalendar): int Ritorna quanti giorni sono passati dal 1-1-1970.

53 di 91 CAPITOLO 6. REALIZZAZIONE

+ formatDate(millisecondsSinceEpoch : Long,setTime : boolean): String il metodo richiede una data espressa in millisecondi dall’epoch time per poi ritornare una stringa formattata. Se setTime è false essa sarà del tipo giorno-mese-anno, altrimenti sarà HH:MM giorno-mese-anno. Anche questo metodo è utile per presentare all’utente delle date in un formato comprensibile.

+ getTimeZone(): String ottiene il fuso orario settato nel dispositivo. Essenziale in fase di sincronizzazione.

+ createSha1(text : String): String permette di creare l’hash di un testo. Utile per la gestione delle password.

Classe AgendaPreferences Tipo, obiettivo e funzione del componente: permette di gestire delle preferenze utili per il corretto funzionamento dell’applicazione Deriva: questa classe non deriva da alcun’altra classe. Campi dati Campi dati per gestire le preferenze dell’utente:

- PASSWORD_PREF : String indica se l’utente vuole utilizzare una password per accedere all’applicativo.

- MINUTE_FOR_APPOINTMENTS : String nella vista giornaliera indica i minuti di salto tra due linee.

- TRANSPORT_COLOR : String indica il colore che l’utente vuole utilizzare per il trasporto.

- NO_Google_CALENDAR_COLOR : String indica il colore che l’utente vuole per gli appuntamenti che non sono associati ad un account Google

- APPOINTMENT_DURATION : String valore di default per la durata degli appuntamenti.

- TRANSPORT_DURATION : String valore di default per la durata del trasporto.

- FIRST_SYNC_START_DAY : String valore per la prima sincronizzazione, indica la data da cui iniziare il pull degli eventi da Google calendar.

- FIRST_SYNC_END_DAY : String indica fino a quando è necessario scaricare gli eventi. È utile anch’esso durante la prima sincronizzazione.

Campi dati per gestire altre variabili:

- PREF_Google_ACCOUNT_KEY : String account Google associato all’applicazione.

- PREF_AUTH_TOKEN : String chiave per accedere al calendario Google dell’utente.

- PREF_GSESSIONID : String identificativo per la sessione che si sta utilizzando con Google.

54 di 91 6.2. DEFINIZIONE DI PRODOTTO

- LAST_SYNC_EPOCH : String indica l’ultimo momento in cui si è effettuata la sincronizzazione.

- instance : AgendaPreferences unica istanza di questa classe presente nel programma.

Metodi

+ getInstace(): AgendaPreferences metodo che permette di accedere all’unica istanza della classe presente nel pro- gramma. Nel caso essa non esista viene creata, implementando così il pattern Singleton.

- AgendaPreferences() costruttore privato per realizzare il pattern citato.

Classe WelcomeActivity

Tipo, obiettivo e funzione del componente: è la classe che genera la grafica appena l’utente entra nel programma. Deriva: è una sottoclasse di Activity Campi dati La quasi totalità dei campi dati di questa classe sono variabili che ne gestiscono la grafica. Viene utilizzato un campo (mDbHelper) per accedere al database e quindi poterlo interrogare. Metodi

+ onCreate(savedInstanceState : Bundle): void permette di creare la grafica di questa finestra.

6.2.2 Realizzazione del package agenda.view.create

Per un diagramma delle classi di tale package si richiama alla Figura 5.4.

Classe ChangePassword

Tipo, obiettivo e funzione del componente: questo componente permette di cambiare la password utilizzata per accedere all’applicativo. Deriva: la classe base è Activity Campi dati: sono di varia natura e permettono di generare la grafica della finestra. Essa è diversa a seconda se è già stata inserita o meno una password nelle preferenze. Nel primo caso si chiede all’utente di inserire quella vecchia nell’apposito campo oldPwdEditText. In entrambi i casi è necessario scrivere due volte la nuova password prima nel campo newPwdEditText e quindi in repeatedPwdEditText. Nella grafica è quindi presente un tasto apposto (saveButton) per salvare i cambiamenti. Prima di salvare la nuova password si controlla che essa sia lunga almeno sei caratteri. Metodi

+ onCreate(savedInstanceState : Bundle): void permette di generare la grafica dell’attività in questione.

- alertUser(message : String,closeChangePwdActivity : boolean): void questo metodo genera una finestra di dialogo nel caso siano stati riscontrati degli errori come password che non corrispondono, password vecchia errata, o nuova password più corta di sei caratteri.

55 di 91 CAPITOLO 6. REALIZZAZIONE

Classe CreateAppointmentActivity

Tipo, obiettivo e funzione del componente: questa classe ha lo scopo di creare un nuovo appuntamento. Deriva: la classe base è Activity Campi dati tra le numerose variabili di questa classe si fanno notare:

- saveButton : Button tasto per salvare il nuovo evento. Richiama il metodo saveEvent(): void

- eventToModify : Event questo campo non è nullo solo nel caso l’attività venga creata per modificare un evento già esistente.

+ ONLY_THIS_REPETITION : String nel caso si voglia modificare una sola occorrenza dell’evento ripetuto.

+ ONLY_FUTURE_REPETITIONS : String per modificare le ripetizioni future dell’evento.

+ ALL_REPETITIONS : String per modificare ogni occorrenza dell’evento ripetuto.

Gli ultimi tre campi sono statici e pubblici in quanto è comodo poterli riferire direttamente anche dall’esterno, in particolare dalla classe DailyViewFragment dalla quale l’utente può selezionare gli eventi da modificare. Metodi

+ onCreate(savedInstanceState : Bundle): void permette di generare la grafica dell’attività.

+ onActivityResult(requestCode : int,resultCode : int,data : Intent): void gestisce le attività che vengono richiamate da questa classe. In particolare vengono gestite SelectRepeatDateActivity e SelectProjectActivity: è necessario poter ri- cordare i dati che vengono immessi dall’utente grazie a queste attività modo che essi vengano correttamente utilizzati dalla classe in oggetto.

- saveEvent(): void permette di salvare il nuovo appuntamento. Questo metodo si occupa anche di generare tutte le ripetizioni necessarie e di inserirle nel database.

Classe CreateStdTaskActivity

Tipo, obiettivo e funzione del componente: permette di creare un task che duri più giorni, suddividendo lo sforzo in parti eque tra esse. Deriva: la classe base è Activity Campi dati

- startDatePicker : DatePicker permette di inserire la data d’inizio del task.

- endDatePicker : DatePick permette di inserire la data di fine del task.

- selectProjectCheckBox : CheckBox selezionando questa checbox si potrà associare un progetto al task.

56 di 91 6.2. DEFINIZIONE DI PRODOTTO

- compeleteSeekBar : SeekBar grazie a questa barra è possibile dare un livello di completamento al task.

Metodi

- saveStdTask(): void permette di salvare il task appena creato.

- generateDivisionEffor(newStdTask : StdTask): void è il metodo che permette di generare le suddivisioni delle ore del task nel caso l’utente lo richieda.

Classe DivideStdTaskEffort

Tipo, obiettivo e funzione del componente: permette di suddividere le ore da svolgere per un task. Deriva: la classe base è Activity Campi dati

+ EFFORT_EVERY_NUMBER : String chiave per contenere ogni quanto tempo viene ripetuto lo sforzo.

+ REPEATED_TYPE : String chiave per indicare se lo sforzo si ripete giornalmente, mensilmente o settimanal- mente.

+ EFFORT_INCLUDE_WEEKEND : String chiave per dire se l’utente vuole svolgere lo sforzo anche nei weekend.

+ MINUTE_PER_EFFORT : String chiave che indica quanti minuti dura ogni sforzo.

Le chiavi sopra elencate sono pubbliche in quanto è necessario che esse vengano utilizzate anche da CreateStdTaskActivity Metodi è sufficiente il metodo onCreate(savedInstanceState : Bundle): void per generare la grafica.

Classe CreateProjectActivity

Tipo, obiettivo e funzione del componente: permette di creare un progetto o di modificarne uno già esistente. Deriva: la classe base è Activity Campi dati

- PICK_CONTACT : int permette di indicare l’attività di selezione di un contatto. Ciò si rivela utile quando l’utente vuole associare un responsabile al progetto.

- SELECT_FATHER : int permette di identificare l’attività di selezione di un progetto nel caso l’utente voglia dare un padre al progetto che si sta creando.

- milestoneCheckbox : CheckBox permette di indicare se il progetto in questione rappresenta una milestone.

57 di 91 CAPITOLO 6. REALIZZAZIONE

- selectFatherButton : Button permette di lanciare l’attività SelectProjectActivity per selezionare il padre del progetto.

- selectResponsibileButton : Button permette di lanciare l’attività per selezionare il responsabile del progetto.

Metodi Sono sufficienti i metodi per creare la grafica e per gestire le attività che vengono lanciate.

Classe NoteEditor

Tipo, obiettivo e funzione del componente: permette di creare una finestra per la creazione o la modifica di una nota. Deriva: la classe base è Activity Campi dati

- titleNoteEditText_ : EditText permette di settare il titolo della nota.

- contentNoteEditText_ : EditText permette di scrivere il contenuto della nota.

- saveNoteButton_ : Button tasto per salvare la nota.

- cancelNoteButton_ : Button tasto per cancellare la nota. Alla sua pressione viene generata una dialog nella quale si chiede all’utente se è veramente sicuro di voler cancellare la nota.

Metodi

+ onBackPressed(): void quando viene cliccato il tasto back del tablet, tale metodo chiede all’utente se vuole salvare le modifiche alla nota prima di tornare indietro.

Classe SelectRepeateDateActivity

Tipo, obiettivo e funzione del componente: permette di selezionare ogni quanto si può ripetere un certo appuntamento. Deriva: la classe base è Activity Campi dati

+ REPEATED_EVERY_NUMBER : String indica ogni quanto tempo si ripete l’evento. Il suo valore viene selezionato grazie a everyNumberPicker.

+ REPEATED_TYPE : String indica se la ripetizione è giornaliera, settimanale, mensile o annuale. typeRepeatitionSpinner permette di selezionare tale valore.

+ REPEATED_FINISH_EPOCH_MILLISECONDS : String indica in millesecondi dall’epoch time la data fino a quando è necessario ripetere l’appuntamento. Il suo valore viene selezionato grazie a finishDateDatePicker.

Metodi è sufficiente il metodo per creare la grafica.

58 di 91 6.2. DEFINIZIONE DI PRODOTTO

Classe SelectProjectActivity Tipo, obiettivo e funzione del componente: permette di selezionare un progetto navigando tra tutti quelli inseriti nell’applicativo. Deriva: la classe base è Activity Campi dati

- okButton : Button permette di selezionare il progetto correntemente visualizzato.

- backButton : Button permette di risalire di un livello.

Metodi

- setProjectItems(project : Project): void mostra i figli del progetto visualizzato. Nel caso nessun progetto sia stato selezionato, mostra i progetti che non hanno alcun padre.

Classe CreateContactTaskActivity Tipo, obiettivo e funzione del componente: tale classe ha come obiettivo quello di generare un nuovo contact task o di modificarne uno di già esistente. Deriva: la classe base è Activity Campi dati

- PICK_CONTACT : int permette di indicare l’attività di selezione di un contatto. Ciò si rivela utile per selezionare il contatto con cui si vuole comunicare.

- SELECT_PROJECT : int permette di identificare l’attività di selezione di un progetto nel caso l’utente voglia dare un padre al progetto che si sta creando.

- priorityRadioGroup : RadioGroup permette di selezionare la priorità del contact task.

Metodi Sono sufficienti i metodi per gestire la grafica e le attività invocate da questa classe.

6.2.3 Realizzazione del package agenda.view.leftFragment In Figura 5.5 si può trovare il già citato diagramma delle classi di tale package.

Classe MenuFragment Tipo, obiettivo e funzione del componente: Questa classe ha lo scopo di generare la parte sinistra dello schermo nella quale è contenuto il menu per navigare tra il calendario, le note ed i progetti. Deriva: questa classe deriva da Fragment, classe offerta da Android che permette di dividere lo schermo in frammenti in modo da gestire aree sé stanti. Campi dati

- rootLayout : LinearLayout rappresenta la radice della grafica a cui verrà attaccato il frammento di sinistra dello schermo.

59 di 91 CAPITOLO 6. REALIZZAZIONE

Metodi + onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle): View permette di generare il frammento. Tale metodo sarà soggetto ad ovveriding da parte delle sottoclassi. + stackRightPanelFragment(panel : RightPanelFragment): void permette di inserire un pannello destro o di sostituirlo.

Classe MenuNotesListFragment Tipo, obiettivo e funzione del componente: rappresenta il menu di sinistra per vedere tutte le note inserite. Permette l’inserimento di una nuova nota. Deriva: questa classe deriva da MenuFragment Campi dati - createNoteButton tasto che avvia la creazione di una nuova nota. - notesArrayList_ : ArrayList rappresenta la lista di tutte le note che vengono visualizzate. - CREATE_NOTE : int è semplicemente un numero per gestire la creazione di una nuova nota. Quando l’utente clicca il tasto createNoteButton viene richiamata l’attività NoteEditor proprio associandole questo numero. Metodi + onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle): View metodo che si preoccupa di creare la grafica di questa classe. + onActivityResult(requestCode : int,resultCode : int,data : Intent): void metodo che gestisce i risultati delle attività che vengono richiamate da questa classe. In particolare quando si termina di creare una nota, questo metodo si preoccupa di aggiornare la lista delle note salvate invocando updateListNote() + updateListNote(): void aggiorna la lista delle note. Si rivela essenziale quando si inserisce una nuova nota e quando si modifica il titolo di una nota esistente.

Classe MenuItemNote Tipo, obiettivo e funzione del componente: rappresenta una singola nota che viene visualizzata nell’elenco delle note mostrate da MenuNotesListFragment. Deriva: questa classe deriva da RelativeLayout. Campi dati - note_ : Note è la nota associata all’istanza di questa classe. Metodi + MenuItemNote(context : Context,note : Note,menuPanel : MenuFragment) costruttore, prende la nota a cui deve essere associata l’istanza della classe ed il pannello a cui poi apparterrà l’istanza della classe.

60 di 91 6.2. DEFINIZIONE DI PRODOTTO

Classe MenuProjectFragment

Tipo, obiettivo e funzione del componente: rappresenta il menu che contiene la lista di tutti i progetti inseriti dall’utente. Deriva: questa classe deriva da MenuFragment Campi dati

- createProjectButton : Button permette di creare un nuovo progetto, richiamando la classe CreateProjectActivity.

- backButton : Button questa classe permette di navigare tra sottoprogetti, questo tasto permette quindi di tornare al livello superiore (se esiste).

- projectHistory : ArrayList questo array contiene lo storico dei progetti che sono stati visualizzati finora e permette di implementare correttamente la funzionalità offerta dal tasto backButton.

Metodi

+ onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle): View crea la grafica della classe.

+ onActivityResult(requestCode : int,resultCode : int,data : Intent): void metodo che permette di gestire le attività che vengono invocate dalla classe in questione. In particolare quando viene richiamata CreateProjectActivity, questo metodo si preoccupa di aggiornare la lista dei progetti visualizzati.

+ setProjectItems(): void aggiorna la lista dei progetti visualizzati.

+ setSonsItems(currentProject : Project): void permette di mostrare i figli del progetto che è stato selezionato.

+ addProjectHistory(project : Project): void aggiunge il progetto selezionato alla projectHistory.

Classe MenuItemProject

Tipo, obiettivo e funzione del componente: rappresenta un singolo progetto che viene visualizzata nell’elenco dei progetti mostrati da MenuProjectFragment Deriva: questa classe deriva da RelativeLayout Campi dati

- project : Project è il progetto associato all’istanza di questa classe.

Metodi

+ MenuItemProject(context : Context,project : Project,menuPanel : MenuProjectFragment ) costruttore, prende il progetto a cui deve essere associata l’istanza della classe ed il pannello a cui poi apparterrà l’istanza della classe.

61 di 91 CAPITOLO 6. REALIZZAZIONE

Classe CalendarViewFragment Tipo, obiettivo e funzione del componente: rappresenta il menu per il calen- dario. Essa permette di selezionare un giorno di cui si vuole il riassunto, nonché di creare appuntamenti e task. Deriva: questa classe deriva da MenuFragment Campi dati

- datePicker : DatePicker è il calendario che permette di selezionare una data. Metodi

+ onCreateView(inflater : LayoutInflater,container : ViewGroup,savedInstanceState : Bundle): View crea la grafica aggiungendo il calendario e i tasti per creare gli appuntamenti e i task.

6.2.4 Realizzazione del package agenda.view.rightFragment In Figura 5.6 si trova il diagramma delle classi di tale package.

Classe RightPanelFragment Tipo, obiettivo e funzione del componente: questa classe è la duale di MenuFragment infatti rappresenta la parte destra dello schermo. Deriva: la classe in oggetto deriva da Fragment Campi dati non ci sono campi dati particolarmente interessanti se non rootLayout : LinearLayout che rappresenta la radice di tutti gli elementi grafici per questa classe e per tutte quelle che da essa derivano aggiungendo nuovi componenti. Metodi

+ stackRightPanelFragment(panel : RightPanelFragment): void permette di sostituire il pannello di destra mostrato con un altro.

Classe DailyViewFragment Tipo, obiettivo e funzione del componente: questa classe permette di visualiz- zare il riassunto di una giornata, mostrando tutte le attività che impegnano l’utente. Deriva: la classe base è RightPanelFragment Campi dati: sono presenti numerosi campi dati, nonostante ciò la maggior parte sono puramente elementi grafici come tasti, e layout. eventArrayList : ArrayList, appointmentArrayList : ArrayList e contactTaskArrayList : ArrayList contengono tutte le attività che devono essere svolte dall’utente per il giorno selezionato essi conterranno quindi le informazioni con le quali si potrà popolare questa vista. Metodi si offrono numerosi metodi set che permettono di aggiungere gli elementi alla grafica e metodi update per aggiornarli.

Classe NoteView Tipo, obiettivo e funzione del componente: la classe in oggetto permette di mostrare il contenuto di una nota. Sono inoltre offerti due tasti uno per modificarla ed uno per cancellarla. Deriva: la classe base è RightPanelFragment

62 di 91 6.2. DEFINIZIONE DI PRODOTTO

Campi dati: anche in questo caso sono presenti numerosi variabili grafiche il cui nome esplicita chiaramente la loro funzione. note_ : Note rappresenta la nota mostrata dall’istanza di questa classe. Metodi: i metodi presenti si occupano di creare la grafica e avviare l’attività di modifica della nota nel caso l’utente lo richieda.

Classe SingleProjectView

Tipo, obiettivo e funzione del componente: il componente mostra tutte le informazioni su un progetto. Deriva: la classe base è RightPanelFragment Campi dati

- project_ : Project rappresenta il progetto mostrato da questa vista.

Metodi

- setAppointment(): void, setStdTaskList(): void, setContactTask(): void, setNoteList (): void permettono di mostrare gli appuntamenti ed i task collegati al progetto.

- setInfo(): void aggiunge le informazioni del progetto come il responsabile, la data d’inzio quella di fine e così via.

6.2.5 Realizzazione del package agenda.sync

Tale package è visibile in Figura 5.7.

Classe CalendarSync

Tipo, obiettivo e funzione del componente: permette di avviare la sincroniz- zazione. In particolare si occupa di autenticare l’utente. Deriva: non deriva da alcuna classe. Campi dati

+ AUTH_TOKEN_TYPE : String indica il tipo di autenticazione che è necessario richiedere a Google. Nel nostro caso sarà quella per il calendario.

- authToken : String token ottenuto da Google per l’autenticazione.

- gsessionid : String identificativo della sessione appena creata da Google

- accountManager : AccountManager permette di accedere al nome utente del’account associato all’applicazione.

- activity : Agenda attività nella quale si farà comparire il messaggio finale di buona riuscita o meno della sincronizzazione.

63 di 91 CAPITOLO 6. REALIZZAZIONE

+ ACCOUNT_LOST : String status che indica l’assenza dell’account Google associato all’applicativo. Per poter utilizzare un account questo deve essere stato impostato nel dispositivo, ma può anche essere rimosso dall’utente. In questo caso la sincronizzazione non può più avvenire in quanto non c’è più modo di richiedere un token di autenticazione.

+ SYNCH_ERROR : String nel caso ci siano dei problemi come mancanza di una connessione di rete

+ SYNCH_IS_FINISHED : String se tutto va bene viene mostrato questo messaggio. Metodi

+ CalendarSync(activity : Agenda) costruttore, prende come parametro l’attività nella quale si mostrerà il messaggio di riuscita o fallimento della sincronizzazione.

+ showMessage(message : String): void permette di aprire una dialog nella quale mostrare un messaggio di buona riuscita o meno della sincronizzazione. Esso verrà mostrato nell’attività activity.

+ firstSync(): void metodo che viene richiamato quando si avvia la prima sincronizzazione in assoluto.

+ autenticate(): void metodo utilizzato per autenticare l’utente ed ottenere l’authToken.

Classe DoSync Tipo, obiettivo e funzione del componente: effettua la sincronizzazione vera e propria. Deriva : da Thread Campi dati

- mDbHelper : DatabaseSchema utile per accedere al database per prendere le informazioni da inviare a Google e per inserire quelle da esso ottenute.

- client : CalendarClient per poter comunicare con Google.

- Google_STATUS_CANCELED : String stringa che indica lo status cancellato secondo Google. Metodi

- downloadEvents(lastSync : Long,pushedEvents : ArrayList): void ottiene gli eventi da Google.

- pushEvents(lastSync : Long): ArrayList invia le modifiche da fare a Google.

6.2.6 Realizzazione del package agenda.sync.model Essendo la realizzazione del package triviale in quanto è sufficiente definire le chiavi, in questa sede mi limito ad esporre l’unica classe non banale.

64 di 91 6.3. REALIZZAZIONE DELLA SINCRONIZZAZIONE

Classe CalendarClient Tipo, obiettivo e funzione del componente: permette di accedere al servizio di Google effettuando delle richieste e ricevendo delle risposte HTTP. Deriva: Campi dati

- requestFactory : HttpRequestFactory oggetto di tipo Factory che permette di costruire una richiesta HTTP. Metodi

+ CalendarClient(requestFactory : HttpRequestFactory) costruttore che necessita di una factory per la costruzione di richieste http.

+ executeDelete(entry : Entry): void permette di cancellare un’entry. Essa deve avere al suo interno l’url dato da Google per la sua cancellazione.

+ executeUpdate(event : EventEntry): void offre la possibilità di aggiornare un evento. Anche qui l’evento deve avere al suo interno l’url predisposto da Google a tal fine.

+ executeInsert(entry : Entry,url : CalendarUrl): Entry effettua l’inserimento nel calendario url dell’evento entry.

+ executeGetCalendarFeed(url : CalendarUrl): CalendarFeed ottiene i calendari presenti nell’account Google dell’utente.

+ executeGetEventFeed(url : CalendarUrl): EventFeed Ottiene gli eventi del calendario indicato dal parametro url.

6.2.7 Realizzazione dei package agenda.model e agenda.controller La realizzazione di tali package è molto semplice, quindi si è deciso di non presentarla.

6.3 Realizzazione della sincronizzazione

La realizzazione della sincronizzazione è stata indubbiamente uno dei problemi più importanti che ho avuto in fase di codifica. In un primo momento volevo sincroniz- zarmi con il calendario presente all’interno del device Android. Dopo un’accurata ricerca ho però constatato che le API ufficiali di Android non permettono ancora di accedere a questo calendario. Sarebbe stato comunque possibile attraverso dei work-around offerti dalla comunità (e non da Google), nonostante ciò il supporto non sarebbe stato ufficiale e di conseguenza non avrei avuto la certezza che le classi ed i metodi utilizzati siano supportati anche in futuro. Abbondata questa soluzione ho trovato la libreria GData che però ho dovuto scartare in quanto incrementava di molto il peso di tutto l’applicativo finale. Ho quindi optato per utilizzare la libreria Google-api-java-client. Essa mi ha permesso di realizzare la sincronizzazione senza dovermi preoccupare di effettuare il parsing di file XML. Nel diagramma di sequenza visibile in Figura 6.1 si possono notare i passaggi principa- li che permettono di realizzare questa funzionalità. Prima di tutto è bene notare che DoSync, ovvero la classe che gestisce tutta la sincronizzazione, è un Thread che viene fatto partire non appena si riesce ad ottenere l’autenticazione da parte di Google. Di conseguenza la sincronizzazione avverrà in parallelo all’utilizzo dell’applicativo. Ciò

65 di 91 CAPITOLO 6. REALIZZAZIONE

è esplicitamente richiesto da Android che non permette di effettuare networking sul main thread in quanto ciò potrebbe compromettere l’esperienza d’uso dell’utente il quale si trova ad aspettare che l’applicazione ottenga una risposta dalla rete, risposta che potenzialmente potrebbe non arrivare. Una volta che il metodo DoSync.run() è stato invocato, esso adempie alla sincronizzazione attraverso l’utilizzo di due metodi privati: pushEvents() e pullEvents(). Il primo chiede al database mediante le fun- zioni offerte dalla classe DatabaseSchema tutti gli eventi che sono stati aggiunti, modificati ed aggiornati dall’ultima sincronizzazione. Quindi per ogni evento trovato viene creata un’istanza della classe EventEntry. Queste istanze permetto di inviare i dati che devono essere inseriti o modificati a Google Calendar. Infine si dice a quest’ultimo quali siano gli eventi che devono essere cancellati. In seguito viene invocato il metodo pullEvents(). Esso richiede a Google i calendari dell’utente che sono stati modificati rispetto all’ultima sincronizzazione. Quindi per ogni calendario ottenuto vengono richiesti tutti gli eventi creati modificati o cancellati. Per ognuno di essi vengono apportate le opportune modifiche nel database dell’applicativo. In questa fase l’applicativo si occupa anche di scaricare gli aggiornamenti ai calendari come l’inserimento o la cancellazione di uno di essi oppure la modifica del nome o del colore di uno già presente nel programma.

6.4 Verifica

La verifica è un’attività che permette di controllare se il lavoro realizzato è funzionante e se abbia una buona qualità realizzativa. In particolare si possono individuare diversi test che permettono di controllare vari aspetti del progetto realizzato. Si possono realizzare test di unità, di integrazione, prestazionali e molto altro. Nonostante ciò nel progetto di stage ci si è limitati ai test funzionali. Non sono stai realizzati dei test di unità in quanto il progetto si trova ancora in una fase prototipale. Aver realizzato delle batterie di test di unità avrebbe richiesto un cospicuo impegno di tempo, che però avrebbe rischiato di essere sprecato. Sviluppare una campagna di test per un prototipo è infatti pericoloso in quanto il codice che lo compone può rivelarsi ancora troppo immaturo e quindi subire non poche modifiche invalidando i test realizzati. Riducendo il tempo dedicato alla verifica ci si è potuti concentrare sul testare le funzionalità offerte dal progetto costruito fino a questo punto. Ciò ha permesso di controllare quali requisiti sono stati effettivamente realizzati. Sono state svolte varie prove, volte ad individuare problemi e bug. Esse sono state realizzate sfruttando l’emulatore. In particolare per controllare che il package model funzionasse correttamente ho realizzato degli inserimenti utilizzando direttamente l’interfaccia grafica sviluppata. Quindi attraverso gli strumenti offerti dalle SDK Android ho potuto accedere al database utilizzato dall’applicazione attraverso la console e controllarne il suo contenuto verificando che esso corrispondesse a quanto previsto. Durante i test svolti in azienda il tutor ha posto l’accento su un errore grafico che avevo commesso durante la codifica della grafica. Nelle attività dove era richiesto l’inserimento di vari dati da parte dell’utente - in particolare in certe classi del package view.create - avevo realizzato uno scrolling verticale che poteva essere notevolmente ridotto ripensando al layout dell’intera finestra. L’errore di fondo è stato utilizzare una sola colonna, cosa che ovviamente allungava di molto le finestre. Seguendo i consigli dell’azienda ho quindi rivisto tale layout, realizzandone uno a 2 colonne che ha permesso di eliminare quasi completamente lo scrolling migliorando notevolmente l’esperienza utente. La maggior parte delle attività in questa fase erano mirate a verificare quali requisiti

66 di 91 6.4. VERIFICA

:DoSync :DatabaseSchema :EventEntry :CalendarClient

run() pushEvents(lastSync) getEventsWithoutGoogleID()

ArrayList

getEventsToUpdate() Per ogni evento che è necessario creare/modificar ArrayList e/cancellare su GoogleCalendar getEventsToCancel()

ArrayList

loop <<<>>>

executeInsert(eventsToInsert)

executeDelete(eventsToDelete)

executeUpdate(eventsToUpdate) Per ogni CalendarEntry che è stato modificato su downloadEvents(lastSync) Google Calendar executeGetCalendarFeed(lastSync)

List

loop executeGetEventFeed(eventsUrl)

List

loop Per ogni evento alt deleteEvent(googleId) [status==cancelled] che è stato modificato nel calendario [status==updated] updateEvent(event)

[status==created] createEvent(event)

Figura 6.1: Diagramma di sequenza che mostra come funziona il processo di sincronizzazione.

67 di 91 CAPITOLO 6. REALIZZAZIONE

siano stati effettivamente realizzati. Il risultato finale è stato soddisfacente in quanto tutti quelli obbligatori hanno trovato un’implementazione funzionante.

6.4.1 Tracciamento requisiti-componenti Di seguito viene presentata in tabella 6.1 un tracciamento nel quale si mostrano le classi che permettono di soddisfare un certo requisito. In questo modo si può dimo- strare che le funzionalità richieste dall’azienda sono state correttamente realizzate. Fra parentesi vengono indicati i packages a cui appartengono le classi citate. Si fa presente che per rendere la lettura della tabella più agevole il package com.ceremit viene sempre sottinteso. Nel caso un intero package sia utile a soddisfare un certo requisito, verrà direttamente riportato il nome di tale package, evitando di citare tutte le classi che lo compongono.

Id Requisito Unità che lo soddisfano F_OB_1 SingleProjectView (agenda.view.rightFragment) CreateProjectActivity, SelectProjectActivity (agenda.view.create) MenuProjectFragment, MenuItemProject (agenda.view.leftFragment) F_OB_1.1 SingleProjectView (agenda.view.rightFragment) CreateProjectActivity (agenda.view.create) F_OB_1.2 SelectProjectActivity (agenda.view.create) F_OB_1.3 NoteEditor, SelectProjectActivity, CreateContactTaskAc- tivity,CreateStdTaskActivity, CreateAppointmentActivity (agenda.view.create) SingleProjectView (agenda.view.rightFragment) F_OB_2 DailyViewFragment, SingleProjectView (agenda.view.rightFragment) CreateStdTaskActivity, DivideStdTaskEffortActivity (agenda.view. create) F_OB_2.1 CreateStdTaskActivity (agenda.view.create) F_OB_2.2 CreateStdTaskActivity (agenda.view.create) F_OB_2.3 DivideStdTaskEffortActivity (agenda.view.create) F_OB_3 DailyViewFragment (agenda.view.rightFragment) CreateAppointmentActivity (agenda.view.create) F_OB_3.1 CreateAppointmentActivity (agenda.view.create) F_OB_3.2 CreateAppointmentActivity (agenda.view.create) F_OB_3.3 SelectRepeatDateActivity (agenda.view.create) F_OB_3.3.1 DailyViewFragment (agenda.view.rightFragment) CreateAppointmentActivity (agenda.view.create) F_OB_4 CreateContactTaskActivity (agenda.view.create) DailyViewFragment (agenda.view.rightFragment) F_OB_4.1 CreateContactTaskActivity (agenda.view.create) F_OB_5 DailyViewFragment (agenda.view.rightFragment) CalendarViewFragment (agenda.view.create) F_OB_5.1 DailyViewFragment (agenda.view.rightFragment) F_OB_5.2 DailyViewFragment (agenda.view.rightFragment) F_OB_5.3 DailyViewFragment (agenda.view.rightFragment) F_OB_5.4 DailyViewFragment (agenda.view.rightFragment) F_OB_5.5 DailyViewFragment (agenda.view.rightFragment) F_OB_6 AgendaPreferences, Agenda (agenda) F_OB_6.1 AgendaPreferences, Agenda (agenda)

68 di 91 6.4. VERIFICA

F_OB_6.2 AgendaPreferences, Agenda (agenda) F_OB_6.3 AgendaPreferences, Agenda (agenda) CreateAppointmentActivity (agenda.view.create) F_OB_6.4 CreateAppointmentActivity (agenda.view.create) F_OB_6.5 CreateAppointmentActivity, ChangePassword (agenda.view.create) F_OB_7 tutto il package agenda.synch F_OB_7.1 Agenda (agenda) F_OB_7.2 tutto il package agenda.synch F_OB_8 WelcomeActivity (agenda) F_OB_9 MenuNotesListFragment, MenuItemNote (agenda.view.leftFragment) F_OB_9.1 NoteView (agenda.view.rightFragment) F_OB_9.2 NoteView (agenda.view.rightFragment) F_OB_10 MenuProjectFragment, MenuItemProject (agenda.view.leftFragment) F_OB_10.1 MenuProjectFragment, MenuItemProject, SingleProjectView (agenda. view.leftFragment) F_OB_10.2 SingleProjectView (agenda.view.rightFragment) F_D_1 SingleProjectView (agenda.view.rightFragment) CreateStdTaskActivity (agenda.view.create) F_D_2 DailyViewFragment (agenda.view.rightFragment) P_OB_1 tutto il package agenda.synch P_OB_2 tutto il package agenda ed i suoi sotto-pacakges. V_OB_1 tutto il package agenda ed i suoi sotto-pacakges. V_OB_2 tutto il package agenda.model V_OB_3 tutto il package agenda.view Tabella 6.1: Tabella dove ogni requisito viene associato alle classi che lo realizzano

69 di 91 CAPITOLO 6. REALIZZAZIONE

70 di 91 Capitolo 7

Consuntivo

Il piano preventivato è stato seguito seppur con alcune variazioni. Ho dovuto investire più tempo di quanto previsto soprattutto nelle fasi di formazione e codifica. Nonostante alcune fasi abbiano richiesto più tempo di quanto preventivato, sono comunque rimasto all’interno delle 320 ore previste come tetto massimo poiché l’analisi e la verifica hanno richiesto meno tempo di quello preventivato. In Figura 7.1 è possibile visualizzare il raffronto tra le ore preventivate e quelle messe a consuntivo, mentre in Tabella 7.1 vengono riassunte le ore impiegate per le principali attività svolte durante lo stage.

Analisi Lo stage è iniziato con la fase di analisi dei requisiti. Essa è stata semplifica- ta dal fatto che il tutor aziendale mi ha esposto in modo chiaro ciò che il programma doveva svolgere, suggerendomi delle fonti da cui attingere altre informazioni. Ho quindi dovuto approfondire il sistema time/system e il programma Task/Timer come esposto nel capitolo 2. Solo dopo aver capito bene il dominio del discorso ho redatto la lista dei requisiti. In questa fase ho anche svolto una breve ricerca sui possibili competitors attualmente presenti nel mercato.

Formazione La formazione, come già anticipato, ha richiesto più tempo rispetto a quanto preventivato, occupando circa una settimana e mezza. Il motivo principale è stato lo studio di Android che non avevo mai utilizzato prima. Per avere delle basi più solide su questa piattaforma ho iniziato seguendo delle lezioni online appositamente tenute per Android reperibili all’indirizzo: https://docs.google.com/Doc?docid=0AeKIW0IjgQ5pZGY2YzJ0am1fODg2ZmJ2Y3NrZDU&hl= en&pli=1 Esse appartengono al corso CSSE490 di Rose-Hulman un collegio statunitense specia- lizzato nelle discipline scientifiche e tecnologiche. Il sito ufficiale di tale istituto è: http://www.rose-hulman.edu/ Di conseguenza ho seguito alcuni tutorial offerti dal sito ufficiale di Andorid. Essi si sono rivelati utili ma entro certi limiti, infatti buona parte di essi vengono realizzati con delle API obsolete. Alla formazione sulle SDK di questa piattaforma ha seguito quella su Google Calendar. Essa si è rivelata estremamente utile per poter realizzare la sincronizzazione in quanto mi ha permesso di capire quali fossero le informazioni più importanti gestite nel cloud di Google. Per realizzare al meglio questa parte di progetto ho studiato un’apposita libreria Google-api-java-client. Dal momento che Android utilizza SQLite3 come database, ho dovuto dedicare qualche ora di formazione anche per l’approfondimento di tale linguaggio. Avendo studia- to MySql nel corso di basi dati e sistemi informativi mi è bastato apprendere le

71 CAPITOLO 7. CONSUNTIVO

attività sotto-attività ore sotto-attività studio di time/system 15 Analisi studio di task/timer 10 analisi competitors 12 redazione requisiti 3 corso CSSE490 10 API e tutorial Android 25 Formazione sqlite3 3 Google Calendar 12 librerie di terze parti 5 progettazione database 15 Progettazione progettazione packages 45 revisione database per sincronizzazione 5 realizzazione grafica 45 Codifica realizzazione database 10 sincronizzazione 50 inserimento javadoc 5 correzione scrolling 20 Verifica test funzionali e correzioni varie 30

Tabella 7.1: Ore consuntivate per le varie sotto-attività. differenze presenti tra i due linguaggi, investendo così poche ore di studio per SQLite3.

Progettazione Questa fase ha subito un leggero incremento delle ore ad essa dedicate in quanto durante la codifica mi sono accorto di non aver progettato bene il database per gestire le informazioni più importanti presenti in Google Calendar. Per questo ho dovuto rivedere alcune tabelle presenti al suo interno.

Codifica La codifica è stata l’attività che maggiormente ha richiesto un incremento delle ore utilizzate. Ciò è stato dovuto a due motivi:

1. la realizzazione della grafica

2. sviluppare la sincronizzazione è stato parecchio complicato.

La codifica ha richiesto più tempo anche perché ho cercato di commentare al meglio il codice, inserendovi javadoc utili nel caso il progetto dovesse venir nuovamente preso in mano in futuro. In questa fase si è rivelato molto utile l’aiuto che ho trovato consultando il forum di stackoverflow.

Verifica La verifica ha richiesto meno tempo di quanto preventivato. Durante i test sui requisiti funzionali, oltre a correggere alcuni bug, ho sistemato alcuni problemi grafici come l’eccessivo scrolling.

72 di 91 120 110

90 90

65 Preventivo 60 60 (totale=300 60 55 ore) 50 50 Ore Consuntivo 40 40 (totale=320 ore)

30

0 Formazione Analisi Progettazione Codifica Verifica Fase

Figura 7.1: Raffronto tra le ore preventivate e quelle a consuntivo.

73 di 91 CAPITOLO 7. CONSUNTIVO

74 di 91 Capitolo 8

Conclusioni

La realizzazione di un’applicazione di time management è stata molto stimolante ed interessante. Non avendo mai realizzato un’agenda, ho potuto infatti affrontare un argomento completamente nuovo. Inoltre l’opportunità di sviluppare per un sistema operativo mobile si è rivelata molto attuale, vista l’ampia diffusione che hanno oggigiorno i dispositivi come tablet e smartphone. Confrontandomi con le altre applicazioni del settore ho notato la grande cura con cui sono state realizzate e le numerose funzionalità da esse offerte. Per poter entrare in questo mercato è quindi necessario sviluppare un prodotto veramente ben fatto, ricco di potenzialità e possibilmente adatto a più sistemi mobili. In quest’ottica il progetto realizzato non può che essere un semplice prototipo con il quale l’azienda può decidere se intraprendere ulteriori sforzi in questa direzione.

L’esperienza in azienda è stata mediamente positiva. Sono stato ben seguito in fase d’analisi e un pò durante la verifica. Al contrario durante la formazione, la progettazione e la codifica ho dovuto svolgere gran parte del compiti da solo. Non metto in dubbio che nell’ambito lavorativo sia necessario essere autonomi, nonostante ciò nell’ottica dello stage un aiuto formativo sarebbe stato utile. Essenziale è stata quindi l’esperienza maturata durante l’università che mi ha dato non solo le basi, ma anche il metodo per studiare nuove tecnologie. Aspetto che ritengo invece completamente sbagliato su come si è svolto lo stage è l’aver realizzato il progetto da solo senza appartenere ad un team anche piccolo. Durante la laurea triennale ho infatti capito che per realizzare un buon lavoro è essen- ziale costruire un gruppo dove i membri si spartiscano i compiti e si aiutino a vicenda.

Dal punto di vista formativo lo stage si è rivelato estremamente interessante. Ho avuto modo in particolare di studiare Android, un dei sistemi operativi del momento. Sono stato piacevolmente colpito da questa piattaforma. Mi ha sorpreso la quantità di strumenti di sviluppo offerti. Alcuni di essi sono ancora da perfezionare, nonostante ciò le funzionalità presenti per gli sviluppatori sono numerose. Molto interessante è la documentazione che si reperisce in rete. Esistono molte comunità e siti che sono nati attorno ad esso. In questo modo risulta semplice trovare un supporto per la risoluzione dei problemi. La documentazione ufficiale risulta ben fatta e ricca di approfondimenti. Unico aspetto negativo sono i tutorial, molti dei quali utilizzano codice obsoleto essendo stati realizzati con le vecchie versioni di Android. Interessante è il canale YouTube di Google nel quale sono presenti numerosi video dedicati agli sviluppatori. Nonostante ciò ho notato alcuni aspetti negativi su cui ritengo si debba ancora lavorare per migliorare il framework in questione. L’emulatore e il plugin per Eclipse

75 CAPITOLO 8. CONCLUSIONI si rivelano molto lenti, causando spesso intoppi nella fase di sviluppo. In particolare il primo è molto instabile e richiede parecchio tempo per partire correttamente. Questo problema risulta facilmente risolvibile con la semplice adozione di un dispositivo Android reale. Purtroppo l’azienda non me ne ha fornito alcuno in quanto al suo interno non esiste ancora una divisione che si occupi di questa piattaforma. Dato che Android utilizza Java ho potuto approfondire un pò questo linguaggio. In particolare ho studiato le classi che permettono di gestire il tempo come Gregorian- Calendar, di cui ho potuto apprezzarne le notevoli potenzialità. Dal punto di vista formativo è anche stato interessante proseguire con l’utilizzo pratico di Eclipse, IDE che si rivela estremamente utile e comodo.

Posso quindi affermare che lo stage si è rivelato utile, in particolare per le conoscenze che ho acquisito nel suo corso.

76 di 91 Appendice A

Manuale Utente

A.1 Introduzione

In questa sede viene brevemente illustrato il funzionamento dell’applicazione realiz- zata nelle sue parti principali.

Definizione dell’utente del prodotto Il prodotto si prefigge di venire in aiuto agli utenti che abbiano necessità di organizzare il proprio tempo in mobilità, avendo sempre sotto controllo i propri progetti ed appuntamenti.

Come leggere il manuale Questo manuale descrive il funzionamento del progetto di stage realizzato, la sezione iniziale presenta una breve panoramica su ciò che il progetto offre. Si prosegue quindi con una discussione di come utilizzarlo. In italico vengono riportate le parole che trovano una definizione nel glossario della tesi.

Documenti utili Il manuale è concepito per poter essere una lettura a sé stante, quindi in questa sezione non vengono forniti documenti di approfondimento necessari alla sua lettura e comprensione.

A.2 Descrizione del prodotto

Installazione Per installare l’applicazione è necessario rivolgersi all’azienda Ceremit srl che detiene l’eseguibile finale realizzato. È quindi sufficiente inviare tale ese- guibile (in formato apk) al proprio tablet: il sistema Android si preoccuperà di completare l’installazione autonomamente.

Requisiti di Sistema Gli unici requisiti che è necessario assolvere per poter utilizzare il programma sono quelli di avere un tablet con le seguenti caratteristiche:

• sistema operativo Android 3.0 Honeycomb o superiore.

• una risoluzione dello schermo maggiore od uguale a 1024*600.

Al fine di poter utilizzare tutte le funzionalità offerte dal programma è necessa- rio disporre di una connessione ad internet. Nonostante ciò anche in assenza di quest’ultima è comunque possibile fruire dell’applicazione in quasi tutte le sue parti.

77 APPENDICE A. MANUALE UTENTE

Funzionalità offerte L’applicazione vuole essere un sistema per poter gestire i propri impegni nel breve e nel lungo termine. In particolar modo vengono gestiti i seguenti eventi:

• appuntamenti: prendono luogo ad una particolare ora in un dato giorno.

• eventi: durano tutta una giornata.

• contact task: rappresentano dei contatti con cui è necessario comunicare.

• standard task: sono dei compiti che devono essere svolti durante un preciso arco di tempo.

Oltre ad un semplice calendario, l’applicazione gestisce anche progetti e note. Caratteristica interessante è la possibilità di sincronizzare gli appuntamenti con quelli presenti in Google Calendar.

A.3 Istruzioni per l’uso

Apertura Per aprire il programma è sufficiente andare nel menu del proprio tablet Android e ricercare l’applicazione ‘‘Agenda’’. Quando l’applicazione viene aperta, si presenta all’utente una breve finestra di benvenuto visibile in Figura A.1. In essa è presente un riassunto di quanto l’utente sia occupato nella giornata odierna. Si possono visualizzare i minuti occupati per il trasporto, per gli appuntamenti ecc... Per utilizzare veramente l’applicazione è necessario tappare sul tasto Entra. Nel caso l’utente nelle preferenze abbia indicato di voler proteggere il programma con una password, essa dovrà essere inserita prima di cliccare su Entra.

Figura A.1: Attività mostrata all’apertura dell’applicazione.

Viste L’applicativo offre tre diverse viste, ognuna delle quali gestisce varie infor- mazioni. Esse sono:

• vista giornaliera.

• vista delle note.

• vista dei progetti.

78 di 91 A.3. ISTRUZIONI PER L’USO

Esse sono raggiungibili grazie a degli appositi tasti presenti in tutte le schermate dell’applicativo in alto a sinistra. Ogni vista è costituita da due parti situate rispettivamente a sinistra e a destra dello schermo. Nella prima sono presenti dei tasti per agire nella vista, mentre nella seconda si trova il vero contenuto della vista.

Vista giornaliera Dopo aver cliccato sul tasto Entra il programma presenta all’utente questa vista posizionata sul giorno corrente. Essa è la sezione principale di tutto l’applicativo. Una sua immagine è visibile in Figura A.2. In essa sono visibili i seguenti elementi:

1. barra di navigazione tra i giorni: sono presenti bottoni che permettono di andare al giorno precedente o a quello successivo rispetto alla data visualizzata tra di essi. Cliccando su quest’ultima il programma rimanda immediatamente al giorno corrente.

2. riassunto degli appuntamenti della giornata. Essi sono inseriti all’interno di una griglia oraria. La linea rossa indica l’ora corrente.

3. eventi del giorno.

4. contatti con cui si deve parlare durante la giornata. Sono inseriti all’interno di una tabella nella quale si visualizzano varie informazioni come la priorità, l’ora d’inizio e la durata. L’ultima colonna indica se l’attività è stata completata (V) o meno (X). Nel secondo caso basta tappare su di essa per segnare il contact task come adempiuto.

5. elenco dei compiti da svolgere. Vengono trattati come i contatti al punto precedente.

Su tutti questi elementi è possibile eseguire un long tap facendo comparire un breve menu contestuale dal quale è possibile eseguire delle azioni di modifica o cancellazione. Ciò è visibile in Figura A.3. Sulla parte sinistra dell’immagine è inoltre possibile visualizzare un calendario che permette di navigare tra i giorni dell’anno. Sotto ad esso sono presenti tre bottoni che permettono di creare degli appuntamenti, dei contact task o degli standard task.

Vista delle note In questa vista è possibile visualizzare l’elenco di tutte le note inserite. Tappando su una di esse ne viene mostrato il contenuto. È possibile inserire nuove note oppure modificare quelle esistenti.

Vista dei progetti In questa vista sono presenti tutti i progetti. È possibile navigare tra di essi, crearne di nuovi e modificare quelli esistenti. Tappando su un progetto si visualizzano i suoi figli e un riassunto dello stato del progetto stesso.

Creazione di un appuntamento La creazione di un appuntamento avviene cliccando su Appuntamento presente nella vista giornaliera. Ciò genera la finestra visibile in Figura A.4. Tra i vari campi che è possibile inserire si fanno notare:

• Calendario: grazie a questo campo è possibile scegliere il calendario a cui l’ap- puntamento appartiene. Tappando sul menu a tendina verranno mostrati tutti i calendari associati all’account Google dell’utente. È possibile selezionare anche nessun calendario: l’evento in questione non sarà quindi sincronizzato con l’account. Nella vista quotidiana l’appuntamento avrà come colore di sfondo proprio quello del calendario ad esso associato.

79 di 91 APPENDICE A. MANUALE UTENTE

Figura A.2: Attività che mostra il riassunto di una giornata.

Figura A.3: Figura che mostra come visualizzare il menu contestuale di un appuntamento.

80 di 91 A.3. ISTRUZIONI PER L’USO

• Associa Progetto: tappando su questa casella si intende collegare un progetto al nuovo appuntamento. Verrà aperta un’apposita finestra la cui spiegazione è reperibile nel paragrafo Selezione di un progetto.

• Tutto il giorno: indica il fatto che l’appuntamento non ha orari precisi. Tappando su di esso verranno bloccati i campi per inserire l’ora d’inizio, l’ora di fine e quelli per il trasporto, in quanto essi non hanno senso se l’appuntamento dura tutto il giorno.

• Ripeti: tappando su di esso viene aperta una finestra nella quale è possibile selezionare ogni quanto si ripete l’appuntamento.

• Trasporto: è possibile indicare la durata espressa in ore e minuti del trasporto che antecede (tappando su Trasporto andata) e/o segue l’appuntamento (tappando su Ritorno).

Una volta inserite tutte le informazioni desiderate è sufficiente cliccare sul tasto Salva. È importante precisare che in fase di sincronizzazione con Google Calendar non tutte queste informazioni vengono sincronizzate in quanto esso non gestisce il trasporto ed i progetti.

Figura A.4: Figura che mostra come creare un nuovo appuntamento.

81 di 91 APPENDICE A. MANUALE UTENTE

Creazione di una nota Per creare una nuova nota è sufficiente andare nella vista delle note e cliccare sul tasto Nuova Nota. Verrà quindi visualizzata la finestra visibile in Figura A.5. in essa sono presenti i seguenti tasti:

• ‘‘Salva’’ permette di salvare la nota che si sta editando.

• ‘‘Cancella’’ permette di cancellare la nota che si sta editando. Verrà visualizzato un messaggio che chiede la conferma prima di procedere con l’effettiva eliminazione.

• ‘‘Associa Nota a...’’permette di associare la nota ad un progetto. Il modo con cui esso verrà scelto viene esposto nel paragrafo successivo.

Figura A.5: Figura che mostra come creare una nuova nota.

Selezione di un progetto Quando è necessario selezionare un progetto viene aperta la finestra visibile in figura A.6. Ricordiamo in questa sede che ogni progetto può avere dei figli: in fase di selezione è dunque possibile navigare tra tutti quest’ul- timi. Appena aperta, la figura mostra tutti i progetti che non hanno nessun padre. Tappando su un progetto viene mostrato in rosso il titolo del progetto, quindi si visualizzano tutti i suoi figli, tappando su uno di essi si scende di un livello e così via. Per tornare al padre del progetto selezionato è sufficiente tappare su Indietro, mentre per selezionare il progetto scritto in rosso basta usare il tasto Seleziona progetto.

Figura A.6: Figura che mostra come selezionare un progetto.

82 di 91 A.3. ISTRUZIONI PER L’USO

Menu Cliccando sul tasto menu presente in tutti i tablet android nell’angolo in alto a destra di ogni schermata si può accedere ad un breve lista di azioni che permettono di:

• sincronizzare l’applicazione con Google Calendar.

• modificare le preferenze dell’applicazione.

• uscire dal programma.

Sincronizzazione Per effettuare la sincronizzazione è necessario permettere all’applicativo di accedere in lettura e scrittura al proprio account di Google Calendar. Tale richiesta verrà fatta alla prima sincronizzazione. Nel caso si neghi il permesso l’applicazione continuerà a funzionare, ma non verrà offerta questa funzionalità. Sempre durante la prima sincronizzazione verrà richiesto all’utente l’intervallo di date tra le quali scaricare gli eventi da google calendar. Più è ampio questo intervallo più tempo sarà necessario per completare l’operazione. Nel caso si voglia effettuare una sincronizzazione di un vasto arco di tempo si consiglia di sfruttare una connessione wi-fi. Requisito essenziale per poter usufruire di questa funzionalità è avere una connessione ad internet attiva.

Preferenze È possibile modificare alcuni parametri del programma in modo da personalizzarlo entro certi limiti. In particolare è possibile:

• associare una password all’applicativo. In seguito è anche possibile cambiare tale password.

• modificare i colori legati al trasporto e agli eventi che non sono associati ad alcun calendario.

• valori di default come la durata del trasporto o quella degli appuntamenti.

Uscire dal programma Quando si termina di utilizzare l’applicativo si consi- glia di uscire dal programma al fine di preservare la batteria del proprio dispositivo.

83 di 91 APPENDICE A. MANUALE UTENTE

84 di 91 Appendice B

Glossario

AES È l’acronimo di Advanced Encryption Standard e viene promosso dal National Institute of Standards and Technology (NIST) che nel 1997 indisse un concorso per realizzare un algoritmo di cifratura che avesse le seguenti caratteristiche:

• doveva essere simmetrico ovvero la chiave per cifrare doveva essere la stessa utilizzata per decifrare il messaggio.

• la licenza d’uso doveva essere royalty-free, permettendo quindi un utilizzo a livello globale.

• essere semplice da implementare sia in hardware che in software.

• offrire un alto livello di sicurezza a numerosi attacchi.

Il vincitore del contest fu l’algoritmo Rijndael. Esso cifra con blocchi a 128 bit e chiavi che posso essere di 128, 192 o 256 bit.

Android È un sistema operativo per dispositivi mobili basato su Kernel Linux. Esso viene mantenuto dalla Handset Alliance di cui fa parte anche Google. Android viene utilizzato sia su tablet che smartphone di numerose case produttrici. I suoi punti di forza sono la filosofia aperta, il vasto mercato che sta creando e la disponibilità di numerose applicazioni di terze parti che arricchiscono notevolmente l’esperienza d’uso.

API È l’acronimo di Application Programming Interface e rappresenta un insieme di procedure disponibili agli sviluppatori per la realizzazione di certi compiti all’interno di un particolare software. In questo modo al programmatore viene risparmiato il dover scrivere tali procedure ex novo, incrementando il livello di riuso del codice.

apk È il formato di estensione delle applicazioni che vengono installate dei disposi- tivi Android.

BlueFish È un cifrario a blocchi di 64 bit che lavora con chiavi da 32 a 448 bit. L’algoritmo si presenta molto veloce, salvo quando si concatenano le chiavi.

Consulting Engineering Si tratta di un’attività per cui uno specialista offre la sua competenza ad aziende che esprimono particolari bisogni in un certo ambito. Esistono molti tipi di consulenza da quella burocratica a quella informatica, spaziando per molti altri campi.

85 APPENDICE B. GLOSSARIO

DBMS Acronimo di DataBase Management System. Indica un sistema software che permette di creare e gestire degli insiemi di dati strutturati ovvero dei database. Vengono anche offerti dei metodi per interrogare le varie tabelle che lo compongono.

Design Pattern Sono delle soluzioni a dei problemi progettuali ricorrenti. Si possono definire 3 diversi gruppi di design patterns:

• design pattern architetturali: si occupano di definire l’infrastruttura generale di un programma. Alcuni esempi sono il paradigma client-server, il modello MVC e il peer-to-peer.

• design pattern progettuali: si occupano di risolvere problemi che riguardano le relazioni che intercorrono tra componenti di un sistema. In questo modo vengono a crearsi delle micro-architetture che rappresentano le basi per costruire i design pattern architetturali

• idiomi: sono la realizzazione dei design pattern progettuali e architetturali in un particolare linguaggio di programmazione, ad esempio come implementare il Singleton in Java. Gli Idiomi rinunciano alla generalità che caratterizza i pattern sopra esposti per poter utilizzare appieno le potenzialità del linguaggio per cui sono ideati.

Façade Si tratta di un desgin pattern strutturale che vuole racchiudere tutte le funzionalità offerte da un package in un’unica classe. In questo modo quando si deve accedere alle funzionalità offerte da questo package è sufficiente utilizzare tale classe Façade incrementando il disaccoppiamento tra le componenti. Tipicamente una classe che implementa questo design pattern può anche utilizzare il Singleton poiché non ha uno stato interno.

FIPS 197 FIPS è l’acronimo di Federal Information Processing Standards e rag- gruppa un insieme di processi standard che devono essere seguiti dai vari apparati del governo statunitense e dalle agenzie (escluse quelle militari). Il numero 197 stabilisce che per criptare dati sensibili è necessario utilizzare AES.

GTD Acronimo di Getting Things Done indica un metodo per l’organizzazione personale del proprio lavoro. Essa si basa sul fatto che più la mente è libera dalle cose da fare più può concentrarsi sul lavoro da svolgere, incrementando la produttività. Lo scopo di questa filosofia è quello di tracciare tutte le cose che devono essere fatte.

HTTP Acronimo di Hypertext Transfer Protocol, viene utilizzato come base per il World Wide Web. Esso stabilisce quali siano le richieste che possono essere fatte da un client e quali risposte il server possa ritornare. Tra le prime ci sono i metodi GET, PUT e DELETE, al contrario le risposte indicano se è andato tutto bene, se ci sono reindirizzamenti oppure errori da parte del client o del server.

IDE acronimo di Integrated development environment. Si tratta di software che permettono agli sviluppatori di avere molti strumenti utili per codificare un applica- tivo. Tipicamente viene offerto un editor per il codice sorgente, un compilatore ed un debugger. Nonostante ciò possono essere presenti svariate altre funzionalità come la navigazione tra le classi o tra i packages che compongono il progetto. Tra gli IDE più diffusi citiamo Eclipse, NetBeans, Xcode e Visual Studio.

86 di 91 iOS È il sistema operativo per dispositivi mobili Apple. Esso viene supportato da iPhone, iPod Touch, iPad ed AppleTV. È stato lanciato nel 2007 ed è tuttora in sviluppo.

Modello relazionale Proposto negli anni ’70, viene utilizzato in molti database commerciali moderni. Esso utilizza due concetti:

• ennupla: viene rappresentata da un insieme di coppie (etichetta, tipo primitivo) dette campi.

• relazione: è un insieme di ennuple.

Al fine di identificare univocamente una particolare ennupla all’interno di una relazione è necessario stabilire dei campi che siano univoci: questi sono le chiavi primarie (PK). È possibile creare delle associazioni tra le relazioni mediante delle chiavi esterne ovvero degli insiemi di attributi che corrispondono alla chiave primaria della tabella riferita.

MVC Si tratta di un Design Pattern Architetturale che permette di ottenere un’ottima divisione tra i diversi strati che compongono l’applicativo. In questo modo essi possono essere progettati, sviluppati, testati e mantenuti in parallelo, incrementando la velocità di realizzazione. Tali strati sono:

• Model: rappresenta il Database nel quale sono contenute in modo persistente tutte le informazioni sulle quali è costruito il programma. In questo strato viene anche inserita la logica per gestire il database.

• View: è l’interfaccia grafica con la quale interagisce l’utente. Essa richiede le informazioni da mostrare al Model; tipicamente è il Controller che dice alla vista di aggiornarsi.

• Controller: in esso è contenuta la logica del programma, ovvero tutto l’insieme di operazioni trasparenti all’utente che permettono la prosecuzione del flusso d’esecuzione.

L’aspetto interessante di questo pattern è che possono esistere diverse viste che interagiscono con lo stesso Model e Controller. Ciò permette di adattare il programma a diversi ambienti d’esecuzione. Ogni vista saprà come dover riprodurre un insieme di dati.

OAuth2 OAuth è un protocollo che permette l’accesso da parte di terzi a dei servizi che richiedono il login senza che questo venga condiviso con tali parti. Ciò permette ad esempio di sviluppare un’applicazione che acceda a GMail richiedendo che l’utente inserisca le sue credenziali per il login, ma senza che queste transitino all’interno dell’applicazione.

Use Cases Sono dei diagrammi UML che permettono di individuare quali siano le funzionalità che il sistema espone ai suoi utenti. Essi permettono di definire degli attori che possono essere utenti, amministratori o altro i quali agiscono sull’applicativo. È anche possibile indicare quali siano i servizi esterni su cui si basa l’applicativo. Per rendere comoda l’individuazione di uno use case tipicamente gli viene attribuito un identificativo univoco in sede d’analisi. l’aspetto più importante degli use case è che essi permettono di individuare facilmente i requisiti funzionali che devono essere soddisfatti dal prodotto finale.

87 di 91 APPENDICE B. GLOSSARIO

SDK Acronimo di Software Development Kit. Esso rappresenta un insieme di strumenti utili per sviluppare un applicativo per una specifica piattaforma. All’interno di questi pacchetti si possono trovare le API, una documentazione sulla piattaforma, IDE e molto altro.

SHA Acronimo di Secure Hash Algorithm. Esso produce un message disgest ovvero un impronta del messaggio. L’input è costituito da un testo di lunghezza variabile di cui si vuole calcolare l’hash. L’output è questo hash che però è sempre di lunghezza fissa. due sono le caratteristiche essenziali di questo algoritmo:

• non è possibile ottenere il messaggio iniziale partendo dal suo hash.

• due messaggi anche molto simili producono due hash completamente diversi.

esistono diverse varianti di questo algoritmo che si differenziano per il numero di bit che compongono il message digest. Si va dai 160 bit dello SHA-1 ai 512.

Singleton Questo Design Pattern creazionale permette di assicurare che all’interno dell’applicazione esista al massimo un’istanza di una certa classe. Ciò viene tipica- mente utilizzato quando quest’ultima non ha uno stato mutevole. Per realizzare questo pattern si rende privato il costruttore e si crea un metodo statico il quale viene richiamato ogni qualvolta sia necessario avere l’unica istanza della classe in oggetto. Questo metodo statico crea l’oggetto nel caso non esista, quindi lo ritorna. Di seguito viene riportata l’implementazione di tale pattern in Java.

class SingletonClass { private SingletonClass instance;

private SingletonClass();

static SingletonClass getInstance(){ if(instance==null) { instance= new SingletonClass(); } return instance; } }

Smartphone Sono cellulari che, oltre all’apparato telefonico, offrono molte altre funzionalità. Esse derivano tipicamente dalla combinazione tra un hardware e un software più complicati e potenti rispetto a quelli offerti per i comuni cellulari. Tra i sistemi operativi più diffusi per smartphone si possono citare: iOS, Android, Windows Phone, Blackberry OS,Symbian, PalmOS, WebOS, Bada. Tipicamente gli smartphone supportano diversi tipi di connessione senza fili: GSM, UMTS, HSDPA, HSUPA, Bluetooth, wi-fi e - recentemente - anche il DLNA.

Thread Quando un’applicazione suddivide la sua esecuzione in processi paralleli che eseguono correntemente si dice che essa crea dei thread. Ciò permette di svolgere più cose allo stesso tempo, velocizzando così il programma.

88 di 91 UML Acronimo di Unified Modeling Language, indica una famiglia di rappresen- tazioni grafiche che permettono di sviluppare delle descrizioni visuali dei progetti software accompagnandoli dal concepimento al rilascio. Si offrono diversi diagrammi, ognuno dei quali ha degli scopi precisi. Tra i più importanti possiamo citare:

• Use Case: permettono di mostrare quali siano le funzionalità che vengono esposte dal sistema agli utenti. In essi non vengono riportati dei dettagli implementativi.

• Diagrammi di attivita’: mostrano quale sia il flusso di esecuzione generale di una certa attività.

• Diagrammi dei packages: visualizzano i packages e le interazioni tra di essi.

• Diagrammi delle classi: permettono di vedere le classi, la loro implementazione (campi dati e metodi) e le relazioni tra di esse.

• Diagrammi di sequenza: mostrano le diverse operazioni che vengono eseguite dal- l’applicativo per effettuare un compito. In essi partecipano diversi oggetti che richiamano diversi metodi gli uni degli altri.

WYSIWYM Acronimo di What You See Is What You Mean. Indica un tipo di programmi dove quello che si scrive è veramente ciò che si intende. Tipicamente ciò corrisponde a vedere su schermo non l’impaginazione finale di una pagina (come con Microsoft Word), ma le righe di codice che - una volta compilate - diano effettivamente il risultato voluto. Un esempio è LATEX.

XML Acronimo di eXtensible Markup Language. Si tratta di un linguaggio di MarkUp che permette di definire dei nuovi linguaggi indicando i marcatori che li compongono. Esso viene soprattutto utilizzato per la realizzazione di basi di dati semi-strutturate e per gestire le esportazioni tra diversi DBMS.

89 di 91 APPENDICE B. GLOSSARIO

90 di 91 Appendice C

Bibliografia

[1] sito ufficiale della Dalvik Virtual Machine: http://www.dalvikvm.com

[2] sito ufficiale di android per sviluppatori: http://developer.android.com/index.html

[3] java code conventions: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf

[4] sito di time/System: http://www.timesystem.com/index.php

[5] introduzione sull’architettura android: http://www.youtube.com/watch?v=Mm6Ju0xhUW8

91