Planes – Jocul copilăriei într-un format modern

UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI FACULTATEA DE INFORMATICĂ

LUCRARE DE LICENŢĂ

Planes – Jocul copilăriei într-un format modern

propusă de

Ionuț Mihai Burlacu

Sesiunea: februarie, 2017

Coordonator ştiinţific

Asist. Dr. Vasile Alaiba

1

UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI FACULTATEA DE INFORMATICĂ

Planes - Jocul copilăriei într-un format modern

Ionuț Mihai Burlacu

Sesiunea: februarie, 2017

Coordonator ştiinţific

Asist. Dr. Vasile Alaiba

2

D ^ECLARAŢIE PRIVIND ORIGINALITATE ŞI RESPECTAREA DREPTURILOR DE AUTOR

Prin prezenta declar că Lucrarea de licenţă cu titlul „Planes – Jocul copilăriei într-un format modern” este scrisă de mine şi nu a mai fost prezentată niciodată la o altă facultate sau instituţie de învăţământ superior din ţară sau străinătate. De asemenea, declar că toate sursele utilizate, inclusiv cele preluate de pe Internet, sunt indicate în lucrare, cu respectarea regulilor de evitare a plagiatului:

- toate fragmentele de text reproduse exact, chiar şi în traducere proprie din altă limbă, sunt scrise între ghilimele şi deţin referinţa precisă a sursei;

- reformularea în cuvinte proprii a textelor scrise de către alţi autori deţine referinţa precisă;

- codul sursă, imaginile etc. preluate din proiecte open-source sau alte surse sunt utilizate cu respectarea drepturilor de autor şi deţin referinţe precise;

- rezumarea ideilor altor autori precizează referinţa precisă la textul original.

Iaşi, data

Absolvent Ionuț Mihai Burlacu

___________________________

3

D ECLARAŢIE DE CONSIMŢĂMÂNT

Prin prezenta declar că sunt de acord ca Lucrarea de licență cu titlul „Planes - Jocul copilăriei într-un format modern”, codul sursă al programelor şi celelalte conţinuturi (grafice, multimedia, date de test etc.) care însoţesc această lucrare să fie utilizate în cadrul Facultăţii de Informatică.

De asemenea, sunt de acord ca Facultatea de Informatică de la Universitatea „Alexandru Ioan Cuza” Iași să utilizeze, modifice, reproducă şi să distribuie în scopuri necomerciale programele-calculator, format executabil şi sursă, realizate de mine în cadrul prezentei lucrări de licenţă.

Iaşi, data

Absolvent Ionuț Mihai Burlacu

_________________________

4

Cuprins

1. Introducere ... 6

1.1 Motivație ... 6

1.2 Context ... 6

1.3 Cerințe funcționale ... 7

1.4 Abordare tehnică ... 8

1.5 Contribuții ... 9

2. Dezvoltarea aplicației server ... 10

2.1 Sails.js ... 10

2.2 Socket.io ... 12

2.3 Configurarea proiectului ... 13

2.4 Cele 3 servere ... 16

2.5 MongoDB ... 17

2.6 isAuthorized ... 19

2.7 Multiple logins ... 20

2.8 Lucrul cu imagini ... 22

2.9 Push Notification ... 23

2.10 Email Service ... 24

2.11 Main Service ... 25

3. Dezvoltarea aplicației client ... 27

3.1 AngularJS 2 ... 27

3.2 Ionic 2 ... 28

3.3 localStorage ... 30

3.4 ApiService ... 31

3.5 DataService ... 33

3.6 Push Notification ... 34

3.7 Globals ... 35

5

3.8 LoadingService ... 36

3.9 Electron ... 37

4. Descrierea aplicației ... 39

4.1 Login ... 39

4.2 Register ... 40

4.3 Forgot Password ... 41

4.4 Home ... 42

4.5 Side Menu ... 43

4.6 Game Invitations ... 44

4.7 Profile ... 45

4.8 Update Info / Change Password ... 46

4.9 Friend List / Search Players ... 47

4.10 Friend Requests / Match History ... 48

4.11 Game Setup ... 49

4.12 Game ... 50

4.13 End Game ... 51

5. Bibliografie ... 52

6

1. Introducere 1.1 Motivație

Majoritatea dintre noi cred că am jucat în pauzele de la liceu sau chiar de la facultate jocul Avioane, însă cel mai mare impediment era faptul că la fiecare joc trebuiau trasate pe foi cele două tabele necesare jocului, lucru care făcea ca jocul să se termine de obicei după o singură rundă. Am ales să realizez o aplicație atât mobilă cât și desktop cu ajutorul căreia să se poată juca Avioane fără a avea nevoie de hârtie și pix, fiind nevoie doar de conexiune la internet și de un dispozitiv mobil sau de un desktop/laptop.

1.2 Context

Jocurile de strategie jucate în două persoane au apărut de foarte mult timp, primul joc de acest gen fiind ”X și 0” care se presupune că își are originile în antichitate.

Jocul Avioane este o variantă alternativă a jocului Battleships¹ care datează din timpul primului război mondial. Avioane este un joc de strategie ce se joacă în două persoane. Pentru a juca acest joc, fiecare jucător are nevoie de o foaie și un instrument de scris. La începutul

jocului, fiecare persoană trebuie să își amplaseze cele 3 avioane pe un chenar de 10x10 căsuțe.

După ce jocul a început, fiecare jucător trebuie să ghicească pe rând câte o căsuță în care se află unul din avioanele inamicului. Jocul se termină atunci când unul din jucători a descoperit toate cele 3 avioane ale jucătorului. Putem vedea mai jos un exemplu de chenar aparținând unuia dintre jucători:

1 https://en.wikipedia.org/wiki/Battleship_(game)

7

Figura 1 – Chenar 10x10 cu cele 3 avioane poziționate²

1.3 Cerințe funcționale

 Posibilitatea de a juca jocul Avioane contra unei alte persoane aleasă de către server care dorește să joace în același timp cu tine sau cu o persoană la alegere din lista de prieteni;

 Crearea de cont, fie direct din aplicație, fie prin intermediul rețelei de socializare Facebook. Contul este necesar pentru a putea avea o listă de prieteni și pentru a putea vedea istoricul meciurilor jucate. Jocul se va putea juca și fără

autentificare, însă utilizatorul nu va avea acces la lista de prieteni sau la istoricul meciurilor, acesta numindu-se în joc “guest” (Oaspete);

 Accesul la lista de prieteni, aceștia fiind adăugați în urma căutării după nume;

 Accesul la istoricul meciurilor jucate unde se va putea vedea între cine și cine s-a jucat meciul, cine a fost câștigătorul și în urmă cu cât timp s-a jucat fiecare meci;

 În cazul în care unul dintre jucători părăsește jocul din greșeală sau din cauza lipsei conexiunii la internet, aplicația va permite acestuia să revină în joc timp de 30 de secunde, în caz contrar celălalt jucător va fi ales învingător.

 Invitarea altor persoane la joc se va putea realiza și pentru jucătorii care se află în aplicație în acel moment, dar și pentru cei care nu se află în aplicație prin intermediul notificărilor push.

2 https://ro.wikipedia.org/wiki/Avioane_(joc)

8

 Accesul la profilul utilizatorului unde acesta își va putea schimba imaginea de profil, username-ul sau parola contului.

1.4 Abordare tehnică

Pentru partea de server (back-end) am folosit NodeJS împreună cu bibliotecile Sails.js și Socket.IO. Baza de date este una de tip NoSQL realizată cu ajutorul arhitecturii MongoDB.

