Folosirea Aplicatiilor Mobile In Industria Turismului

Informatica

Folosirea Aplicatiilor Mobile In Industria Turismului

Byadmin ianuarie 1, 2024

Cuprins

Introducere

Capitolul 1: Aplicații mobile

1.1 Dispozitivele mobile

1.2 Platformă

1.2.1 Web sau nativ

1.2.2 Platforme de dezvoltare a aplicațiilor mobile native

1.3 Limitările și provocările de dezvoltare mobilă

Capitolul 2: Aplicații mobile din domeniul turistic

2.1 Folosirea aplicațiilor mobile în industria turismului

2.2 Aplicații mobile din domeniul turistic

2.2.1 TripAdvisor

2.2.2 TripIt

2.2.3 TripCase

2.2.4 Travefy

2.2.5 Kayak

2.3 Arhitectura aplicațiilor mobile din domeniul turistic

2.3.1 Modelele folosite în aceste aplicații

2.3.2 Structura mediului de lansare a acestor aplicații

Capitolul 3: Travel Day, o aplicație mobilă pentru călătorii în grup

3.1 Noutăți aduse de către aplicație pentru industria turismului

3.2 Proiectarea aplicației

3.1.1 Arhitectura aplicației

3.1.2 Backend

3.1.3 Modele

3.3 Detalii de implementare

3.3.1 Sincronizare de date activă

3.3.2 Sincronizare de date manuală

3.3.3 Declanșatoare în baza de date

3.4 Modul de utilizare

3.4.1 Creare de cont și autentificare

3.4.2 Ecranul principal

3.4.3 Planificarea zilelor de călătorie

3.4.4 Vizualizarea zilelor de călătorie

3.4.5 Detaliile utilizatorului

Concluzii

Bibliografie

Lista figurilor

Numărul telefoanelor inteligente vândute în 2012 și 2013 grupate după producători, p. 18

Numărul telefoanelor inteligente vândute în 2012 și 2013 grupate după platforme, p. 20

Segmentarea platformei Android, p. 21

2.1 TripAdvisor, p. 26

2.2 TripIt, p. 27

2.3 TripCase, p. 27

2.4 Travefy, p. 28

2.5 Kayak, p. 28

2.6 Modelul conceptual al aplicațiilor din domeniul turistic, p. 32

2.7 Structura mediului de lansare, p. 33

3.1 Model-View-Controller, p. 36

3.2 Tabela de utilizatori, p. 38

3.3 Nivelul de model al aplicației Travel Day, p. 39

3.4 Notificări push, p. 40

3.5 Capabilitățile aplicației, p. 41

3.6 Setări pentru modul de fundal, p. 41

3.7 Tabela “Updates” din Parse, p. 43

3.8 Ecranul de autentificare și creare cont, p. 46

3.9 Ecranul principal, p. 47

3.10 Ecranul cu detalii despre obiective turistice, p. 47

3.11 Ecranul cu harta, p. 48

3.12 Ecranele cu planificarea zilei de călătorie, p. 49

3.13 Ecranul cu împărtășire, p. 49

3.14 Ecranele cu zilele de călătorie, p. 50

3.15 Ecranul cu detaliile profilului, p. 51

Lista acronimelor

GSM – Global System for Mobile Communications (Sistem Global pentru Comunicații Mobile)

PDA – Personal Digital Assistant (Asistent personal digital)

GPS – Global Positioning System (Sistem de poziționare globală)

IDE – Integrated Development Environment (Mediu integrat de dezvoltare)

PC – Personal computer (Calculator personal)

API – Aplication Programming Interface (Interfață pentru programarea de aplicații)

UML – Unified Modeling Language (Limbaj de modelare unificat)

HTTP / HTTPS – Hyper Text Transfer Protocol / HTTP Secure (Protocol de transfer hypertext / HTTP securizat)

SSL / TLS – Secure Socket Layer / Transport Layer Security (Nivelul de socket securizat / nivelul de transport securizat)

MBaaS – Mobile Backend as a Service (Serviciu de backend pentru mobile)

APNs – Apple Push Notification Service (Serviciul de notificări de tip push de la Apple)

SQL – Structured Query Language (Limbaj structurat de interogare)  

PL / SQL – Procedural Language / Structured Query Language (Limbaj procedural / limbaj structurat de interogare)

Introducere

Odată cu răspândirea telefoanelor inteligente, dezvoltarea aplicațiilor mobile a devenit esențială pentru industria software. Cele mai importante magazine online de aplicații mobile – Apple App Store și Google Play – au listat impreună peste un milion de aplicații. Pentru nenumărate firme a devenit mai mult a regulă decât excepție să aiba propria lor aplicație mobilă. Tehnologia telefonelor mobile se află în plină evoluție. Telefoanele inteligente devin tot mai perfomante cu fiecare an ce trece. Acesta duce la creșterea funcționalităților și a nevoilor pe care le poate satisface. Numărul abonaților și a numărul telefoanelor mobile vândute este în creștere constantă decând au apărut telefoanele inteligente.

Evoluția rapidă a ecosistemului mobil este facilitat și de lupta pentru cota de piață și profit ai mare a companiilor de platforme mobile native precum Google, Apple și Microsoft. Multe aplicații mobile se bazează pe conexiune de internet. Creșterea este asistat și de faptul că internetul a devenit tot mai rapid și crescut numărul spațiilor și zonelor publice care oferă conexiune Wi-Fi gratuit. Deși apar anual sute de mii de aplicații mobile acestea devin rapid învechite decă dezvoltatorul nu ține pasul cu noile tendințe al platformei pentru care a dezvoltat aplicația. Pe când pentru calculatoarele personale apar odată la 3-4 ani o nouă versiune a sistemului de operare, pe domeniul mobil companiile de platforme mobilă dezvoltă și pun pe piață o nouă versiune a sistemului de operare anual. Astfel, deși sunt peste un milion de aplicații listate este ușor de creat ceva nou în domeniu.

Aplicațiile mobile au devenit esențiale pentru toate industriile. Nu este o excepție nici industria turismului. Și acestă industrie a simțit o creștere rapidă în utilizarea de aplicații mobile. Piața s-a diversificat în ultimii ani și sunt disponibile pentru turiști aplicații mobile care oferă asistență pentru fiecare etapă a călătoriei. Diferențele sunt în principal legate de conținut, funcționalitate și platformele pentru care acestea sunt dezvoltate.

Cel mai important serviciu oferite de aplicațiile mobile din domeniul turistic este prezentarea detaliilor despre destinații turistice, despre obiectivele turistice. Aceste aplicații adesea oferă sugestii și sfaturi pe baza profilului și preferințele utilizatorului. Evidențiază rute turistice și pot ghida utilizatorul. Ghidarea pe care aceste aplicații o fac nu numai că sunt mai interactive, dar și mai fiabile. Informațiile derivate din opinia și experiența altor utilizatori sunt foarte căutate de turiști. Iar aplicațiile mobile, și tehnologia care se află în spatele lor, fac posibile ca aceste detalii să fie accesate de oriunde și oricând.

Lucrarea va prezenta o aplicații mobile care să faciliteze călătoriile de grup. Aplicația Travel Day se bazează pe alte aplicații din domeniul turistic, păstrând cele mai importante funcționalități, și extins cu funcționalități de caracter social. Obiectivul aplicației Travel Day, este de a prezenta utilizatorilor mai multe detalii despre destinațiile turistice, să permită utilizatorilor să creeze itinerare. Aceste itinerare se pot împărtăși cu prietenii. Ei la rândul lor pot modifica aceste itinerare, iar aceste modificări vor fi vizibile pentru toți din cercul de preieteni care folosesc aplicația.

Motivația în spatele lucrării a fost faptul că aveam nevoie de o aplicație similară, să organizăm o excursie cu prietenii, și nu am găsit nici o aplicație mobilă nativă similară. Momentan pe domeniul turistic nu există o aplicație mobilă nativă care să ajute călătoriile de grup. Să ofere asitență turistică și să aibă și un caracter social. M-am uitat la nenumărate aplicații, iar în cadrul lucrării o să scriu despre cele mai populare aplicații mobile turistice. Voi descrie funcționalitățile lor și voi prezenta lipsele pe care le au. Nici una din aplicațiile la care m-am uitat nu aveau funcționalități de care aveam nevoie eu. Astfel am decis să creez una eu.

Pentru a putea crea o aplicație mobilă, trebuie să ințelegem ecosistemul mobil și al aplicațiilor mobile, mai ales cel al aplicațiilor mobile. Trebuie analizate modelele conceptuale definite de industrie care sunt șablonate și se pot refolosii și alte aplicații mobile din domeniu. Analiza facută va fi prezentată pe parcursul acestei lucrări.

Astfel lucrarea va fi structurat în trei capitole. Primul capitol va conține o prezentare în ansamblu a telefoanelor mobile inteligente. Va prezenta o scurtă istorie a telefoanelor mobile, a platformelor pe care se pot dezvolta și va prezenta totodată și limitările impuse de mediul mobil. Al doilea capitol va prezenta aplicațiile din domeniul turistic, la ce sunt folosite acestea și care sunt cele mai importante funcționalități, după care voi prezenta cele mai importante aplicații din domeniul turistic, și voi prezenta arhitectura acestor aplicații. Al treilea capitol va conține detalii despre aplicația creată de mine. Voi prezenta funcționalitățile cele mai importane și noutățile aduse de acesta pentru industria turistică. Pe lânga asta voi scrie despre proiectarea aplicației, arhitectura, modelele și backendul aplicației, după care voi prezenta implementarea celor mai importante funcționalități. Iar la sfârșit voi prezenta modul de utilizare a aplicației.

Capitolul 1: Aplicații mobile

În acest capitol voi prezenta o imagine în ansamblu al ecosistemul dispozitivelor mobile. Ecosistem mobil definește o platformă comună care permite o gamă largă de dispozitive, cum ar fi telefoanele inteligente, tablete și laptop-uri să se integreze eficient unele cu altele pentru a împărtăși date.

O scurtă istorie a telefoanelor mobile va arăta viteza și ritmul alert în care tehnologia avansează. O viteză cu care uneori este foarte greu de ținut pasul. Creștera este facilitat atât de concurența mare de pe piață, cât și tendița oamenilor de a vrea să aibă toate informațiile în cel mai scurt timp la îndemână.

Tot în acest capitol o să scriu în generală despre platformele și sistemele de operare pentru telefoanele mobile, technologii folosite, limitările și provocările cu care se înfruntă programatorii dezvoltând aplicații pentru aceste dispozitive.

1.1 Dispozitivele mobile

Conceptul de ecosisteme mobile este unul relativ nou, dar ca orice dezvoltare tehnologică este supusă unor modificări enorme pe o perioadă scurtă de timp și impactul acesteia, în special asupra afacerilor, par a fi imens. Ecosistemul mobil constă din mai multe componente diferite, dar probabil cea mai recunoscută și importantă este telefonul mobil. Telefonul mobil este un dispozitiv electronic portabil care funcționează fără fir (prin radio) pe baza rețelei GSM.

Deși conceptul de telefonie mobilă a apărut deja în anii 1910, aceste telefoane adesea au fost instalate în automobile din cauza mărimii și greutății lor. Primul telefon adevărat portabil a apărut abia în 1973. De aici se înregistrează un salt uriaș. Primele telefoane mobile ofereau posibilitatea de inițieare și recepționare de apeluri telefonice. Însă în scurti timp, cu avansarea technologiei și miniturizarea continuă, tot mai multe funcționalități au fost adăugate. În anii ‘90 trimiterea mesajelor, crearea fotografiilor, accesarea fișierelor multimedia au devenit posibile cu includerea în aceste dispozitive ecranele color, procesoare mai performante și spațiu de stocare mai mare. Apar și primele aplicații care pot fi instalate pe telefoanele mobile, scrise în general sub platforma Java ME sau BREW. Iar în anul 2000 este lansat primul telefon cu sistemul de operare Symbian, care este considerat primul telefon inteligent.

