UNIVERSITATEA „DUNĂREA DE JOS” DIN GALAȚI

FACULTATEA DE AUTOMATICĂ, CALCULATOARE, INGINERIE

ELECTRICĂ ȘI ELECTRONICĂ

Anexa 8 la Regulamentul de întocmire a proiectelor de diplomă și a lucrărilor de disertație

PROIECT DE DIPLOMĂ

Îndrumă tor proiect/Coordonator științific,

Dr. Ing. Dan Munteanu
Absolvent,
Bogdan-Ionuț
Mihailov

Galați
2019
 UNIVERSITATEA „DUNĂREA DE JOS” DIN GALAȚI
FACULTATEA DE AUTOMATICĂ, CALCULATOARE, INGINERIE
ELECTRICĂ ȘI ELECTRONICĂ

SPECIALIZAREA:Calculatoare și Tehnologia informației

Aplicație de chat pe mobil

Coordonator științific,
Dr. Ing. Dan Munteanu
Absolvent,
Mihailov
Bogdan-Ionuț

Galați
2019

Departamentul __________________________________________________________________________

Str. Științei Nr. 2, cod poștal 800146, Galați, România, tel/fax: +0236 470 905, e-mail: aciee@ugal.ro, web: www.aciee.ugal.ro
 UNIVERSITATEA „DUNĂREA DE JOS” DIN GALAȚI
FACULTATEA DE AUTOMATICĂ, CALCULATOARE, INGINERIE
ELECTRICĂ ȘI ELECTRONICĂ

Anexa 1 la Regulamentul de întocmire a proiectelor de diplomă și a lucrărilor de disertație

PROIECT DE DIPLOMĂ /LUCRARE DE DISERTAŢ IE

Numele si prenumele absolventului:

_____________________________________________________________
Domeniul / Specializarea:
_________________________________________________________________________
Tema proiectului de diplomă / lucră rii de disertație
____________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
________________________________
Conducă tor științific:
______________________________________________________________________________
Consultant de specialitate:
________________________________________________________________________
Data primirii temei:____________________________
La elaborarea proiectului de diplomă / lucră rii de disertație se va respecta
Regulamentul de întocmire a proiectelor de diplomă și a lucră rilor de disertație,
disponibil pe site-ul facultă ții http://www.aciee.ugal.ro/studenti/finalizare-
studii/regulamente-si-formulare
Conducă tor științific, Absolvent,

Nr. _____/__________________

Str. Științei Nr. 2, cod poștal 800146, Galați, România, tel/fax: +0236 470 905, e-mail: aciee@ugal.ro, web: www.aciee.ugal.ro
 UNIVERSITATEA „DUNĂREA DE JOS” DIN GALAȚI
FACULTATEA DE AUTOMATICĂ, CALCULATOARE, INGINERIE
ELECTRICĂ ȘI ELECTRONICĂ

Aprobat,
Decan

Anexa 2 la Regulamentul de întocmire a proiectelor de diplomă și a lucrărilor de disertație

DOMNULE DECAN

Subsemnata/Subsemnatul,
_______________________________________________________________________, absolventă /absolvent
a/al Facultă ții de Automatică , Calculatoare, Inginerie Electrică și Electronică , din cadrul
Universită ții Dună rea de Jos din Galați, domeniul __________________________________,
specializarea (licență /master) ______________________________________
_____________________________________________________________________________________________________
________, promoția ______________, vă rog să -mi aprobați înscrierea la examenul de
licență /disertație sesiunea _________________________________________________.
Am ales proiectul de diplomă /lucrarea de disertație cu titlul
_________________________________________________
_____________________________________________________________________________________________________
________sub îndrumarea
___________________________________________________________________________.
Am citit cu atenție REGULAMENTUL DE ÎNTOCMIRE A PROIECTELOR DE
DIPLOMĂ ȘI LUCRĂ RILOR DE DISERTAȚ IE și l-am respectat integral.

Data: __________________________ Semnă tura ____________________________

Viza îndrumă torului proiectului/coordonatorului lucră rii__________________________

Viza Directorului de departament ce coordonează programul __________________

Media Viză secretariat ACIEE

multianuala

Str. Științei Nr. 2, cod poștal 800146, Galați, România, tel/fax: +0236 470 905, e-mail: aciee@ugal.ro, web: www.aciee.ugal.ro
 UNIVERSITATEA „DUNĂREA DE JOS” DIN GALAȚI
FACULTATEA DE AUTOMATICĂ, CALCULATOARE, INGINERIE
ELECTRICĂ ȘI ELECTRONICĂ

Anexa 3 la Regulamentul de întocmire a proiectelor de diplomă și a lucrărilor de disertație

DECLARAŢ IE

Subsemnata (ul),
_________________________________________________________________________________
absolventă /absolvent a/al Facultă ții de Automatică , Calculatoare, Inginerie Electrică și
Electronică , din cadrul Universită ții “Dună rea de Jos” din Galați, promoția ________________,
specializarea
_____________________________________________________________________________________________, declar
pe proprie ră spundere că proiectul de diplomă /lucrare de disertație cu titlul
„____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_______________”este elaborat/elaborată de mine și nu a mai fost prezentat/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, inclusive cele de pe Internet,
sunt indicate în proiect/lucrare, cu respectarea regulilor de evitare a plagiatului.

“Plagiatul: însușirea ideilor, metodelor, procedurilor, tehnologiilor, rezultatelor sau

textelor unei persoane, indiferent de calea prin care acestea au fost obținute,
prezentându-le drept creație proprie.”

Am luat la cunoștință că prezentarea unui/unei proiect/lucră ri plagiate va

conduce la anularea diplomei de licență /master.

Lucrarea conține un numă r de __________ pagini.

Data: ________________ Semnă tura ____________________________

Str. Științei Nr. 2, cod poștal 800146, Galați, România, tel/fax: +0236 470 905, e-mail: aciee@ugal.ro, web: www.aciee.ugal.ro
 UNIVERSITATEA „DUNĂREA DE JOS” DIN GALAȚI
FACULTATEA DE AUTOMATICĂ, CALCULATOARE, INGINERIE
ELECTRICĂ ȘI ELECTRONICĂ

Anexa 4 la Regulamentul de întocmire a proiectelor de diplomă și a lucrărilor de disertație

ACORD PRIVIND TRANSFERUL REZULTATELOR PROIECTULUI DE DIPLOMĂ /LUCRĂ RII

DE DISERTAŢ IE

Subsemnata (ul), _________________________________________________________,

absolventă /absolvent a/al Facultă ții de Automatică , Calculatoare, Inginerie Electrică și
Electronică , din cadrul Universită ții “Dună rea de Jos” din Galați, promoția
_______________________, specializare
_____________________________________________________________________________________________________
________,
(NU) SUNT DE ACORD * să cedez rezultatele software și hardware - aferente
proiectului de diplomă /lucră rii de disertație – în favoarea Facultă ții de Automatică ,
Calculatoare, Inginerie Electrică și Electronică , din cadrul Universită ții “Dună rea de Jos”
din Galați, pentru creșterea dotă rii materiale a facultă ții și în folosul exclusiv al
studenților.

Proiectul/lucrarea conține urmă toarele:

1) Partea hardware compusă din:

_____________________________________________________________________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
________________________________________
2) Partea software compusă din:
_____________________________________________________________________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
________________________________________

Data: ________________ Semnă tura ___________________________

Str. Științei Nr. 2, cod poștal 800146, Galați, România, tel/fax: +0236 470 905, e-mail: aciee@ugal.ro, web: www.aciee.ugal.ro
 Anexa 5 la Regulamentul de întocmire a proiectelor de diplomă și a lucrărilor de disertație

Departamentul __________________________________________________________________________
Sesiunea:_________________________________________________________________________________

REFERAT DE EVALUARE

a proiectului de diplomă / lucră rii de disertație cu titlul

________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
________________________
Elaborat (ă ) de absolventul
_______________________________________________________________________
Perioada de documentare și pregă tire
___________________________________________________________
Conținutul proiectului
_____________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
________________________________
Contribuții personale ale autorului
_______________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
________________________________

