Sviluppo di un applicazione Android per la gestione di eventi presso siti turistici

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Programmazione I Sviluppo di un applicazione Android per la gestione di eventi presso siti turistici Anno Accademico 2015/2016 Candidato: Bruno Capuozzo matr. N46/61

2 A mia madre e a Roberta

3 Indice Indice... III Introduzione... 4 Capitolo 1: Perché Android Android e Java Android vs ios vs Windows phone L evoluzione di Android Diffusione di Android nel mondo... 9 Capitolo 2: Napp Analisi dei requisiti Progettazione Use case diagram Sequence Diagram Class Diagram Scelta della piattaforma e del database Implementazione Fragment home Fragment musei Fragment eventi Classe Chat Classe Evento Le Activity Activity Login Activity DescrizioneMuseo Activity ChatUtenti Activity VisualizzaEventi Activity InserisciEvento Struttura del database Conclusioni Bibliografia... 27

4 Introduzione L utilizzo degli smartphone, i telefonini intelligenti, ha conosciuto negli ultimi anni un notevole sviluppo grazie soprattutto alle nuove tecnologie che, se da un lato hanno permesso di costruire prodotti sempre più affidabili e versatili, tanto che la telefonata è solo una delle tante funzioni possibili, dall altro hanno consentito di ridurne sensibilmente i costi, così da poterli rendere accessibili ad una fascia di acquirenti sempre più larga. Certo, l introduzione di queste funzioni ha forse reso il dispositivo più complicato da utilizzare, soprattutto per la clientela non più giovanissima, ma sicuramente si è posta come uno stimolo per gli sviluppatori nell inventare e re-inventare applicazioni sempre più efficaci ed adeguate all odierno stile di vita. Attualmente esistono differenti tipi di smartphone, caratterizzati dai diversi sistemi operativi che montano, Android, ios, RIM, Windows Phone, ciascuno dei quali con sue caratteristiche peculiari, che lo rendono più indicato per una certa utenza piuttosto che per un altra. Tra i tanti sistemi operativi presenti, uno dei principali è sicuramente Android, il cui mondo ruota tutto attorno alla parola open source. In Android, infatti, si ha libero accesso a tutti gli strumenti utilizzati dagli stessi sviluppatori del sistema e quindi il potenziale delle applicazioni sviluppate da terzi non è soggetto a limitazioni, tanto più che applicazioni native e di parti terze hanno lo stesso 4

5 peso. Inoltre, chiunque può sviluppare per Android senza dover acquistare software o licenze particolari. Il caso di studio del presente lavoro è appunto quello di illustrare l architettura e lo sviluppo di Napp, un app da me progettata e implementata col fine di creare uno strumento per la gestione e la visualizzazione di eventi relativi ai musei di Napoli. Entrando più nello specifico, esso può sostanzialmente essere suddiviso in due parti: nella prima cercherò di illustrare Android, i motivi per cui è, da alcuni, ritenuto migliore rispetto ad altri sistemi operativi, la sua diffusione nel mondo e la sua evoluzione del software; nella seconda, presenterò nello specifico Napp descrivendo le varie fasi che ne hanno permesso lo sviluppo. 5

6 Capitolo 1: Perché Android In qesto capitolo illustrerò brevemente le motivazioni che mi hanno indotto a svlippare per Android. 1.1 Android e Java Il linguaggio Java, rispetto al C, gestisce automaticamente il ciclo di vita di un applicazione e anche l allocazione della memoria, rendendo più semplice lo sviluppo. Android, inoltre, è completamente open source, quindi rende possibile reperire, modificare e ridistribuire il codice sorgente, adattandolo ad ogni dispositivo e creandone la propria versione personalizzata ed ottimizzata. E anche il sistema operativo mobile più diffuso, ha una gestione di grafica e audio di alta qualità, le applicazioni native e di terze parti sono di uguale importanza e possono essere aggiunte o rimosse senza alcun vincolo. La scelta di Android non porta, tuttavia, solo vantaggi dal punto di vista informatico, ma anche dal punto di vista economico. Pubblicare applicazioni sullo store di Android (Google Play Store) ha un costo di iscrizione di 25 euro ed è possibile programmare l app con tutti i sistemi operativi per desktop più diffusi: Windows, OS X e Linux. Scegliere ios invece comporta un costo di circa 4 volte superiore per l iscrizione all App Store e serve necessariamente un computer Mac per programmare, anche questo molto costoso. Vediamo ora, nel prossimo paragrafo, le principali differenze che distinguono i diversi sistemi operativi che dominano il mercato. 6