Telefoanele inteligente la rândul lor pornesc o revoluție, ajungând ca în 2013 să domine piața mobilă cu o cotă de piață de 57.6% și aproape un miliard de dispozitive vândute pe parcursul unui singur an [1]. Aceste telefoane au un sistem de operare avansat, și combină funcționalitățile unui telefon mobil și alte dispozitive mobile, precum un PDA sau un sistem de navigare prin GPS.

Pe lângă telefoanele inteligente trebuie să menționăm și tabletele. Aceste dispozitive oferă același funcționalități ca un telefon inteligent, însă sunt echipate cu un ecran mai mare și scopul lor este redarea conținuturile multimedia. Deși tabletele sunt disponibile de ceva timp, acestea s-au răspândit recent, cu apariția iPad-urilor de la Apple. Astfel trebuie să luăm în considerare că “mobil” nu mai înseamnă doar telefon.

Tehnologia telefoniei mobile se află în plină evoluție. Care constă atât în creșterea numărului de abonați și de posesori deprocesoare mai performante și spațiu de stocare mai mare. Apar și primele aplicații care pot fi instalate pe telefoanele mobile, scrise în general sub platforma Java ME sau BREW. Iar în anul 2000 este lansat primul telefon cu sistemul de operare Symbian, care este considerat primul telefon inteligent.

Telefoanele inteligente la rândul lor pornesc o revoluție, ajungând ca în 2013 să domine piața mobilă cu o cotă de piață de 57.6% și aproape un miliard de dispozitive vândute pe parcursul unui singur an [1]. Aceste telefoane au un sistem de operare avansat, și combină funcționalitățile unui telefon mobil și alte dispozitive mobile, precum un PDA sau un sistem de navigare prin GPS.

Pe lângă telefoanele inteligente trebuie să menționăm și tabletele. Aceste dispozitive oferă același funcționalități ca un telefon inteligent, însă sunt echipate cu un ecran mai mare și scopul lor este redarea conținuturile multimedia. Deși tabletele sunt disponibile de ceva timp, acestea s-au răspândit recent, cu apariția iPad-urilor de la Apple. Astfel trebuie să luăm în considerare că “mobil” nu mai înseamnă doar telefon.

Tehnologia telefoniei mobile se află în plină evoluție. Care constă atât în creșterea numărului de abonați și de posesori de telefoane, cât și în creșterea numărului de servicii și opțiuni realizabile cu ajutorul telefonului. Ritmul alert în care se produc schimbările tehnologice și creștera pieței de telefonie mobilă face dificil planificarea și dezvoltarea strategică a unui proiect, nu numai din punc de vedere tehnic, ci și pentru că cota de piață a telefoanelor inteligente se schimbă rapid între diferite sisteme. Până de curând, Apple iOS domina piața de telefonie mobilă, dar Google Android l-a depășit pe acesta, ajungând în scurt timp să domine piața în proporție de peste 78% [1] datorită politicii sale de sursă deschisă. Alte sisteme de operare includ Windows 8 de la Microsoft, RIM OS de la Blackberry și Bada OS (mai nou Tizen) de la Samsung. Pe lângă nenumăratele platforme, există acum mai mulți producător de hardware decât oricând pe piața mobilă. Samsung, Apple, LG, Lenovo, Huawei și Nokia fiind liderii de piață (vezi figura 1.1). Fiecare oferind dispozitive cu sistemele de operarea menționate mai sus, și nu numai, constumizând acestea după cerințele lor specifice.

1.2 Platformă

1.2.1 Web sau nativ

Când vine vorba de platformă pentru dezvoltarea aplicațiilor mobile pentru telefoanele inteligente, primul lucru cu care se confruntă un programator este alegera dintre web și nativ (aplicațiile native sunt aplicații scrise în limbajul de programare specific platformei pentru care se dezvoltă). Crearea unei aplicații web optimizat pe accesare mobilă sau crearea unei aplicații specific unei platforme mobile? Există a serie de avantaje și dezavantaje pentru fiecare abordare.

Avantajele unei aplicații web constă în faptul că trebuie creat și optimizată doar o singură aplicație care este scrisă într-un limbaj de programare web, iar acesta va fi accesibil de pe mai multe sisteme de operare și mai multe dispozitive mobile. Astfel scade atât efortul și timpul de dezvoltare cât și cel de întreținere. Pentru mai multe platforme native, un programator va avea nevoie de abilități mai diversificate pentru dezvoltarea unei aplicații. În funcție de programator și de mărimea aplicației, de obicei un design receptiv durează mult mai puțin timp. Totodată nu există nici un fel de aprobare necesară pentru lansare, sau limitări și orientări care sunt impuse. În comparație cu Google Play, Apple App Store sau magazinul online pentru Windows Phone, care impune restricții pentru dezvoltatori, și conformitatea aplicațiilor sunt verificate cu strictețe înainte de publicația lor. În cazul în care scopul este de a crea o aplicație universală accesibil de pe orice dispozitiv, aplicația web este soluția.

Încă un avantaj este faptul că tehnologii web se potrivesc bine pentru tendințele actuale ale industriei de software mobile. Ciclurile de viață a aplicațiilor sunt scurte, dezvoltarea este rapidă și cerințele sunt schimbate des. Fiind un limbaj ușor și dinamic, JavaScript este conceput pentru asta. Nu este nevoie nici de SDK-uri grele sau de instrumente de dezvoltare: tot ce este nevoie pentru a începe dezvoltarea unui software web este un editor de text și un web browser. Construirea o interfaței de utilizator cu HTML este rapid și flexibil, și adăugarea funcționalitate cu JavaScript este simplă. Schimbarea și actualizarea aplicații web este de asemenea rapid comparativ cu o aplicație nativă care trebuie să fie recompilată și apoi încarcată din nou pe magazinele online de aplicații, unde trebuie să treacă tot timpul printr-o verificare.

O aplicație mobilă este conceput pentru o experiență unică, exclusiv pentru sistemul de operare în care trăiește. Access nativ la interfața cu utilizator crează un nivel de interacțiune care este dificil, dacă nu chiar imposibil, să se realizeze prin intermediul uni browser web. Pentru aplicațiile mobile pe web este mult mai simplu crearea paginilor simple, însă este mult mai greu pentru a proiecta tranziții și interacțiuni frumoase. Unele facilități oferite de hardware pot fi accesate doar de aplicațiile native, cum ar fi accelerometre, bluetooth, cameră sau GPS. Aplicațiile native oferă și o interfață mai ușor de utilizat, mai intuitiv pentru utilizator, la o viteză considerabil mai mare decât aplicațiile web. Unele elemente de interfață sau acțiuni sunt specifice platformelor, aplicațiile native pot fi ușor costumizate și pentru o platformă specifică. Pe langă posibilitatea de a utiliza mai multe dintre caracteristicile încorporate într-un dispozitiv mobil, o aplicație mobilă are adesea acces la mai multe date de la un utilizator și, prin urmare , poate oferi o experiență mai personalizată. Această personalizare prin date ar putea avea rolul de a oferi recomandări de produse, a sugeră conținut pentru vizualizare, să trimită notificări de tip push pentru a alerta utilizatorul când se produce un eveniment care l-ar putea interesa, sau alte acțiuni specifice care sunt determinate de utilizator. Când un utilizator crează un profil pe o aplicație, colectarea de date despre acea persoană și obiceiurile sale online devine mult mai ușor pentru o afacere. Iar folosind aceste date poate crea pentru utilizator un mediu mult mai interesant în cadrul aplicației.

Giganții piețelor de aplicații mobile sunt tot mai interesați de îmbunătățirea mediilor de dezvoltare și a șabloanelor de lucru, totul pentru a atrage de partea lor cât mai mulți dezvoltatori de aplicații mobile. Acesta este un lucru cât se poate de bun pentru un dezvoltator care poate profita de unelte gratuite menite să facă implementarea aplicației cât mai rapidă, câștigând mai mult timp pentru investirea în idei noi sau finisarea produsului.

“Majoritatea brand-urilor mari din lumea aplicațiilor sociale (Facebook, Twitter, Linkedin, etc.) și-au dat seama de puterea aplicațiilor native de a atrage utilizatori și au ales să meargă pe această nișă” [2].

86% din utilizatorii de telefonie mobilă preferă aplicațiile față de browser-ul [3]. Cu un motiv bun. Experiența nativ este superior mult superioară față de cea web. Și în cele mai multe cazuri merită depus efortul pentru a crea o aplicație de calitate.

1.2.2 Platforme de dezvoltare a aplicațiilor mobile native

Momentant în ecosistemul mobil sunt trei mai concurenți, Apple, Google și Microsoft. Concurența intensă de pe piața software mobil facilitează o schimbare în fiecare dintre platforme. Windows Mobile a fost înlocuit de Windows 7, care a devenit acum Windows 8. Atât sistemul de operare iOS de la Apple cât și Android de la Google au avut modificări semnificate cu fiecare lansare.

Android este una din cele mai populare platforme mobile (vezi figura 1.2). Creat în 2003, și cumpărat în 2005 de Google, sistemul de operare a fost lansat în 2008. Este un sistem de operare bazat pe kernel Linux și dezvoltat de Google. Cu o interfață de utilizator bazat pe manipularea directă, Android este destinat în primul rând pentru dispozitive mobile cu ecran tactil, cum ar fi telefoanele inteligente sau tablete, dar oferă interfețe specializate de utilizator pentru televizoare (Android TV), autoturisme (Android Auto), și ceasuri de mână (Android Wear). În ciuda faptului că este destinat în primul rând pentru dispozitive care se folosesc de intrări prin atingere, Android este folosit și în console de jocuri, camere digitale, calculatoare și alte electronice. Dat fiind popularitatea, am putea considera că mediul de dezvoltare este una din cele mai bune. Dar din cauza vitezei de dezvoltare și adoptare al acestuia, mediul de dezvoltare Android Studio, bazat pe IntelliJ IDEA, nu este încă la nivelul competiției.

Serviciile precum Google Drive, Google Play și restul suitei de aplicații Google, inclusiv YouTube și Google Maps, sunt constante pe diferitele dispozitive, există problema de fragmentare. Versiunile multe răspândite pe piața, precum Lollipop, Jelly Bean, Ice Cream Sandwich, Gingerbread, și diferențe mari între aceste versiuni, creaza o confuzie atât pentru dezvoltatori cât și pentru clienți. După lansarea unei noi versiuni, constumizarea acesteia de către diferitele producători de telefoane poate dura mai multe luni. Crearea aplicațiilor care să ruleze pe diferitele versiuni crește complexitatea acestora. Cu toate astea, IDE-ul poate fi rulat atât pe Windows, cât și pe Linux și Mac OS. Principalul limbaj de programare pentru Android este Java, un limbaj de programare cunoscut și iubit de mulți. Și asta atrage mulți dezvoltatori. Android este un sistem de operare cu sursă deschisă și oferă multe unelte care nu sunt disponibile pe platformele oferite de competiție.

iOS este a doilea cel mai popular sistem de operare, creat și menținut de Apple Inc., și este distribuit exclusiv pe dispozitivele mobile produse de Apple. Lansat în 2007 pentru iPhone, a fost extins pentru a suporta iPod-ul în 2007, iPad în 2010, iPad Mini în 2012 și a doua generație de Apple TV in 2010, și Apple Watch în 2014. Apple a fost unul dintre primii producatori care a adus împreună toate dispozitivele sale, unificând platformele cu ajutorul serviciilor oferite de acesta, precum iCloud, serviciul de stocare în cloud. Deoarece Apple produce atât hardware-ul cât și software-ul experiența utilizatorului pe toate dispozitivele sunt foarte asemănătoare. Versiuni majore ale iOS-ului sunt lansate anual, și devine accesibil instant pe toate dispozitivele. IDE-ul principal este Xcode, care poate fi rulat doar sub Mac OS, pe un calculator de tip Mac. Astfel tot ecosistemul de Apple este unul închis, fiind nevoie în întregime de sistemele lor ca un programator să poată crea aplicații mobile.