Comunicarea între aplicație și server se va realiza prin intermediul websocket-urilor în timpul jocului propriu-zis și prin intermediul serviciilor web REST pentru restul funcționalităților.

Aplicația va fi de două feluri, pentru desktop și pentru mobil. Pentru aplicația de mobil voi folosi biblioteca Ionic, iar pentru aplicația de desktop voi folosi biblioteca Electron. Datorită tehnologiilor folosite aplicația de mobil va putea fi rulată pe Android, iOS și Windows Phone, iar aplicația de desktop va putea fi rulată pe Windows, OS X și Ubuntu. Eu voi alege să prezint aplicația doar pe Android în cazul celei pentru mobil și doar pe Windows în cazul celei pentru desktop. Avantajul folosirii acestor tehnologii este faptul că aplicația este scrisă o singură dată, iar apoi compilată pentru platforma dorită.

JavaScript este un limbaj de programare orientat obiect bazat pe conceptul

prototipurilor care a apărut în anul 1995 și care a fost dezvoltat inițial de către Brendan Eich.

Acest limbaj a fost inițial conceput pentru a putea adăuga funcționalități paginilor web care până la acea vreme erau statice, însă mai târziu a început să fie utilizat și pentru crearea serverelor web.

NodeJS este un mediu de programare bazat pe limbajul JavaScript, multiplatformă, cu sursă deschisă, cu ajutorul căruia se pot realiza servere web. NodeJS oferă o arhitectură bazată pe evenimente capabilă să realizeze transfer de date asincron. Aceasta permite realizarea de aplicații web scalabile care conțin multe operații de intrare/ieșire, dar și realizarea de aplicații care rulează în timp real (”real-time”) cum ar fi o aplicație de chat sau un joc.

9

1.5 Contribuții

Prezenta lucrare este împărțită în trei capitole: Dezvoltarea aplicației server, Dezvoltarea aplicației client și Descrierea aplicației.

Capitolele Dezvoltarea aplicației server și Dezvoltarea aplicației client prezintă în primul rând tehnologiile folosite în dezvoltarea acestora, dar și unele funcționalități importante ce merită a fi menționate. Ambele capitole au atașate secțiuni de cod relevante din ambele aplicații, client și server.

Capitolul Descrierea aplicației prezintă succint fiecare ecran din aplicația client împreună cu o scurtă descriere a funcționalităților acestora. Și aici avem atașate capturi de ecran realizate pe un dispozitiv mobil ce rulează aplicația client.

10

2. Dezvoltarea aplicației server 2.1 Sails.js

Sails.js este o bibliotecă cu sursă deschisă de tip MVC (Model-View-Controller) scrisă în totalitate în limbajul JavaScript. Aceasta este una dintre cele mai populare biblioteci bazate pe Node.js. Sails.js poate fi folosit pentru realizarea de aplicații de tip enterprise, dar mai cu seamă pentru aplicații de tip chat sau jocuri multiplayer.

Figura 2: Structura de tip MVC³

Structura unui proiect bazat pe biblioteca Sails.js este una de tip modulară pentru a permite o dezvoltare cât mai ușoară a aplicației. Împărțirea este realizată după funcționalitatea pe care o are fiecare fișier în proiect.

Din structura proiectului merită menționate următoarele dosare/fișiere importante:

 Dosarul /api conține toată logica aplicației server și are în componență următoarele dosare:

 Dosarul /controllers conține toate clasele care manipulează datele definite în modele cu ajutorul serviciilor;

 Dosarul /models conține clasele ce ajută la reprezentarea datelor din baza de date;

 Dosarul /policies conține politicile ce sunt aplicate în momentul realizării unei cereri către server, dar înainte ca aceasta să ajungă în controller (ex. Verificarea că un utilizator este autentificat atunci când face o cerere);

 Dosarul /services conține clasele care realizează interogări în baza de date cu ajutorul modelelor și apoi returnează răspunsul înapoi către controller.

 Dosarul /config are în componență toate fișierele de configurare necesare funcționării serverului cum ar fi: datele de conectare la baza de date, regulile de rutare, constante folosite în clase, etc.;

3 https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

11

 Dosarul /node_modules conține toate librăriile externe ce au fost instalate în prealabil utilizând comanda npm install nume_librărie ;

 Fișierul app.js reprezintă nucleul serverului, el fiind cel care înglobează toate fișierele descrise mai sus într-un singur proces;

 Fisierul package.json este un fișier ce conține toate datele necesare instalării aplicației pe o mașină ce rulează Node.js.

Figura 3: Structura aplicației server Interacțiunea cu serverul se poate defini în câțiva pași:

1. Utilizatorul realizează o cerere către server printr-o anumită adresă definită în fișierul routes.js;

2. Cererea trece mai întâi prin politicile definite pentru această rută dacă este cazul, iar apoi ajunge în controller;

3. Controllerul apelează un serviciu pentru o interogare în baza de date;

4. Serviciul realizează interogarea cu ajutorul modelului definit pentru respectivul tabel din baza de date și returnează un răspuns către controllerul care l-a apelat;

5. Controllerul preia răspunsul returnat de către serviciu și îl trimite înapoi către utilizator.

12

2.2 Socket.io

Socket.io este o bibliotecă cu sursă deschisă care permite comunicarea bidirecțională în timp real între server și clienți. Comunicarea este bazată pe evenimente, iar protocolul de comunicare este WebSocket.

Această bibliotecă este alcătuită din două părți: o librărie pentru partea de client ce poate fi fie un browser, fie o aplicație pentru mobil și o librărie pentru partea de server.

Un scenariu simplu de interacțiune între client și server poate fi definit astfel:

1. Clientul apeleaza funcția connect() ce primește ca parametru un URL și un port definit de către server;

2. Serverul acceptă cererea de conectare trimisă de către client, iar apoi ascultă pe mai multe evenimente ce ar putea fi emise de către client;

3. Se realizează schimbul de date între client și server;

4. Clientul se deconectează de la server apelând funcția disconnect() sau prin distrugerea obiectul în care era păstrată conexiunea.

Am ales să folosesc această bibliotecă pentru a asigura o experiență de joc cât mai plăcută, toată acțiunea jocului petrecându-se în timp real.

Figura 4: Secțiune din codul unui server ce acceptă conexiuni de timp WebSocket

13

2.3 Configurarea proiectului

În urma creării proiectului cu ajutorul comenzii sails new Planes-Backend au fost

generate în mod implicit fișierele de configurare pentru a putea rula aplicația server fără a face nici o modificare în ele.

Pentru a asigura comunicarea dintre client și server, avem nevoie mai întâi să definim un set de reguli de rutare pentru a asigna fiecărei metode din controller un URL prin care poate fi apelată. Acest lucru se realizează în fișierul routes.js din dosarul /config. Mai jos avem

prezentată o secțiune din acest fișier de configurare:

Figura 5: Secțiune din fișierul /config/routes.js

Apoi, pentru setarea portului pe care va rula aplicația server, dar și pentru configurarea modulului SSL am modificat în fișierul local.js din dosarul /config proprietatea port pentru a defini portul și proprietatea ssl pentru configurarea modulului SSL.

Figura 6: Secțiune din fișierul /config/local.js

Cheia ca vine din engleză de la Certificate Authority și reprezintă un lanț de încredere ce asigură browser-ul sau aplicația că certificatul folosit în cheia cert este unul valid. Acest lanț este format din mai multe certificate ce sunt oferite de către companiile ce vând certificate SSL.

