Elaborato Capuozzo Bruno N46000061

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
A mia madre e a Roberta
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Perché Android.................................................................................................................. 6
1.1 Android e Java ........................................................................................................................... 6
1.2 Android vs iOS vs Windows phone ........................................................................................... 7
1.3 L’ evoluzione di Android ........................................................................................................... 8
1.4 Diffusione di Android nel mondo .............................................................................................. 9
Capitolo 2: Napp ................................................................................................................................ 11
2.1 Analisi dei requisiti .................................................................................................................. 11
2.2 Progettazione ............................................................................................................................ 12
2.2.1 Use case diagram .............................................................................................................. 12
2.2.2 Sequence Diagram ............................................................................................................ 13
2.2.3 Class Diagram ................................................................................................................... 15
2.2.4 Scelta della piattaforma e del database ............................................................................. 16
2.3 Implementazione ...................................................................................................................... 16
2.3.1 Fragment home ................................................................................................................. 19
2.3.2 Fragment musei ................................................................................................................. 20
2.3.3 Fragment eventi................................................................................................................. 20
2.3.4 Classe Chat ........................................................................................................................ 20
2.3.5 Classe Evento .................................................................................................................... 21
2.4 Le Activity ............................................................................................................................... 22
2.4.1 Activity Login ................................................................................................................... 23
2.4.2 Activity DescrizioneMuseo............................................................................................... 23
2.4.3 Activity ChatUtenti ........................................................................................................... 24
2.4.4 Activity VisualizzaEventi ................................................................................................. 24
2.4.5 Activity InserisciEvento .................................................................................................... 24
2.5 Struttura del database ............................................................................................................... 24
Conclusioni ........................................................................................................................................ 26
Bibliografia ........................................................................................................................................ 27
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
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
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
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
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
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 1000 €.
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
Figura n.2
10
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
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 domini come @gmail.com,
@hotmail.com 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.
2.2.1 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
Figura n.3
2.2.2 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
Figura n.4
Figura n.5
14
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
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
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 pagine
@Override
public int getCount() {
return NUM_ITEMS;
}
// Ritorno i fragment da visualizzare
@Override
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' indicatore
@Override
public CharSequence getPageTitle(int position) {
if(position==0)
return "Home";
if(position==1)
return "Musei";
if(position==2)
return "Eventi";
else return "Page " + position;
}
}
@Override
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
@Override
public boolean onCreateOptionsMenu(Menu menu) {
if(Login.mAuthData!=null){
getMenuInflater().inflate(R.menu.logout, menu);
}else {
getMenuInflater().inflate(R.menu.login, menu);
}
return true;
}
@Override
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 super.onOptionsItemSelected(item);
}
@Override
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
Figura n. 9
Figura n. 10
Figura n. 11
2.3.1 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
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 2.4.2.
2.3.3 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 2.4.4 e l’ altro all’ activity
InserisciEvento di cui al sottoparagrafo 2.4.5.
2.3.4 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 author;
@SuppressWarnings("unused")
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
}
}
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.
2.3.5 Classe Evento
Di seguito si riporta il codice relativo alla classe Evento funzionale alla creazione dell’
oggetto evento:
public class Evento {
private
private
private
private
private
String
String
String
String
String
nome;
luogo;
dataEvento;
prezzo;
ora;
@SuppressWarnings("unused")
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
2.4 Le Activity
Illustrati i vari fragment, analizzeremo ora le activity presenti in Napp.
Figura n.12
Figura n.13
Figura n.15
Figura n.14
Figura n.16
22
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 email 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 simbolo @
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. [email protected],
abiliterebbe l’ utente ad inserire, oltre che a leggere, gli eventi attraverso l’ activity
InserisciEvento la quale sarà discussa nel sottoparagrafo 2.4.5.
2.4.2 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
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.
2.4.4 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 email 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.
2.4.5 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
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. 17
25
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
Bibliografia
[1]
https://it.wikipedia.org/wiki/Android
[2]
http://tech.everyeye.it/articoli/speciale-android-ios-e-windows-phone-quanto-sono-
diffusi-27417.html
27