Xcode include un editor de cod sursă, un editor de interfață grafică, precum și alte unelte de test și de analiză. SDK-ul de iOS extinde Xcode-ul cu unelte, compilator și alte framework-uri care sunt necesare pentru dezvoltare software pentru iOS. Inițial limbajul de programare era Objectiv C, este construit peste limbajului de programare C, înmprumutând noțiuni din limbajul de programare Smalltalk și oferă capabilități orientate-obiect și o execuție dinamică. În schimb sintaxa limbajului este diferit de C, și mulți programatori erau reticenți în a învăța limbajul. Astfel Apple a lansat în 2014 un nou limbaj de programare, Swift. Acesta oferă o sintaxă mai accesibilă, și un compilator optimizat mult mai bine. Acum dezvoltatorii web care fac tranziția către aplicațiile mobile native pot folosi un limbaj de programare care are o sintaxă asemănătoare a Javascript-ului. Este un limbaj modern, simplu și sigur, iar citirea codului este mul mai ușoară. Programele scrise în Swift sunt mai rapide, administrarea memoriei este mult mai bună pe dispozitivele mobile oferite de Apple.

Windows Phone, creat de Microsoft, este succesorul sistemului de operare Windows Mobile, și a fost lansat ca și Windows Phone 7 în 2010. Spre deosebire de Windows Mobile, acesta vizează în primul rând pe piața de consum, și pe piața întreprinderilor. Acesta prezintă o interfață de utilizator derivat din stilul de design Metro. Recepția interfața în ansamblu fost apreciat pentru stilul de mulți critici. Cu Windows 8, lansat în 2014, Microsoft a dezvoltat o platformă care unește o gamă largă de dispozitive cu aceeași interfață de utilizator. Noul sistem de operare încearcă să ofere același experiență pentru utilizator pe fiecare dispozitiv, și oferă o navigare transparentă de la un dispozitiv la altul. Programele funcționează la fel, indiferent dacă sunt accesate prin intermediul unui telefon inteligent, tabletă sau calculatoarele personale. În 2011 Microsoft Phone a devenit principalul sistem de operare pentru telefoanele Nokia, înlocuind Symbian-ul.

Însă nici schimbările de politică, nici crearea unei interfețe plăcute și nici susținerea oferită de Nokia nu a fost de ajuns să trimită Microsoft-ul pe primul loc în concureța de pe piața mobilă. Acesta aflânduse pe locul trei, după Google și Apple. Pentru a crește numărul aplicațiilor lansate, în 2015 au lansat o platformă prin care dezvoltatorii pot convertii aplicațiile mobile de pe Android și iOS pe Window Phone cu ușurință. Tot pentru asta Microsoft menține și o pagină web unde utilizatorii pot scrie și vota idei care să fie incluse în următoarele versiuni ale sistemului de operare. Principalele limbaje de programare care se pot folosi pentru a crea aplicații pentru dispozitivele lor mobile sunt C# / Basic.Net (.Net) și C++. Aplicațiile pentru Windows Phone trebuie create și testate în IDE-ul oferit de Microsft, Visual Studio sau Visual Studio Express. Inainte ca o aplicație să fie lansată în Windows Phone Store, acesta trebuie supus unei verificări facute de Microsoft.

1.3 Limitările și provocările de dezvoltare mobilă

Deși tehnologia mobilă se îmbunătățește, crearea unei bune experiențe pentru utilizatorul telefoanelor mobile rămâne o provocare serioasă. Acesta este cauzat de existența mai multor limitări în mediul mobil.

Cea mai importantă limitare în telefoanelor mobile este dimensiunea ecranului mic. În trecut dimensiunile ecranului în diagonală rar treceau peste 3.5 in, mai recent acestea au ajuns la 5-6 in, care încă sunt mult sub 15 in cu care ne-am obișnuit pe un laptop sau chiar mai mult pe un calculator personal. Ecranele mai mici înseamnă că mai puține opțiuni sunt vizibile pe ecranele mobilelor, nu mai este loc de meniurile de navigare cu care ne-am obișnuit pe calculatoarele personale. Soluțiile pentru asta include folosirea unui font creat pentru a fi lizibil pe ecranele mici a telefonului, cum este Verdana sau Helvetica, păstrarea unei spații cât mai mici în marginile paginilor, pentru maximiza locul pentru conținut. Ajută și folosirea gesturilor pentru navigare suportate de sistemul de operare. Introducerea textului pe ecranele mici ii mult mai greu decât pe un calculator, astfel minizarea intrărilor de tip text este necesară.

O altă limitare este accesul la internet, și viteze acesteia. Deși conexiunea la internet pe mobile este din ce în ce mai rapid, acesta încă nu este nici atât de rapidă și nici atât de sigur ca și prin cablu. Astfel conținuturile care se afișează des și sunt încărcate, trebuie persistate local. Trebuie luat în calcul că anumite cereri s-ar putea să nu ajungă la destinație din cauza lipsei de semnal, sau acestea să dureze mult prea mult, astfel trebuie pus la punct un sistem robust de manipulare a erorilor într-o aplicație mobilă.

Iar cum am prezentat și mai sus, unul din cele mai mari provocări sunt cauzate de fragmentarea pieței mobile. Există pe piață o multitudine de telefoane mobile, cu diferite siteme de operare, cu viteză de procesare diferită, marimi de ecran care diferă în mărimi, rezoluție și în raportul între înălțime și lățime. Este nevoie de crearea unei interfețe cu utilizatorul care se poate adapta fără probleme la diferitele mărimi. Iar alegera sistemului de multe ori nu depinde de preferința creatorului, ci de preferința clientului. Înainte de lansare este greu de estimat că publicul vizat ce platformă preferă. Studii de piață sunt necesare în domeniul aplicațiilor mobile pentru a minimiza rescurilor de a alege o platformă specifică. Dezvoltarea unei aplicații mobile pe toate platformele poate fi costisitor.

Astfel putem conclude că, deși sunt multe limitări și provocări în dezvoltare pe platforme mobile, situația nu este chiar așa de rea. Există soluții pentru astea, iar cercetare și documentare este necesar pentru a crea o aplicație care să se potrivească nevoilor curente și viitoare.

Capitolul 2: Aplicații mobile din domeniul turistic

În acest capitol o să prezint cele mai importante aplicații mobile din domeniul turistic, tendințele, beneficiile acestora. O să prezint caracteristicile și funcționalitățile celor mai folosite și celor mai reprezentative aplicații din acest domeniu. Aceste aplicații s-au remarcat și prin arhitectura bine construită care a permis readaptarea și adăugarea funcționalităților de a lungul anilor.

În același timp voi prezenta și structura modelelor conceptuale și o arhitectură generală a acestor aplicații. Definirea modelelor este un pas important în dezvoltarea software. Aceste modele conceptuale ajută în reprezentarea entităților a unei industrii și în definirea relațiilor între aceste entități. Modelele conceptuale definite de o industrie sunt șabloane care se pot refolosii în aplicațiile mobile din domeniu. Astfel de șabloane se regăsesc și în industria turistică. Acestea sunt deja folosite în aplicațiile mobile. Analiza acestor modele conceptuale ajută nu numai la crearea aplicației mele dar și la orice aplicație de turism.

2.1 Folosirea aplicațiilor mobile în industria turismului

La fel ca în alte industrii, și sectorul turismului a simțit o creștere rapidă în utilizarea de aplicații mobile. Potențialul și caracteristicile telefoanel inteligente, precum accesul la internet și geo-localizare, l-au transformat pe acesta în cele mai folosite dispozitive mobile în turism. A crescut numărul spațiilor și zonelor publice care oferă conexiune Wi-Fi gratuit. De asemenea au scăzut și tarifele în roaming, permițând astfel turiștilor să se conecteze la internet indiferen de țara în care se află. Aceste lucruri au ajutat ca aceste tipuri de aplicații să devină populari și de folos pentru turiști.

Pentru orice tip de afacere o aplicație mobilă poate ajută în obținerea și păstrarea clienților. Primul loc unde un client caută un produs sau servicie este online. Dacă o afacere este disponibil online și în plus are și o aplicație care utilizatorii pot descărca pe dispozitivele lor, afacerea va face o impresie bună. Avantajele pe care o aplicație mobilă oferă pentru o afacere este consolidarea brandului, îmbunătățirea vizibilității, creșterea accesibilității, conectarea mai bună cu consumatorii, și creștera vânzărilor prin expunere mai largă.

Acceste servicii aduc valoare semnificativă pentru orice companie din această industrie. Companiile turistice care sunt în stare să creeze aplicații pe placul utilizatorilor pot ajunge într-o poziție avantajoasă. De asemenea folosirea noilor tehnologii ajută companiile să ajungă la clienți mai ușor și mai eficient. Rețelele sociale au devenit instrumente fundamentale pentru industria turismului.

2.2 Aplicații mobile din domeniul turistic

2.2.1 TripAdvisor

TripAdvisor (vezi figura 2.1) este una din cele mai populare aplicații de călătorie la ora actuală. Platforma web a fost lansat în 2000, mai tarziu au apărut și aplicațiile mobile native pentru iOS, Android și Windows Phone. Este o aplicație care oferă detalii despre destinațiile turistice. Are cea mai mare bază de date generat de utilizatori cu detali, recenzii, poze create de acestia. Potrivit datelor emise pe pagina lor web, au peste 225 de milioane de recenzii și opinii de la călători din întreaga lume. Au listat peste 4.9 milioane de afaceri care includ restaurante, hoteluri și atracții [5]. În 2014 a primit premiul pentru cea mai bună aplicație mobilă de la Eye for Travel în cadrul Invoation Awards (trad. prop. Premiul pentru inovații).

Aplicație ajută în a plănui o excursie de la început. Deși nu centralizeaza date legat de voiaj ca și alte aplicații, nu oferă funcționalități unde putem salva orele de zbor, sau hotelul rezervat, acesta oferă ajutor în a găsi un loc de cazare potrivit, destinațiile care merită vizitate pe baza recenziilor. Are integrat și servicii externe pentru rezervarea hotelului (servicii oferite de rezervări hotel oferit de booking.com) și pentru rezervarea zborului (servicii oferite de Expedia). Se poate crea și un itinerar de călătorie, dar aceasta funcționalitate nu este scos în evidență. Itinerarele de călătorie, destinațiile alese se pot împărtășii prin rețelele sociale Facebook sau Twitter. Însă nu are funcționalități de călătorii în grup. Itinerarele create nu pot fi modificate de alții. Prietenii interesați nu pot exprima părerea lor prin cadrul aplicației.

Până în primul sfert al anului 2015 aplicația mobilă a fost descărcate de peste 190 milioane de călători. Aproape dublându-se într-un singur an. În prima parte a anului 2014 acesta a fost la doar 100 milioane. La ora actuală aproape jumătate din trafic provine de pe dispozitive mobile. [5]

2.2.2 TripIt

O altă aplicație mobilă populară din domeniul turistic în care se pot organiza cu ușurință informațiile de călătorie din mai multe surse. Tripit (vezi figura 2.2) a fost lansat în 2006 tot pe platformă web, după care a urmat lansarea pe iOS, Android, Windows Phone și chiar și pe Rim OS și au peste 5 milioane de utilizatori activi.