Respectă regulile de întocmire și redactare? DA / NU *

 Se propune ADMITEREA / RESPINGEREA proiectului / lucră rii pentru susținerea
publică .
Nota propusă _________________________ (această notă nu va fi luată în calculul mediei
finale)

Data, Conducă tor științific,

Notă:
* Se taie (bifează), după caz
 Rezumat

Structura proiectului de licență este formată din patru capitole.

În primul capitol s-a efectuat o analiză a industriei aplicațiilor de chat mobile, fiind
decrise câ teva aspecte ale aplicațiilor prezente pe piață în acest moment.

În cel de-al doilea capitol, sunt prezentate resursele aplicației care au fost folosite
în crearea acesteia și logica pe care am abordat-o în diferite situații,

În cel de-al treilea capitol, este prezentată aplicație din punctul de vedere al unui
utilizator și nu al unui programator.
 CUPRINS

Cuprins
Introducere..........................................................................................................................................1
Capitolul 1. Analiza industriei aplicațiilor mobile de chat....................................................................2
1.2.2 Facebook Messenger....................................................................................................................5
1.2.3 Platforme pentru distribuția aplicațiilor mobile...........................................................................6
Capitolul 2. Resursele folosite și dezvoltarea aplicației.......................................................................8
2.1 Prezentare C#..................................................................................................................................8
2.2 Prezentare Xamarin.Forms..............................................................................................................9
2.3 Integrarea Firebase Database în proiectul de licență....................................................................11
2.4 Convertorii.....................................................................................................................................16
2.5 Mecanismul din spatele trimiterii mesajelor.................................................................................17
2.6 Cum funcționează înregistrarea?...................................................................................................25
2.7 Șablonul MVVM(Model-View-ViewModel)....................................................................................27
2.8 Life cycle-ul unei aplicații în cadrul platformei Android.................................................................31
2.9 Custom renderers..........................................................................................................................33
Capitolul 3. Descrierea aplicației........................................................................................................37
3.1 Înregistrarea..................................................................................................................................37
3.2 Logarea și utilizatorii......................................................................................................................39
3.3 Trimiterea mesajelor.....................................................................................................................40
Concluzie.............................................................................................................................................42
Bibliografie..........................................................................................................................................43
Lista figurilor
Figura 1. WhatsAppLogo........................................................................................................................3
Figura 2. WhatsApp Chat page..............................................................................................................4
Figura 3 SSL Asyncron............................................................................................................................4
Figura 4 Logo Messenger.......................................................................................................................5
Fig 5 Android, iOS chat..........................................................................................................................6
Fig 6 Stastici pe piață a platformelor.....................................................................................................6
Fig 7 Android OS....................................................................................................................................7
Fig 8 Ecosistemul Apple.........................................................................................................................8
Fig 9 Schemă compilare Xamarin.Forms..............................................................................................10
Fig 10 Firebase flow.............................................................................................................................12
Fig 11 Pagina de înregistrare...............................................................................................................15
Fig 12 Structura bazei de date în FireBase a userilor...........................................................................16
Fig 13 Structura bazei de date a conversațiilor....................................................................................17
Fig 14 Secțiunea de profil a utilizatorului.............................................................................................18
Fig 15 Logarea în aplicație...................................................................................................................19
Fig 16 Logarea pagina de HomePage...................................................................................................20
Fig 17 Pagina de chat a aplicației.........................................................................................................20
Fig 18 Chat-ul.......................................................................................................................................23
Fig 19 Înregistrarea..............................................................................................................................25
Fig 20 Logarea utililizatorului...............................................................................................................26
Fig 21 Pagina de înregistrare...............................................................................................................27
Fig 22 Schemă reprezentativă pentru patternul MVVM......................................................................28
Figura 23 Binding-ul din spatele paginilor(flow)..................................................................................29
Figura 24 Lifecycle-ul unei aplicații în Android....................................................................................33
Figura 25 Lifecycle-ul unei aplicații în iOS............................................................................................34
Fig 26 Custom Renders(Schemă).........................................................................................................35
Fig 27 Register Page.............................................................................................................................36
Fig 28 Cum se face logarea?................................................................................................................38
Fig 29 Înregistrarea unui utilizator nou................................................................................................39
Fig 30 Pagina de homepage a aplicației...............................................................................................40
 Introducere

Motivul pentrucare am Aplicația creată în acest proiect se numește Chat 1o1.

Scopul acestei aplicații este acela de a facilita comunicarea dintre două persoane,
nefiind nevoie de introducerea unui numă r de telefon, ci doar de o conexiune la internet
pentru vizualizarea utilizatorilor, trimiterea și primirea mesajelor între aceștia. Această
aplicație poate fi instalată atâ t pe iOS câ t și pe Android.
Aplicația, prin intermediul accesului la Internet, se conectează la un server cu o
bază de date unde sunt stocate toate informațiile despre utilizatorii înregistrați și
oferind facilitatea de a alege unul dintre ei pentru a comunica cu acesta.
Pentru a intra în acest sistem, utilizatorul care va instala aplicație va fi
redirecționat direct pe pagina de Login de unde va apă sa butonul de înregistrare. De
acolo acesta va fi dus pe o pagină unde va trebui ca acesta să își introducă datele
necesare: email, nume,prenume,parolă .
Pas, care după ce va fi efectuat, acesta va fi introdus în baza de date a sistemului,
avâ nd acces la facilită țile oferite de aplicație și la vizualizarea utilizatorilor existenți în
acel moment.
Proiectul este unul simplu, avâ nd la bază tehnologii noi, de actualitate, care la
râ ndul acestora au principiile vechi de comunicare cu un server, facilitâ nd însă
utilizarea lor.
Principalele tehnologii folosite în crearea proiectului au fost Xamarin.Forms,
Firebase Cloud Database, iar ca și limbaj de programare s-a folosit limbajul C#. Motivul
pentru care am ales să folosesc Xamarin.Forms și Firebase a fost acela că primul oferă
posibilitatea ca o aplicație să fie compilată în același timp pe Android, iOS și Windows,
fiind necesar doar codul de C# , acesta la compilare fiind transformat în codul nativ
specific fiecă rei platforme mobile în parte. În android codul va fi transformat în java, în
iOS în Swift, pă strâ nd în același timp caracteristicile vizuale(mai mult sau mai puțin).
Motivul pentru care am ales să folosesc Firebase este acela că acestă bază de date
în cloud oferă posibilitatea de a primit notifică ri în cazul unor date noi la care pot avea
subscribe, fă ră să fie necesar ca dezvoltatorul să facă requesturi continue pentru a
verifica prezența unor date noi. La bază firebase este NoSQL, datele fiind stocate în
format JSON, oferind posibilitatea de deserializare a acestora și nefiind necesar un
server care să se ocupe cu asta.

1
 Capitolul 1. Analiza industriei aplicațiilor mobile de chat

În cadrul acestui proiect, s-a efectuat un studiu de piață al alternativelor oferite la

momentul actual:
WhatsApp
Facebook Messenger
1.1 Descrierea alternativelor existente

Companie Whatsapp
Numele aplicației Whatsapp
Necesită conexiune constantă la internet Da
Mentenanță Da
Gratis Da
Protocol folosit XMPP
Transmiterea securizată a datelor folosind SSL Da
DBMS folosit Mnesia(SQL)
Platforme suportate Android, IOS, Windows Phone, Windows
Videocall Da
Audiocall Da
Comunicare prin text Da

Companie Facebook
Numele aplicației Messenger
Necesită conexiune constantă la internet Da
Mentenanță Da
Gratis Da
Protocol folosit Handover Protocol
Transmiterea securizată a datelor folosind SSL Da
Platforme suportate Android, iOS, Windows Phone, Windoww
Videocall Da
Audiocall Da
Comunicare prin text Da

1.2 Detalierea aplicațiilor existente

1.2.1 WhatsApp
Whatsapp este o aplicație de mesagerie gratuită , cross-platform deținută de
Facebook. Aceasta permite utilizatorilor să trimită mesaje de tip text sau audio, să
efectueze apeluri video sau audio, trimiterea de fișiere: fișiere text, documente, locații
etc.