Cheia key reprezintă cheia de criptare cu care a fost realizat certificatul, iar cheia cert reprezintă certificatul în sine. Acest modul asigură un protocol de comunicare sigur între client și server, evitând astfel atacuri de timp man-in-the-middle de exemplu. Serviciile web sunt apelate folosind protocolul https în loc de http cum este definit în mod implicit.

14

Pentru comunicarea cu baza de date a trebuit să configurez în fișierul connections.js din dosarul /config o conexiune oferind adresa, portul și credențialele serverului de tip MongoDB.

Inițial, la instalarea serverului de baze de date nu este configurat un utilizator cu care să se facă conexiunea. Am configurat manual un utilizator pentru a nu lăsa serverul pe oricine să acceseze datele din el.

Figura 7: Exemplu conexiune cu serverul MongoDB

Unele rute ce au fost definite în routes.js trebuie să poată fi accesate doar de către utilizatorii ce s-au autentificat înainte. Acest lucru se poate face după ce am creat o politică ce verifică dacă utilizatorul este autentificat, iar rutele ce folosesc această politică se configurează în fișierul policies.js din dosarul /config astfel:

Figura 8: Definirea rutelor ce folosesc politici

Cheia * reprezintă faptul că toate metodele din acel controller vor folosi politica isAuthorized, iar la MainController doar cele două metode vor folosi aceeași politică. În cazul controllerului AuthController este setat valoarea true deoarece în acest caz nu avem nevoie de nici o politică în metodele din acel controller.

15

Ultima setare care merită menționată este făcută în fișierul cron.js din dosarul /config.

În acest fișier se definesc procesele de tip cron⁴ ce rulează în mod independent de serverul propriu-zis la o anumită perioadă de timp definită în prealabil.

Figura 9: Exemplu configurare cron

Acest cron din exemplu rulează la fiecare cincisprezece secunde și are rolul de a verifica utilizatorii care sunt online în aplicație în acel moment. Logica din spate este următoarea:

1. După ce un utilizator s-a autentificat în aplicație, aceste anunță serverul la fiecare trei secunde printr-o cerere faptul că el este online;

2. În momentul în care serverul a primit o astfel de cerere, el marchează pentru acest utilizator timestamp⁵-ul curent;

3. Atunci când cron-ul rulează, el va verifica pentru fiecare utilizator din lista celor online diferența dintre timestamp-ul curent și cel al utilizatorului;

4. Dacă diferența este mai mare de zece secunde, înseamnă că acel utilizator nu a mai anunțat serverul la fiecare trei secunde că este online, deci va fi marcat ca fiind offline.

Constantele folosite în aplicația server sunt definite tot în dosarul /config într-un fișier creat de mine care este numit const.js. Folosirea constantelor asigură faptul că atunci când dorim să schimbăm o valoare, această va fi schimbată automat în tot proiectul. Ele pot fi accesate în proiect folosind variabila globală sails.config.const.NUME_CONST.

Figura 10: Exemplu definire constante

4 https://en.wikipedia.org/wiki/Cron

5 https://en.wikipedia.org/wiki/Timestamp

16

2.4 Cele trei servere

În urma unei analize realizată înainte de începerea lucrului la aplicația server am ajuns la concluzia că folosirea protocolului WebSocket pentru întreaga comunicare dintre client și server nu este o soluție viabilă. Folosirea acestui protocol presupune menținerea unei conexiuni permanente, iar acest lucru face ca nivelul de date consumate să crească, iar durata de viață a bateriei dispozitivului mobil să scadă.

Așadar, am decis să împart aplicația server în trei părți:

1. Primul server este realizat pe bază de servicii web REST⁶ și se ocupă de toate funcționalitățile aplicației mobile, înafară de ecranele Game Setup și Game, și funcționalitatea Search For Opponent;

2. Al doilea server este realizat cu ajutorul bibliotecii Socket.io și se ocupă de toată logica din spatele jocului propriu-zis. Conexiunea cu acest server începe în momentul când utilizatorul a ajuns în ecranul Game Setup și se termină atunci când revine în ecranul acasă.

3. Al treilea server este realizat tot cu ajutorul bibliotecii Socket.io și conține doar logica din spatele funcționalității Search For Opponent. Conexiunea cu acest server începe în momentul când utilizatorul apasă pe butonul Search for Opponent și se termină atunci când acesta și-a găsit un adversar sau când a renunțat la căutare.

În acest fel, împărțirea aceasta asigură comunicare în timp real între clienți și server doar acolo unde este într-adevăr nevoie, iar bateria dispozitivelor mobile este păstrată în cel mai bun mod posibil.

Mai merită menționat faptul că cele trei servere rulează pe trei porturi diferite însă comunicarea cu serverul de baze de date MongoDB se realizează printr-o singură conexiune.

6 https://spring.io/understanding/REST

17

2.5 MondoDB

Pentru a păstra datele utilizatorilor avem nevoie de o bază de date. Unul dintre avantajele bibliotecii Sails.js este ușurința și flexibilitatea cu care poate comunica cu multe tipuri de baze de date cum ar fi: Postgres, Oracle, MySQL, MongoDB, etc.

MongoDB este un program de baza de date cu sursă deschisă, multiplatformă orientat pe obiecte. MongoDB este clasificat ca fiind NoSQL și folosește documente de tip JSON pentru stocarea datelor. Acesta a fost lansat în anul 2009 de către compania MongoDB Inc. MongoDB prezintă o soluție din ce în ce mai căutată pentru aplicațiile care au nevoie de acces rapid asupra datelor.

Eu am ales să folosesc MongoDB datorită vitezei cu care poate extrage datele și a scalabilității. Datele sunt stocate sub formă de documente, în format JSON, împăcându-se foarte bine cu Node.js.

Pentru a defini un document în MongoDB avem nevoie de un model declarat în aplicația server. Un model este ca o schemă pentru acel document deoarece în el se declară coloanele din acel document și tipul acestora. Tipul datelor poate fi: string, integer, date, etc.

Figura 11: Exemplu Model GameInvitation

18

În figura 11 mai putem vedea declarate și două relații de tip one-to-many⁷ între modelul User și modelul GameInvitation. Aceste relații ușurează extragerea datelor din baza de date și sporește viteza de lucru.

Manipularea datelor se realizează în totalitate cu ajutorul ORM⁸-ului numit Waterline.

Waterline este o colecție de API-uri ce face ca lucrul cu datele din baza de date să fie unul foarte curat și ușor de înțeles, indiferent de tipul de baze de date folosit.

Figura 12: Exemplu de interogare ce returnează invitațiile la joc acceptate trimise de către utilizator

În figura 11, metoda find() este echivalentul lui SELECT din limbajul SQL, metoda populate() este echivalentul lui JOIN din limbajul SQL, iar method exec() este cea care execută interogarea și returnează rezultatul într-o funcție de tip callback⁹ în parametrul result.

Pentru vizualizarea mai ușoară și mai rapidă a datelor în faza de dezvoltare am folosit un utilitar gratuit numit Robomongo¹⁰. Acesta permite reprezentarea vizuală a datelor, dar și execuția de interogări în același mod ca și în terminal.

7 https://en.wikipedia.org/wiki/One-to-many_(data_model)

8 https://en.wikipedia.org/wiki/Object-relational_mapping

9 https://en.wikipedia.org/wiki/Callback_(computer_programming)

10 https://robomongo.org/

19

2.6 isAuthorized

isAuthorized este o politică creată pentru a limita utilizatorii care nu sunt autentificați în aplicație să folosească anumite servicii web. Logica din spate poate fi descrisă astfel:

1. Clientul trece prin procesul de autentificare și primește un token de la server ca și răspuns dacă autentificarea se face cu succes;

2. Atunci când clientul face o cerere către server, acesta atașează în header¹¹ o cheie numită authorization-token ce va conține token-ul primit la autentificare;

3. Token-ul este mai întâi validat de către server, iar dacă validarea se face cu succes, cererea merge mai departe către controller-ul corespunzător. În caz contrar, serverul returnează un răspuns prin care anunță clientul de faptul că token-ul trimis de el este invalid. Același lucru se întâmplă și în cazul în care token-ul lipsește din header.

Figura 13: Secțiune de cod din generarea token-ului

Generarea token-ului pe server se realizează cu ajutorul librăriei numită jsonwebtoken¹². Această librărie conține trei funcții principale: sign(), verify() și decode().

Funcția sign() este exemplificată în figura 13 și este folosită pentru generarea de token.

Primul parametru reprezintă datele ce vor fi criptate, iar al doilea parametru reprezintă o cheie unică cu ajutorul căreia se criptează datele din primul parametru. Metoda de criptare folosită se numește HS256¹³.

Funcția verify() este folosită pentru a verifica dacă un token trimis de către client este unul valid și poate fi decriptat mai departe. Aceasta primește ca parametrii token-ul și cheia de criptare folosită în funcția sign().

Funcția decode() este folosită, după cum sugerează și numele acesteia, pentru

decriptarea token-ului trimis de către client. Parametrii acestei funcții sunt aceiași cu cei folosiți în funcția verify().

11 https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

12 https://github.com/auth0/node-jsonwebtoken

13 https://en.wikipedia.org/wiki/JSON_Web_Token

20

Figura 14: Secțiune de cod din procesul de decriptare a unui token

După fiecare proces de decriptare se verifică dacă id-ul conținut de acel token este unul din baza de date și dacă aparține unui utilizator. În cazul în care acesta este găsit în baza de date, trimite cererea mai departe către controller cu ajutorul metodei next(). Dacă id-ul nu există în baza de date, se trimite un răspuns clientului prin care se anunță acest lucru.

În realitate, acest token nu ar putea fi niciodată invalid dacă este trimis de cineva care folosește aplicația. El ar putea fi invalid doar dacă cineva ar face reverse engineering¹⁴ la aplicație și ar descoperi că trebuie să trimită acest token pentru a avea acces la aceste servicii web.

2.7 Multiple logins

Serverul tratează într-un mod elegant cazul în care un utilizator dorește să se autentifice în aplicație, dar acesta deja este autentificat pe un alt dispozitiv în acel moment. Dacă acest lucru nu ar fi tratat, atunci ar putea apărea conflicte la nivel de server și eventual crash-uri.

La fiecare proces de autentificare sau la fiecare revenire în aplicație fiind deja

autentificat, se salvează în baza de date pentru acel utilizator token-ul folosit mai departe în cereri. În acest mod, un utilizator poate avea doar un singur token valid într-un moment oarecare.

Putem distinge două cazuri de autentificare multiplă:

14 https://en.wikipedia.org/wiki/Reverse_engineering

21

1. Utilizatorul dorește să se autentifice. Dacă acesta este deja autentificat pe un alt dispozitiv și este într-un meci, va primi o alertă pe noul dispozitiv ce îl va anunța că nu se poate autentifica din această cauză. Dacă deja este autentificat, dar nu este într-un meci, atunci acesta va trece de procesul de autentificare, noul token generat îl va suprascrie pe cel vechi, iar celălalt dispozitiv va fi anunțat în câteva secunde că sesiunea i-a expirat și va fi trimis către ecranul de autentificare.

2. Utilizatorul este deja autentificat dintr-o sesiune anterioară și intră în aplicație.

Serverul va face o verificare în baza de date după ce token-ul a fost decriptat pentru a verifica dacă acest token se potrivește cu cel din baza de date. Dacă se potrivește atunci el va fi trimis către ecranul acasă, altfel va fi anunțat ca

sesiunea i-a expirat și va fi trimis către ecranul de autentificare.

Figura 15: Secțiune de cod din funcția care verifică token-ul în cazul în care utilizatorul este deja autentificat

22

2.8 Lucrul cu imagini

Aplicația permite utilizatorilor care și-au creat cont în aplicație să își seteze o imagine de profil după propria lor dorință. Fișierul poate proveni din orice sursă, atât timp cât el este încărcat prin aplicație.

Pentru prelucrarea imaginilor am folosit librăria numită gm ce are la bază o altă librărie numită GraphicsMagick¹⁵.

GraphicsMagick este o colecție de funcții folosite pentru procesarea de imagini. Ea poate fi instalată și folosită pe majoritatea sistemelor de operare. Printre numeroasele funcții se numără și convertirea de fișiere, redimensionarea, rotirea, modificarea culorilor chiar și compararea a doua imagini.

Fișierele trimise de către utilizatori sunt redimensionate la o dimensiune fixată de 500 pe 500 de pixeli, sunt decupate în formă de pătrat pentru a se putea afișa bine în aplicația mobilă și apoi sunt salvate pe disc într-o locație aflată în exteriorul dosarului unde se afla codul serverului. Acest lucru previne ștergerea accidentală a imaginilor atunci când se trag modificări ale codului de pe GitHub. Fișierele care nu mai sunt folosite sunt șterse pentru a nu ocupa spațiu inutil pe disc.

Pentru a putea servi imaginile din server în aplicație am creat un server în Apache¹⁶ care redirecționează cererile făcute pe portul 443 către dosarul cu imagini de pe disc.

Figura 16: Secțiune de cod din procesul de salvare a imaginilor pe disc

15 http://www.graphicsmagick.org/

16 https://httpd.apache.org/

23

2.9 Push Notification

Firebase Cloud Messaging (FCM) este o soluție gratuită multiplatformă care permite trimiterea de notificări push către dispozitivele mobile și care este oferită de către Google.

Am ales să folosesc acest serviciu pentru a anunța utilizatorii de anumite evenimente petrecute în aplicație chiar și când aceștia au aplicația închisă. Un exemplu de eveniment este primirea unei invitații la joc de la un alt utilizator al aplicației.

În primul rând, pentru folosirea serviciului FCM a fost nevoie să creez o aplicație pe site- ul celor de la Google Firebase, iar de acolo să iau un cheie numită Server key care este folosită mai departe pentru a trimite notificări către dispozitive.

În al doilea rând, pentru folosirea serviciului FCM în aplicația server a mai fost nevoie să instalez biblioteca node-gcm ce permite trimiterea de notificări dintr-un server scris în Node.js.

Un utilizator poate avea într-un moment oarecare maxim un token pentru notificări push salvat în baza de date. Acest lucru face ca utilizatorul să primească notificări push doar pe dispozitivul pe care este autentificat în acel moment.

Figura 17: Secțiune de cod din procesul de trimitere a notificărilor push

24

2.10 Email service

Pentru trimiterea de email-uri către utilizatori am folosit librăria numită nodemailer ce permite trimiterea de email-uri cu conținut text, dar și cu conținut de tip HTML.

Protocolul prin care se trimit aceste email-uri este SMTPS care reprezintă o metodă de securizare a protocolului STMP. Protocolul SMTP este un standard al internetului ce permite transmiterea de email-uri. Acesta a fost definit prima dată în anul 1982 și a fost actualizat ultima dată în anul 2008. Portul folosit de protocolul SMTPS este 587.