Funcționalitatea prinicipală a lui este crearea de itinerare. Prin aceste itinerare oferă posibilitatea de a salva toate informațiile pentru călătorie. Se poate salva detaliile biletelor de avion, rezervarari de hotel, închiriere auto. Este o aplicație care centralizează toate datele. Nu mai este necesar pentru a memora număruri de confirmare, numărul avionului, orele de zbor sau de check-in la hotel. Au și o versiune PRO care, contra cost și pe lângă alte funcționalități, va urmării rezervările de bilete, și ne va anunța în caz de schimbări în programul de zbor. Deși se pot introduce și destinații turistice și aplicația va arata locația lui pe harta, nu oferă sugestii de destinații, nu oferă informații (descrieri, poze) despre obiectivele turistice. Se integrează cu rețelel sociale, itinerarul poate fi împărtășit pe aceste rețele, însă nu are funcționalități care să ajute pentru o călătorie în grup. Prietenii cu care călătorim nu pot adăuga sau modifica itinerarul creat de noi. Chiar dacă se călătorește în grup, un itinerare creat în aplicație conține detaliile doar pentru un singur călător.

TripIt oferă o platformă deschisă pentru integrarea și organizarea informațiilor de călătorie din mai multe surse diferite printr-un API public. Astfel orice aplicație poate intgra sau folosi cu ușurință funcționalitățile de baza a aplicației.

2.2.3 TripCase

TripCase (vezi figura 2.3) este o aplicație mobilă, lansat în 2009 direct pe platformele mobile iOS și Android. Conform paginii lor de web: „din prima zi, obiectivul nostru a fost de a oferi călătorilor un mod simplu de a gestiona tot ce au nevoie pentru călătorie, de oriunde și oricând” [6]. La fel ca TripIt, TripCase este un serviciu/aplicație care încearcă centralizarea a tuturor documentelor și datelor de călătorie.

Se poate introduce pe dispozitivul mobil toate datele despre zbor, tren, hotel, iar TripCase il organizeaza intr-un itinerar care poate fi vizualizat în ordine cronologică arătând pas cu pas detalii, timpul și locațiile pe hartă. Însă ca și în TripIt, nu oferă informații despre destinația turistică, despre obiectivele turistice. Nu oferă nici un ajutor pentru cei care călătoresc în grup. Nu au nici integrare cu rețelele sociale, astfel călătoria planificată poate fi vizualizat doar de cel care l-a creat.

TripCase a fost printre primele aplicații să extindă suportul pe iOS Watch și ii printre puținele aplicații din domeniul turistic care oferă suport pentru ceasuri inteligente. În 2015 a primit premiul pentru cea mai bună aplicație mobilă din domeniul turistic de la Eye for Travel în cadrul Invoation Awards (trad. prop. Premiul pentru inovații). Până în 2015 peste 30 de milioane de itinerare au fost create cu ajutorul aplicației. [6]

2.2.4 Travefy

Travefy (vezi figura 2.4) este o aplicație web optimizat pe mobile. Nu au aplicație mobilă nativă. A fost lansat în 2012. Este un start-up relativ nou, care în scurt timp a reușit să strângă 2.2 milioane de dolari de la investitori conform CrunchBase.

Este o aplicație creată pentru călătorii în grup. Prin intermediul aplicației utilizatorii care călătoresc împreună poate crea itinerar, pot colabora prin planificarea călătoriei, pot lăsa mesaje, notițe unul la celălalt, pot începe discuții. Tot în cadrul aplicației turiștii pot adăuga costurile/cheltuielile pentru fiecare zi din excursie, sau pentru fiecare punct din itinerar, și pot stabilii cine cât trebuie să contribuie. Itinerarul creat poate fi împărtășit în grup. Toată lumea poate edita, adăuga obiective turistice sau cheltuieli, care apoi sunt vizibile pentru toată lumea.

Deși nu oferă detalii despre locațiile alese și toate locațiile trebuie adaugate manual, au integrat serviciile de Foursquare care oferă recomandări pentru destinațiile turistice. Interfața și experiența utilizatorului necesită îmbunătățiri. Unele funcționalități sunt greu de găsit. La calculul de cheltuieli nu acceptă mai multe tipuri de valută și nu oferă convertor valutar. Funcționalitatea de căutare este uneori lentă.

2.2.5 Kayak

Kayak (vezi figura 2.5) este o aplicație mobilă ajută la rezervări de hotel, bilet de avion sau închirieri de mașină. A fost lansat în 2004 în Statele Unite și extins pe piața globală în 2010. Inițial a fost lansat ca și platformă web, lansând aplicațiile mobile pentru iOS și Android doar în 2012. În 2013 Travel + Leisure a numit aplicația Kayak ca cea mai bună aplicație pentru călătorii de afaceri.

Aplicația funcționează ca și un motor de căutare, care permite căutarea de cazare, bilete de avion sau închirieri de mașină. Oferă foarte bune filtre care să ajute la căutare și agregă informațiile de pe mai multe servicii. Se poate face comparări de prețuri de pe diferite alte pagini, astfel ajutând în a alege cele mai bune oferte. În afară de căutarea celor mai bune prețuri nu oferă alte servicii care să ajute la planificarea călătoriei.

Nu au detalii despre obiective turistice, și nu au funcționalități pentru călătorii în grup. Deși este integrat cu rețele sociale, se pot împărtăși doar ofertele gasite prin cadrul aplicației. Opțiunile de rezervări sunt limitate sau chiar nu se pot face în cadrul paginii web sau a aplicației, în general trimite utilizatorul către altă aplicație sau pagină web unde se poate face rezervarea și cumpărarea. Include doar hoteluri și nu include metode alternative de cazare, precum Airbnb.

2.3 Arhitectura aplicațiilor mobile din domeniul turistic

2.3.1 Modelele folosite în aceste aplicații

Scopul modelele conceptuale este de a exprimă semnificația termenilor și a conceptelor utilizate de către experți în domeniu. Acestea expune relațiile între diferitele concepte. Modelele conceptuale încearcă să clarifice semnificația diferitelor termeni, de obicei, ambiguu, fără să lase loc interpretării diferite pentru o anume problemă. Astfel de interpretări contradictorii ar putea cauza cu ușurință confuzie între părțile interesate, în special a celor responsabili pentru proiectare și implementarea unei soluții. Odată ce conceptele de domenii au fost modelate, modelele devine o bază stabilă pentru dezvoltarea aplicațiilor în domeniu. Conceptele ale modelului pot fi transcrise în design fizic într-o aplicație. Acestea pot fi descrise folosind diferite notații, cum ar fi UML. În notație UML, modelul conceptual este adesea descris cu o diagramă de clase în care clasele reprezintă conceptele, asociațiile reprezintă relațiile dintre concepte și tipurile rolul unei asociații reprezintă tipuri de roluri care pot fi luate de instanțe ale conceptelor modelate în diferite situații.

Martin Fowler, inginer software britanic specializat în proiectare orientată obiect spune că: „Un principiu important în dezvoltarea orientată obiect este proiectarea programlui în așa fel încât structura reflectă cea a problemei” [7]. El și-a dat seama că alegerea modelelor este una din lucrurile elementare în dezvoltarea software. Modelele alese afectează flexibilitatea și reutilizarea sistemului creat. „Inginerii software trebuie să găsească un compromis între costul de construcție și costul de întreținere a unui sistem. Pentru a construi o aplicație care să fie apt pentru un scop trebuie dezvoltat un model conceptual care să se potrivească cerințelor și să modeleze problemele pentru care se caută soluții. Pentru asta avem nevoie de cele mai simple modele posibile. Și nu este necesar adăugarea flexibilitatății, pe care cel mai probabil nu o sa folosim. Cel mai simplu model nu este neapărat prima la care ne gândim. Găsirea soluțiilor simple necesită timp și efort, care poate fi uneori frustrant. […] Dar găsirea modelelor simple intotdeauna merită efortul. Nu numai că fac lucrurile mai ușor de construit, dar mai important decât acesta, reduc efortul de întreținere și efortul de a extinde” [7].

Christopher Alexander, un profesor de architectură de la Universitatea Berkeley din California, a fost printre primele care a descoperit existența și utilitatea șabloanelor în dezvoltare software. Alexander a dezvoltat o serie de teorii despre modelele de arhitectura, și a catalogat mai multe tipuri de șabloane în cartea lui. Aceste șabloane nu numai că ajută în scăderea necesară a timpului de dezvoltare, dar ajută și la crearea unei arhitecturi mai robuste, mai eficiente și mai corecte. [8] Martin Fowler la rândul lui, a dus idea mai departe, și a demonstrat existența șabloanelor și la nivelul de modele în cartea sa intitulat „Analysis Patterns, Reusable Object Models” (trad. prop. Analiza șabloanelor, modele de obiecte care se pot refolosi). El crede că folosirea acestor șabloane nu numai că este utilă, este și absolut necesară, deoarece acestea modelează cu acuratețe problemele întâlnite în acest domeniu, oferind a soluție bună la aceste probleme. Însă recunoaște că o problema ar putea avea mai multe soluții. Astfel unele probleme pot fi reprezentate cu diferite modele conceptuale [7].

Analizând cererile și răspunsurile trimise și primite de către aplicațiile mobile putem să ne dăm seama de structura modelelor folosite de acesta. Aplicațiile dintr-un domeniu de obicei au o structură asemănătoare. Determinarea structurii modelelor a aplicațiilor mobile din domeniul turistic poate să ne ajută la crearea aplicației proprii. Cererile și răspunsurile pot fi interceptate cu ajutorul unui server proxy. Un server proxy este un server (un sistem informatic sau o aplicație), care acționează ca un intermediar pentru cereri de la clienți care doresc resurse de la alte servere. Un client se conectează la serverul proxy, solicitând unele servicii, cum ar fi un fișier, conexiune, pagină web, sau alte resurse disponibile de la un alt server și serverul proxy evaluează cererea ca o modalitate de a simplifica și de a controla complexitatea sa.

O aplicație care poate servi ca un server proxy este Burp Suite. Aplicația pe care am folosit ca și client este TripAdvisor, care este cea mai populară aplicație mobilă din domeniul turistic. Astfel am setat ca aplicația să se conecteze la serverul proxy creat de Burp Suite și să trimită toate cererile acolo. Burp Suite a recepționat cererile care au trecut prin el, afișândule pentru a analiza acestea. Prin analiza acestora putem să ne dăm seama de structura modelelor conceptuale a aplicațiilor mobile din industria turistică.

Aplicația TripAdvisor returnează datele pe răspuns în JSON-uri. JSON este un format de tip text structurat, care este folosit pentru a trimite date pe rețea. În continuare voi prezenta câteva din răspunsuri primite de la server pentru aplicație care ne va ajuta crearea modelului conceptual. Pentru a putea crea modelul conceptual avem nevoie doar de cheile din acest JSON, iar din motive de securitate a datelor, valorile returnate au fost șterse în următoarele răspunsuri.

La autentificare în aplicația TripAdvisor, se face o cerere pentru a obține datele utilizatorului, ca și răspuns, primim următorul JSON:

"user": {

"user_id": ,

"name": ,

"member_id": ,

"private_info": ,

"gender": ,

"age": ,

"username": ,

"user_location": ,

"avatar": ,

"link": ,

"created_time": ,

}

De aici putem să ne dăm seama că este vorba de un obiect de tip “User” (trad. “Utilizator”), care are mai multe date precum un număr de identificare unic, nume de utilizator, data creări contului, vârstă și chiar și locația lui actuală. Locația lui este defapt un alt model pe care putem vedea mai jos.

Obiecte de “Location” (trad. “locații”) se obțin atunci când în aplicație se încarcă locația actuală a utilizatorului, locațiile preferate de acesta sau când se caută locațiile incluse în aplicație. Mai jos avem un răspuns pentru a obține locațiile preferate:

[{

"location_id": ,

"name": ,

"latitude": ,

"longitude": ,

"num_reviews": ,

"timezone": ,

"photo": ,

"awards": ,

"description": ,

"web_url": ,

"ancestors”: ,

"category”: ,

"subcategory”: ,

"parent_display_name":

},…]