2
 Figura 1. WhatsAppLogo

Aceasta, la esență , este o aplicație pentru dispozitivile mobile, putâ nd fi totuși

accesată și de pe sisteme Desktop(Windows, Mac) atâ ta timp câ t utilizatorul este
conectat pe aplicație de pe dispozitivul mobil.
Este necesară din partea utilizatorului introducerea numă rului de telefon.
Aceasta folosește ca și protocol de comunicare, o versiune personalizată a XMPP.
În momentul instală rii, este creat un cont de utilizator ce folosește ca și username
numă rul de telefon introdus(exemplu: 0712345678@s.whatsapp.net).
Pentru adă ugarea contactelor, aplicația scanează toată lista de contacte,
comparâ nd numerele de telefon cu cele existente în baza sa de date, ca mai apoi
adă ugâ ndu-le în listă doar pe cele care corespund celor din telefon.
Cei de la WhatsApp folosesc un mecanism “store and forward” pentru trimiterea și
primirea mesajelor dintre 2 utilizatori.
La trimiterea unui mesaj, acest ajunge prima dată la serverul aplicației unde este
stocat în baza de date, acestă fă câ nd apoi un request la receiver pentru un mesaj de tip
acknowledge. Câ nd acesta este primit, mesajul este șters din baza date nemaiputâ nd fi
recuperat. Mesajele care nu au fost urmate de un mesaj de acknowledge de la receiver
sunt șterse după 30 de zile de la trimiterea acestora.
Există totuși posibilitatea să se pă streze o copie de rezervă a mesajelor la cererea
utilizatorului.

3
 Figura 2. WhatsApp Chat page

Mesajele multimedia sunt mai întâ i transformate în Base64, apoi fiind trimise
că tre server și date mai departe. La primirea acestora se face decodarea din base64 în
fișierul trimis.

Ca și securitate, aplicația folosește end-to-end encryption la trimiterea și primirea

mesajelor. Atunci câ nd este deschisă aplicația prima dată , sunt generate 2 chei: o cheie
publică și una privată . Cea publică se ocupă de criptarea datelor, cea privată de
decriptarea lor. Mesajul poate fi decriptat numai de că tre cel care a trimis și a primit
mesajul.

Figura 3 SSL Asyncron

4
1.2.2 Facebook Messenger

Facebook Messenger reprezintă o aplicație de comunicare, fă cută de gigantul

Facebook, care este deținut în acest moment de Mark Zuckerberg.
Prima dată , aplicația a avut un alt nume(Facebook chat), fiind mai apoi schimbat în
numele curent. Momentan, aplicația poate fi descă rcată de pe magazinul specific fiecă rei
platforme în parte GooglePlay, AppStore sau Windows Store. Pe parcursul timpului,
interfața și funcționalită țile acesteia au suferit modifică ri, fiind introdus acum ceva timp
modul Dark Mode ce face interfața de utilizator neagră .Un user poate comunica prin
intermediul textului, video sau audio, poate trimite sau primi diverse fișiere sau
stickere. Nu este nevoie de crearea unui alt cont, acesta folosindu-l pe cel de pe
Facebook.

Figura 4 Logo Messenger

Ca și protocol de comunicare, este folosit un protocol proprietar Facebook, numit
Handover Protocol. Acest protocol permite unor două sau mai multe aplicații să
participe în conversații, parsâ nd controlul conversației între ele. În mod normal, toate
mesajele sunt trimise că tre un aplicația care are rolul de primitor principal. În
momentul câ nd o altă aplicație deține controlul conversației, toate mesajele se duc că tre
aceea. Toate aplicațiile care nu au controlul conversației, au în schimb subscribe la
mesaje.

5
 Fig 5 Android, iOS chat

1.2.3 Platforme pentru distribuția aplicațiilor mobile

Pe parcursul timpului, mai multe sisteme de operare mobile au încercat să se

ridice sus, dar nici una nu a reușit să atingă performanțele fă cute de cei de la Apple cu
sistemul de operare iOS și de cei de la Google cu platforma Android.
Momentan, gigantul Google cu platforma acestora deține peste 70% din piața de
sisteme de operare destinate dispozitielor mobile.

Fig 6 Stastici pe piață a platformelor

Android rulează în acest moment atâ t pe smartphone-uri, câ t și pe tablete,

smartwatch-uri. Pe data de 23 septembrie 2008, a fost lansată prima versiune de
Android.

6
 Cu timpul, au fost lansate mai multe versiune ale acestuia, purtâ nd numele unor
deserturi: Cupcake 1.5; Donut 1.6; Eclair 2.0; Froyo 2.2; Gingerbread 2.3; Honeycomb
3.0; Ice Cream Sandwich 4.0; Jelly Bean 4.1; KitKat 4.4; Lollipop 5.0; Marshmallow 6.0;
Nougat 7.0, Oreo 8.0 și ultima versiune 9.0 Pie.
În ceea ce privește customizarea, Android oferă o libertată infinită . Numă rul de
aplicații este mult mai mare și fiind Open Source, oricine poate avea acces la acesta și
modificâ nd OS-ul, putâ nd ca fiecare să își facă propria lor versiune de Android.

Fig 7 Android OS

Pe celă lalt front se află cei de la Apple cu sistemul lor de operar IOS. Diferența
dintre acesta și cel de la Google este customizarea. Cei de la Apple nu permit deblocarea
acestuia, singura metodă curată prin care se poate face update la o nouă versiune este
cea oficială , atunci câ nd Apple trimite că tre utilizatori o nouă versiune. Sistemul lor de
operare este valabil pe tablete, telefoane și smartwatch-uri. Apple a implementat prin
intermediul acestui sistem de operare un mic ecosistem. Toate informațiile sunt
sincronizate între device-uri de la mesaje la apeluri, la fișiere. O altă diferență o
reprezintă interfața celor două sisteme de operare. Unde Android oferă o interfață mai
friendly plină ce culori și animații, cei de la Apple oferă una mult mai profesională și mai
simplistă , mergâ nd pe o cale mai minimalistă .
Magazinul de aplicații reprezintă încă o diferență . În Android, toate aplicațiile pot
fi puse în market, neavâ nd parte de o testare precisă , fiind cazuri în care viruși au ajuns
acolo. În schimb, pe App Store așa ceva nu e posibil. La publicarea fiecă rei aplicații, un
om stă și testează aplicația asigurâ ndu-se că nu există nimic suspect în legă tură cu ea.
Cred că cea mai mare diferență dintre cele 2 sisteme de operare o reprezintă
performanța acestora. Unde Android e plin de instabilită ți în multe cazuri, nefiind
optimizat pentru toate tipurile de procesoare datorită faptului că există în acest
moment pe piață foarte mulți producă tori de telefoane cu propriile lor versiuni de
procesor, Apple își optimizează sistemul de operare pe procesorul produs de ei,
oferindu-le posibilitatea ca să livreze un OS optimizat ca la carte, avâ nd un numă r redus
de instabilită ți.

7
 Fig 8 Ecosistemul Apple

Capitolul 2. Resursele folosite și dezvoltarea aplicației

Aplicația acesta a fost dezvoltată folosind limbajul de programare C#, în mediul

Visual Studio Community 2017, folosind framework-ul Xamarin.Forms, folosind ca bază
de date Firebase Database. Aceasta poate fi compilată pe sistemul de operare Android și
iOS, deși din lipsa resurselor, nu am putut pune aplicația pe sistemul de operare al celor
de la Apple deoarece pentru a compila pe acela, este necesar un mac, trebuind o licență
specială oferită de cei de la Apple.
Ca și mod de lucru, am folosit sistemul Agile, aducâ nd iterații aplicației, iar ca și
mod de salvare al progresului fă cut, m-am folosit de facilită țile oferite de cei de la Git.
Am avut un branch master pe care ajungeau doar lucrurile testate de mine și de care
eram sigur că sunt funcționale, iar dezvoltarea s-a petrecut pe branchuri separate
fiecă rei facilită ți în parte, la urmă , după ce totul era ok, fă câ nd merge cu masterul.
Ca și principii de programare, am recurs la principiul MVVM(Model-View-
ViewModel). Principalul aspect al acestui principiu este acela că toate elementele de
user control trebuiesc puse numai în fișierele .xaml ale proiectului.
Modelul ține toate datele despre diferite obiecte(în cazul meu mesajee), în ViewModel le
procesez, iar apoi le transmit că tre utilizator. În mod invers, toate informațiile puse de