7 1.2 Android vs ios vs Windows phone Il sistema proprietario Apple è sicuramente più user friendly, cioè è più adatto ad una clientela poco abituata ad utilizzare smartphone, ma d altro canto per poter sincronizzare il telefono con il PC (scambio di foto, musica etc.) o ottenere aggiornamenti software, richiede il costante utilizzo di programmi forniti da Apple, come itunes. La libertà di poter installare qualsiasi applicazione, anche non ufficiale, rende Android migliore per gli sviluppatori, che possono così provare le loro applicazioni sui terminali senza dover per forza ricorrere ad un emulatore. Poter ottenere il codice sorgente ha come effetto la possibilità di avere sempre diverse versioni del sistema operativo ottimizzate per ogni tipo di telefono e con funzionalità che la versione originale non aveva. Una famosa distribuzione di Android modificata, detta Custom ROM, è la Cyanogen Mod. L utilizzo di una custom ROM dà all utente i privilegi di root, cioè quei permessi che consentono all utente di fare qualsiasi cosa col telefono, anche accedere o modificare risorse il cui accesso era stato impedito dalla ROM originale. Si puo` fare qualcosa di simile anche in ios tramite il cosiddetto jailbreak, che permette sì di avere nuove funzionalità, ma la licenza del sistema rimane comunque di Apple. Dal punto di vista della flessibilità, ios è molto meno personalizzabile di Android, il quale lascia maggior voce in capitolo all utente. Guardando al kernel, invece, entrambe sono basate su kernel Linux. Symbian, invece, sistema proprietario Nokia fino a poco tempo fa, è stato abbandonato e sostituito da Windows Phone, sviluppato da Microsoft. Quest ultimo ha introdotto una grande novità: le tiles. Le tiles sono delle tessere che si trovano al posto delle classiche icone e che rendono la ricerca di app e informazioni nel proprio telefono estremamente rapida. La sostanziale differenza tra i due sistemi operativi sta nel fatto che Windows Phone si concentra maggiormente sulla condivisione di informazioni su social network. Per il resto i sistemi sono quasi equivalenti, se non per il fatto che lo store di Android è sicuramente più ricco di app, motivo per il quale molta gente opta per il robottino piuttosto che per Windows Phone. 7

8 1.3 L evoluzione di Android Dal 2008, data della prima uscita su smartphone, ad oggi, Android è migliorato moltissimo e ha subìto grandi variazioni dal punto di vista grafico, funzionale e delle prestazioni. Si sono susseguite 53 versioni (contando anche le release minori) e 23 livelli di API, Application User Interface [1]. Le API sono un insieme di funzioni disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per lo svolgimento di un determinato compito all interno di un certo programma. Spesso con tale termine si intendono le librerie software disponibili in un certo linguaggio di programmazione. Le release maggiori, cioè che portano grandi cambiamenti, passano da un numero ad un altro (es. da 3 a 4) mentre le release minori, correzioni di piccoli bug e piccole novità, mantengono quasi lo stesso numero di versione (es. da 4.0 a 4.1). Figura n.1 Le versioni di Android prima della 1.0 non avevano un nome identificativo ma solamente un numero di riconoscimento come m3-rc20a e m5-rc15. Per poter essere ricordate più facilmente anche dagli utenti, si decise di dare a queste due versioni dei nomi che potessero ricordare un robottino e furono rispettivamente Astro Boy e Bender. Per le versioni seguenti gli sviluppatori decisero che avrebbero invece utilizzato dei nomi di dolcetti, senza un particolare motivo, ma in ordine alfabetico. La prima di queste versioni è Cupcake, la prima che esce anche in Italia, introduce delle novità che con l evolversi del sistema operativo verranno mantenute, migliorate e considerate sempre più importanti, come i Widget e la rotazione dello schermo. Donut e Eclair non sono particolarmente 8

9 interessanti dato che ottimizzano solo in parte le prestazioni di Android ed infatti non sono per nulla diffuse. Froyo introduce importantissime novità nel kernel2 grazie alla Dalvik Virtual Machine (di cui parleremo più avanti) e al JIT (Just in Time compiler). Gingerbread porta solamente delle piccole migliorie, mentre con HoneyComb Google si sposta anche nel settore tablet, introducendo la grafica Holo che sarà alla base delle successive versioni per smartphone come Ice Cream Sandwich e Jelly Bean. Quest ultima versione è decisamente migliore delle precedenti grazie all implementazione del Project Butter, un iniziativa di Google per rendere il sistema più fluido. Attualmente è in corso la distribuzione dell ultima versione Marshmallow su tutti i dispositivi marcati Samsung, LG, HTC etc. etc., già presente sui nexus (dispositivi prodotti direttamente da google in collaborazione con degli OEM). 1.4 Diffusione di Android nel mondo In questi anni il robottino verde ha guadagnato moltissimi utenti e continua ad essere il sistema operativo più diffuso in europa [2]. ios, come si può notare dall immagine (fig. 2), è meno diffuso in europa rispetto ad android; ciò è dovuto principalmente al costo più elevato dei dispositivi in quanto gli attuali top di gamma possono addirittura superare i C è infatti da aggiungere che android, a differenza di ios, si trova su dispositivi appartenenti a qualsiasi fascia di prezzo e quindi non è molto difficile acquistarne uno con una modica spesa di circa 100, mentre per ios il prezzo base di un dispositivo che lo monti si aggira intorno ai 300. Per quanto riguarda windows phone, il sistema operativo più recente dei 3 principali, continua a guadagnare terreno grazie alla sua buona ottimizzazione ma resta comunque ancora il meno diffuso attualmente in europa. 9

10 Figura n.2 10

11 Capitolo 2: Napp In questo capitolo descriverò le fasi di sviluppo che mi hanno permesso di realizzare Napp partendo dall analisi dei requisiti, in cui spiegherò da un punto di vista concettuale a cosa serve e come funziona l app, per arrivare alla fase di progettazione e implementazione in cui, attraverso opportuni digrammi e codice, andrò ad analizzare più nel dettaglio gli aspetti funzionali ed implementativi dell app stessa. 2.1 Analisi dei requisiti Napp è ideata allo scopo di offrire un servizio ai turisti in visita nella città di Napoli. Essa consentirà di ricercare e ottenere informazioni inerenti ai musei presenti a Napoli come: numeri di telefono, indirizzo, tariffe, orari, eventuali chiusure o aperture straordinarie etc. Ogni museo sarà geolocalizzato su una mappa, dando così l opportunità al fruitore di ottenere le indicazioni stradali utili per raggiungere il museo prescelto semplicemente cliccando sul relativo marker. Sarà anche prevista la possibilità, previa registrazione su Napp, di interazione tra gli utenti registrati i quali, tramite una chat, potranno richiedere o approfondire informazioni sui musei di interesse, come la presenza o meno di un opera in quel particolare periodo, acquisire ulteriori notizie circa i monumenti o siti cittadini più interessanti da visitare o scambiarsi opinioni, offrire suggerimenti, dare una valutazione ai servizi ricevuti e così via. Sarà, inoltre, presente un area dedicata nella quale si troveranno tutti gli eventi associati ai vari musei. A tal proposito, tuttavia, occorre qui precisare che, poichè per l inserimento degli eventi sarà necessrio registrarsi su Napp attraverso una mail che contenga il dominio: 11

12 napp.it. e che attualmente tale dominio non esiste, al momento, sarà implementata solo la funzionalità per testarla. Va da sé che, una volta acquistato il dominio, l app, già predisposta, sarà perfettamente funzionante. Per visualizzare gli eventi, invece, basterà registrarsi sul portale attraverso una qualsiasi mail senza vincoli sul dominio (saranno accettati etc. etc.). 2.2 Progettazione Per capire al meglio come ho sviluppato Napp e comprendere i requisiti del progetto analizzerò inizialmente alcuni casi d uso e successivamente, entrando più nello specifico, i sequence diagram e il class diagram Use case diagram Il caso d uso (use case diagram), in informatica, è una tecnica usata nei processi di ingegneria del software per effettuare, in maniera esaustiva e non ambigua, la raccolta dei requisiti al fine di produrre software di qualità. Vengono utilizzati per l individuazione e la registrazione dei requisiti funzionali scrivendo come un sistema possa essere utilizzato per consentire agli utenti i raggiungere i loro obiettivi. Come si può notare dalla (fig. 3) sono presenti due attori: il Turista e il Gestore. Entrambi gli attori, una volta effettuata l operazione di login, potranno accedere alle funzionalità offerte dall app come la visualizzazione degli eventi, ma solo il Gestore, loggato mediante una mail contenente il dominio napp.it, sarà abilitato all inserimento di eventi sul database. Per quanto riguarda l untente Public esso potrà solo visualizzare la mappa, dove si troveranno i musei, e la loro descrizione senza avere nè la possibilità di chiedere informazioni alla community nè la possibilità di visualizzare o insierire gli eventi nel database. 12

13 Figura n Sequence Diagram Per comprendere al meglio i due use-case realtivi, l uno all inserimento di un evento e l altro alla richiesta di informazioni su un museo, analizzeremo i loro sequence diagram, riproducendo la sequenza di azioni necessarie da fare per effettuare l operazione desiderata. In figura 4 è rappresentato il sequence diagram relativo all iserimento di un elemento nel database, in figura 5 è rappresentato invece quello relativo alla richiesta di informazioni alla community. 13

14 Figura n.4 Figura n.5 14

15 2.2.3 Class Diagram Il Class Diagram presente in figura 6 mostra la struttura dell app e la relazione fra i vari componenti. Come si può notare l app è composta da 3 fragment principali i quali saranno spiegati più nel dettaglio nel paragrafo 2.3. I collegamenti tra le varie activity sono stabiliti da intent, i quali hanno il compito di richiamare l activity desiderata e renderla visualizzabile dall utente. ChatListAdapter e CustomAdapterListaEventi sono i componenti che si occupano della rappresentazione grafica dei dati per ogni elemento delle ListView a cui fanno riferimento, mentre FireBaseList adapter ha il compito di andarle a "popolare" tramite il metodo populateview. Chat ed Evento, infine, sono le due classi che servono a generare i vari oggetti, appunto chat ed evento, che saranno poi memorizzati sul database. Figura n.6 15

16 2.2.4 Scelta della piattaforma e del database Per sviluppare Napp ho scelto come ambiente di sviluppo Android Studio (fig.7). La scelta è ricaduta su Android Studio dato che esso è lo strumento ufficiale messo a disposizione da Google per lo sviluppo di app per android. Figura n.7 Figura n.8 Per quanto riguarda il database utilizzato per implementare la chat, l inserimento e la visualizzazione degli eventi in remoto, ho utilizzato Firebase (fig.8). Esso è un database non relazionale, molto veloce, che offre nativamente il supporto ad Android Studio. Oltre ad essere perfettamente gestito da Android Studio e supportato da Android, esso offre anche il supporto verso ios in quanto supporta perfettamente, oltre a Java, anche Swift e Objective-C. E quindi un database molto versatile, e proprio grazie alla sua versatilità sarà relativamente semplice riadattarlo all occorrenza verso ios. 2.3 Implementazione Entraimo adesso nel cuore dell app analizzando nel dettaglio il codice che ne ha permesso la realizzazione. Qui di seguito, riporto il codice relativo alla classe Principale che funge da contenitore in quanto in essa saranno visualizzati i fragments relativi alle varie pagine. 16

17 public class Principale extends AppCompatActivity { Intent effettualogin,effettualogout; public static class MyPagerAdapter extends FragmentPagerAdapter { private static int NUM_ITEMS = 3; public MyPagerAdapter(FragmentManager fragmentmanager) { super(fragmentmanager); // Ritorno il numero delle public int getcount() { return NUM_ITEMS; // Ritorno i fragment da public Fragment getitem(int position) { switch (position) { case 0: return Home.newInstance(0, "Home"); case 1: return Musei.newInstance(1, "Musei"); case 2: return Eventi.newInstance(2, "Eventi"); default: return null; // Ritorno i titoli delle pagine nell' public CharSequence getpagetitle(int position) { if(position==0) return "Home"; if(position==1) return "Musei"; if(position==2) return "Eventi"; else return "Page " + protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_principale); setrequestedorientation(activityinfo.screen_orientation_portrait); ViewPager vppager = (ViewPager) findviewbyid(r.id.viewpager); vppager.setadapter(new MyPagerAdapter(getSupportFragmentManager())); PagerSlidingTabStrip tabsstrip = (PagerSlidingTabStrip) findviewbyid(r.id.tabs); tabsstrip.setviewpager(vppager); 17

18 @Override public boolean oncreateoptionsmenu(menu menu) { if(login.mauthdata!=null){ getmenuinflater().inflate(r.menu.logout, menu); else { getmenuinflater().inflate(r.menu.login, menu); return public boolean onoptionsitemselected(menuitem item) { int id = item.getitemid(); if (id == R.id.action_login) { effettualogin=new Intent(getApplicationContext(), Login.class); startactivity(effettualogin); return true; else if(id == R.id.action_logout){ Login.mAuthData=null; Login.mFirebaseRef.unauth(); effettualogout=new Intent(getApplicationContext(), Principale.class); startactivity(effettualogout); return public void onbackpressed() { Toast t=toast.maketext(getapplicationcontext(),"premi il tasto home per uscire",toast.length_long); t.show(); return; Come si può evincere dal codice, Napp è costituita da 3 fragment principali: Home Musei Eventi e da un OptionsMenu, ovvero un menù che, a seconda che l utente sia loggato o meno, consente di effettuare rispettivamente operazioni di logout e login. 18

19 Figura n. 9 Figura n. 10 Figura n Fragment home Il fragment home, come mostra la figura n. 9, è costituita da 3 elementi principali: Mappa TextView Button La mappa è gestita attraverso le API delle maps messe a disposizione da Google. In essa si trovano i marker relativi alle posizioni dei vari musei della città di Napoli. Per il momento sono stati inseriti solo 4 musei in locale per effettuare la fase di test dell app, ma in futuro potranno poi essere inseriti, sempre in locale, tutti i musei appartenenti alla città. Cliccando su un marker è possibile, attraverso il navigatore di default di Android maps, ottenere le indicazioni stradali necessarie per raggiungere il museo desiderato. La TextView fornisce una breve descrizione di Napp. Al suo interno, infatti si possono trovare descritte le funzionalità principali offerte dall app. Il Button fornisce un collegamento rapido verso la pagina di Login necessaria per poter usufruire appieno delle funzionalità di Napp. 19

20 2.3.2 Fragment musei Questa Activity (fig. 10) è costituita sostanzialmente da una custom ListView. Essa è una lista dei musei della città di Napoli. Anche per questa ListView valgono le stesse considerazioni fatte per la mappa, ovvero sono, al momento, presenti solo 4 musei, ovviamente correlati a quelli presenti nella mappa, necessari per effettuare la fase di testing. Cliccando su un item della lista si è indirizzati verso un activity dinamica contenente tutte le informazioni relative al museo selezionato. Ulteriori chiarimenti riguardo quasta activity si potranno trovare nel sottoparagrafo Fragment eventi Come si può notare nella figura n.11, il fragment eventi è costituito da una una TextView e da due Buttons, di cui uno rimanda alla visualizzazione dell activity VisualizzaEventi, per i cui approfondimenti si rimanda al sottoparagrafo e l altro all activity InserisciEvento di cui al sottoparagrafo Classe Chat Di seguito riporto il codice relativo alla classe Chat funzionale alla creazione dell oggetto chat indispensabile per la pubblicazione dei messaggi da parte dell utente che ha superato la fase di login. public class Chat { private String message; private String private Chat() { public Chat(String message, String author) { this.message = message; this.author = author; public String getmessage() { return message; public String getauthor() { return author; 20

21 Come si può notare dal codice, in essa troviamo i costruttori con e senza argomenti e i due metodi relativi alle variabili dell oggetto Chat, i quali ritornano rispettivamente il messaggio e l autore del messaggio mandato dall utente Classe Evento Di seguito si riporta il codice relativo alla classe Evento funzionale alla creazione dell oggetto evento: public class Evento { private String nome; private String luogo; private String dataevento; private String prezzo; private String private Evento() { public Evento(String nome,string luogo, String dataevento,string prezzo,string ora){ this.nome=nome; this.luogo=luogo; this.dataevento=dataevento; this.prezzo=prezzo; this.ora=ora; public String getnome(){return nome; public String getluogo(){return luogo; public String getdataevento(){return dataevento; public String getprezzo(){return prezzo; public String getora(){return ora; Come si può notare dal codice, in essa troviamo i costruttori con e senza argomenti e i cinque metodi relativi alle variabili dell oggetto Evento i quali ritornano rispettivamente il nome, il luogo, la data, il prezzo e l ora dell evento stesso. 21

22 2.4 Le Activity Illustrati i vari fragment, analizzeremo ora le activity presenti in Napp. Figura n.12 Figura n.13 Figura n.14 Figura n.15 Figura n.16 22

23 2.4.1 Activity Login Come già accennato nel sottoparagrafo 2.3.1, l activity Login (fig. 12) è raggiungibile attraverso il Button presente nel fragment Home e mediante l OptionsMenu presente nella Toolbar. Essa è costituita da un ImageView contentente il logo di Napp, due EditText necessarie per l acquisizione rispettivamente di e password ed infine un Button che richiama il metodo attemptlogin() il quale effettua un tentativo di autentinticazione dell utente, e, in caso positivo, riporta l utente autenticato nel fragment Home. C è da sottolineare che le due EditText, oltre ad acquisire i dati dell utente, effettuano anche un controllo sui dati inseriti, in quanto la mail inserita deve contenere il e la password deve contenere almeno quattro caratteri ; nel caso in cui i vincoli imposti non dovessero essere soddisfatti sarà necessario reinserire i dati. Successivamente alla fase di login è effettuato un ulteriore controllo sulla mail dell utente, la quale, qualora dovesse appartenere al dominio napp.it, ad es. bruno@napp.it, abiliterebbe l utente ad inserire, oltre che a leggere, gli eventi attraverso l activity InserisciEvento la quale sarà discussa nel sottoparagrafo Activity DescrizioneMuseo Dalla ListView, appartenente al fragment Musei, cliccando sull item prescelto si è indirizzati verso un activity dinamica contenente tutte le informazioni relative al museo selezionato. Sono infatti presenti, come si vede in figura n.13, 4 elementi principali: Una ImageView, 2 TextView ed un Button a comparsa. L ImageView conterrà una foto relativa al museo selezionato in precedeza, la prima TextView, dall alto, una breve descrizione del museo stesso, e l ultima TextView che, una volta cliccata, reindirizzerà l utente verso il sito ufficiale del museo contenente informazioni relative agli orari i prezzi e i giorni di apertura. Per quanto riguarda il Button, esso non sarà visualizzabile da tutti ma solo dagli utenti che si saranno loggati su Napp. Tramite esso si sarà collegati ad una chat, gestita tramite il database in remoto Firebase, dove sarà possibile chiedere maggiori informazioni sul museo di interesse come: la presenza di un opera un feedback etc etc. 23

24 2.4.3 Activity ChatUtenti L activity ChatUtenti (fig.14) è composta da una TextView contenente il nome del museo selezionato, una EditText nella quale l utente andrà ad inserire il messaggio che desidera inviare, un Button che si interfaccerà con il database attraverso il metodo sendmessage() necessario per l invio del messaggio stesso, ed infine una Custom ListView la quale, aggiornandosi in maniera del tutto automatica, sia all invio che alla ricezione di un messaggio, conterrà tutti i messaggi inviati Activity VisualizzaEventi Come si può notare in figura n. 16, l activity VisualizzaEventi è costituita da una custom ListView. In essa troviamo tutte le informazioni relative agli eventi in programma dei singoli musei : nome, luogo, data, ora, prezzo. Tali eventi possono essere pubblicati, come già detto in precedenza, solo dagli utenti registrati su Napp in possesso di un indirizzo e- mail relativo al dominio napp.it. E importante sottolineare che, per poter accedere a tale lista, è necessario essere loggati ; in caso contrario, invece della ListView, si visualizzerà una TextView contente l invito a loggarsi Activity InserisciEvento L activity InserisciEvento (fig. 15) è costituita da una ImageView, da 5 EditText e da un Button. L ImageView contiene il logo dell app, i cinque EditText sono relativi rispettivamente : al nome dell evento, alla data dello stesso, al luogo in cui si verifica, all ora e all eventuale prezzo ; il Button si interfaccia con il database, attraverso il metodo inseriscievento(), e consente la pubblicazione, qualora i campi degli EditText siano stati tutti correttamente compilati, dell evento. 2.5 Struttura del database Come già accennato in precendenza, per effettuare la fase di testing dell app ho scelto di utilizzare il database Firebase. In esso non vi sono tabelle né record, nessuna traccia dell approccio relazionale. 24

25 Tutti i dati inseriti in Firebase vanno a costituire un albero JSON. Esso contiene sia le chat relative ai singoli musei che gli eventi inseriti dai vari gestori. In figura n. 17 è possibile notare come ho strutturato il database e come vengono memorizzati gli oggetti chat ed evento. Si evince dalla seguente figura la corrispondenza che c è tra i dati inseriti nel database e quelli presenti nelle activity: VisualizzaEventi e ChatUtenti. Figura n

26 Conclusioni Lo sviluppo di un applicazione su mobile per turisti, s inserisce nel più ampio concetto di Smart Cities, concetto questo, che sta guadagnando sempre più importanza. Anche se la maggior parte delle città vogliono essere Smart, non esiste una definizione condivisa di cosa questo significhi. Una Smart City è, infatti, più di una città digitale: è quella che è capace di legare il capitale fisico (infrastrutture) con quello sociale (umano e culturale) e capace di sviluppare servizi migliori, integrati, condivisi e innovativi. Deve quindi integrare tecnologia, informazione e visione politica in un programma coerente di miglioramenti urbani e dei servizi. Napp, così come ideata e sviluppata nelle sue funzionalità sembra rispondendere a questi requisiti non solo per il suo stato attuale ma anche per quelle potrebbero essere i suoi futuri arricchimenti, come la sua predispodizione nativa per offrire uno strumento di supporto alle guide turistiche, o la sua eventuale e futura interazione con altre apps. 26

27 Bibliografia [1] [2] 27