Cum putem vedea și obiectul de locație are un număd de identificare unic, mai are un nume, imagine, categorie, etc. Vedem că are și coordonatele (longitudine și latitudine) locației care pot forma ele în sine un obiect model pe care putem numii „Coordinates”. Câmpul de „ancestors” (trad. „strămoși”) mai este interesant, deoarece acestea conține alte obiecte de tip locație, însă au categoria și subcategoria diferită. Astfel putem identifica mai multe modele care moștenesc din obiectul „Location” și acestea: „City” (trad. „Oraș), „Region” (trad. „Regiune”), „Country” (trad. „Țară”).

Următorul model important pe care îl întâlnim este una numită „Business” (trad. „Activitate”). Activitățile le putem vedea pe răspunsul primit pe cerera de căutare de activități pentru un anumit oraș. JSON-ul primit ca și răspuns arată așa:

[{

"location_id": ,

"name": ,

"latitude": ,

"longitude": ,

"num_reviews": ,

"timezone": ,

"photo:,

"api_detail_url": ,

"awards": ,

"ranking_geo": ,

"ranking_geo_id": ,

"ranking_position": ,

"ranking_denominator": ,

"ranking_category": ,

"ranking": ,

"rating": ,

"price_level": ,

"price": ,

"special_offers": ,

"category":

},…]

Și modelul „Business” poate fi de mai multe feluri, definit de categoria sa, astfel putem să diferențiăm „Hotel”, „Restaurant” și „Attraction”. Acestea aum ca și celălalte înainte, un număr unic de identificare, un nume, imagine, coordonate, și pe lângă asta pot avea și preț și oferte speciale. Acest obiect se leagă de un obiect de tip “Location” prin câmpul “ranking_geo_id” care conține numărul de identificare a unei “City” sau “Region”, simbolizând locația acestuia.

Putem identifica și alte modele, de exemplu “Awards” (trad. “Premii”) care face parte din obiectul “Business” și arată în felul următor în format JSON:

[{

"award_type": ,

"year": ,

"images": ,

"categories": ,

"display_name":

}, …]

sau cel de „Review” (trad. „Recenzie”), însă aceste obiecte sunt specifice businessului promovat de aplicația TripAdvisor și nu se regăsesc în alte aplicații din domeniul turistic.

Din datele menționate mai sus, se poate construi modelul conceptual al aplicațiilor mobile din domeniul turistic, acesta se poate vedea în figura 2.6.

2.3.2 Structura mediului de lansare a acestor aplicații

Aplicațiile mobile din domeniul turistic nu numai că au structura modelelor conceptiale asemănătoare dar și structura mediului de lansare este asemănătoare. Astfel, cum putem observa și în figura 2.7, putem delimita clar partea de client și cea de backend la aplicațiile mobile din acest domeniu.

Partea de client reprezintă telefonul mobil. Iar pe partea de client regăsim aplicația în sine. Regăsim aici și o bază de date locală, în care sunt salvate datele utilizatorului, și datele care sunt refolosite des. Datele care sunt refolosite des sunt salvate local în telefon astfel scade efortul și timpul necesar obținerii acestor date prin internet de la un server. Tot aici avem și serviciile oferite de hardware-ul telefonului. Servicii precum GPS-ul este folosit des în aplicațiile turistice pentru a localiza utilizator și pentru a cere de la server date mai relevante pentru utilizator, în funcție de locația acestuia.

Partea de backend include atât serverul folosit și baza de date efectivă, cât și alte servicii web. Serverul oferă acces la datele stocate în baza de date. Face posibil conectarea și deservirea mai multor clienți deodată. Servicii des întâlnite în aplicațiile din domeniul turistic include de exemplu Google Maps API, un API public pentru afișa hărți, geo-localizare, transformarea coordonatelor în nume de străzi, orașe etc, și pentru navigare.

Aplicațiile mobile cominucă cu serverul de obicei prin cereri și răspunsuri HTTP sau HTTPS. HTTP este metoda cea mai des utilizată pentru accesarea informațiilor în Internet care sunt păstrate pe servere World Wide Web. Protocolul HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. HTTPS reprezintă protocolul HTTP încapsulat într-un flux SSL/TLS cu scopul de a se oferi o identificare criptată și sigură la server.

Capitolul 3: Travel Day, o aplicație mobilă pentru călătorii în grup

În acest capitol voi prezenta partea aplicativă a lucrării. Travel Day, este o aplicație mobilă pentru iOS pe care l-am scris în limbajul Swift. În crearea aplicației m-am bazat pe alte aplicații din domeniul turistic. Am păstrât funcționalitățile cele mai importante din acestea, și apoi am extins cu funcționalități care nu există încă în aplicații mobile din domeniu.

Momentan pe domeniul turistic nu există o aplicație mobilă nativă care să ajute călătoriile de grup. Să ofere asitență turistică și să aibă și un caracter social. Deși Travefy (prezentat în subcapitolul 2.2.4) încearcă acest lucru, ei nu au o aplicație mobilă nativă și nu oferă nici detalii despre obiectivele turistice. În cadrul aplicației Travel Day, pe lângă faptul că utilizatorii pot afla mai multe detalii despre destinațiile turistice, pot crea itinerare, pot folosi hartă inclusă în aplicație, ei pot și să impărtășească aceste itinerare cu prietenii. Ei la rândul lor pot modifica aceste itinerare împărtășite iar aceste modificări vor fi vizibile pentru toți care folosesc aplcația și au acces la itinerar.

În următoarele subcapitole voi prezentate în detaliu funcționalitățile cele mai importante al aplicației Travel Day și o să prezint și noutăție aduse de acestă aplicația industrai turismului. O să prezint proiectarea aplicației, și câteva detalii de implementare a celor mai importante funcționalități. După care voi prezenta modul de utilizare al aplicației.

3.1 Noutăți aduse de către aplicație pentru industria turismului

Cu 85.5 milioane de utilizatori unice lunar a aplicației mobile de la Facebook, nu e de mirare că aplicațiile sociale sunt atăt de populare. Richard Branson, fondatorul Virgin Groups, a spus într-un intreview: „fie că sunteți la lansarea unui start-up sau sunteți lideri la o companie consacrată pe piață, trebuie să creați o prezență pe rețelel sociale” [9]. Eu cred că nu numai prezența pe rețelele sociale este importantă, ci este foarte important și crearea unei părți sociale direct în aplicație. Momentan în domeniul turistic sunt foarte puține aplicații mobile care încearcă asta. Și nu am gasit nici una care să fie axat pe turiștii care călătoresc în grup, prieteni care își planifica vacanța împreună, familii care crează planul de călătorie împreună. Acesta încearcă să remedieze aplicația Travel Day.

Travel Day este o aplicație mobilă creat pentru domeniul turistic. Aplicația are scopul de a ajuta planificarea excursiilor oferind asistență turistică. Utilizatorii pot accesa prin intermediul aplicației informații despre obiectivele turistice; pot vedea descriere, imagini, chiar și locația lor pe hartă. Ei pot definii zile de călătorie, pot aleage destinația călătoriei, data la care vor călătorii și pot adăuga la itinerar obiectivele pe care vor să le vizitieze. De asemena aceste zile de călătorie create vor putea fi vizualizate de către utilizatori ulterior, afișând pe toate într-o listă. Ei poat apoi edita sau șterge aceste itinerare. Totodată pot vedea ușor pe ecranul prinicpal dacă au ceva planificat în ziua curentă. Turiștii care folosesc aplicația pot folosi harta inclusă în aplicație pentru a naviga și a găsi mai ușor obiectivele turistice. Pe această hartă obiectivele sunt marcate vizual, și harta poate fi ușor accesibilă de pe ecranul principal în ziua în care a fost planificat călătoria.

Un lucru important este că după crearea unei zi de călătorie, detaliile acestea vor fi vizibile și în timpul călătoriei, chiar dacă nu are utilizatorul access la internet. Numai pentru autentificare în aplicație, creare de itinerare și modificarea acestor itinerarelor necesită internet, vizualizarea lor nu.

Pe lângă aceste funcționalități de bază, aplicația are și o parte socială, care ajută organizarea călătoriilor în grup. Acesta este factorul care diferențiază Travel Day de restul aplicațiilor mobile native care oferă asistență turistică. Ca și pe rețelel sociale, și în cadrul aplicației putem să ne adăugăm prieteni. Lista de prieteni este vizibil accesând profilul nostru. Putem vedea poza și numele lor. Pe urmă, după crearea unui itinerar sau o zi de călătorie, putem împărtășii aceste zile de călătorie cu ei. Astfel o să primească și ei acces la aceste zile de călătorie, pe care la rândul lor o pot vizualiza și edita. Editările făcute vor fi vizibile pentru toți din grupul de prieteni care au acces la itinerar. Prin aceste funcționalități aplicația devine una interactivă.

3.2 Proiectarea aplicației

3.1.1 Arhitectura aplicației

În arhitectura aplicației Travel Day voi folosi șablonul de Model-View-Controller. Conform documentației de la Apple, „Model-View-Controller este esențial pentru un design bun în aplicațiile Cocoa” [9]. Șablonul de design Model-View-Controller (MVC) asignează pentru obiecte unul din trei tipuri de roluli, astfel obiectul poate fi model, view sau controller. Șablonul definește nu numai rolul obiectelor din aplicație, dar și modul în care obiectele comunică între ele. Fiecare din cele trei tipuri de obiecte sunt separate de restul prin limite abstracte și comunicarea cu celelalte tipuri de obiecte sunt limitate de reguli. Colecția de obiecte dintr-un tip în MVC sunt numite nivele, de exemplu nivelul de model [10].

Obiectele de model încapsulează date specifice pentru aplicație și definesc logica și funcțiile care manipulează și porcesează datele. Un model poate avea relație de unu la unu sau unu la mai multe cu alte obiecte din acest nivel. Datele care sunt păstrate în aceste obiecte reprezintă starea persistentă a aplicației. Chiar dacă aceste date sunt salvate în fișier sau într-o bază de date, în momentul în care acestea sunt încărcate în aplicația, datele trebuie ținute în aceste obiecte de model. Deoarece modelele reprezintă cunoștințele și expertizele legate de un domeniu specific, aceste obiecte pot fi refolosite pentru probleme asemănătoare. În mod ideal, aceste obiecte nu ar trebui să aibă o conexiune co obiectele de view care prezintă datele în mod vizual pentru utilizatori. Nu ar trebui să se ocupe cu probleme de interfață și afișare. Acțiunile utilizatorului la nivelul de view care crează sau modifică date sunt comunicate la model prin intermediul obiectelor de tip controller. Dacă un obiect de tip model se modifică (de exemplu la date primite de pe server) notifică obiectul de controller care actualizează obiectul de view.

Obiectele de view sunt acele obiecte în aplicație care sunt vizibile pentru utilizatori. Un obiect de tip view știe cum ar trebui să se deseneze și cum să răspundă la acțiunile utilizatorului. Scopul lor este de a afișa vizual obiectele de model al aplicației și să permită editarea lor. În ciuda acestui fapt, aceste obiecte sunt decuplate de obiectele de model în cazul aplicațiilor MVC. Obiectele de tip view pot afla schimbările la nivel de mode de la obiectele de controller al aplicației și comunică schimbări cauzate de utilizator pe model tot prin aceste controllere. Deoarece aceste obiecte sunt refolosite de la aplicație la aplicație, ei asigură consistență între aplicații.

Obiectele de tip controller acționează ca și intermediar între unul sau mai multe obiecte de view al aplicației și între unul sau mai multe obiecte de tip model. Obiectele de controller sunt acele obiecte prin care un view află dacă modelul a fost schimbat și invers. Aceste obiecte pot face și inițializări, să coordoneze procese și să gestioneze ciclul de viață a celorlalte modele. Ei interpretează acțiunile utilizatorilor pe obiectele de view și comunică datele noi sau cele schimbate la nivelul de model. Când un model se schimbă, aceste obiecte sunt care comunică schimbările din model la obiectele de view.

3.1.2 Backend