8
utilizator sunt puse în Model, iar apoi trimise că tre viewModel unde le voi afișa sau le
voi trimite.
Xamarin.Forms mi-a oferit posibilitatea de a scrie un cod C#, care este apoi
transformat la compilare în codul nativ specific fiecă rei platforme în parte. Am folosit
această libră rie pentru a proiecta interfața. Aceasta îmi oferă posibilitatea ca, printr-un
fișier .xaml unde sunt stocate toate elementele de user control, să transmit date că tre și
din interfață .
De asemenea, Firebase Database m-a scutit de un lucru și acela de a face eu
management pe o bază de date și pe serverul acesteia. În cloud se află baza de date, eu
trebuind doar să îi specific un cod special care îmi oferă posibilitatea de a mă loga pe
acesta cu un user și o parolă (sau utilizatorului de a se loga după ce s-a înregistrat).
Datorită faptului că Xamarin.Forms este încă relativ nou, fiind lansate versiuni noi care
repară probleme, nu toate lucrurile merg bine sau sunt implementate într-un mod ok,
uneori neexistâ nd versiuni oficiale ale unor libră rii și trebuind astfel să recurg la third-
party-uri care nu mereu se comportau cum trebuie. De aseemenea, Firebase oferă
posibilitatea ca logarea sau înregistrarea să se facă folosind contul de Google sau de
Facebook, dar fiind un third-party, nu am avut posiblitatea de a implementa această
funcționalitate care ar fi ușurat munca unui utilizator.

2.1 Prezentare C#

C# reprezintă un limbaj de programare orientat pe obiecte, fă cut de Microsoft în cadrul

inițiativei .NET. Este un limbaj care în ultimul timp a devenit foarte popular datorită
robusstită ții oferite de acesta. Motivul pentru care am ales C# este acela de a învă ța ceva
nou care se caută pe piața de muncă și care folosește aceleași principii de OOP ca și Java,
tranziția la acesta fiind destul de ușoară .

2.2 Prezentare Xamarin.Forms

Xamarin.Forms reprezintă un framework cross-platform ce permite crearea de interfețe

de utilizator(UI) ce sunt apoi partajate fiecă rei platforme în parte: Android , iOS,
Windows și Windows Phone. Aceste interfețe sunt desenate folosind controalele native
ale fiecă rei platforme pe care este compilat codul, permițâ nd ca aplicația să aibe un
aspect mai mult sau mai puțin identic pentru fiecare platformă în parte.

Desigur că vor fi și diferențe de comportament sau de aspect diferite între

platforme(cum ar fi utilizarea calendarului pe iOS ce face schimbarea în timp real spre
deosebire de Android unde pentru a efectua schimbarea este necesară apă sarea
butonului de Done).

9
Principiul de bază de funcționare al acestui framework este acesta: codul în C# este
transformat, la compilare, în cod nativ pentru fiecare platformă în parte. Elementele
grafice pot fi adă ugate folosind fie fișiere de tip XAML, avâ nd în spate o clasă parțială de
C#(acestea două împă rțind obiectele celuilalt), fie creâ nd clase C# separate ce conțin
elementele grafice respective.

Fig 9 Schemă compilare Xamarin.Forms

Exemplu de fișier XAML necesară adă ugă rii elementelor grafice:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:local="clr-namespace:App4"
x:Class="App4.MainPage">

<StackLayout>
<!-- Place new controls here -->
<Label x:Name="LabelDemo" Text="Welcome to Xamarin.Forms!"

HorizontalOptions="Center"
VerticalOptions="CenterAndExpand" />
</StackLayout>

</ContentPage>

Exemplu de clasă C# din spatele acestui XAML, putâ nd folosi elementele definite în
fișierul de mai sus:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xamarin.Forms;

namespace App4
{
public partial class MainPage : ContentPage

10
 {
public MainPage()
{
InitializeComponent();
LabelDemo.TextColor = Color.Aqua;
}
}
}

Transmiterea datelor din fișierul de .xaml unde utilizatorul a efectuat câ teva acțiuni se
desfă șoară prin intermediul conceptului de Binding.
<flex:FlexButton x:Name="loginButton" Text="Login" ClickedCommand="{Binding
LoginCommand}"
WidthRequest="76"
HeightRequest="76"
CornerRadius="38"
ForegroundColor="#ffffff"
HighlightForegroundColor="#49516F"
BackgroundColor="#6279B8"
HighlightBackgroundColor="#8EA4D2"
IsEnabled="{Binding IsBusy}"
IsToggled="{Binding IsBusy}"
Clicked="UnfocusEntry"
FontFamily="LilitaOne-Regular.ttf#LilitaOne-Regular"
Grid.Row="2" Grid.Column="0"/>
Fiecare View are în componența sa un ViewModel de care se leagă care reprezintă o
clasă din care preia datele sau le introduce. Prin acest mod, diferite componente pot
avea proprietă ți diferite în funcție de câ mpurile viewmodel-ului. Acest binding poate fi
de mai multe tipuri. Voi exemplifica cele două tipuri care sunt cele mai folosite:
- OneWay- care doar preia datele din viewModel, neputâ nd transmite informații
înapoi la viewmodel, utilizatorul neputâ nd direct să afecteze acele date.
- TwoWay – care, la fel ca și numele permite schimbul de informații dintre view și
viewmodel.

În exemplul de mai sus, se află un astfel de concept, proprietă țile care au ca valori
Binding, fiind luate din viewmodel.

Datorită faptului că unele elemente grafice arată sau se comportă diferit în funcție de
fiecare platformă în parte, uneori este necesară crearea unui custom render. Acesta
reprezintă un element grafic, scris în subproiectele xamarin și folosind elemente
specifice acelei platforme. Astfel, la compilare, compilatorul știe să selecteze elementul
și să ruleze codul pentru fiecare platformă .

11
2.3 Integrarea Firebase Database în proiectul de licență

Firebase reprezintă o platformă specifică aplicațiilor mobile și a celor web ce a

luat naștere în anul 2011, fiind apoi cumpă rată de cei de la Google în anul 2014. Această
platformă conține mai multe servicii specifice acestor tipuri de aplicații:
Firebase Analytics, ce reprezintă un tool necesar monitoriză rii aplicațiilor

Firebase Auth este o soluție ce permite logarea userilor pe platformă folosind doar
codul din aplicație. Aceasta permite logarea prin intermediul rețelelor de socializare
cum ar fi Google, Facebook, Twitter, Google Play Games. De asemenea, în acest serviciu
este inclus și managementul de că tre programatori a utilizatorilor, permițâ nd logarea în
aplicație cu un email și o parolă , date ce sunt stocate în Firebase.

Firebase Realtime Database reprezintă o bază de date și un back-end ca serviciu

disponibil. Acesta oferă programatorilor un API ce oferă posibilitatea ca datele aplicației
să fie sincronizate între toți clienții conectați, fiind stocate în mediul cloud Firebase.

Fig 10 Firebase flow

Bazele de date relaționale au apă rut la începutul anului 1970, permițâ nd stocarea
datelor și prelucrarea acestora folosind un limbrja de programare numit
SQL(Structured Query Language). În acea perioadă , stocarea datelor era scumpă și
schema de date era destul de simplă . În momentul câ nd Internetul a devenit mult mai
accesibil, cantitatea de informații legate de useri, obiecte și evenimente a explodat.
Datele, acum, sunt accesate mult mai frecvent și procesarea acestora a devenit cu mult
mai intensive. Să luă m ca exemplu rețelele de socializare ca Facebook ce crează sute de
milioane de pagini de noută ți pentru useri în funcție de activită țile acestora.

Bazele de date relaționale nu au fost proiectate să se descurce la acestă scară .