În inițializarea librăriei nodemailer avem nevoie de o adresă de email validă ce va fi folosită pe post de server pentru trimiterea de email-uri. În cazul meu am folosit adresa personală de Gmail. Utilizatorii primesc email-uri doar după primul pas din procesul de înregistrare sau după primul pas din procesul de resetare parolă.

Figura 18: Secțiune de cod din procesul de trimite a unui email

25

2.11 Main service

Pentru a realiza funcționalitatea jocului propriu-zis a trebuit să stochez undeva datele despre meciurile aflate în progres, dar nu am putut să le stochez în baza de date. Motivul este acela că baza de date ar fi să facă foarte multe scrieri și citiri pentru fiecare meci în parte ceea ce ar îngreuna timpul de răspuns, respectiv experiența de joc. Așa că am ales să creez un serviciu numit MainService ce păstrează aceste date direct pe server.

Structura acestui serviciu este următoarea:

Figura 19: Secțiune de cod din clasa MainService

În figura 19 putem observa următoarele chei: onlinePlayers și onlinePlayersTimestamps care reprezintă doi vectori în care sunt stocate id-urile utilizatorilor online, respectiv ultimul timestamp din momentul când aceștia au anunțat serverul că sunt online. Mai putem observa și cheile inGamePlayers unde sunt stocate id-urile utilizatorilor care se află într-un meci și cheia waitingOpponent care este folosită pentru funcționalitatea Search for Opponent. Cea mai importantă cheie această clasă este gameRooms unde sunt păstrate toate informațiile despre meciurile aflate în derulare în orice moment pe server.

O cameră de joc se creează în momentul în care un utilizator trimite o invitație de joc unui alt utilizator sau în momentul când doi utilizatori sunt introduși în meci în urma apăsării butonului Search for Opponent.

O cameră de joc este distrusă în momentul când meciul s-a terminat, iar ambii utilizatori au refuzat remiza sau atunci când ambii utilizatori părăsesc jocul, fie intenționat, fie din cauza lipsei de conexiune la internet.

26

Figura 20: Secțiune de cod din procesul de creare a unei camere de joc

Fiecărei camere de joc îi este atribuit un id unic generat cu ajutorul librăriei uuid care asigură că la fiecare generare returnează un șir de caractere unic.

În cazul în care în timpul meciului unul dintre jucători este deconectat de la server din cauza lipsei conexiunii la internet, starea meciului se păstrează intactă timp de treizeci de secunde, timp în care jucătorul deconectat se poate reconecta în meci și poate continua de unde a rămas în momentul deconectării. Toate informațiile necesare pentru reconectarea în meci sunt păstrate în aceste obiecte numite camere de joc.

Dacă jucătorul deconectat nu s-a reconectat în cele treizeci de secunde acordate, el este declarat pierzător, iar oponentul său este declarat învingător.

27

3. Dezvoltarea aplicației client 3.1 AngularJS 2

AngularJS 2 este urmașul binecunoscutului AngularJS 1, bibliotecă ce permite realizarea părții de front-end a aplicațiilor web.Acesta a fost lansat în anul 2010 de către compania Google, iar principala lui caracteristică este posibilitatea de a crea aplicații web pe o singură pagină (“single-page”).

AngularJS 2 nu a fost lansat încă, acesta fiind în beta¹⁷. Schimbările față de predecesorul său sunt în primul rând în materie de performanță, dar și de organizare a codului. Limbajul în care este scris AngularJS 2 este TypeScript.

TypeScript este un limbaj realizat de către cei de la GitHub ce permite scrierea de clase, interfețe, etc. ca apoi acestea să fie compilate și transformate în cod JavaScript.

Figura 21: Secțiune de cod scrisă în TypeScript

17 https://en.wikipedia.org/wiki/Software_release_life_cycle#Beta

28

3.2 Ionic 2

Ionic 2 este o bibliotecă cu sursă deschisă ce permite realizarea de aplicații mobile folosind limbaje web. Acesta este succesorul bibliotecii Ionic 1 ce a fost lansată în anul 2013 de către compania Drifty.

Ionic 2 este scrisă cu ajutorul bibliotecii AngularJS 2 și se află în același stagiu ca și AngularJS2, adică în beta. Pentru a putea compila aplicații pentru dispozitive mobile, Ionic 2 se folosește de librăria Cordova. Cordova permite folosirea de funcționalități native ale

dispozitivelor în cod scris în JavaScript/TypeScript, cum ar fi: camera foto, geolocation, vibration, etc.

Structura unui proiect realizat cu ajutorul lui Ionic 2 este una de tip modulară.

Împărțirea este realizată în funcție de ecran, fiecare ecran având dosarul său.

Din structura proiectului merită menționate următoarele dosare/fișiere importante:

 Dosarul node_modules conține librăriile instalate cu ajutorul comenzii npm install;

 Dosarul platforms conține build-urile aferente fiecărei platforme: android, ios, windows phone;

 Dosarul plugins conține plugin-urile ce fac legătura între funcționalitățile native ale dispozitivului și AngularJS 2;

 Dosarul resources conține resursele folosite în aplicație: pictogramele și ecranele splash

 Dosarul res reprezintă nucleul aplicației, aici aflându-se toată logica aplicației;

 Dosarul app conține componenta principală ce rulează la deschiderea aplicației;

 Dosarul pages conține toate ecranele prezente în aplicație, fiecare ecran având în dosarul său un fișier HTML, unul SCSS și unul TypeScript;

 Fișierul index.html ce reprezintă primul fișier executat la deschiderea aplicației, acesta dând startul celorlalte component din aplicație.

 Dosarul www conține același cod cu dosarul res doar că în acest caz toate fișierele de tip JavaScript sunt comprimate într-un singur fișier, la fel și pentru fișierele de tip SCSS.

Conținutul acestui dosar este folosit în momentul în care se creează un build pentru o anumită platformă;

 Fișierul package.json este un fișier ce conține toate datele necesare instalării aplicației pe o mașină ce rulează Node.js.

29

Figura 22: Structura unui proiect realizat cu ajutorul bibliotecii Ionic 2

În faza de dezvoltare, aplicația se poate testa în browser rulând comanda ionic serve.

Această comandă va deschide un nou tab cu aplicația simulând astfel un dispozitiv mobil.

Pentru rularea proiectului pe un dispozitiv cu sistemul de operare Android, se rulează comanda ionic run android --prod , iar pentru realizarea unui build se rulează comanda ionic build android --release --prod . După rulare, build-ul creat se va afla în locația

/platforms/android/build/outputs/apk/android-release-unsigned.apk.

Principalul avantaj al bibliotecii Ionic 2 este acela că aplicația în sine este scrisă o singură dată, iar apoi este compilată pentru orice sistem de operare mobil. Singurele intervenții

necesare sunt în cadrul design-ului unde elementele din ecran pot arăta diferit pe două sisteme de operare diferite.

30

3.3 localStorage

localStorage este un obiect disponibil în orice browser care suportă limbajul HTML în versiunea cinci și este folosit în stocarea permanentă a datelor.

Acest obiect seamănă ca și funcționalitate cu obiectul care păstrează sesiunile în browser, diferența fiind lipsa unei date de expirare a datelor din obiect în cazul localStorage.

Datele din localStorage pot fi șterse în două moduri: prin apelarea directă a funcției localStorage.removeItem(”nume_cheie”) sau atunci când aplicația este dezinstalată din dispozitivul mobil.

Manipularea datelor din localStorage se realizează ușor cu ajutorul metodelor setItem() și getItem().

Metoda setItem() primește doi parametrii, primul fiind numele cheii unde se stochează datele, iar al doilea parametru reprezintă datele se urmează a fi stocate, sub formă de șir de caractere. Pentru a transforma datele într-un șir de caractere se folosește metoda