Ca și backend pentru aplicație voi folosi un „Mobile Backend as a Service” (trad. prop. Seviciu de backend pentru mobile). Scopul serviciilor de backend pentru mobile este de a oferii programatorilor un sistem ușor de creat și ușor de menținut care să funcționeze ca și backend pentru aplicațiile mobile [11]. Aceste backenduri oferă bază de date, spațiu de stocare în cloud, posibilitatea de a scrie cod și logică care să se execute pe servere externe și nu pe dispozitivele mobile și oferă și alte servicii precum trimiterea notificărilor de tip push. Aceste servicii sunt oferite prin intermediul utilizării unui kit de dezvoltare software costumizat (SDK) și interfețe de programare a aplicațiilor (API). Serviciile de MBaaS sunt relativ noi, majoritatea companiilor înființate în 2011 sau mai târziu. Comapniile care oferă aceste servicii sunt specializate pe backend, astfel în multe cazuri, un serviciu de backend mobil este superior serverelor normale. Sunt în cele mai multe cazuri mai rapide, și mai solide decât serverele normale. Deoarece sunt relativ noi multe aplicații din domeniul turistic consacrate nu folosesc un serviciu de acest tip, optând pentru servere care sunt mai lente, mai nesigure și mai greu de întreținut.

MbaaS-ul pentru care am optat eu este Parse. Parse a fost înființat în 2011 și cumpărat de Facebook doi ani mai târziu. Cu peste 100000 de aplicații care folosesc Parse [12], este una din cele mai populare și versatile servicii de tip backend.

Astfel în Parse am creat mai multe tabele. Cunoștințele din domeniul turistic relevante acestei aplicații sunt stocate într-o bază de date, ce conține tabele cu: orașe, obiective turistice, detalii despre utilizatori și itinerarele create de ei. Tabela “User” (trad. “Utilizator”) conține datele despre utilizator: număr de identificare, nume de utilizator, parola și adresa de email, data creării contului și data la care a fost modificat ultima oară. Această tabelă este vizibilă în figura 3.2.

Într-o tabelă separată avem stocate relațiile de prietenie între utilizatori, tabela se numește “Friends”. Această tabelă conține o coloană cu numărul de identificare a unui utilizator și o altă coloană care are o listă de numere de identificare a utilizatorilor care reprezintă prietenii. Tabela de “Cities” conține o listă de orașe care sunt suportate de aplicație. Aici avem o coloană cu un număr care identifică orașul, avem coordonatele orașului, numele, și țara în care se află. Pentru a persista obiectivele turistice, avem tabela “Landmarks”. Pentru fiecare intrare în această tabelă avem un număr de identificare pentru obiectivu turistic. Un număr de identificare a orașului în care se află obiectivul turistic, am a nume șu descriere pentru acesta, imagine și coordonatele sale pe hartă. Și una din cele mai importante tabele este cea în care sunt salvate itinerarele, zilele de călătorie. Această tabelă reprezintă legătura dinte utilizaror și obiectivele turistice. Astfel în tabelă avem o coloană pentru numărul de identificare a zilei de călătorie, numele și data la care este planificar această călătorie. Tot aici avem o numărul de identificare a orașului și o listă cu numere de identifiacre a obiectivelor turisice pe care utilizatorul vrea să viziteze, și avem și numărul de identificare a utilizatorului.

Mai există tabele create implicit de Parse, precum Installation sau Role. Tabela de Role nu este folosită de aplicația Travel Day, insă în Intallation avem salvăm identificatorul telefonului și utilizatorul care folosește acel telefon. Ne folosim de tabela de Installation pentru a trimite notificări de tip push, descris mai amănunțit în capitolul 3.3.

Tot Parse folosim și să trimitem notificări de tip push. Metoda care trimite aceste notificări se află tot pe serverele din cloud pe care le furnizează Parse și este rulat tot pe aceste servere prin intermediul Cloud Code-ului. Astfel doar trebuie să trimitem o cerere către Parse cu parametrii necesari, iar acesta va trimite mesajele, iar clientul nu mai trebuie să facă nimic altceva. Metoda aceasta este descris tot la subcapitolul 3.3.

3.1.3 Modele

Pentru a definii domeniul modelului conceptual m-am folosit de analiza făcută la subcapitolul 2.3. Deoarece modelele reprezintă cunoștințele și expertizele legate de problemele unui domeniu specific, aceste obiecte pot fi refolosite pentru probleme asemănătoare. Astfel modelele conceptuale pe care aplicația Travel Day folosește este asemănătoare cu cele pe care toate aplicațiile din domeniul turistic le folosesc. Putem vedea și vizual asemănările dacă observăm figura 3.3. Diagrama UML în figura 3.3 reprezintă modelele conceptuale ale aplicației Travel Day, și este o diagrama mai simplificată a diagramei din figura 2.6.

Pentru aplicația Travel Day am simplificat modelele conceptuale care a reieșit în urma analizei pe care am făcute pe aplicații din domeniu. Am păstrât doar elementele importante, și l-am exstins cu elementa care sunt necesare buisnessului meu. Astfel acesta este extinsă cu conceptul de “TravelDay”, model care reprezintă o zi de călătorie, acesta conține detaliile itinerarul pe care utilizatorul poate crea în aplicația.

Din modelul conceptual determinat la subcapitolul 2.3 am păstrat elementul de utilizator. Am redus locațiile la doar model de oraș, precum elementul de “Business” este redus la doar obiectivele turistice, adică modelul de “Attraction” (numit “Landmark” în aplicația Travel Day). Am avut nevoie și de coordonate, astfel am păstrat modelul de “Coordinate”. În aplicație Travel Day, utilizatorul poate avea prieteni, astfel aici modelul de “User” are o relație unu la mai multe cu el însuși. Au fost schimbate, simplificate și proprietățile pe care le are un model. Acestea sunt vizibile în figura 3.3.

Nivelul de model mimică și structura bazei de date. Avem tabele pentru fiecare model conceptual din aplicație. Astfel este ușor de încărcat, modificat și salvat datele în baza de date creat pe Parse.

3.3 Detalii de implementare

3.3.1 Sincronizare de date activă

Caracterul social este una din cele mai importante părți a aplicației, acesta este trăsătura care diferențiază aplicația Travel Day de restul aplicațiilor existente din domeniul turistic. Prin intermediul aplicației ne putem adăuga prieteni, și după ce creăm o zi de călătorie putem împărtăși acesta cu prietenii. Așa mai mulți utilizatori pot avea acces la același zi de călătorie, pot vizualiza călătoria, pot adăuga sau șterge obiective de vizitat, pot modifica titlul, data excursiei, chiar și locația. Și aici pot apărea probleme. Cum ținem pe toate telefoanele mobile toate datele la zi? Cum sincronizăm datele pentru toți care au acces la el?

O soluție, ce am folosit și eu, este sincronizarea de date activă. Parse oferă suport pentru Apple Push Notification Service (trad. prop. „serviciul de notificări push de la Apple”), și are o bibliotecă bine documentată și ușor de integrat. Prin intermediul APNs-ului, putem trimite notificări către dispozitivele mobile atunci cănd are loc o modificare pe o zi de călătorie, prezentat în figura 3.4. Cei care primesc notificarea la răndul lor vor putea reîncărca datele actualizate din baza de date. Putem trimite notificări tăcute, care nu afișează nici un mesaj, nu emit nici un sunet, actualizarea de date este aproape invizibil pentru utilizatori. Și aceste actualizări se pot intâmpla chiar și dacă aplicația este în fundal. Iar când utilizatorul revine în aplicație va vedea datele noi. Putem trimite și un mesaj în aceste notificări, pe care putem afișa în aplicație, și astfel utilizatorul va vedea cine și pe ce a făcut modificarea.

Primul pas în implementarea sincronizării active a fost crearea unui certificat pentru aplicație prin intermediul centrului de membrii Apple care să ne permită să trimitem notificări Push. Acest certificat trebuie folosit când compilăm aplicația și trebuie încărcat și pe Parse la aplicația creată pe acesta. După care a trebui sa ma înregistez pentru notificări în clasa AppDelegate în funcția application: didFinishLaunchingWithOptions:.

func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
application.registerForRemoteNotifications()
return true
}

Acesta la rândul lui va apela funcția application: didRegisterForRemoteNotifications WithDeviceToken:, și ne dă un număr de identificare a telefonului numit “device token”, pe care îl setăm pe un obiect de Installation în Parse (pentru acest obiect corăspunde un tabel în baza de date).

func application(application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: NSData) {
let installation = PFInstallation.currentInstallation()
installation.setDeviceTokenFromData(deviceToken)
installation.saveInBackgroundWithBlock(nil)
}

Este important de notat, ca acesta să funcționeze și să se conformeze de regulile impuse de Apple, trebuie să permitem notificările și în modul de fundal la capabilitățile aplicației (vezi figura 3.5). Și să adăugăm intrearea de "App downloads content in response to push notifications" la "Required background modes" în info.plist (vezi figura 3.6). Acesta din urmă va anunța utilizatorul când descarcă aplicația că acesta va face actualizări la date în background.

După astea am adăugat numărul de identificare a utilizatorului din baza de date la acelaș obiect de Installation folosit mai sus. Numărul de identificare trebuie adăugat doar atunci când utilizatorul este înregistrat și autentificat în aplicație. Iar când se deconecteaza ștergem acest număr de pe instanța de Installation. Pentru că după autentificare descărcăm toate datele utilizatorului, planificările de călătorie pot deveni învechit doar atunci când este utilizatorul este deja autentificat. Astfel în funcția de autentificare apelăm și metoda de addCurrentUserToInstallation():

private func addCurrentUserToInstallation() {

let currentInstallation = PFInstallation.currentInstallation()

let currentUserID = PFUser.currentUser()!.objectId!

currentInstallation.setObject(currentUserID, forKey: "userID")

currentInstallation.saveInBackground()

}

Iar pe funcția de deconectare apelăm metoda de removeCurrentUserFromInstallation():

private func removeCurrentUserFromInstallation() {

let currentInstallation = PFInstallation.currentInstallation()

currentInstallation.setObject("", forKey: "userID")

currentInstallation.saveInBackground()

}

După ce m-am înregistat la notificări și am adăugat numărul de identificare a utilizatorului la tabelul de Installation a urmat trimiterea efectiv a notificărilor. „Viziunea Parse-ului este de a permite dezvoltatorilor sa construiască aplicații mobile fără ca acestea să se ocupe de server. Dar pentru aplicații complexe uneori este nevoie de puțină logică care să nu se execute pe dispozitivele mobile. Cloud Code face acest lucru să fie posibil” [14]. Parse Cloud Code este construit pe JavaScript SDK, iar funcțiile scrise aici se execută pe serverele de Parse și nu pe dispozitivele mobile. Iar aceste funcții sunt accesibile în orice mediu mobil. Astfel am creat o funcție numită sendPushNotifications. Această funcție primește ca și parametru un număr de identificare a dispozitivului mobile, o listă de numere de identificare a utilizatorilor, și un mesaj de tip text care se va afișa la utilizatorii notificați. Și va trimite la toți utilizatorii care sunt conectați la ziua de călătorie în afară de cel care a facut modificarea o notificare push.