12
 Bazele de date NoSQL au fost construite ca o soluție la această problemă , fiind
concepute în așa fel încâ t să permită introducerea de date fă ră o schemă anume.

Datele pot fi stocate în format JSON(key-store value), facilitâ nd requesturile și

nemaifiind necesară prelucrarea datelor din format CSV în JSON pentru partajarea
acestora la client de că tre un REST API.

Spre deosebire de cele relaționale, aici datele pot fi doar adă ugate sau șterse,
nefiind posibil o eventuală actualizare fă ră înlocuirea completă a acestora.
Astfel de alternative sunt folosite în domeniul:
-naval(prelucrarea datelor a sute sau mii de nave)
-aerian(prelucrare datelor avioanelor)
rețele de socializare/servicii de muzică (Spotify, Facebook, SoundCloud)
În esență , NoSQL este folosit în momentul câ nd este vorba de cantită ți imense de
date(Big Data).

Nefolosing o libră rie oficială , nu am acces la toate facilită țile oferite de cei de la
Google prin intermediul acestei baze de date. Facilitatea principală pe care am folosit-o
este stocarea mesajelor și subscribe-ul la inserarea unor date noi în aceasta, primind în
momentul câ nd se stochează informații noi, o notificare și afișâ nd-o pe ecran. Am folosit
această logică la implementarea mesajelor primite și trimise.
Acest lucru a fost posibil prin integrarea metodei de subscribe din interiorul
nuggetului folosit.
var observable = child.AsObservable<MessageModel>();
var subscription = observable
.Where(f => !string.IsNullOrEmpty(f.Key))
.Subscribe(f =>
{
if (f.Object.AuthorUuid == User.UserUUID)
{
if (!(messageUuids.Contains(f.Object.MessageUuid)))
{
//sorted.Add(f.Object);
MessageList.Add(f.Object);

MessagingCenter.Send(new ScrollToBottomMessage(),
"ScrollToBottomMessage");
messageUuids.Add(f.Object.MessageUuid);
}
}

});

Voi explica acum codul de mai sus pentru a înțelege mai bine cum funcționează
acestă funcționalitate de subscribe.

13
 După cum se vede am creat o variabilă de tip observable, mai apoi stocâ nd în ea
informații. Acel subscribtion este defapt o listă , care prin intermediul LINQ din C# ce îmi
permite o parcurgere a listei sub o formă a asemă nă toare interogă rilor din SQL, reușesc
să îmi caut efectiv “tabelul” de la care vreau noile date. Subscribeul de mai sus este
pentru primirea mesajelor noi de la alt utilizator, neffind necesară crearea unor
requesturi continue pentru date noi. Ceea ce fac eu mai sus, este să îmi fac subscribe la
json-ul cu uuid-ul meu, ceilalți utilizatori, care atunci câ nd îmi scriu mesajele, stochează
datele în felul acesta Conversation/user-uuid/message-uuid. Partea de aici care mă
interesează pe mine este user-uuid.
În momentul câ nd am primit un mesaj nou, îl adaug într-o listă pe care o
ordonez după un timestamp.

Trecâ nd mai departe, voi ară ta structura sub care am stocat informațiile legate de
utilizatori și de mesajele acestora.
Voi începe mai întâ i cu partea de utilziatori. În momentul câ nd un user nou se
înregistrează , datele despre el sunt trecute în felul urmă tor:

public class UserModel

{
public string FirstName { get; set; }
public string LastName { get; set; }
public string UserUUID { get; set; }
public string UserEmail { get; set; }
public string UserImage { get; set; }

public UserModel(string firstName, string lastName, string userUUID, string

userEmail, string userImage)
{
this.FirstName = firstName;
this.LastName = lastName;
this.UserUUID = userUUID;
this.UserEmail = userEmail;
this.UserImage = userImage;

Toate aceste date provin din această pagină :

14
Fig 11 Pagina de înregistrare

Utilizatorul trebuie să introducă urmă toarele lucruri:

 -First Name
 -Last Name
 -Email
 -Password
 -Confirm Password

Primele două valori vor fi folosite la afișarea numelui acestuia în lista de utilizatori.
Emailul va fi folosit pentru a permite accesul acestuia în platformă .
Parola care va fi folosită împreună cu emailul la logare.

15
 De precizat este faptul că atâ t mailul, câ t și parola nu sunt scrise în nicio structură , ci
reprezintă efectiv crearea unui utilizator care va permite accesul la serverul unde
este gă zduită baza de date.
Cele din urmă , uuid și imaginea de utilziator, sunt setate by-default.
Uuid-ul ajută la unicitatea unui utilziator și idendificarea acestuia cu succes, iar
imaginea reprezintă efectiv o simplă imagine din proiect care este mai întâ i fă cută în
base64 pentru a putea fi stocată în baza de date.

var assembly = Assembly.GetExecutingAssembly();

string base64 = "";
string resourceName = assembly.GetManifestResourceNames()
.Single(str => str.EndsWith("icon.png"));
using (Stream stream = assembly.GetManifestResourceStream(resourceName))
using (StreamReader reader = new StreamReader(stream))
{
var bytes = new byte[stream.Length];
await stream.ReadAsync(bytes, 0, (int)stream.Length);
base64 = System.Convert.ToBase64String(bytes);
}

Aici, am pus o imagine default în proiect și am definit-o ca fiind resource. Folosing acel
string care îmi caută numele resursei cu acel nume și îmi face un stream, reușesc să fac
un array de byti și apoi îi convertesc în base64 datorită funcției de mai sus.
Voi exemplifica mai tâ rziu cum sunt aduse din format base64 în imagini propriu-zise.
Structura sub care am stocat conversațiile este urmă toarea:

Fig 12 Structura bazei de date în FireBase a userilor

Toate informațiile utilizatori sunt stocate sub acel uuid unic al lor pentru unicitate.

16
Ceea ce vedeți mai sus, în momentul câ nd fac un request, este adus ca și UserModel la
mine în aplicație, știind automat să își gă sescă câ mpurile necesare pe care să le
completeze cu informațiile nou venite.
Conversațiile au urmă toarea structură

Fig 13 Structura bazei de date a conversațiilor

Fiecare utilizator are scris în această structură , uuid-ul lui la care are subscribe și de la
care primește notifică ri noi în cazul venirii unui mesaj.
La fel ca și mai sus, aici câ nd vin informațiile din DB, este fă cut un bind automat la
modelul de mesaje, nefiind necesar ca eu să îi fac bindingul și scutindu-mă de acest
efort.

2.4 Convertorii
În Xamarin.Forms există termenul de converters? Ce sunt aceștia? Aceștia sunt clase cu
o metodă ca cea de mai jos
class ImageConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter,
CultureInfo culture)
{
if (!(string.IsNullOrEmpty(value.ToString())))
{
byte[] Base64Stream =
System.Convert.FromBase64String(value.ToString());

return ImageSource.FromStream(() => new

MemoryStream(Base64Stream));
}
return null;

17
 }

Aceștia sunt folosiți atunci câ nd, vrem să convertim o simplă valoare într-o proprietate
a unui element grafic cum ar fi sursa unei imagini.
<controls:CircleImage x:Name="image" Source="{Binding
CurrentUserImage, Converter={StaticResource imageConverter}}" Aspect="AspectFill"
Grid.Column="0" IsVisible="True">

După cum puteți vedea, am dat ca surcă a imaginii un string, care reprezintă
imaginea utilziatorului în base64 venită din baza de date. Apoi am folosit Converter,
care primește automat ca și parametru CurrentUserImage. Acesta știe automat să își ia
parametrii și să îi convertească , putâ nd adă uga diverse condiții.

Aveștia sunt definiți atunci câ nd se definesc în XAML toate resursele care urmează să fie
folosite(importul de clase efectiv)
<ContentPage.Resources>
<ResourceDictionary>
<cvrt:ImageConverter x:Key="imageConverter"/>
</ResourceDictionary>
</ContentPage.Resources>
Ce face acest convertor? Prin intemrediul lui am reușit să obțin acest efect al imaginii de
utilizator.
În momentul randă rii paginii, acesta primește ca parametru imaginea în format base64,
apoi convertind-o într-o imagine propriu-zisă .