JSON.stringify() înainte de apelararea metodei setItem().

Metoda getItem() primește doar un parametru, acesta fiind numele cheii unde sunt stocate datele și returnează datele sub formă de șir de caractere. Pentru a transforma acest șir de caractere înapoi în obiectul inițial, se apelează metoda JSON.parse().

În aplicația client am folosit localStorage pentru a memora anumite date ce fac ca utilizarea aplicației de către utilizator să fie cât mai plăcută.

Un exemplu este memorarea token-ului primit după autentificare pentru a permite autentificarea automată a utilizatorului la următoarele accesări ale aplicației. Putem spune că acest lucru funcționează pe același principiu ca și cookie¹⁸-urile din browser. În momentul în care utilizatorul deschide aplicația, se verifică dacă acest token se află în localStorage în cheia authorization-token, iar dacă acesta se află atunci el este trimis către server pentru a verifica dacă acesta este valid. În același timp, serverul verifică și dacă de la ultima accesare a aplicației acest utilizator s-a mai autentificat și pe alt dispozitiv. În acest caz el va fi anunțat că sesiunea a expirat și va trimis către ecranul de autentificare. Dacă serverul spune că token-ul trimis este valid, atunci utilizatorul este trimis direct către ecranul acasă.

Un alt exemplu este salvarea id-ului camerei de joc la începutul fiecărui meci și

ștergerea acestuia la sfârșitul fiecărui meci. În acest mod, în momentul când utilizatorul intră în aplicație se verifică dacă acesta are un meci care se află în desfășurare, iar dacă se află atunci acesta este anunțat că se poate reconecta pentru a continua meciul de unde a rămas în momentul deconectării de la server sau în momentul când acesta a pierdut conexiunea la internet.

18 https://en.wikipedia.org/wiki/HTTP_cookie

31

Figura 23: Secțiune de cod din metoda utilizată pentru a verifica validitatea token-ului din localStorage

3.4 ApiService

Pentru ca aplicația să poată funcționa are nevoie să comunice cu aplicația server, iar pentru a comunica cu aceasta avem nevoie de modulul Http deja inclus în codul de bază al bibliotecii AngularJS 2.

Cu scopul de a face codul mai ușor de citit, dar și pentru a menține o anumită ordine în cod am ales să creez un serviciu numit ApiService care se ocupă cu trimiterea de cereri către server de tip și manipularea răspunsurilor primite de la acesta.

Primele două metode prezente în acest serviciu sunt folosite pentru a adăuga în header valorile necesare înainte de a face cererea către server.

Prima dintre ele adaugă în header cheia Authorization-Token pentru serviciile web ce necesită ca utilizatorul să fie autentificat, iar valoarea pentru această cheie este preluată din obiectul global localStorage.

Cea de-a doua metodă adaugă în header cheia Content-Type și valoarea

application/json, aceasta fiind folosită doar în cazul cererilor de tip POST pentru a anunța aplicația server că datele trimise de către aplicație sunt în format JSON.

32

Figura 24: Secțiune de cod cu funcțiile ce modifică header-ul

În continuare am declarat alte două metode ce se ocupă de trimiterea de cereri către server de tip GET, respectiv POST. Aceste două metode au functionalități foarte asemănătoare, iar din această cauză voi descrie doar pe una dintre ele, adică metoda post().

În metoda post(), în apelul funcției subscribe(), metodă ce așteaptă de la server un răspuns, avem dați ca parametrii două funcții de tip callback, prima dintre ele executându-se în momentul în care aplicația server a returnat un răspuns, iar cea de-a doua executându-se atunci când serverul nu răspunde sau când dispozitivul mobil nu dispune de conexiune la internet.

Figura 25: Secțiune de cod din metoda post()

Dacă aplicația a primit un răspuns de la server, mai întâi se verifică dacă codul primit corespunde cu cel pentru evenimentul de sesiune expirată, în acest caz utilizatorul fiind trimis către ecranul de autentificare. Dacă sesiunea nu a expirat, atunci se apelează funcția callback

33

trimisă ca parametru prin care se returnează datele în controller sau serviciu. Parametrul secure se trimite cu valoarea true dacă acel serviciu necesită trimiterea în header a parametrului Authorization-Token, iar cu valoarea false în caz contrar.

În cazul în care aplicația nu a primit un răspuns de la server atunci se afișează pe ecran un mesaj care îl anunță pe utilizator că acesta s-a deconectat și în același moment se apelează o funcție care verifică la fiecare trei secunde dacă aplicația s-a reconectat cu aplicația server.

3.5 DataService

Unele date din aplicație trebuie să poată fi accesibile din toate controllerele și serviciile acesteia cum ar fi datele despre utilizator după autentificare sau datele despre meciul aflat în desfășurare. Pentru acest lucru am creat un nou serviciu numit DataService.

DataService este o clasă de tip Injectable¹⁹ ce se instanțiază o singură dată la

deschiderea aplicației și păstrează în interiorul ei anumite date la fel ca și obiectul localStorage, doar că datele din DataService se vor pierde la închiderea aplicației. Acest serviciu este injectat în clasa AppModule pentru a avea o singură instanță a acestuia pe toată durata de execuție a aplicației.

Un exemplu de date stocate în acest serviciu sunt datele despre utilizator ce sunt afișate în meniul lateral sau în pagina de profil a utilizatorului. Obiectul userData este inițializat ca fiind un obiect gol în funcția constructor a clasei DataService și îi sunt atribuite date în momentul când aplicația primește răspuns de la server în urma unei autentificări realizate cu succes sau în momentul când aplicația este deschisă și se verifică dacă token-ul stocat în localStorage este valid. În aceeași variabilă userData se mai reține și variabila booleană isGuest care va avea valoarea true dacă utilizatorul este autentificat în aplicație ca fiind Oaspete și valoarea false în caz contrar.

Un al doilea exemplu în acest serviciu sunt datele despre meciul aflat în desfășurare ce sunt stocate în variabila gameData. Motivul principal pentru folosirea acestei variabile este nevoia de a avea acces la datele despre meci din ecranul Game Setup în ecranul Game.

19 https://angular.io/docs/ts/latest/api/core/index/Injectable-decorator.html

34

Figura 26: Secțiune de cod cu clasa DataService

3.6 Push Notification

Pentru a putea primi notificări push trimise de către aplicația server am instalat plugin-ul cordova-plugin-fcm. Acest plugin este unul cu sursă deschisă și permite acceptarea și afișarea notificărilor native ale dispozitivului mobil cu ajutorul bibliotecii AngularJS 2.

Configurarea acestuia este foarte rapidă, fiind nevoie de un apel al metodei getToken() și de un apel al metodei onNotification().

Metoda getToken() generează un token ce va fi folosit de către serviciul FCM²⁰ pentru a trimite notificări push către acest dispozitiv mobil. Răspunsul returnat de către această metodă este apoi trimis către server pentru a fi salvat în baza de date.

Figura 27: Secțiune de cod cu metoda getToken()

20 https://firebase.google.com/docs/cloud-messaging/

35

Metoda onNotification() este apelată la intrarea în aplicație și are rolul de a asculta orice notificare push ce va fi trimisă de către server. În datele trimise prin intermediul notificării va fi prezentă tot timpul o cheie ce va fi folosită de către aplicația client să trimită utilizatorul către ecranul corespunzător în urma apăsării pe notificare.

Figura 28: Secțiune de cod cu metoda onNotification()

3.7 Globals