Parse.Cloud.define("sendPushNotification", function(request, response) {

var deviceToken = request.params.deviceToken;

var userIDs = request.params.userIDs;

var message = request.params.message;

var query = new Parse.Query(Parse.Installation);

query.notEqualTo("deviceToken", deviceToken);

query.containedIn("userID", userIDs);

Parse.Push.send({

where: query,

data: {

"content-available" : 1,

"message" : message,

"action" : "TRAVEL_DAYS_CHANGED"

}

}, {

success: function() {

response.success();

},

error: function(error) {

response.error(error);

}

});

Și apelăm metoda din Cloud Code la salvarea editării unei zi de călătorie:

PFCloud.callFunctionInBackground("sendPushNotification", withParameters: ["message": "Travel day named \(travelDay.name!) was changed by \(PFUser.currentUser()!.username!).","userIDs" : travelDay.connections, "deviceToken": deviceToken], block: nil)

După acesta un utilizator va primii o notificare când o zi de călătorie este modificat. Tot ce a mai rămas este ca în funția de application: didReceiveRemoteNotification: care se apeleaza când aplicația primește o notificare sa redescarce zilele de călătorie a utilizatorului și să afișeze mesajul primit.

3.3.2 Sincronizare de date manuală

Notificările de push trimise prin APNs de obicei ajung în sub 3 secunde, rar depășind 5. Astfel utilizatorul va avea date actualizate aproape tot timpul. Însă sunt cazuri în care aceste notificări nu ajung la destinație, prin testele efectuate de mine acestea au fost sub 1% din cazuri. Dar și documentați dat de Apple spune ca nu garantează ca se va trimite cu success [15]. Astfel a fost nevoie să introduc și un alt mecanism de reîncărcare.

Sincronizare de date manuală constă în adăugarea unui buton în interfață prin care utilizatorul poate să redescarce datele pentru zilele de călătorie. Iar pentru a nu putea edita zile de călătorie neactualizat am creat un tabel nou în baza de date numit Updates (vezi figura 3.7). Acesta conține numărul de identificare a fiecărui utilizator și un boolean dacă are sau nu date neactualizate, vizibil în figura 3.7. Numărul de identificare se va adăuga la tabel în momentul când un utilizator se înregistrează. Iar când apelez metoda de sendPushNotifications din Cloud Code setez pentru fiecare utilizator pe „true” coloana de hasUpdates.

var updateQuery = new Parse.Query("Updates");

updateQuery.notEqualTo("deviceToken", deviceToken);

updateQuery.containedIn("userID", userIDs);

updateQuery.find({

success: function(users) {

for (var i = 0; i < users.length; i++) {

users[i].set("hasUpdates", true);

console.log("1");

}

Parse.Object.saveAll(users, nil)

},

error: function(error) {

response.error(error);

}

})

Iar când ce un utilizator a făcut actualizarea voi seta înapoi pe „false”. Astfel știu tot timpul când un utilizator are date neactualizate sau nu. Și înainte de a face modificări pe o zi de călătorie, verific dacă toate datele sunt actualizate. Daca nu, atunci îl oblig sa facă o actualizare înainte.

Deoarece numărul de cereri și transferul de date în Parse sunt limitate, fac aceste verificări înainte de fiecare cerere de update, și să las să se trimită doar atunci când nu este actualizat deja.

3.3.3 Declanșatoare în baza de date

După sincronizarea de date apare o altă problema cu impărtășirea datelor între utilizatori. Atunci când un utilizator împărtășește o zi de călătorie cu un prieten se va crea o conexiune între acel utilizator și ziua călătoriei. Acesta este persistat pe tabela de „Connection”, și pe coloana de „travelDay” conține numărul de identificare a zilei de călătorie, iar pe coloana de „user” conține numărul de identificare utilizatorilor. Astfel nu trebuie să duplic datele în tabela de „TravelDay” (care conține fiecare zi de călătorie) pentru fiecare utilizator. Însă când un utilizator șterge o zi de călătorie, șterg doar conexiunea din baza de date. Nu șterg întreaga zi de călătorie deoarce s-ar putea să fie mai mulți utilizatori conectați la el. Dar totuși vreau să șterg pe acesta când nu mai sunt utilizatori conectați la el. Nu vreau ca baza de date să se umple cu date care au ajuns irelevante. Să fac verificările la fiecare ștergere pe partea de client necesită din nou cereri în plus la Parse, necesită resurse și va crește timpul de execuție. Pentru asta am folosit așa numitele declanșatoare în baza de date.

„O procedură sau funcție stocată sunt obiecte de aplicație a bazei de date, ce incapsuleaza instrucțiuni SQL sau logică de business. Păstrând o parte a logicii din aplicație în baza de date oferă îmbunătățiri de performanță, deoarece traficul de rețea între aplicație și baza de date se reduc considerabil. Pe lângă asta oferă și un loc centralizat pentru a păstra codul, ca mai multe aplicații să o pot refolosi” [16]. „Declanșatoarele sunt asemănătoare cu procedurile stocate. Un declanșator stocat în baza de date poate include instrucțiuni SQL și PL/SQL sau Java care se pot executa și care pot la rându lor invoca proceduri stocate. Însă, procedurile stocate diferă de declanșatoare în modul în care acestea sunt invocate. Declanșatoarele sunt executate implicit când se întâmplă un eveniment, indiferent ce utilizator este conectat sau ce aplicație este folosită” [17]. Astfel un declanșator este o funție sau cod procedural care este executat automat atunci când se insereaza, șterge sau se face o actualizare pe un tabel, când se creaza un tabel sau este modificat. De obicei este folosit pentru a păstra integritatea bazei de date sau a tabelului, sau pentru asigurarea securitații datelor.

Sunt patru astfel de declanșatoare pe care putem implementa în Parse, unul apelat înainte să introducem o nouă intrare în baza de date, unul după, unul înainte și unul după ștergere. Numele acestor metode în Parse sunt beforeSave, afterSave, beforeDelete, afterDelete. Aceste metode au câteva limitări, de exemplu, o metodă va fi oprită dacă timpul de execție durează mai mult de 3 secunde. Pentru orice ce depășește acest timp Parse recomandă folosirea operațiunilor în fundal. Operațiunile în fundal în Parse sunt metode sau funcții stocate pentru care se poate seta un interval de timp, iar Parse va executa funcția la acele intervale. Însă pentru noi cele 3 secunde sunt suficiente.

Putem să ne folosim de metoda de afterDelete pe tabela care ține conexiunile între utilizatori și zilele de călătorie. Și verificăm în el dacă mai există vreo conexiune între o zi de călătorie și un utilizator oarecare. Dacă nu mai există putem șterge definitiv ziua de călătorie din baza de date.

Ca prim pas am implementat metoda de afterDelete:

Parse.Cloud.afterDelete("Connection", function(request) {});

unde “Connection” este numele tabelului care ține conexiunile la diferitele zile de călătorie. În această metodă avem access la obiectul care a fost șters prin request.object. Totodate, nu trebuie să returnăm nimic din această funcție, clientul va primi un mesaj de success pe cererea de ștergere după ce declanșatorul își termină execuția.

Aici am nevoie să fac o interogare pe același tabel de conxiuni, numit „Connections” cu numărul de identificare a zilei de călătorie să văd dacă mai există vreo altă conexiune la el:

var travelDayId = request.object.get("travelDay");
var query = new Parse.Query("Connection");
query.equalTo("travelDay", travelDayId);
query.find({

})

Funcția find() va apela blocul de succes și dacă nu mai există conexiune cu numărul de identificare a zilei de călătorie dat, dar lista pe care acest bloc de succes va primi va fi gol. Ne focusăm pe acesta, și verificăm lungimea listei primite de la funcția find()

success: function(connections) {
if (connections.length == 0) {

}
}

Iar în if, dacă lungimea listei este egală cu 0, șterg ziua de călătorie din tabelul TravelDay. Pentru acesta trebuie să fac o cerere să obțin data, după care, apelând metoda de destroy() pe un obiect Parse, șterg acel obiect.

Pentru că clientul de pe mobile va primi success dacă conexiunea sa șters, indiferent dacă a fost ultima și a reușit să șteargă și ziua de călătorie sau nu, va trebui să verific logurile, și să ștergem manual dacă din ceva motiv nu a fost șters. Asta din păcate este limitarea sistemului și acestei metode (nu putem exporta logurile într-un fișier text și să le parsăm și să reîncercăm ștergerea), dar aceste cazuri sunt extrem de rare.

Această metodă ne asigură că datele pe care le avem în baza de date sunt relevante, și datele irelevante sau care nu mai sunt necesare sunt șterse.

3.4 Modul de utilizare

În acest subcapitol este prezentat modul de utilizare a aplicației Travel Day, sunt prezentate și descrise ecranele pe care un utilizator poate întâlni, și este descris cum poate interacționa acest utilizarot cu aplicația.

3.4.1 Creare de cont și autentificare

La rularea aplicației Travel Day, primul ecran pe care utilizatorul întâlnește atunci când încă nu s-a autentificat este cea de autentificare (vezi figura 3.8). Se oferă două opțiuni pentru utilizator. El poate introduce numele utilizatorului și parola pentru autentificare sau poate opta pentru crearea unui cont nou. În cazul în care utilizatorul introduce datele contului deja creat și apasă pe butonul “Login”, aplicația va trimite datele la server, iar dacă autentificarea a fost cu succes, se va afișa ecranul principal al aplicației. Dacă autentificarea a eșuat se va afișa un mesaj de eroare.

Utilizatorul poate opta și pentru crearea unui cont nou în cazul în care încă nu are. El poate ajunge acolo prin apăsarea bunotunul “Signup”. Pe ecranul de creare cont (vezi al doilea ecran din figura 3.8) el trebuie să introducă numele utilizatorului, parola, să confirme parola și adresa sa de email. Aceste câmpuri trebuie completat obligatoriu dacă utilizator vrea să avanseze. Sunt impuse și limitări pe câmpurile acestea. Astfel numele utilizatorului trebuie să fie minim 4 caractere, parola trebuie să fie minim 6 caractere, adresa de email trebuie să se conformeze regurilor impuse de standardele RFC 5321 și RFC 5322. Aceste standarde descriu cum trebui să arate o adresă de email, astfel de exemplu [anonimizat] este valid în schimb john@[anonimizat] nu este valid. După care prin apăsarea butonului “Signup” se va crea contul. Dacă crearea contrulu a fost cu succes, se va afișa ecranul principal al aplicației. Dacă autentificarea a eșuat se va afișa un mesaj de eroare.

3.4.2 Ecranul principal

Utilizatoru poate ajunge pe ecranul principal de pe ecranul de autentificare sau de creare cont. Și în cazul în care un utilizator s-a autentificat anterior și va porni aplicația, datele de utilizator sun încărcate din baza de date local, iar ecranul prinicpal este cel care se afișează prima oară.

Pe acest ecran în colțul din stânga sus a ecranului este afișat data curentă. Pe partea dreapta sus are un buton de actualizare, acesta va redescărca datele utilizatorului de pe server în cazul în care din ceva motiv acestea nu s-au actualizat automat.

Tot pe acest ecran utilizatorul poate vedea dacă are sau nu planificat pe ziua curentă (vezi figura 3.9). Dacă nu are atunci se este afișat textul “You have nothing planned for today” (trad. “Nu aveți nimic plănuit pe azi”). Dacă are ceva plănuit, atunci se va afișa imaginile, pozele obiectivelor turistice pe care vrea utilizatorul sa viziteze. Dimensiunea imaginilor afișate sunt calculate în funcție de numărul lor. Astfel dacă este o imagine atunci se afișează o imagine mare pe ecran, dacă sunt două atunci se afișează două imagini de dimensiune medie, la trei imagini se afișează o imagine la dimensiune medie și două la dimensiune mici, la patru imagini toate sunt de afișate în dimensiune mică, iar dacă sunt mai mult de 4 acestea sunt afișate în dimensiune mici și se pot naviga pe orizontală.

Selectând una din imagini, se va afișa un ecran pe care putem afla mai multe detalii despre acel obiectiv turistic (vezi figura 3.10). Acest ecran se va afișa animat în fața ecranului principal. Pe acest ecran avem imaginea mare a obiectivului turistic, numele obiectivului, și o scurtă descriere a acesteia. Ecranul se poate ascunde apăsând oriunde pe acesta.

În cazul în care avem ceva planificat pe ziua curentă, putem vedea și locațiile aferente obiectivelor turistice pe hartă. Harta este accesibil apăsând butonul “See map”. Harta va fi afișată centrat pe orașul în care avem planificat vizitele obiectivelor turistice. Tot pe hartă sunt afișate și toate punctele de interes (vezi figura 3.11). Harta poate fi mărită și micșorată pentru a ajuta utilizatorul să găsească obiectivele turistice. Selectând un obiectiv turistic, marcat pe hartă cu o bulină albastră vizibil pe figura 3.11, se va afișa numele acelui obiectiv turistic. Se poate închide harta apăsând butonul “Close”. În acest caz utilizatorului se va afișa ecranul anterior.

Utilizatorul poate să ajungă pe alte trei ecrane. Acesta poate naviga pe ecranul în care sunt afișate toate zilele de călătorie planificate apăsând butonul “Travel Days”, descris în subcapitolul 3.4.4. Dacă alege “Plan a Travel Day”, utilizatorul va ajunge pe ecranul în care poate planifica o zi de călătorie, care este descris în subcapitolul 3.4.3. Și mai poate alege “Profile”, unde poate vedea detalii de profil și poate adăuga prieteni, descris în subcapitolul 3.4.5.

3.4.3 Planificarea zilelor de călătorie

De pe ecranul principal putem accesa ecranele pe care pe care putem planifica zi de călătorie. Funcționalitatea asta poate fi accesat doar dacă avem conexiune la internet, în cazul în care nu avem, se va afișa un mesaj de eroare pe ecranul prinicpal. Această funcționalitate include trei ecrane care sunt vizibile în figura 3.10.

Pe primul ecran trebuie să introducem nume, data și locația unde vrem să călătorim. Primul câmp ne lasă să introducem un titlu pentru ziua de călătorie, pentru a se putea identifica mai ușor în viitor. Data este precompletat cu data curentă. Dacă îl selectăm câmpul unde scrie “When are you traveling?” (trad. “Când călătoriți?”) apare un selector de date unde putem alege data la care vrem să călătorim. Există pe acest câmp, astfel data selectată nu poate fi în trecut. Locațiile posibile sunt defapt orașe și sunt încărcate din baza de date. Selectând câmpul unde scrie “Where are you traveling?” (trad. “Unde călătoriți?”) va apărea un selector asemănător cu cea a datei. Ca utilizatorul să poată avansa la următorul ecran trebuie să completeze toate câmpurile. În cazul în care nu face acest lucru se va afiș un mesaj de avertizare, și nu se va deschide următorul ecran.

Pe al doilea ecran, vizibil în figura 3.12, se va afișa harta centrată pe orașul selectat anterior, și o listă cu obiectivele turistice din acel oraș. Lista obiectivelor turistice conține o imaginea și numele acestora, și sub titlul atracției este și un buton pe care scrie “Details” (trad. “Detalii”). Dacă selectăm acest buton, se va afișa ecranul din figura 3.10, cu mai multe detalii despre acel obiectiv turistic. Dacă selectăm o atracție turistică acesta va fi marcat pe hartă, și se va marca vizual și în tabelă. Dacă selectăm o atracție turistică care deja a fost selectat, acesta se deselectează, se șterge maractorul vizual și din tabelă și se va șterge și de pe hartă.

Avansarea pe ecranul al treilea se face de pe ecranul al doilea, apăsând butonul de “Done” (trad. “Finalizare”) din colțul stânga sus a paginii. Dacă ziua de călătorie se crează cu succes se va afișa ecranul al treilea, dacă nu, se va afișa un mesaj de eroare.

Pe ecranul al treilea vedem un mesaj care confirmă că ziua de călătorie s-a creat cu success. Mesajul este “The travel day has been successfully created” (trad. “Ziua de călătorie s-a creat cu success”). Tot pe acest ecran utilizatorul va avea doă opțiuni, să apase pe butonul “Done”, care îl va întoarce pe ecraul principal, sau sa apase pe butonul “Share” (trad. “Împărtășire”). Cel din urmă va deschide un ecran vizibil în figura 3.13. Pe acest ecran utilizatorul va vedea lista cu prietenii. El poate selecta unu sau mai mulți prieteni cu care vrea să împărtășsească ziua de călătorie creat de el. Iar la apăsarea butonului “Share” prietenii care folosesc aplicația vor primii o notificare, și vor avea access la ziua de călătorie creat mai înainte.

3.4.4 Vizualizarea zilelor de călătorie

Dacă utilizatorul va selecta “Travel Days” (trad. “Zile de călătorie”) atunci va accesa ecranele pe care se pot vizualiza toate zilele de călătorie (vezi figura 3.14). Aceste ecrane sunt accesibile și atunci când utilizatorul nu are conexiune la internet.

Pe primul ecranul este o listă care conține toate zilele de călătorie creat de utilizator, sau cele care au fost împărtășită cu el. Lista este ordonat după data călătoriei în ordine crescătoare. Selectând una din zilele de călătorie va afișa al doile ecran. Tot pe această listă avem posibilitatea de a șterge o zi de călătorie. Dacă tragem cu degetul spre stânga pe unul din elementele listei, se va afișa un buton de “Delete” (trad. “Șterge”). Apăsând butonul va șterge ziua de călătorie din tabel, și va șterge și conexiunea utilizatorului catre acea zi de călătorie. Pentru acesta avem nevoie de acces la internet, în cazul în care nu avem, se va afișa un mesaj de eroare.

Al doile ecran afișează o hartă pe care sunt marcate toate obiectivele turistice pe care utilizatorul vrea să viziteze, și sub el a o listă care conține imaginea și numele acestor destinații turistice. Poate vedea mai multe detalii despre un obiectiv turistic selectând butonul de “Details”. Are și un buton de “Share” care va deschide ecranul de împărtășire descris în subcapitolul 3.4.3.

Utilizatorul poate și edita o zi de călătorie. Acesta se poate face apăsând butonul de “Edit” (trad. “Editare”) de pe al doile ecran. De aici utilizatorul va ajunge pe ecranele din figura 3.12. Însă pentru a putea face asta, el are nevoie de access la internet, în caz că nu are, se va afișa un mesaj de eroare.

3.4.5 Detaliile utilizatorului

Butonul de “Profile” de pe ecranul principal va deschide ecranul cu detaliile utilizatorului (vezi figura 3.15). Acest ecran este accesibil și fără conexiune la internet

Pe acest ecran putem vedea imaginea utilizatorului, numele utilizatorului și emailul lui. Sub acesta este funcționalitatea de adăugare prieteni. Aici utilizatorul poate introduce numele altui utilizator și dacă apasă butonul de “Add” (trad. “Adăugare”), se va adăuga utilizatorul ca și prietem. În cazul în care nu există utilizator cu numele introdus, deja ii adăugat sau nu are acces la internet se va afișa un mesaj de eroare. Când sa adăugat un prieten, acel prieten va primi o notificare că a fost adăugat ca și prieten. Sub această funcționalitate avem și lista întreagă de prieteni care este navigabil pe orizontală.

Utilizatorul tot de pe acest ecran are posibilitatea de a închide sesiunea. Odată ce sesiunea se va închide, se va șterge din memorie detaliile utilizatorului, zilele de călătorie și detaliile despre obiectivele turistice.

Concluzii

Din aspectele prezentate în acestă lucrare se poate concluziona că deși există nenumărate aplicații turistice încă sunt funcționalități care nu au fost încă implementate și cu care se pot extinde aceste aplicații. Deoarece domeniul de aplicații mobile este în constană evoluție, crearea unei aplicații noi, diferite de restul, este posibilă. În ultimii ani sectorul turismului a simțit o creștere rapidă în utilizarea de aplcații mobile. Potențialul și caracteristicile telefoanel inteligente, precum accesul la internet și geo-localizare, l-au transformat pe acesta în cele mai folosite dispozitive mobile în turism.

În cadrul lucrării am prezentat aplicația Travel Day, o aplicație mobilă creat de mine pentru domeniul turistic. Această aplicație include cele mai importante funcționalități din aplicațiile turistice, precum crearea unui itinerar, oferirea asistenței turistice prin prezentarea locației exacte pe hartă a obiectivelor tuistice, afișarea detaliilor și imaginilor despre obiectivele turistice. Pe lânga asta a fost extinsă cu funcționalități de caracter social. Astfel aceste itinerare create pot fi împărtășite cu prieteni, ei pot modifica aceste itinerare iar modificările vor fi vizibile în timp real la toți utilizatorii din acel cerc de prieteni.

Pe viitor aplicația va fi extinsă și cu alte funcționalități. Unul din planuri este includerea navigației până la obiectivele turistice. Momentan aceste obiective sunt doar prezentate pe hartă, dar se poate lua locația utilizatorului și calcula cel mai scurt drum către acel obiectiv turistic. O altă îmbunătăție ar fi la adăgarea de prieteni. Acum în aplicație nu există nici un mecanism de aprobare când adăugăm prieteni. Aplicația ar putea fi extinsă cu acesta, astfel un prieten să fie adăugat doar atunci când și el acceptă. Încă o funcționalitate interesantă care să extindă partea socială a aplicației ar fi afișarea locației exacte pe hartă și prietenilor în timpul excursiei.

Bibliografie

[1] Anshul Gupta, Roberta Cozza, CK Lu, Market Share Analysis: Mobile Phones, Worldwide, 4Q13 and 2013, URL: https://www.gartner.com/doc/2665319, accesat la data de 09.05.2015

[2] Cătălin Prata, Dezvoltarea aplicațiilor mobile: Între nativ și hibrid, URL: http://www.todaysoftmag.ro/article/542/dezvoltarea-aplicatiilor-mobile-intre-nativ-si-hibrid, accesat la data de 10.05.2015

[3] Simon Khalaf, Apps Solidify Leadership Six Years into the Mobile Revolution, URL: http://flurrymobile.tumblr.com/post/115191864580/apps-solidify-leadership-six-years-into-the-mobile, accesat la data de 16.05.2015

[4] Android – Dashboard, URL: https://developer.android.com/about/dashboards/index.html, accesat la data 18.05.2015

[5] TripAdvisor – Fact Sheet, URL: http://www.tripadvisor.com/PressCenter-c4-Fact_Sheet.html, accesat la data de 24.05.2015

[6] TripCase – About Us, URL: http://travel.tripcase.com/about-us/, accesat la data de 24.05.2015

[7] Martin Fowler, Analysis Patterns, Reusable object models, editura Addison-Wesley Longman, 1997

[8] Alexander, C., S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. A Pattern Language, editura Oxford University Press, 1977

[9] Jack Preston, Richard Branson – The Importance of Social Media, URL: http://www.virgin.com/entrepreneur/richard-branson-importance-social-media, accesat la data de 06.06.2015

[10] Apple – Model-View-Controller, URL: https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html, accesat la data de 07.06.2015

[11] Kin Lane, Rise of Mobile Backend as a Service, URL: http://apievangelist.com/2012/06/03/rise-of-mobile-backend-as-a-service-mbaas-api-stacks, accesat la data de 07.06.2015

[12] Jim Edwards, This Guy Thinks A Little-Noticed Facebook Acquisition Gives It A Head Start On Finding The Next Instagram, URL: http://www.businessinsider.com/why-facebook-acquired-parse-for-app-acquisitions-2013-9, accesat la data de 07.06.2015

[13] David Chan, What’s New with Multitasking, URL: http://devstreaming.apple.com/videos/wwdc/2013/204xex2xvpdncz9kdb17lmfooh/204/204.pdf, accesat la data de 03.05.2015

[14] Parse – Cloud Code Guide, URL: https://parse.com/docs/cloud_code_guide, accesat la data de 03.05.2015

[15] Apple Push Service, URL: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html, accesat la data de 03.05.2015

[16] Neeraj Sharma, Liviu Perniu, Raul F. Chong, Abhishek Iyer, Chaitali Nandan, Adi-Cristina Mitea, Mallarswami Nonvinkere, Mirela Danubianu, Database Fundamentals, editura IBM Corporation, 2010

[17] Oracle – Database Concepts, URL: http://docs.oracle.com/cd/B19306_01/server.102/b14220/triggers.htm, accesat la data de 05.05.2015