Fig 14 Secțiunea de profil a utilizatorului

Convertorul primește 4 parametri, primul este valoarea care urmează să fie convertită ,
al doilea este tipul de element care este de așteptat să fie convertit, cel de-al treilea
parametru (puteți trece un parametru suplimentar la convertor), iar ultimul
informațiile despre cultură .

Sfat: este mai bine să adă ugați toate clasele de conversie într-un dosar pentru a fi
organizate.

Sfat: Pentru a numi convertorul este mai bine să folosiți un nume intuitiv, ca preferință
personală îmi place să pun un nume referitor la ceea ce face convertorul, de exemplu
dacă convertorul convertește un null la bool cu scopul de a fi folosit pe Isvisible
proprietatea este numită , NullToVisibilityConverter.

Patternul de MVVM poate fi aplicat și în cazul acestuia, ceea ce este bine.

18
2.5 Mecanismul din spatele trimiterii mesajelor

Să începem cu începutul. Cum ajungem în pagina de trimitere a mesajelor?

Fig 15 Logarea în aplicație

19
Fig 16 Logarea pagina de HomePage

Fig 17 Pagina de chat a aplicației

Pașii sunt urmă torii:

- Userul se loghează

20
 - Din lista utilizatorilor, acesta alege un user că ruia să îi trimită mesajul.

Ceea ce se află mai sus reprezintă ChatPageView.xaml.

<ListView ItemsSource="{Binding MessageList}" HasUnevenRows="True"
RowHeight="60" x:Name="MessagesListView" >
<ListView.ItemTemplate>
<DataTemplate>
<ViewCell>
<StackLayout Margin="8">
<StackLayout Orientation="Horizontal">
<Frame BackgroundColor="{Binding AuthorUuid,
Converter={StaticResource colorConverter}}" WidthRequest="400">
<Frame.HasShadow>
<OnPlatform x:TypeArguments="x:Boolean" iOS="false"
Android="true"/>
</Frame.HasShadow>
<Frame.Content>
<Label Text="{Binding Content}" FontFamily="LilitaOne-
Regular.ttf#LilitaOne-Regular" TextColor="Black" />
</Frame.Content>
</Frame>
</StackLayout>
</StackLayout>
</ViewCell>
</DataTemplate>
</ListView.ItemTemplate>
</ListView>

Ok. Am pus mai sus elementele importante ale acestui view.

În primul râ nd, acel listview are ca sursă o listă observable de MessageModels din
viewModel.
private ObservableCollection<MessageModel> messageList = new
ObservableCollection<MessageModel>();

public ObservableCollection<MessageModel> MessageList

{
get
{
return messageList;
}
set
{
messageList = value;
OnPropertyChanged("MessageList");
}

21
 }
Lista este de tip observable pentru ca vizual aceasta să fie actualizată cu noile date venit
din rqeusturile fă cute la baza de date.

Requestul la baza de date este urmă torul:

var firebase = Connectors.Client.DatabaseClient;
var messages = await firebase
.Child("Conversations")
.Child(Helper.RetainedData.CurrentUser.UserUUID)
.OrderByKey()
.OnceAsync<MessageModel>();
foreach (var message in messages)
{
if (message.Object.TargetUuid == User.UserUUID || message.Object.AuthorUuid
== User.UserUUID)
{
sorted.Add(message.Object);

messageUuids.Add(message.Object.MessageUuid);
}

}
sorted = sorted.OrderBy(o => o.TimeStamp).ToList();//necessary for ordering
the messages when arriving
foreach (var item in sorted)
{
MessageList.Add(item);

}
sorted.Clear();

}
După cum puteți vedea, am folosit prima dată un connector pentru baza de date
pe care îl salvez în momentul câ nd îl creez la logare, apoi parcurg toate datele de
dedesubtul structurii care începe de la uuid-ul utilizatorului pe care îl contactez câ t și al
meu.
De ce am fă cut acest lucru? Trebuia să preiau atâ t mesajele lui câ t și pe alemele.
În momentul câ nd scriu un mesaj scriu și în structura mea și în structura utilziatorului
țintă .
După ce am preluat mesajele a trebuit să fac în așa fel încâ t să le ordonez după un
criteriu. Am ales timestamp. Mesajele sunt ordonate în ordine crescă toare începâ nd de
sus pâ nă jos în funție de timestampul acestora. Mai întâ i adaug mesajele în lista de
sorted, mai apoi le adaug în lista eventuală de mesaje direct sortate.
Acum că am trecut peste această list, așa arată un utilziator cu mesaje trimise și primite.

22
Fig 18 Chat-ul

Mesajele persoanei țină t este pe un fundal albastru. Am obținut acestl ucru folosin un
convertor care seta culoarea de background a fiecă rui frame în funcție de authoruuid-ul
dat. Dacă era la fel ca utilizatorul curent salvat la logare atunci era alb, altfel este
albastru.
La fel ca mai sus acesta este codul Convertorului.
public object Convert(object value, Type targetType, object parameter, CultureInfo
culture)
{
return value.ToString() == Helper.RetainedData.CurrentUser.UserUUID ?
"#F5F5F5" : "#03A9F4";
}

23
Ș i la această linie este setat backgroundul
<Frame BackgroundColor="{Binding AuthorUuid,
Converter={StaticResource colorConverter}}" WidthRequest="400">
<Frame.HasShadow>

AuthorUUid reprezintă parametrul primit de că tre converter pentru a converti uuidul în

culoarea fundalului.

Un alt lucru de precizat este faptul că ...de fiecare dată câ nd fac requestul...pentru
a nu lua aceleași mesaje de fiecare dată , afișâ ndu-le de două ori, fac în felul urmă tor:le
rețin pe cele pe care le-am luat, iar fiecare mesaj care îmi vine cu ceea ce am deja și apoi
îl adaug în listă . Prima dată m-am lovit de această problemă și am rezolvat-o astfel.

O altă problemă de care m-am lovit inițial a avut legă tură cu subscribeul la
structura uuid-ului utilizatorului propriului utilizator în tabela de conversații. Din
pă cate, nu se poate face subscribe la un lucru care inițial nu există și apoi să facă
automat acest lucru câ nd se crează . Dacă nu aș fi aplicat urmă toarea soluție, nu aș fi
putut să primesc mesajele de la alți utilizatori.
Care a fost soluția? În momentul înregistră rii

24
 Fig 19 Înregistrarea
După ce utilziatorul a completat toate datele și a apă sat pe butonul de
înregistrare, atunci voi scrie în tabela de conversații a utilziatorului respectiv un mesaj,
pentru a crea structura și ap utea face subscribe cu succes.
MessageModel message = new MessageModel("abv", "abc",
Helper.RetainedData.UserUuid, "abc", "abc", DateTime.Now);
await firebaseClient
.Child("Users")
.Child(loginNewlyCreatedUser.User.LocalId)
.PutAsync(userToBeAdded);
await firebaseClient
.Child("Conversations")
.Child(loginNewlyCreatedUser.User.LocalId)
.Child(Helper.UUIDGenerator.UuidGenerator)

25
 .PutAsync(message);

2.6 Cum funcționează înregistrarea?

Pentru a ajunge la pagina de înregistrare utilizatorul trebuie să apese pe butonul
de înregistrare din imaginea ală turată

Fig 20 Logarea utililizatorului

Ca mai apoi să fie dus în această pagină

26
Fig 21 Pagina de înregistrare
Unde va fi rugat să își introducă datele de înregistrare. Ca și celelalte view-uri, acestă
pagină are în spate un ViewModel care se ocupă cu trimiterea de date că tre Firebase.
await
Connectors.Client.FireBaseAuthConfig.CreateUserWithEmailAndPasswordAsync(Email,
Password);

De precizat faptul că atunci câ nd se apelează această metodă , nu se scrie în baza