La fel ca în aplicația server, și în aplicația client am creat un obiect numit GlobalVariable ce are rolul de a reține variabile constante folosite în toată aplicația. Acest lucru ușurează foarte mult munca în cazul în care trebuie schimbată una dintre valori nefiind nevoie să schimbi în tot proiectul unde e folosită.

Printre datele stocate ca și constante în acest obiect merită menționate următoarele:

 Adresele împreună cu port-urile către cele trei servere ale aplicației server, cât și adresa de unde pot fi accesate imaginile de profil ale utilizatorilor. Folosirea constantelor în acest caz ajută în momentul în care se lucrează cu două sau mai multe mașini pe care este instalată aplicație server, de exemplu putem avea o mașină folosită în faza de dezvoltare și o mașină în faza de producție;

36

 Căile către fiecare serviciu web oferit de către aplicația server. La fel ca și în cazul precedent acest lucru ajută în cazul în care una dintre căi este schimbată dintr- un oarecare motiv;

 Codurile primite ca și răspuns de la server în urma unei cereri efectuate către acesta. Exemplu: 500 pentru sesiune expirată, 400 pentru eroare, etc.

Figura 29: Secțiune de cod cu obiectul GlobalVariable

3.8 LoadingService

LoadingService este un serviciu ce se ocupă de toate ecranele de încărcare din aplicație.

Nevoia de a avea un astfel de serviciu a venit după ce mi-am dat seama că unele ecrane de încărcare trebuie să poată apărea peste orice ecran din aplicație, însă acestea nu ar putea fi afișate deoarece nu se află în domeniul de aplicare al controllerului ce conține ecranul afișat în acel moment. LoadingService rezolvă acest lucru prin utilizarea unui vector de obiecte de tip Observable²¹ care ascultă anumite evenimente din aplicație, iar la primirea unui eveniment execută o anumită funcție declarată în ecranul de încărcare dorit. Clasa LoadingService se inițializează o singură dată la pornirea aplicației.

Un astfel de ecran de încărcare este cel ce apare atunci când utilizatorul a trimis o invitație la joc către alt utilizator, iar acel utilizator a acceptat invitația. În acel moment, pe întreg ecranul va aparea peste ecranul curent un nou ecran care îl va anunța ca oponentul său a acceptat invitația, iar după o secundă acesta este introdus în meci, adică în ecranul Game Setup.

21 https://angular-2-training-book.rangle.io/handout/observables/using_observables.html

37

Figura 30: Secțiune de cod din clasa LoadingService

Un alt ecran de acest fel este afișat în momentul când aplicația server a picat sau când utilizatorul nu mai dispune de conexiune la internet. Dacă după orice cerere făcută către server, clasa ApiService primește răspuns pe funcția callback de eroare, atunci peste ecranul curent va apărea un ecran de încărcare prin care utilizatorul va fi anunțat că a pierdut conexiunea cu serverul și că se încearcă recuperarea acesteia.

Figura 31: Exemplu de afișare a ecranului de încărcare în cazul pierderii conexiunii

3.9 Electron

Electron este o bibliotecă cu sursă deschisă dezvoltată de compania GitHub și permite realizarea de aplicații native pentru sistemele de operare Windows, MacOS și Ubuntu cu ajutorul limbajelor web.

Structura unui proiect realizat cu Electron este asemănătoare cu cea din Ionic 2, iar realizarea aplicației Planes pentru sistemul de operare Windows a fost foarte ușoară, fiind necesari doar trei pași simpli:

1. Crearea unui proiect gol în care am creat fișierul main.js ce conține minimul necesar pentru crearea unei aplicații utilizând Electron și fișierul package.json în care au fost declarate dependențele necesare pentru instalare;

2. Rularea comenzii npm install pentru instalarea tuturor librăriile necesare ce au fost declarate în package.json;

38

3. Copierea conținutului din dosarul /www al proiectului Ionic 2 în același dosar cu fișierele menționate mai sus, main.js și package.json.

39

4. Descrierea aplicației 4.1 Login

Primul ecran cu care utilizatorul este întâmpinat atunci când intră în aplicație pentru prima dată este cel de autentificare.

Accesul propriu-zis în aplicație se face numai după ce utilizatorul trece de acest ecran și primește de la server o așa zisă identitate pentru a putea fi identificat mai târziu în ecranele următoare.

Autentificarea se poate face în două moduri: cu ajutorul unui cont ce a fost creat în prealabil din ecranul de înregistrare sau cu un cont de pe rețeaua de socializare Facebook. Dacă utilizatorul nu dorește să se autentifice, dar totuși dorește să folosească aplicația, acesta poate să continue ca și Oaspete apăsând butonul Continue as Guest. În cazul acesta îi va fi

restricționat accesul la principalele funcționalități ale aplicației, acesta putând doar să joace contra unor utilizatori aleși aleatoriu de către server.

Figura 32: Ecranul de autentificare

40

4.2 Register

Ecranul de înregistrare este cel ce permite utilizatorului să își creeze un cont pentru a putea folosi toate funcționalitățile oferite de aplicație. Cele 4 câmpuri necesare înregistrării sunt: Email, Username, Parolă și Confirmare Parolă. Email-ul va fi utilizat ulterior în procesul de autentificare, iar username-ul va fi folosit pentru a putea fi identificat în aplicație și în timpul jocului.

Modalitatea de verificare a identității unui utilizator în momentul înregistrării este obligativitatea confirmării contului cu ajutorul unui cod aleatoriu de patru cifre primit pe adresa de email introdusă în câmpul Email. În acest fel putem fi siguri că acea adresă de email este în realitate deținută de către acest utilizator.

În cazul în care un utilizator introduce o adresă de email pe care nu o poate confirma, contul creat va rămâne inactiv până în momentul în care adevăratul posesor al adresei de email își va crea un cont. Acesta din urmă va suprascrie informațiile introduse de primul utilizator în formularul de înregistrare.

Figura 33: Ecranul de înregistrare Figura 34: Ecranul de confirmare cont

41

4.3 Forgot Password

Ecranul de resetare parolă oferă utilizatorului posibilitatea de a-și reseta parola contului în cazul în care acesta nu și-o mai amintește. Pentru a face acest lucru, acesta trebuie să

introducă adresa de email cu ajutorul căreia și-a creat contul în trecut.

Dacă adresa de email introdusă de către utilizator există în baza de date se va genera un cod aleatoriu de patru cifre pentru a confirma că el este posesorul adresei de email înainte de a-i oferi posibilitatea de a-și reseta parola. Acest lucru împiedică ca o persoană rău intenționată să poată să schimbe parola contului unui alt utilizator dacă acesta cunoaște adresa de email a acestuia.

Figura 35: Ecranul de resetare parolă Figura 36: Ecranul de confirmare a identității

42

4.4 Home

Ecranul Acasă reprezintă ecranul cu care este întâmpinat utilizatorul după ce acesta s-a autentificat sau după ce acesta a deschis aplicația, el fiind autentificat în trecut.

Aici putem observa o listă cu ultimele patru meciuri ale utilizatorului în ordine

descrescătoare a datei în care a fost jucate. În partea în care culoarea textului este verde este reprezentat câștigătorul meciului, iar în partea opusă, cu roșu, este reprezentat pierzătorul.

Această listă nu va conține nici un meci la prima accesare după înregistrare și se va umple pe măsură ce utilizatorul va juca.

În partea de sus avem butonul Search for Opponent care odată apăsat introduce

utilizatorul într-o coadă de așteptare până când un alt utilizator va apăsa și el pe acest buton. În cazul în care în momentul apăsării un alt jucător este în așteptare, cei doi vor fi introduși în meci automat.