de date efectivă a proiectului, ci se crează un utilizator LA NIVEL DE SERVER care
permite intrarea în el. Am ales să fac acest lucru datorită faptului că nugget-ul îmi
permitea asta și am decis că nu are rost să complic și să încarc baza de date cu o logică
care e complet inutilă din prisma faptului că ar putea fi înlocuită cu ceva mult mai ușor,
parola fiind stocată în md5 pe server, fă ră să mai fie necesar să fac eu asta. Încă un
lucru...toate mesajele și logă rile sunt securizate

27
2.7 Șablonul MVVM(Model-View-ViewModel)

Pentru a respecta un pattern, am folosit patternul Model-View-

ViewModel(MVVM).
Principala idee a acestuia este aceea că toate elementele ce țin de interfețele de
utilizator se află într-un fișier, iar toate informațiile sunt stocate într-un Model, acestea
fiind transmise printr-un fel de broker care este ViewModel.

Fig 22 Schemă reprezentativă pentru patternul MVVM

Un avantaj al acestui pattern este organizarea mult mai bună a codului aplicației.
Toate elementele grafice se află într-un folder al soluției, iar logica din spate în alt
folder, fiind mult mai ușor de urmă rit cursul aplicației. Acest pattern se bazează foarte
mult, cel puțin în cazul de față , pe principiul de Binding. Fiecare view are un viewmodel
din care își poate primi datele sau le poate trimite. Diferite elemente grafice pot avea ca
binding date din view model. Să luă m ca exemplu un buton care se face roșu în cazul în
care este o acțiune nepermisă . În mod normal, s-ar fi scris în code-behind(clasa din
spatele xaml-ului) toată acestă logică . Dar este greșit. În acea clasă ar trebui să fie câ teva
linii de cod, toată logica de colorare a butonului aflâ ndu-se în viewmodel care este
binduit la view.
Pentru a fi posibil așa ceva, există termenul de Observable. Pentru ca acesta să
poate fi manipulat de utilizator sau de acțiunile acestuia, culoarea butonului definită în
viewmodel ca fiind un string ce ține culoarea, trebuie să fie declarat ca observable. La
fiecare modificare a valorii stringului, UI-ul primește o notificare în spate și își schimbă
proprietea respectivă în funcție de culoarea aleasă .
Este un pattern care uneori este foarte dificil de urmat, fiind mult mai ușor să se
scrie pur și simplu o clasă care deține informații necesare decâ t să se facă un
viewmodel, care să își extragă datele din altă clasă etc. Este de asemenea un pattern
foarte asemă nă tor cu MVC(Model-View-Controller).

28
 În principiu, acest model separă logica de business, pă strâ nd-o în clasele dedicate
acesteia de cea de UI.
Mai jos se află o figură mai detaliată al proceselor care au loc în spatele folosirii
acestui pattern.

Figura 23 Binding-ul din spatele paginilor(flow)

În proiectul meu am încercat să respect pe câ t de mult am putut acest pattern.

Structura este urmă toarea: în componența proiectului se află două modele pe care le
folosesc pentru a actualiza, șterge sau introduce date.

MessageModel.cs

public class MessageModel

{

public string MessageUuid { get; set; }

public string Author { get; set; }
public string AuthorUuid { get; set; }
public string Content { get; set; }
public string TargetUuid { get; set; }
public DateTime TimeStamp { get; set; }
public MessageModel(string messageUuid, string author,string
useruuid, string content, string targetUuid, DateTime timestamp)
{
this.MessageUuid = messageUuid;
this.Author = author;
this.AuthorUuid = useruuid;
this.Content = content;
this.TargetUuid = targetUuid;
this.TimeStamp = timestamp;

29
 }
}

Voi explica fiecare field al clasei în parte. Stocarea în baza de date se face pe baza unui
JSON, o structură de date. Pentru a adă uga unicitate fiecă rui mesaj în parte și de a evita
suprascrierea mesajelor, am ales să ofer fiecă rui mesaj în parte pe care eu îl trimit un id
unic(uuid), avâ nd o metodă separată pentru generarea acestui id, folosindu-mă efectiv
de funcția de random. Printr-un loop for reușesc să convertesc un numă r de 10 numere
în char, generâ nd astfel acel UUID.

public static string UuidGenerator

{
get
{
StringBuilder builder = new StringBuilder();
Random random = new Random();
char ch;
for (int i = 0; i < 10; i++)
{
ch = Convert.ToChar(Convert.ToInt32(Math.Floor(26 * random.NextDouble()
+ 65)));
builder.Append(ch);
}
return builder.ToString();
}
}

În concluzie acest MessageModel reprezintă modelul în care stochez datele.

Împreună cu acest uuid, stochez în aceasă clasă numele autorului mesajului, uuid-ului
acestuia, timestampul și conținutul mesajului și uuidul utilizatorului că tre care îi trimit
mesajul respectiv.

Mai sus am oferit un exemplu. Voi explica în urmă toarele râ nduri cum am reușit să
adaptez acest pattern acestui proiect printr-un exemplu mult mai detaliat, acela fiind
preluarea listei de utilizatori existenți în platformă .

După ce userul a reușit cu succes să se logheze în aplicație, acesta va fi redirecționat

că tre un view(MainPageView).

30
<ListView x:Name="List" ItemsSource="{Binding Userlist}"
RowHeight="60" ItemSelected="OnSelectedItem">
<ListView.ItemTemplate>
<DataTemplate>
<ViewCell>
<StackLayout Margin="8">
<StackLayout Orientation="Horizontal">
<controls:CircleImage Source="{Binding UserImage,
Converter={StaticResource imageConverter}}" Aspect="AspectFill" Grid.Column="0"
IsVisible="True">
<controls:CircleImage.WidthRequest>
<OnPlatform x:TypeArguments="x:Double">
<On Platform="Android, iOS">50</On>
</OnPlatform>
</controls:CircleImage.WidthRequest>
<controls:CircleImage.HeightRequest>
<OnPlatform x:TypeArguments="x:Double">
<On Platform="Android, iOS">50</On>
</OnPlatform>
</controls:CircleImage.HeightRequest>
</controls:CircleImage>
<Label Text="{Binding FirstName}"
FontFamily="LilitaOne-Regular.ttf#LilitaOne-Regular"/>
<Label Text="{Binding LastName}"
FontFamily="LilitaOne-Regular.ttf#LilitaOne-Regular"/>
</StackLayout>
</StackLayout>
</ViewCell>
</DataTemplate>
</ListView.ItemTemplate>
</ListView>

În acest Xaml sunt mai multe cuvinte cheie de care trebuie să se țină cont. În primul
râ nd este acel ListView. ListView-ul reprezintă o listă grafică , care inițial este goală ,
urmâ nd ca ulterior informațiile să fie adă ugate în acesta și randate eventual pe ecran.

În primul râ nd i-am definit sursa, care este UserList. Această listă este definită în
ViewModel

public ObservableCollection<UserModel> Userlist

{
get
{
return userlist;
}
set
{

31
 userlist = value;
OnPropertyChanged("Userlist");
}
}

În mod normal, dacă nu aș fi adă ugat acel Observable la definitea listei de useri (în care
sunt aduși toți userii câ nd se face requestul la baza de date pentru aceștia), obiectele ar
fi fost randate pe ecran, însă dacă ar fi trebuit să actualizez lista, de exemplu câ nd se
adaugă un nou user, pe ecran nu ar fi apă rut noul utilizator, el fiind totuși prezent în
lista din viewmodel. Acel Observable, atunci câ nd sunt schimbă ri legate de datele din
interior, trimite o notificare la cei care au subscribe la această listă (în cazul nostru
listview-ul) și aceștia updatează lista cu informațiile nou venite. E asemă nă tor cu
patternul de Observable unde există obiecte ce, atunci câ nd sunt modifică ri, toți
subscriberii la acel obiect primesc o notificiare, putâ nd efectua diferite acțiuni în funcție
de aceasta.

Dar cum se face legarea la viewmodel? La fel cum am mai spus, în spatele acestui xaml
se află o clasă de C#, care inițial nu are decâ t câ teva linii de cod ce țin mai mult de
inițializarea acesteia.

InitializeComponent();
BindingContext = new MainPageViewModel();
this.viewModel = viewModel;