Mai putem observa în colțul din dreapta sus un buton ce duce utilizatorul pe ecranul cu invitațiile la joc. Numărul aflat în cerculețul roșu reprezintă numărul de invitații active primite până în acel moment. Acest număr este actualizat în mod automat la fiecare 3 secunde.

Figura 37: Ecranul Acasă

43

4.5 Side Menu

Meniul principal este de două tipuri. Utilizatorului autentificat ca fiind Oaspete i se oferă doar două butoane: Home și Logout ce permite deconectarea din aplicație. Utilizatorului

autentificat în mod clasic i se oferă toate butoanele aferente ecranelor din aplicație.

Figura 38: Meniul lateral

44

4.6 Game Invitations

Ecranul cu invitații la joc conține toate invitațiile active primite de către utilizator.

Fiecare invitație menționează cât timp a trecut de la primirea acesteia, iar utilizatorul poate lua două decizii asupra acestora.

Dacă utilizatorul decide să refuze invitația la joc, celălalt utilizator este anunțat prin notificare push în privința acestui lucru.

Dacă utilizatorul decide să accepte invitația la joc, acesta este trimis în ecranul de start joc, iar celălalt utilizator este trimis și el în mod automat către același ecran. În cazul în care în urma acceptării unei invitații serverul anunță că cel care a trimis invitația este în alt meci sau este ieșit din aplicație, utilizatorul este anunțat de acest lucru, iar invitația este ștearsă.

Figura 39: Ecranul cu invitații la joc

45

4.7 Profile

Ecranul de profil reprezintă ecranul în care sunt afișate informații despre utilizator. În partea de sus avem imaginea de profil împreună cu un buton ce permite schimbarea acesteia cu una aleasă de către utilizator. La înregistrare, contului i se atribuie în mod implicit o imagine stocată în prealabil pe server.

Sub secțiunea cu informațiile despre utilizator mai avem două butoane, Update Info și Change Password ce permit acestuia să iși schimbe informațiile despre cont, respectiv să își schimbe parola contului.

Figura 40: Ecranul de profil

46

4.8 Update Info / Change Password

Ecranul Update Info permite utilizatorului să își modifice username-ul ales la înregistrare cu un altul preferat de el. Nu există restricție ca acesta să fie unic, însă există restricție ca acesta să conțină maximum douăsprezece caractere.

Ecranul Change Password permite utilizatorului să își schimbe parola curentă a contului.

Aici avem o primă validare care constă în introducerea parolei vechi pentru a proteja contul de persoane rău intenționate. Apoi mai avem o restricție ca parola să conțină minimum opt caractere pentru a spori securitatea contului.

Figura 41: Ecranul Update Info Figura 42: Ecranul Change Password

47

4.9 Friend List / Search Players

Ecranul Friend List conține lista de prieteni ai utilizatorului. Pentru fiecare utilizator avem în stânga o bulina ce poate avea una din următoarele culori: gri dacă acel prieten este deconectat, verde dacă acel prieten este conectat, iar albastru dacă se află într-un meci. În partea dreaptă avem două butoane, primul permite invitarea acelui prieten la joc, iar al doilea permite ștergerea acelui prieten din listă. În cazul în care un prieten este invitat la joc, acel utilizator va primi o notificare push prin care este anunțat că a primit o invitație. Din acel moment utilizatorul care a trimis invitația trebuie doar să aștepte ca celălalt să accepte

invitația. Dacă un prieten este șters din lista, automat și acest utilizator este șters din lista lui de prieteni.

Dacă utilizatorul apasă pe buton + din colțul dreapta sus, acesta este trimis într-un alt ecran numit Search Players unde poate adăuga noi persoane la lista de prieteni. Căutarea se face dupa username, iar ca rezultat sunt afișați primii 15 utilizatori în ordinea relevanței căutării. Rezultatele căutarii sunt extrase din tabelul cu toți utilizatorii, exceptând pe cei care sunt deja prieteni cu utilizatorul care face căutarea.

Figura 43: Ecranul Friend List Figura 44: Ecranul Search Players

48

4.10 Friend Requests / Match History

Ecranul Friend Requests conține toate cererile de prietenie primite de către utilizator care nu au fost acceptate sau refuzate încă. Dacă utilizatorul dorește să accepte sau să refuze o cerere de prietenie, atunci celălalt utilizator este anunțat prin notificare push în privința deciziei acestuia.

Ecranul Match History istoricul ultimelor 20 de meciuri ale utilizatorului. Meciurile cu fundal verde reprezintă victoria, iar cele cu fundal roșu reprezintă înfrângerea.

Figura 45: Ecranul Friend Requests Figura 46: Ecranul Match History

49

4.11 Game Setup

Ecranul Game Setup reprezintă primul ecran din jocul propriu-zis. În acest ecran fiecare dintre cei doi jucători trebuie să își amplaseze strategic cele trei avioane pentru a fi cât mai greu de ghicit de către adversar. După ce toate avioanele au fost amplasate, apăsarea butonului Ready îl trimite pe utilizator în ecranul Game. Dacă adversarul nu și-a amplasat încă avioanele utilizatorul trebuie să aștepte până acesta termină de amplasat, iar dacă adversarul era deja gata atunci jocul poate începe.

Figura 47: Ecranul Game Setup

50

4.12 Game

Ecranul Game reprezintă ecranul pe care utilizatorul ajunge după ce a apăsat butonul Ready pe ecranul precedent, Game Setup.

În acest moment fiecare dintre cei doi jucători vor încerca pe rând să ghicească câte o celula din avionul adversarului. Dacă unul dintre jucători nimerește capul unuia dintre avioanele adversarului (marcate cu albastru) atunci acel avion este complet distrus.

Jocul se termină în momentul în care unul dintre jucători are toate cele trei avioane complet distruse de către adversar. Câștigător este considerat jucătorul care nu are toate avioanele distruse, iar pierzător celălalt jucător.

Figura 48: Ecranul Game, runda Figura 49: Ecranul Game, runda adversarului jucătorului curent

51

4.13 End Game

Ecranul End Game apare atunci când un joc s-a terminat, iar cei doi jucători au fost declarați învingător, respectiv pierzător. Dacă oricare dintre cei doi dorește remiza, atunci acesta îl poate invita pe adversar să joace din nou între ei. În momentul în care adversarul acceptă, cei doi sunt trimiși înapoi în ecranul Game Setup pentru a-și amplasa din nou avioanele pentru un nou joc.

Figura 50: Ecran End Game, Figura 51: Ecran End Game, jucător victorios jucător înfrânt

52

5. Bibliografie

1.

JavaScript

Bhangal, Sham; Jankowski, Tomasz (2003). Foundation Web Design:

Essential HTML, JavaScript, CSS, PhotoShop, Fireworks, and Flash.

2. Node.js

https://en.wikipedia.org/wiki/Node.js

3. Sails.js

http://sailsjs.org/

4. Socket.io

https://en.wikipedia.org/wiki/Socket.IO

5. MongoDB

Banker, Kyle (March 28, 2011), MongoDB in Action (1st ed.) 6. AngularJS

https://en.wikipedia.org/wiki/AngularJS

7. Ionic

https://github.com/driftyco/ionic

8. Electron

https://github.com/electron/electron

9. Jocul X și O

http://familist.ro/jocul-x-si-0-pe-hartie-cel-mai-vechi-joc-din-istorie

10. Avioane (Joc)

https://ro.wikipedia.org/wiki/Avioane_(joc)