Mai sus este prezentată clasa din spatele pagini Main unde sunt ară tați utilizatorii
existenți. După cum vedem, se setează un BindingContext care stă efectiv la baza
transmiterii de date ale modelului prin viewmodel.

2.8 Life cycle-ul unei aplicații în cadrul platformei Android

În Android, fiecare aplicație are un life cycle care începe din momentul câ nd aceasta a
fost lansată .
În figura ală turată este prezentat lifecycle-ul unei aplicații în Android.

32
Figura 24 Lifecycle-ul unei aplicații în Android

33
Figura 25 Lifecycle-ul unei aplicații în iOS
În momentul lansă rii aplicației, este apelată metoda de onCreate(), atunci câ nd se
face tranziție din background în foreground, este apelată metoda de onResume(), câ nd
este bă gată în background cea de onPause() și așa mai departe.
Programatorul trebuie să țină cont de aceste lucruri, deoarece unele lucruri ar
putea dispă rea câ nd se revine în aplicație, mai ales câ nd sunt puse requesturi de date în
metoda de onAppearing afiecă rei pagini. Această metodă se execută de fiecare dată câ nd
apare pagina respectivă pe ecran, astfel putâ nd avea loc un numă r considerabil de
operațiuni inutile care în mod normal ar trebui să se execute numai o singură dată .
Aceste metode sunt automat suprascrise de Xamarin.Forms la crearea
proiectului pentru fiecare platformă în parte. Aceste metode pot avea în interiorul lor
diferite acțiune în funcție de life cycle-ul curent. Un exemplu ar fi un request de date
atunci câ nd se revine în aplicație din background.

2.9 Custom renderers

Noțiunea de Custom Render a apare în momentul câ nd, folosind elementele grafice

default din Xamarin.Forms, acestea nu corespund cu standardul impus de utilizator sau
de programator.
Să luă m ca exemplu un entry(acesta reprezintă un text box în care sunt scrise
date de că tre utilizator și prin care sunt trimise datele la ViewModel).
În mod norma, Xamarin.Forms nu conține un entry la fel ca cel prezentat în
figura de mai jos. Câ nd am ajuns în acestă situație, a trebuit să creez un custom render.

34
Fig 26 Custom Renders(Schemă )

În astfel de situații, este necesar ca programatorul să își creeze propria componentă și

să folosească elementele grafice ce vin în proiectul de Android. Un dezavantaj ar fi aceal
că , dacă se dorește ca acesta să fie și pe iOS și pe Android, atunci trebuie creat în ambele
pă rți, pe iOS fiind cu totul diferit, fiind necesare cunoștințe mai vaste al acestui sistem
de operare.

35
Fig 27 Register Page
Ceea ce am fă cut pentru a ajunge la acest rezultat a fost urmă torul lucru: a fost necesară
crearea unei clase în proiectul de Xamarin.Forms(nu cel specific platformei) care
extindea clasa elementului grafic pe care voiam să îl folosesc.
public class CustomEntry : Entry
{

}
Dacă se dorește adă ugarea de proprietă ți noi, se poate face acest lucru foarte
ușor, dar am ales să merg pe calea mai simplă .
Apo a trebuit să creez clasa acestei componente în proiectul de Android.
protected override void OnElementChanged(ElementChangedEventArgs<Entry> e)
{
base.OnElementChanged(e);

if (e.OldElement == null)
{
var gradientDrawable = new GradientDrawable();
gradientDrawable.SetCornerRadius(60f);
gradientDrawable.SetStroke(5, Android.Graphics.Color.DarkGray);
gradientDrawable.SetColor(Android.Graphics.Color.Transparent);
Control.SetBackground(gradientDrawable);
e.NewElement.PlaceholderColor = Color.Gray;
Control.SetPadding(50, Control.PaddingTop, Control.PaddingRight,
Control.PaddingBottom);
}
}
Această metodă este apelată în momentul câ nd este detectată , din fișierul .xaml
unde este folosită componenta modificată , o schimbare a comportamentului
componentei respective. Astfel se setează colțurile componentei(care dau acea
rotunjime a acestora), stroke-ul, culoarea și culoarea fundalului aplicației. De
assemenea poate fi adă ugat și un place holder care să îi ofere un indiciu utilizatorului în
legă tură cu informațiile cerute de la acesta. Pe iOS, codul acestei componente ar fi ară tat
complet diferit folosind metode specifice Swift-ului ce țin de elementele grafice ale
acestuia.
Pentru a folosi această componentă , am creat această componentă în fișierul
de .xaml unde sunt adă ugate toate elementele de grafică .
<Controls:CustomEntry x:Name="Email"
Grid.Row="0"
Grid.Column="0"
Placeholder="Email"
VerticalOptions="CenterAndExpand"
Text="{Binding UserEmail}"
TextColor="White"
FontFamily="LilitaOne-Regular.ttf#LilitaOne-Regular"/>

36
 Importul clasei se face la fel ca în C#. Trebuie doar chemat obiectul, apă râ nd un
prompt de a adă uga folderul unde se află componenta respectivă .

37
 Capitolul 3. Descrierea aplicației

Aplicație fă cută în cadrul proiectului de licență este o aplicație de chat care are ca scop
oferirea unei că i de comunicare între două persoane prin text.
Fiecare utilizator va trebui facă un cont pentru a putea avea acces la serviciile oferite de
că tre aplicație.

3.1 Înregistrarea
Prima dată , câ nd userul va intra în aplicație acesta va trebui să apese pe acest
buton în cazul în care nu are cont.

Fig 28 Cum se face logarea?

38
Urmâ nd ca mai apoi să fie dus în această pagină de înregistrare unde va trebui să
completeze câ mpurile cu urmă toarele date:
 Numele de familie
 Prenumele
 Adresa de email
 Parola

Fig 29 Înregistrarea unui utilizator nou

După apă sarea butonului de înregistrare acesta va fi adus în pagina de Logare unde va
trebui să introducă datele cu care va intra în sistem.

39
3.2 Logarea și utilizatorii

După ce utilizatorii s-au logat, aceștia vor avea o pagină de unde pot face urmă toarele
lucruri
 Să selecteze un utilziator cu care să vorbească
 Să își seteze o poză de profil
 Să se delogheze

Fig 30 Pagina de homepage a aplicației

După ce este selectat un utilizator, el este dus la o pagină în care poate
conversaționa cu el.
De precizat este faptul că fiecare utilizator își poate seta o poză de profil care va
fi salvată în baza de date și încă rcată de fiecare dată câ nd acesta va intra în această
pagină .

3.3 Trimiterea mesajelor

40
 În această pagină , conversaționează doi utilizatori. Fiecare poate trimite mesaj,
backgroundul fiecă rui mesaj fiind în funcție de cine a trimis mesajul respectiv.
Culoarea albastră pentru mesajul venit de la celă lalt user și gri pentru cel care logat în
momentul acesta în aplicație

Fig 31 Trimiterea unor mesaje

41
 Concluzie

În final, această aplicație a avut două scopuri majore. Unul dintre ele a fost faptul
că am avut oportunitatea de a mă folosi de tehnologii noi pe care nu le-am mai folosit
înainte, care sunt în vogă și din ce în ce mai adoptate, suportul pentru ele fiind încă mic,
dar cu timpul va crește. Am avut ocazia să fac aplicația de la 0, neavâ nd o bază propriu-
zisă dintr-un tutorial.
Al doilea motiv, folosind aceste tehnologii am avut ocazia să aplic lucruri pe care
le știam deja și am reușit să le aprofundez, reușind de asemenea să deprind lucruri
noi(Xamarin.Forms, MVVM, Firebase).
În final, aplicația rezultată din acest efort reprezintă timpul pe care l-am acordat
învă ță rii acestor lucruri noi și a unor lucruri învă țate în cei 4 ani de facultate.

42
 Bibliografie

https://en.wikipedia.org/wiki/C_Sharp_(programming_language)

https://www.telerik.com/blogs/what-is-xamarin-forms

Xamarin .Forms Notes for Professional

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

https://www.mongodb.com/nosql-inline

https://www.slideshare.net/VirginiaSgargi/whatsapp-project-work

43