UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI

FACULTATEA DE INFORMATICĂ

LUCRARE DE LICENŢĂ

My Bills Manager

propusă de

Buzatu Florin-Vasile

Sesiunea: februarie, 2017

Coordonator ştiinţific

Asist. Dr. Vasile Alaiba

UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI

FACULTATEA DE INFORMATICĂ

My Bills Manager

Buzatu Florin-Vasile

Sesiunea: februarie, 2017

Coordonator ştiinţific

Asist. Dr. Vasile Alaiba

DECLARAŢIE PRIVIND ORIGINALITATE ŞI RESPECTAREA

DREPTURILOR DE AUTOR

Prin prezenta declar că Lucrarea de licenţă cu titlul „My Bill Manager” 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 Buzatu Florin-Vasile

_____________________________________

DECLARAŢIE DE CONSIMŢĂMÂNT

Prin prezenta declar că sunt de acord ca Lucrarea de licență cu titlul „My Bill Manager”,

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 Buzatu Florin-Vasile

___________________________________

1

Cuprins

1. Introducere ..................................................................................................................... 3

1.1 Motivație ............................................................................................................................................ 3

1.2 Context ............................................................................................................................................... 3

1.3 Funcționalități ................................................................................................................................... 4

1.4 Specificații tehnice ............................................................................................................................ 5

2. Tehnologii utilizate ........................................................................................................ 6

2.1 Sistemul de operare Android ........................................................................................................... 6

2.2 Android API ...................................................................................................................................... 7

2.3 Android Studio .................................................................................................................................. 8

2.4 Biblioteca Butter Knife ..................................................................................................................... 9

2.5 Biblioteca Google Maps ................................................................................................................. 10

2.6 Bibliotecile Firebase ....................................................................................................................... 11

3. Arhitectura soluției ...................................................................................................... 12

3.1 Analiza problemei și găsirea soluției ............................................................................................. 12

3.2 Model View Presenter ..................................................................................................................... 13

3.3 View-ul în aplicațiile Android ........................................................................................................ 14

3.4 Presenter-ul în aplicația My Bills Manager .................................................................................. 16

3.5 Relația dintre View și Presenter .................................................................................................... 16

3.6 Modelul în aplicația My Bills Manager ......................................................................................... 16

4. Proiectare ..................................................................................................................... 18

4.1 Baza de date a aplicației My Bills Manager ................................................................................. 18

4.2 Implementare .................................................................................................................................. 20

4.2.1 Activitățile și fragmentul de bază .............................................................................................. 20

4.2.2 SplashScreenActivity ................................................................................................................. 23

4.2.3 Fereastra de autentificare ........................................................................................................... 23

4.2.4 Fereastra de înregistrare ............................................................................................................. 25

4.2.5 Meniul aplicației ........................................................................................................................ 26

4.2.6 Listele de facturi......................................................................................................................... 27

4.2.7 Adăugare, modificare și vizualizare facturi ............................................................................... 28

4.2.8 Notificări .................................................................................................................................... 29

2

4.2.9 Internaționalizare ....................................................................................................................... 30

5. Manual de utilizare ...................................................................................................... 31

5.1 SplashScreen .................................................................................................................................... 31

5.2 Autentificare .................................................................................................................................... 31

5.3 Înregistrare ...................................................................................................................................... 32

5.4 Facturi viitoare și meniul aplicației ............................................................................................... 33

5.5 Facturi restante și facturi neplătite ............................................................................................... 34

5.6 Facturi plătite .................................................................................................................................. 35

5.7 Adăugare și modificare/vizualizare factură.................................................................................. 36

5.8 Selectare data scadenței și selectarea punctului de plată ............................................................ 37

5.9 Informații despre aplicație și notificări ......................................................................................... 38

6. Concluzii ....................................................................................................................... 40

7. Bibliografie ................................................................................................................... 41

3

1. Introducere

My bills manager este o aplicație android care oferă utilizatorilor posibilitatea de a-și

gestiona facturile. Utilizatorul poate să își adauge mereu câte o factură nouă completând

câmpurile manual. Acesta va primi notificare atunci când se apropie data scadenței la o factură.

La oricare factură utilizatorul poate atașa locații unde ar putea fi plătită (pentru facturile

care nu sunt plătite online), iar dacă va intra în raza uneia dintre acele locații și factura nu este

plătită încă va primi o notificare în care i se vor menționa detaliile acesteia.

1.1 Motivație

Orice persoană care locuiește la casă sau apartament are de plătit facturi la utilități oferite de

diferite companii. Acestea pot fi: gaze naturale, curent electric, apă, TV etc. Se întâmplă de

foarte multe ori să uităm să plătim facturile pentru aceste utilități la timp și acest lucru este

deranjat mai ales atunci când o să trebuiască sa plătim penalizări.

My bills manager este o aplicație creată special pentru a-i aminti utilizatorului atunci

când se aproprie data scadenței. Aceasta îl anunță pe utilizator și în momentul în care intră în

raza unei locații (punct de plată) setate pentru factura respectivă.

Dacă dorești să economisești bani și să nu mai fii stresat fiindcă ai uitat să plătești

facturile la timp, My bills manager este aplicația perfectă.

1.2 Context

În ziua de astăzi, telefoanele mobile și tabletele joacă un rol foarte important în viața tuturor

persoanelor care dețin aceste dispozitive inteligente. Cu aceste dispozitive pot fi efectuate acțiuni

clasice cum ar fi apeluri telefonice, trimitere și primire de mesaje sau notițe. Acestea dispun de

camere de fotografiat performante, difuzoare de calitate, dar și de o multitudine de senzori cum

ar fi: accelerometru, temperatură, umiditate, gravitație, giroscop, lumină ambientală, câmp

magnetic, proximitate etc.

Aplicațiile pe care le instalăm pe aceste dispozitive sunt încadrate în mai multe categorii,

cum ar fi: educație, comunicare, cumpărături, jocuri, productivitate etc. Acestea ajută foarte mult

persoanele care le utilizează, făcându-le uneori viața mai ușoară. Aplicația My bills manager se

încadrează în categoria productivitate și este foarte utilă pentru toate persoanele care au de plătit

facturi și doresc să aibă o evidență asupra acestora. O altă aplicație ce este folosită în scop

4

asemănător este aplicația Bills Reminder.

1.3 Funcționalități

1. Utilizatorul are posibilitatea de a adăuga, vizualiza/modifica și șterge o factură. Principalele

câmpuri ce trebuie completate atunci când se adaugă o factură nouă sunt: nume factură, data

scadenței și totalul de plată. Aceste date pot fi modificate oricând dorește utilizatorul. Factura

poate fi ștearsă sau marcată ca fiind platită direct din lista de facturi.

2. Înregistrare: se poate crea un cont nou folosind e-mail și parolă (e-mailul trebuie să fie valid,

iar parola să aibă lungimea mai mare ca șapte, cel puțin o majusculă și cel puțin un număr).

3. Atașarea unei locații unei facturi dintr-o fereastră care are încărcată harta folosind Google

Maps.

4. Notificări

4.1. Utilizatorul va primi notificări atunci când se aproprie data scadenței la facturi (ora

șapte dimineața).

4.2. Setarea unei raze de maxim 100 de metri pentru locația atașată facturii și trimiterea unei

notificări dacă utilizatorul intră în raza respectivă.

5. Lista de facturi

5.1. Facturile sunt afișate în listă ordonate după data scadenței. Cele plătite sunt marcate cu

culoarea verde, cele neplătite sunt marcate cu culoarea roșu daca au depășit data

scadenței, iar dacă nu au depășit și încă nu au fost platite sunt marcate cu albastru.

5.2. Utilizatorul poate filtra lista de facturi după urmatoarele criterii: facturi viitoare, facturi

neplătite, facturi plătite, facturi care au depășit data scadenței.

6. Internaționalizare: limba predefinită pentru această aplicație este limba engleză. Aplicația

oferă suport și pentru limba română în cazul în care utilizatorul își setează această limbă din

setările telefonului sau tabletei.

5

1.4 Specificații tehnice

My bills manager oferă suport pentru versiunile de Android de la 4.3 în sus, atât pentru

telefoane mobile cât și pentru tablete. Este dezvoltată utilizând limbajul de programare Java, iar

mediul de dezvoltare este Android Studio. Arhitectura este realizată folosind șablonul

architectural Model View Presenter. Ferestrele principale ale aplicației sunt implementate într-o

singură activitate. Aceasta gestionează toate fragmentele aplicației, fiecare reprezentând

conținutul acelei activități.

Android Studio este mediul de dezvoltare recomandat de compania Google pentru platforma

Android și poate rula pe Windows, Linux și Mac OSX. Acesta este bazat pe programul IntelliJ

IDEA care aparține companiei JetBrains și a fost special creat pentru dezvoltarea aplicațiilor

pentru platforma Android.

Limbajul de programare Java a fost folosit pentru a dezvolta API-ul Android. Acesta este un

limbaj de programare orientat-obiect dezvoltat de compania Sun Microsystems și lansat în anul

1995. Sintaxa limbajului moștenește foarte mult limbajele C și C++.[1]

Firebase este o platformă creată pentru a ajuta programatorii să dezvolte aplicații de înaltă

calitate. Produsul inițial al companiei Firebase a fost o bază de date în timp real. Firebase Auth

este un serviciu care permite autentificarea utilizatorilor scriind cod doar pe partea de client.

Acest serviciu suportă și autentificarea folosind conturile de Facebook, Twitter sau Google. Baza

de date Firebase oferă dezvoltatorilor de aplicații un API ce permite stocarea de date în cloud-ul

Firebase-ului. Acesta oferă deasemenea SDK pentru IOS, Android și Web.[2]

6

2. Tehnologii utilizate

În acest capitol sunt prezentate tehnologiile şi bibliotecile utilizate în dezvoltarea aplicaţiei

My Bills Manager .

2.1 Sistemul de operare Android

Android este un sistem de operare pentru dispozitive mobile, telefoane sau tablete. Android a

devenit lider mondial în acest segment în 2010, în primul trimestru al anului 2012 raportând o

cotă de 59% din piaţa mondială a smartphone-urilor, cu un total aproximat la 331 milioane de

dispozitive cu acest sistem de operare instalat .

Android a început de la o companie mică, achiziţionată de Google în 2005. În prezent,

dezvoltarea sistemului de operare este supervizată de Open Handset Alliance, o comunitate

condusă de Google din care mai fac parte companii ca ARM Holdings, HTC, Inel, LG, Motorola,

Samsung Electronics, Nvidia, TMobile sau Texas Instruments.

Kernelul sistemului de operare Android se bazează pe kernelul de Linux. Acest kernel a

suferit modificări de arhitectură realizate de inginerii Google în afara procesului tipic de

devoltare a kernel-ului Linux. Android nu are un sistem nativ X Window şi nu suportă întregul

set de biblioteci standard GNU, ceea ce face destul de dificilă portarea aplicaţiilor şi bibliotecilor

existente de Linux pe Android. Principalele modificări pe care Google le-a adus într-o primă fază

kernelului au fost legate de eficientizarea consumului bateriei. Aceste modificări au fost respinse

în prima fază de dezvoltatorii kernel-ului Linux de bază, motivând lipsa de încredere în intenţia

Google de a se ocupa în continuare de acest cod. În 2010 s-a făcut un pas major pentru integrarea

modificărilor din Android în Linux, prin adăugarea unui modificări care îmbunătăţea framework-

ul de wakeup events existent şi care permitea drivere-lor Android să fie uşor integrate în Linux

de bază. În August 2011 Linus Torvalds spunea că în patru sau cinci ani Linux şi Android se vor

întoarce la un kernel comun (prezentat în imaginea de mai jos).

Arhitectura Android presupune existenţa a patru nivele, cel de la bază fiind kernelul de

Linux. Al doilea nivel, cel de mijloc, conţine biblioteci de C. Acesta este cod nativ, rulând direct

peste cel de Kernel. Următorul nivel este cel de application framework, care cuprinde biblioteci

compatibile Java, bazate pe versiunea de Java Apache Harmony.

Fiecare aplicaţie Android rulează în propriul proces cu propria instanţă a maşinii virtuale.

Dalvik a fost dezvoltat în aşa fel încât un dispozitiv poate rula mai multe maşini virtuale eficient.

Maşina virtuală Dalvik se bazează pe kernel-ul Linux pentru funcţionalităţile de bază, cum ar fi

gestionarea firelor de execuție şi menţinerea nivelului de memoriei scăzut.[3]

7

Figura 1: Arhitectura sistemului de operare Android [3]

2.2 Android API

API-ul Android este utilizat pentru a crea aplicațiile care rulează pe dispozitivele cu sistemul

de operare Android. Acest API este scris în limbajul de programare Java de către dezvoltatorii

platformei Android. Acesta este public și gratuit, iar Google pune la dispoziție și o pagină web

dedicată documentației API-ului, dar și tutoriale și aplicații de test care să ajute viitorii

dezvoltatori de aplicații Android. Există mai multe versiuni de Android API, iar la fiecare

versiune nouă de Android apare și o versiune nouă de API. Android API 1 corespunde primei

versiuni de Android, însă prima versiune de API facută publică este Android API 3 ce

corespunde versiunii Android 1.5. Repartiția versiunilor de Android pe toate dispozitivele care

rulau acest sistem de operare la data de 9 ianuarie 2017 este următoarea:

8

Figura 2: Diagrama popularității versiunilor de Android, 9 ianuarie 2017 [4]

Aplicația My Bills Manager este dezvoltată în așa fel încât să ocupe peste jumătate din

dispozitivele pe care rulează sistemul de operare Android. Astfel, versiunea minimă pe care

poate fi rulată această aplicație este 4.3 (Android API 18), iar versiunea maximă fiind cea mai

nouă 7.1 (Android API 25) urmând ca după jumatatea anului 2017 să apară noua versiune de

Android și anume 8, precum și noul Android API 26, iar odată cu apariția acestora se va putea

face o actualizare a versiunii maxime pe care va putea rula aplicația My Bills Manager.

2.3 Android Studio

Android Studio este mediul de dezvoltare recomandat de Google pentru platforma Android,

acesta fiind bazat pe IntelliJ IDEA. Prima versiune stabilă a acestui program a fost lansată în

Decembrie 2014, începând de la versiunea 1.0 și continuând până în ziua de astăzi, ultima

versiune apăruta fiind 2.2.3. [12]

Atunci când a apărut Android Studio, acesta a înlocuit mediul de dezvoltare Eclipse,

adăugând în același timp o interfață mult mai prietenoasă pentru dezvoltatorii de aplicații,

precum și unelte mai ușor accesibile și mai ușor de folosit. A fost adăugat și un build automation

system numit Gradle, cu ajutorul căruia se pot configura build-urile făcute pentru aplicațiile

9

Android mult mai ușor și mult mai rapid. Cu ajutorul acestui se pot descărca biblioteci specifice

Android-ului printr-o simplă linie de cod și apoi apăsarea butonului Sync. În imaginea de mai jos

se poate vedea cât de ușor se poate crea interfața unei ferestre în Android Studio: în fișierul xml

se adaugă componentele view, iar în partea stângă a ecranului putem vedea cum se modifică în

timp real fereasta ajutând foarte mult la dezvoltare (se poate selecta orice tip de telefon sau

tabletă, cu orice rezoluție și versiune pentru prezentarea ecranului).

Figura 3: Android Studio – implementarea unei ferestre (parte de layout)

2.4 Biblioteca Butter Knife

Biblioteca Butter Knife este utilizată pentru a face legăturile mai ușor cu obiectele view

după ce se face inflate la un fișier xml ce conține layout-ul ferestrei. Această bibliotecă este

utilizată deoarece:

Elimină apelurile la metoda findViewById pentru a instanția obiectele view, folosind

adnotarea @Bind pe câmpurile acestora.

Grupează mai multe view-uri într-o listă și operează asupra lor cu acțiuni, setări sau

proprietăți.

10

Elimină clasele anonime pentru evenimentele setate view-urilor adnotând metode, de

exemplu cu @OnClick pentru acțiunea de apăsare asupra unui view.

Elimină interogările resurselor prin utlizarea de adnotări pe câmpurile acestora. [5]

Această bibliotecă este importată adăugând în fișierul gradle linia urmatoare:

compile 'com.jakewharton:butterknife:7.0.1'

Figura 4:Utilizarea adnotărilor în Activitatea de Înregistrare

2.5 Biblioteca Google Maps

Biblioteca Google Maps este utilizată pe ecranul Bill Location pentru a încărca harta lumii și

pentru a selecta coordonatele unei locații (latitudine, longitudine) pentru Geofencing. Atunci

când utilizatorul intră în raza acelei locații o să primească o notificare.

În momentul în care harta este gata încărcată în MapView se obține o instanță a obiectului

GoogleMap utilizat pentru a seta un listener pe care să primească evenimente atunci când se

schimbă locația în centrul hărții (pe centrul hății este afișat un pin pentru a arăta utilizatorului ce

locație va selecta). Dependența ce trebuie adăugată în fișierul gradle pentru a descărca biblioteca

Google Maps este urmatoarea:

compile 'com.google.android.gms:play-services-maps:10.0.1'

11

2.6 Bibliotecile Firebase

Firebase Authentication este o bibliotecă utilizată pentru a crea cont unui utilizator în

aplicația My Bills Manager. Clasa FirebaseAuth oferită de această bibliotecă oferă metode

pentru a crea un cont nou, folosind o adresă de email și o parolă, posibilitatea de a ne autentifica

și de asemenea de a ne deloga.

Un obiect FirebaseUser reprezintă contul unui utilizator care s-a înregistrat în aplicație.

Instanța obiectului FirebaseUser este independentă de instanța obiectului FirebaseAuth. Un

utilizator Firebase are un set fix de proprietăți de bază: un identificator unic, o adresă de email,

un nume, o fotografie URL stocate în baza de date a utilizatorilor Firebase. Nu se pot adăuga

alte proprietăți utilizatorului Firebase, dar se pot stoca proprietăți adiționale în baza de date

Firebase care este independentă de baza de date a utilizatorilor. Se poate crea un nod, cheia

acestuia fiind ID-ul unic al utilizatorului, iar pe acel nod putem seta alte detalii despre utilizator.

Dependența ce trebuie adăugată în aplicație pentru a descărca această bibliotecă este urmatoarea: [6]

compile 'com.google.firebase:firebase-auth:10.0.1'

A doua bibliotecă oferită de Firebase ne oferă posibilitatea de a ne conecta și crea instanțe

către baza de date a Firebase-ului, aici fiind stocate facturile utilizatorilor. Această bază de date

este stocată în cloud. Datele sunt stocate într-un JSON și sincronizate în timp real între

utilizatorii aplicației.

În loc să utilizeze cereri HTTP, această bază de date folosește sincronizarea datelor de fiecare

dată când acestea se schimbă, orice utilizator conectat primind actualizările în milisecunde.

Dacă telefonul nu are conexiune la Internet, SDK-ul persistă datele pe disc, dacă se încearcă

de exemplu salvarea de date în bază, iar când conexiunea se restabilește aceste date o să se

salveze și aplicația se sincronizează cu starea curentă a server-ului.

Folosind această bibliotcă putem crea referințe la orice nod din JSON-ul de pe server și se

pot face modificări asupra acelor noduri sau chiar șterge acele noduri. Pentru a descărca

biblioteca aceasta trebuie adăugată această linie în fișierul gradle al aplicației: [7]

compile 'com.google.firebase:firebase-database:10.0.1'

12

3. Arhitectura soluției

În acest capitol este prezentată arhitectura clientului Android și cum este structurat proiectul

aplicației My Bills Manager.

3.1 Analiza problemei și găsirea soluției

Design-ul unui proiect ar trebuie să fie o preocupare încă de la început. Unul dintre primele

lucruri pe care ar trebui să îl luăm în considerare este arhitectura pe care dorim să o adoptăm,

deoarece va defini modul în care diferitele elemente ale aplicaţiei noastre sunt legate una de alta.

Acesta va stabili, de asemenea, unele reguli de bază pentru a ne ghida în timpul dezvoltării.

În general, un framework sau un SDK se așteaptă ca lucrurile să fie făcute într-un anumit

fel, dar nu este întotdeauna potrivit pentru un proiect. Uneori, nu există nici o modalitate

predefinită sau corectă de a face lucrurile , lăsând deciziile de proiectare în mâna dezvoltatorului.

SDK-ul Android-ului se așteaptă ca lucrurile să fie făcute într-un anumit fel, dar acest lucru nu

este întotdeauna suficient sau cea mai bună alegere.

Cu toate că Android oferă un SDK excelent, modelele sale arhitecturale sunt destul de

neobișnuite și ne pot sta în cale în timpul dezvoltării, în special atunci când construim aplicații

complexe care trebuie testate și menținute pentru o perioadă lungă de timp. Din fericire putem

alege din soluții arhitecturale multiple pentru a rezolva această problemă.

Instrumentele oferite de Android, cum ar fi layout-uri, Activități, Fragmente și structuri de

date par să ne orienteze în direcția șablonului arhitectural Model View Controller (MVC). Acesta

este un șablon solid care își propune să izoleze diferitele roluri ale aplicației. Acest lucru este

cunoscut sub numele de separare a preocupărilor. Această arhitectură crează trei nivele: Model,

View și Controller. Fiecare este responsabil de un aspect al aplicației. Modelul răspunde la

logică, View-ul reprezintă interfața cu utilizatorul, iar Controllerul mediază accesul View-ului la

Model (Figura 5).

13

Figura 5: Model View Controller [8]

Dacă analizăm îndeaproape arhitectura Android, în special relația dintre View (Activități,

Fragmente) și Model (structuri de date), putem concluziona că nu poate fi considerată Model

View Controller. Este destul de diferit de MVC și urmează propriile reguli, iar acest lucru ne

poate sta în cale atunci când obiectivul este de a crea aplicații de înaltă calitate.

Această problemă poate fi rezolvată implementând un șablon arhitectural diferit, și din

fericire SDK-ul Androidului ne permite să alegem între multiple soluții. Model View Controller

este o alegere bună, dar o alegere și mai bună este șablonul Model View Presenter (MVP).

3.2 Model View Presenter

Model View Presenter este o derivare a șablonului Model View Controller și este folosit în

principal pentru a construi interfețele cu utilizatorul. Ideea principală din spatele Model View

Presenter-ului este de a decupla implementarea view-ului de logica aplicației și de Model,

adăugând un concept numit Presenter unde este implementată logica de prezentare (Figura 6).

14

Figura 6: Model View Presenter [9]

3.3 View-ul în aplicațiile Android

View-ul în aplicațiile Android este reprezentat de Activități și Fragmente. Activitatea în

cadrul aplicației Android este componenta care oferă un ecran prin intermediul căruia utilizatorul

interacționeză cu aplicația. Fragmentul reprezintă un comportament sau o porțiune din Activitate.

Într-o singură activitate pot fi combinate mai multe fragmente. Aceste fragmente pot fi folosite în

orice activitate. Fiecare activitate și fiecare fragment primesc un fișier de tip layout care

reprezintă interfața grafică a acestora.[10] [11]

O aplicație pentru platforma Android conține mai multe activități dintre care una este

activitatea principală, care este prezentată atunci când este deschisă aplicația. Toate aceste

activități sunt prezentate în fișierul AndroidManifest.xml.

15

Figura 7: Ciclul de viață al unei activități [10]

O activitate nouă poate fi creată de către o altă activitate. După ce activitatea este creată,

cealaltă o să fie adăugată într-o stivă de activități numită back-stack (o să fie readusă în

foreground după ce activitatea nouă este distrusă). O activitate nou creată poate trece prin mai

multe stări. Prima metodă ce se apelează când aceasta este creată este metoda onCreate().

Aceasta este urmată de metodele onStart() și onResume(). Când activitatea este trimisă în

background se apelează pe rând metodele onPause() și onStop(), iar dacă urmează să fie distrusă

se apelează onDestroy(). Dacă o activitate este în background, când va reveni în foreground se

va apela metoda onResume(). Toate aceste metode din ciclul de viață al unei activități sunt

prezentate mai sus în Figura 7.

16

3.4 Presenter-ul în aplicația My Bills Manager

În această aplicație este creat câte un Presenter pentru fiecare ecran sau subecran. Acesta ține

o referință la activitatea ce îl creează, iar dacă este creat de un Fragment acesta va ține o referință

la activitatea din care face parte acesta.

Fiecare Presenter comunică cu baza de date Firebase în momentul în care View-ul dorește să

fie populat cu date (de exemplu în cazul ecranelor cu listele de facturi). În momentul în care setul

de date se schimbă este de datoria Presenterului să facă modificările necesare View-ului. Atunci

când se face o acțiune asupra unui view din ecran (de exemplu apăsarea unui buton), acesta va

apela o metodă publică din Presenter. Dacă este necesar ca view-urile să fi modificate la acea

acțiune, Presenterul aplează o metodă din interfața implementată de Activitate sau Fragment

pentru a face acest lucru. Presenter-ul primește ca parametru această interfață implementată de

ecran pentru a ajuta la comunicarea cu acesta.

3.5 Relația dintre View și Presenter

În șablonul Model View Presenter, View-ul este complet pasiv, iar datele sunt trimise mereu

la View de Presenter. View-ul și Presenter-ul au o relație unu-la-unu, prin urmare, Presenter-ul

este legat de un singur View.

Există mai multe interpretări ale modului în care Model View Presenter-ul poate fi

implementat în Android. În general, Activităților și Fragmentelor le este asignat rolul de View și

sunt responsabile de crearea Presenterului și Modelului. View-ul are deasemenea

responsabilitatea de a informa Presenterul atunci cand el este distrus, și de a menține Modelul.

Principalele responsabilități ale Presenterului sunt urmatoarele:

Decide când datele sunt încărcate;

Decide ce parte a modelului este utilizată pentru a prelua datele;

Reacționează la evenimentele primite de View, cum ar fi apăsarea unui buton, pentru

a face modificări setului de date, sau a stimula în alte moduri aplicația (cum ar fi

postarea de notificări sau preluarea locației);

Validează datele de intrare;

Transformă informația dacă este nevoie, pentru a evita cuplarea view-ului de model.

3.6 Modelul în aplicația My Bills Manager

Modelul aplicației My Bills Manager este reprezentat de clasa Bill, o instanță din această

clasă conținând toate câmpurile pe care utilizatorul le poate adăuga din fereastra de adăugare

factură.

17

Cea de-a doua clasă ce reprezintă un model este clasa FirebaseUser. Nu s-a mai creat o clasă

separată pentru utilizator în proiect, deoarece instanța clasei FirebaseUser conține toate

informațiile necesare aplicației. Aceste informații sunt adresa de email a utilizatorului și

indentificatorul unic al acestuia. În momentul în care utilizatorul se înregistrează în aplicație sau

se autentifică se va prima acest obiect.

Identificatorul unic al utilizatorului este utilizat atunci când se creează o referință spre nodul

din baza de date al utilizatorului autentificat sau chiar spre nodul facturilor acestuia. Acest

identificator se poate obține apelând metoda getUid(). Pentru a obține adresa de email se

apelează metoda getEmail(). Această metodă este folosită de catre Presenterul meniului, și

emailul este trimis spre View-ul meniului pentru a fi afișat acolo.

Instanțe ale clasei Bill se creează atunci când utilizatorul completează câmpurile din ecranul

de adăugare sau modificare factură. Apăsând pe butonul de salvare sau modificare, datele sunt

preluate din view-uri și trimise la Presenter spre validare. După ce se trece de pasul de validare

se creează o instanță a clasei Bill utilizând câmpurile validate (acestea vor fi trimise ca parametri

în constructorul clasei). Acest obiect va fi salvat în baza de date, iar numele câmpurilor o să fie și

numele cheilor din baza de date pentru fiecare proprietate a facturii.

Atunci când se face o cerere la baza de date pentru lista de facturi se va primi un obiect

DataSnapshot ce va fi prelucrat de Presenter pentru a forma un ArrayList de facturi. Pentru a

prelua un obiect Bill din DataSnaphot se aplează metoda: Bill bill = billSnapshot.getValue

(Bill.class); Clasa Bill reprezintă modelul principal al aplicației My Bills Manager. Acesta este

prezentat în diagrama UML de clasă de mai jos:

Figura 8: Diagrama clasei Bill (sunt prezentate doar o parte din metode)

18

4. Proiectare

În acest capitol este prezentată structura proiectului și modul în care au fost implemente

ferestrele aplicației, sistemul de notificări, baza de date și cum comunică entitățile între ele.

4.1 Baza de date a aplicației My Bills Manager

Baza de date a aplicației este reprezentată de Firebase. Acestă bibliotecă importată în proiect

oferă o foarte ușoară comunicare cu baza de date și modulul de autentificare al Firebase-ului.

Utilizatorii autentificați cu ajutorul Firebase-ului pot fi vizualizați din consola acestuia pe

care a fost configurat proiectul My Bill Manager. Crearea unui cont se realizeză utilizând o

adresă de email și o parolă, acestu lucru putând fi realizat și din consolă, nu doar din aplicație.

În momentul în care s-a creat utilizatorul, acestuia i se va asigna un identificator unic. În

imaginea de mai jos putem vedea utilizatorii adăugați în baza de date (acest lucru se poate realiza

accesând opțiunea Authentication din consola Firebase a proiectului). După cum se poate

observa putem să vedem adresa de email, data când utilizatoul s-a autentificat ultima oară și ID-

ul unic al acetuia.

Figura 7: Utilizatori în aplicația My Bills Manager

Pentru a autentifica sau înregistra un utilizator în aplicație este utilizată o instanță a clasei

FirebaseAuth. Înregistrarea se realizează apelând metoda createUserWithEmailAndPassword,

aceasta primind ca parametri o adresă de email și o parolă. Pentru a se autentifica, utilizatorul

19

apelează metoda signInWithEmailAndPassword cu aceeași parametri folosiți la înregistrare.

Pentru a deloga un utilizator autentificat se apelează metoda signout. Toate aceste trei metode

sunt implementate în clasa FirebaseAuth. Aceste metode returnează un obiect Task<AuthResult>

pe care se setează listener-ul addOnCompleteListener. Se va apela metoda onComplete tot cu un

obiect Task<AuthResult>. Se va putea ști daca operația a avut loc cu success apelând metoda

isSuccessful.

Baza de date a aplicației în care sunt salvate facturile pentru fiecare utilizator poate fi

accesată din consola Firebase apasând pe opțiunea Database din meniul din stânga. Datele sunt

stocate într-un JSON și sincronizate în timp real între utilizatorii aplicației. Primul nod din acest

JSON se numește Users. Pentru a accesa acest nod din aplicația Android se creează o instanță a

clasei DatabaseReference către acel nod apelând metoda: FirebaseDatabase.getInstance().

getReference(“Users”). Cheile din JSON pentru copii acestui nod reprezintă identificatorii unici

ai utilizatorilor creați folosind Firebase. Cheia Bills din fiecare utilizator conține facturile

acestuia.

În imaginea de mai jos se poate vedea JSON-ul din consola Firebase a aplicației My Bills

Manager. Dacă un utilizator nu are încă nici o factură adăugată, nodul cu identificatorul acetuia

nu apare înca în baza de date.

Figura 8: JSON-ul aplicației My Bills Manager din Firebase

20

4.2 Implementare

În acest subcapitol sunt prezentate implementările fiecărui ecran din aplicație (Activități,

Fragmente) și manager-ul de notificări.

4.2.1 Activitățile și fragmentul de bază

Activitatea și fragmentul de bază al aplicației se află în pachetul base. Clasele se numesc

BaseActivity și BaseFragment. BaseActivity extinde clasa Activity din SDK-ul Android-ului, iar

BaseFragment extinde clasa Fragment, și aceasta tot din SDK-ul Android-ului. Aceste două

clase vor fi la rândul lor moștenite de ferestrele aplicației My Bills Manager.

BaseActivity este o clasă abstractă. Ea implementează metoda onCreate din ciclul de viață al

activității. În acestă metodă se setează layout-ul activității ce extinde BaseActivity apelând

metoda setContentView(getLayoutResId()). Metoda getLayoutResId() este o metodă abstractă pe

care fiecare activitate ce extinde BaseActivity trebuie să o implementeze. Aceasta returnează id-

ul layout-ului activității respective. După ce se setează layout-ul activității se apelază metoda

ButterKnife.bind(this) care face legătura cu view-urile și metodele din Activitate ce sunt adnotate

de librăria ButterKnife. Metoda onCreateFinished() este implementată în activitatea care

moștenește BaseActivity dacă se dorește. Aceasta se aplează la sfârșitul metodei onCreate.

BaseActivity implementează deasemnea și metoda onDestroy, deoarece înainte de a se

distruge activitatea trebuie apelată metoda ButterKnife.bind(this) pentru a desface legăturile de

view-urile activității.

21

La fel ca și BaseActivity, BaseFragment este o clasă abstractă. Fiecare fragment din aplicația

My Bills Manager implementează BaseFragment. Acesta deține ca și în cazul activitații metoda

abstractă getLayoutResId ce returnează id-ul pentru layout-ul fragmentului. Atunci când se

creează fragmentul se apelează metoda onCreateView din ciclul de viață al fragmentului. Acestă

metodă face inflate la layout-ul fragmentului și returnează un obiect View ce reprezintă

conținutul fragmentului. Deasemenea în această metodă se fac legăturile cu view-ul fragmentului

apelând metoda ButterKnife.bind(this, fragmentContent).

Metoda abstractă getScreenTitle trebuie implementată de fiecare fragment pentru a returna

numele ferestrei ce va fi setat în partea de sus a ecranului din care face parte fragmentul.

După ce se apeleză metoda onCreateView se va apela metoda onActivityCreated. Aici se

setează faptul că fragmentul este în foreground și se obține și o instanță a activitații din care face

parte fragmentul (în cazul acesta activitatea MenuActivity).

BaseFragmentsActiviy este o activitate ce moștenește clasa BaseActivity. Această clasă poate

fi moștenită de activitățile ce doresc să facă management cu fragmente. În metoda

onCreateFinished se obține o instanță a managerului de fragmente. Acest manager de fragmente

este utilizat de metodele setFragment, addFragment și onBackPressed.

22

Metoda setFragment este utilizată pentru a seta un nou fragment în layout-ul activității.

Înainte de a se apela metoda ce înlocuiește fragmentul vechi cu cel curent se aplează metoda

popBackStack din fragmentManager pentru a elimina toate fragmentele adăugate în stivă.

Metoda addFragment este folosită atunci când se dorește adăugarea unui nou fragment peste

cel vechi. Acest fragment va fi adăugat deasemenea și în stiva de fragmente. Înainte de a se

adăuga fragmentul nou se obține fragmentul curent, se setează booleana isInForeground a

acestuia pe fals și se va apela metoda onPause, deoarece acest fragment va fi considerat în

background după ce se adaugă cel nou.

Metoda onBackPressed() este apelată atunci când se apasă pe butonul nativ de back de pe

telefon sau tabletă. Dacă stiva de fragmente conține cel puțin un element se va scoate din stivă

ultimul fragment adăugat apelând metoda popBackStackImmediate din managerul de fragmente.

După ce se scoate fragmentul din stivă se obține fragmentul ce ar trebui să revină în foreground,

se setează pe true booleana isInForeground a acestuia și se apelează metoda onResume pentru a

actualiza view-ul acestuia, titlul din partea de sus a ferestrei și butoanele de acolo. Dacă nu sunt

fragmente în stivă se va distruge activitatea ce face management-ul fragmentelor.

23

4.2.2 SplashScreenActivity

SplashScreenActivity este primul ecran ce i se afișează utilizatorului atunci când deschide

aplicația. În acest ecran, utilizatorului îi sunt prezentate numele și sigla aplicației. Această

activitate creează o instanță a clasei SplashScreenPresenter. În constructorul Presenter-ului se

atașează un listener instanței de FirebaseAuth. Dacă utilizatorul era deja autentificat ultima data

când a închis aplicația, în momentul în care se atașează listener-ul se va primi obiectul

FirebaseUser. Dacă acesta este null utilizatorul va fi redirectat spre fereastra de autentificare,

altfel se va face autologin și va fi redirectat spre fereastra cu facturile viitoare ale utilizatorului.

Cat timp se vor face aceste verificări, pe fereastră va fi afișat view-ul ProgressBar, setat cu

proprietatea de nedeterminat pe true. Dacă datele se obțin foarte rapid din baza de date, se vor

aștepta trei secunde pe acestă fereastră ca să nu dispară instant din fața utilizatorului.

Deoarece acestă activitate o să fie prima care se pornește când se deschide aplicația, trebuie

adăugate niște taguri speciale în fișierul AndrodiManifest.xml, ca în imaginea de mai jos:

4.2.3 Fereastra de autentificare

LoginActivity este fereastra care i se afișează utilizatorului dacă nu este autentificat în

aplicație în momentul în care deschide aplicația. Deasemenea această activitate este deschisă și

după ce se deloghează utilizatorul cu succes. În metoda onCreateFinished implementată de

activitate se crează o instanță o clasei LoginPresenter. Această activitate implementează interfața

LoginView.

Principalele view-uri de pe acest ecran sunt câmpurile în care utilizatorul completează adresa

de email și parola, deasemenea butonul de autentificare și TextView-ul care redirectează

utilizatorul spre ecranul de înregistrare.

În momentul în care utilizatorul apasă pe TextView-ul cu textul “Sign up now” se va face

start la activitatea SignUpActivity care se va deschide pe deasupra ferestrei de autentificare.

Atunci când utilizatorul apasă pe butonul de autentificare se apelează metoda login din presenter.

Aceasta primește ca parametri textul din EditText-ul edtEmail și textul din EditText-ul

edtPassword.

24

Metoda login din LoginPresenter validează cele două câmpuri primite. Dacă se trece de pasul

de validare, presenterul blochează cele două view-uri care au acțiune de click pe ele, până când

autentificarea se realizează. Dacă autentificarea are loc cu succes, se deschide activitatea

MenuActivity, iar cea de autentificare se închide apelânduse metoda finish(), altfel se va afișa un

mesaj pe ecran cu textul “Eroare la autentificare” și se vor debloca view-urile cu acțiune pe ele.

Pentru validarea celor două câmpuri se utilizează metodele din clasa InputValidator. Dacă unul

din câmpuri nu a fost completat se returnează eroare de câmp obligatoriu, care se va seta pe

EditText-ul respective apelând metoda setError cu mesajul specific.

25

4.2.4 Fereastra de înregistrare

Fereastra de înregistrare (SignUpActivity) poate fi accesată din ecranul de autentificare. Acest

ecran este format din patru componenete pe care utilizatorul le poate folosi: câmpurile pentru

adresa de email, parolă, confirmare parolă și butoanele de înregistrare și închidere fereastră.

Dacă se apasă pe butonul Închide, se apelează metoda onBackPressed(), iar utilizatorul este

redirectat spre ecranul anterior. Dacă se apasă pe butonul de înregistrare, se preiau textele din

câmpurile menționate mai sus și se apelează metoda createNewAccount din presenter

(SignUpPresenter) cu aceste texte (email, parolă, parola de confirmare). La fel ca și la

autentificare mai întâi sunt validate câmpurile respective. Pentru validare se folosește tot clasa

InputValidator. Se validează mai întâi dacă cele trei câmpuri sunt completate. Dacă sunt

completate se verifică dacă adresa de email este validă, apoi dacă parola are cel puțin 8 cifre, cel

puțin un număr și cel puțin o majuscule, iar în ultimul rând dacă parola și parola de confirmare

sunt egale. Dacă acestea nu sunt valide se setează o eroare și în funcție de aceasta se afișează în

câmpul potrivit eroarea apelând metoda setError din EditText.

Dacă toate câmpurile sunt valide, presenterul apelează metoda din FirebaseAuth care

crează cont folosind adresa de email și parola (metoda createUserWithEmailAndPassword).

26

4.2.5 Meniul aplicației

Meniul aplicației este implementat în activitatea BaseMenuActivity, clasă moștenită de

activitatea principală a aplicației (MenuActivity). Componenta se numește DrawerLayout.

BaseMenuActivity implementează toată logica ce ține de meniul aplicației și bara din partea de

sus a ecranului.

Primul copil din DrawerLayout reprezintă conținutul ecranului, iar celălalt view-ul ce conține

layout-ul ecranului. În activitate sunt metode care implementează setarea titlului din bara de sus,

ascunderea acesteia, blocarea meniului sau deblocarea acestuia când este nevoie.

În momentul în care se apasă pe o opțiune din meniu se salvează View-ul acestuia și se

setează ca selectat. Dacă se apasă din nou pe acea opțiune, fiind deja selectată se închide doar

meniul.

Meniul este prezent în toate ecranele aplicației după ce se autentifică utilizatorul. Acesta

poate fi blocat sau deblocat în funcție de ecran. Activitatea MenuActivity moștenește clasa

BaseMenuActivity care la rândul ei moștenește clasa BaseFragmentsActivity. MenuActivity face

managementul ecranelor ce vor fi afișate în view-ul ce reprezintă conținutul meniului. În acest

fel meniul o să poate fi afișat în toate ecranele fară a mai crea o activitate nouă. În momentul în

care se setează un fragment nou meniul va fi închis.

27

4.2.6 Listele de facturi

Fragmentul ce implementează listele de facturi din aplicație se numește BillsListFragment,

iar presenterul ce implementează logica acestui este clasa BillsListPresenter. În funcție de ce

listă se dorește afișată se apelează una din metodele statice din fragment care setează modul

pentru lista de facturi și creează fragmentul cu acel mod. Modurile sunt variabile statice în

BillsListFragment. În imaginea de mai jos este prezentat cum se crează fragmentul pentru listele

de facturi neplătite.

Atunci când se instanțiază presenterul acestui ecran în constructorul clasei BillsListPresenter

se trimite și modul ecranului pentru a ajuta la filtrarea listei de facturi atunci când se primește de

la server și pentru a afișa mesajul specific atunci când nu sunt facturi. De la server se primește

toată lista de facturi sortată în funcție de data scadenței. Lista se trimite ca parametru la metoda

filterBills din presenter și acesta în funcție de modul ecranului filtrează facturile (există câte o

metodă pentru fiecare tip de factură). Lista filtrată este trimisă la fragment de presenter, iar

acesta crează adapter-ul pe care îl setează la RecyclerView. În adapter se setează acțiunile pe

facturile din listă, mesajele de pe ele și culoarea datei în funcție de mod. Metoda care marchează

ca plătită o factură se află tot în presenter.

28

Pentru a face legătura cu baza de date și pentru a se obține o referință la nodul cu facturile

utilizatorului curent se folosește clasa DatabaseUtils.

4.2.7 Adăugare, modificare și vizualizare facturi

Aceste funcționalitați sunt implementate de presenterul fragmentului AddEditBillFragment.

La fel ca și la fragmentul cu listele de facturi, și acest ecran poate fi deschis în două moduri:

modul de adăugare și modul de vizualizare/modificare. Modul de adăugare se deschide în

momentul în care utilizatorul apasă pe butonul plus din partea de sus a ecranului. Modul de

vizualizare/modificare se deschide atunci când utilizatorul apasă pe opțiunea Vizualizare/

Modificare din ecranul cu listele de facturi (pentru fiecare factură).

Acest fragment are un buton care salvează sau modifică factura în baza de date și un buton de

închide care ne întoarce la ecranul anterior. Metoda saveBill din presenter verifică mai întâi dacă

câmpurile obligatorii sunt completate (acestea sunt numele facturii, data scadenței și totalul de

plată). Dacă câmpurile sunt valide se va apela metoda saveBillInFirebase sau editBillInFireBase

în funcție de modul ecranului. Dacă salvarea sau modificarea se face cu success se va redirecta

utilizatorul la ecranul anterior.

29

4.2.8 Notificări

Toată logica ce se ocupă de crearea notificărilor și postarea acestora se află în pachetul

notifications. Notificări se vor primi doar pentru facturile care au data scadenței egală cu data

curentă sau mai mare decât aceasta. În momentul când se actualizeză lista de facturi viitoare se

setează pe AlarmManager-ul din Android când să se posteze notificarea pentru fiecare factură

din listă. Dacă data scadenței este egală cu data curentă se va seta ca notificarea să fie primită

dupa un minut, altfel ea se va seta să fie primită în data scadenței la ora șapte dimineața. Mereu

când se setează lista de facturi la AlarmManager, se șterg facturile postate mai demult din lista

de alarme.

În manifestul proiectului este înregistrat receiver-ul UpcomingBillsReceiver. Acesta

implementează metoda onReceive din BroadcastReceiver. Această metodă va fi apelată (cu

intent-ul ce conține detaliile facturii) atunci când este momentul ca notificarea să fie creată și

postată. Metoda care crează notificarea se numește createNotification și se află în clasa

NotificationFactory. Aceasta primește ca parametru titlul notificării, conținutul acesteia și

identificatorul unic al notificării (acesta reprezintă poziția din lista de facturi viitoare).

30

4.2.9 Internaționalizare

Textele afișate în aplicație sunt preluate din fișierul strings.xml din directorul values pentru

limba engleză, iar cele pentru limba română din directorul values-ro. Dacă utilizatorul schimbă

limba telefonului în română textele vor fi preluate din values-ro, altfel pentru orice altă limbă

selectată vor fi preluate din directorul values. Textele setate trebuie să aibă același identificator

unic în ambele fișiere strings.xml.

Pentru a prelua un text programatic se apealază metoda getString, parametrul dat fiind

identificatorul string-ului. Texte se pot seta și pe view-urile din layout-urile proiectului. La fel se

setează identificatorul din strings.xml pentru a fi afișate în limba selectată de utilizator. În

imaginile de mai jos se pot vizualiza o parte din textele aplicației pentru ambele limbi.

31

5. Manual de utilizare

5.1 SplashScreen

În momentul în care se lansează aplicația, utilizatorului îi este prezentat un ecran cu logo-ul ,

numele aplicație și un progress loader care se încarcă până când se verifică dacă utilizatorul este

deja autentificat sau nu. Dacă utilizatorul este deja autentificat acesta va fi redirectat spre ecranul

cu facturile viitoare, altfel o să fie redirectat spre ecranul de autentificare.

5.2 Autentificare

Dacă utilizatorului îi este prezentat ecranul de autentificare acesta se poate conecta

completând câmpurile email și parolă, iar dacă nu are încă cont poate să apese pe textul

“Înregistrează-te acum” și o să fie redirectat spre ecranul de creare cont nou.

Dacă datele de conectare sunt corecte, utilizatorul va fi redirectat spre ecranul cu facturile

lui viitoare, altfel îi va fi afișat în câmpul care nu este valid mesajul de eroare “Acest câmp este

32

obligatoriu”. Cât timp se face cererea de Log in la server butoanele Log in și “Înregistrează-te

acum” o să fie blocate.

5.3 Înregistrare

Ecranul de creare cont nou este asemănator cu cel de autentificare în aplicație. Aici

utilizatorul trebuie să completeze adresa de email , parola și să confirme parola introdusă, toate

aceste câmpuri fiind obligatorii. Utilizatorul va fi notificat prin urmatoarele mesaje dacă datele

completate nu sunt valide:

Adresă de email invalidă;

Parola trebuie să conțină cel puțin 8 caractere, o majusculă și un număr (mesajul este

afișat în imaginea de mai jos);

Acest câmp este obligatoriu (mesaj valabil pentru toate câmpurile);

Parolele nu se potrivesc.

Dacă înregistrarea se face cu succes, utilizatorul este autentificat automat și va fi redirectat la

fel ca la Log in pe ecranul cu facturile viitoare. Atunci când are loc înregistrarea, butoanele

33

„Închide” și „Înregistrează-te acum” vor fi blocate. La apăsarea butonului „Închide” utilizatorul

se va întoarce pe fereastra de autentificare.

5.4 Facturi viitoare și meniul aplicației

Prima fereastra pe care utilizatorul o să o vadă imediat după autentificare este cea cu facturile

viitoare. Dacă se deschide meniul se va observa că această optiune este selectată (apare colorată

cu verde) . Atunci când se face click pe o factură din lista de facturi viitoare se va afișa un dialog

cu opțiunile: Marchează ca platită, Vizualizare/Modificare, Ștergere.

În partea de sus a ferestrei se află toolbar-ul pe acesta fiind afișat numele ferestrei, butonul

care deschide meniul aplicației și butonul de adăugare factură nou (atunci când este apăsat

utilizatorul este redirectat spre ecranul de adăugare factură nouă).

Meniul aplicație poate fi accesat din ferestrele cu listele de facturi sau din fereastra cu

descrierea aplicației. Din acesta se pot accesa listele cu facturi viitoare, facturi care au depășit

data scadenței, facturi neplătite, facturi plătite și descrierea aplicației. Deasemenea exista și un

buton care face logout și utilizatorul în cazul acesta este redirectat spre ecranul de autentificare.

Meniul se poate închide apăsând pe butonul nativ de back sau apăsând înafara meniului.

34

5.5 Facturi restante și facturi neplătite

Fereastra de facturi restante este se poate accesa din meniu și afișeaza lista cu facturile care

au depășita data scadenței. Data este marcata cu, culoarea roșu pentru a se diferenția de celelalte

tipuri de facturi.

Fereastra de facturi neplătite cuprinde facturile viitoare și facturile restante. Primele afișate în

listă sunt facturile restante urmate de cele viitoare. La fel ca pe fereastra cu facturi viitoare dacă

se apasă pe un element din listă se va afișa un dialog cu posibilitatea de a vizualiza, modifica,

șterge sau marca ca plătită factura respectivă. Dacă se apasă pe opțiunea Vizualizare/Modificare,

utilizatorul va fi redirectat spre ferestra de modificare factură unde se vor putea vedea toate

câmpurile precompletate de datele facturii selectate. Opțiunea Marchează ca platită va afișa un

dialog (DatePicker) din care utilizatorul să selecteze data când a plătit acea factură. După ce data

a fost selectată acea factură va fi mutată in lista de facturi platite.

35

5.6 Facturi plătite

Fereastra de facturi plătite la fel poate fi accestă din meniu la fel ca celelalte liste de facturi.

Fiecare factura din listă are marcata data scadenței cu verde pentru a arăta că a fost plătită.

Deasemenea pe fiecare element din listă este afișată și data când a fost plătită această factură.

Dacă se face click pe factură se vor afișa doar două opțiuni de această dată:

Vizualizare/Modificare și Ștergere factură.

După cum a fost menționat și mai sus o factură poate ajunge în această listă daca este

marcată ca plătită din celelate trei liste.

36

5.7 Adăugare și modificare/vizualizare factură

Fereastra de adăugare factură noua poate fi accesată din toolbar, în partea dreaptă sus, în timp

ce utilizatorul se află pe unul din ferestrele accesate din meniu. Utilizatorul trebuie să

completeze câmpurile nume factură, data scadenței și totalul de plată acestea fiind obligatorii. El

mai poate selecta locația unde ar putea face plata (pentru a primi notificare când intră în raza

acelei locații) și să completeze câmpurile URL de plată online și descriere factură.

În momentul în care utilizatorul apasă pe butonul save acesta va fi redirectat la ecranul

anterior dacă factura se salvează cu succes în baza de date. La fel este redirectat la ecranul

anterior dacă apasă pe butonul Închide.

Fereastra de modificare/vizualizare factură poate fi accesată atunci când se apasă pe opțiunea

Vizualizare/Modificare din listele de facturi. Datele facturii respective vor fi precompletate când

se ajunge pe ecran pentru a fi vizualizate și modificate. Dacă se apasă pe butonul Modifică,

37

factura se va actualiza, iar utilizatorul va fi redirectat la ecranul anterior, la fel ca în ecranul de

adăugare factură nouă.

5.8 Selectare data scadenței și selectarea punctului de plată

Din fereastrele de adăugare sau modificare factură utilizatorul poate să selecteze data

scadenței apasând pe câmpul Selectează data scadenței. Se va afișa dialogul nativ de selectare

dată din android. Data minimă care poate fi selectată este ziua curentă. Când utilizatorul va apăsa

pe butonul Ok data se va afișa în câmp și poate fi modificată apasând încă odată pe aceasta.

În momentul în care utilizatorul va apăsa pe câmpul Selectează punctul de plată se va afișa

un ecran de selectarea a locației. Acesta are un pin în centrul hartei, iar când utilizatorul ajunge

în poziția dorită și apasă pe butonul Selectează va fi redirectat la ecranul anterior și coordonatele

selectate vor fi afișate pe ecran.

38

5.9 Informații despre aplicație și notificări

Pentru a afla informații despre aplicație se deschide meniul și se apasă pe opțiunea

Informații. Această fereastră prezintă când se vor afișa notificările și cum putem utiliza aplicația.

Notificările aplicației se afișează cu sigla aplicației și păot fi vizualizate pe status bar-ul din

Android. Aceste notificări au setate în titlu numele facturii, iar în conținut informații despre data

scadenței și totalul de plată.

39

40

6. Concluzii

În această lucrare este descrisă aplicația My Bills Manager care ajută utilizatorul să își

gestioneze facturile, să poată vedea facturile pe care trebuie să le platească, dar și cele care au

fost plătite sau restante.

Aceasta aplicație este foarte utilă fiindcă utilizatorul este notificat atunci când se aproprie

data scandenței la facturile viitoare sau dacă utilizatorul intră în raza locației setate pentru o

factură și aceasta nu este plătită încă.

My Bills Manager poate fi instalată pe telefoanele si tabletele pe care rulează sistemul de

operare Android (versiunile de la 4.3 în sus).

Aplicația ar putea fi îmbunătățită dacă s-ar adăuga autentificare cu Google și Facebook,

să fie mai ușor pentru utilizator atunci când își creează cont nou.

Pentru adăugarea unei facturi noi s-ar putea completa o parte din câmpuri încărcând poza

ei și preluarea detaliilor din textul din imagine. Aplicația ar putea să fie implementată și pentru

Google Watch , fiind mult mai simplu să vedem notificările (mai ales dacă avem ceasul pe

mână).

41

7. Bibliografie

[1] Limbajul de programare Java

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

[2] Firebase

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

[3] Sistemul de operare Android

https://en.wikipedia.org/wiki/Android_(operating_system)

[4] Versiunile de Android

https://developer.android.com/about/dashboards/index.html

[5] Biblioteca Butter Knife

https://github.com/JakeWharton/butterknife

[6] Autentificare folosind Firebase

https://firebase.google.com/docs/auth/android/start/

[7] Baza de date Firebase

https://firebase.google.com/docs/database/android/start/

[8] Introducere în Model View Presenter

https://code.tutsplus.com/tutorials/an-introduction-to-model-view-presenter-on-android--

cms-26162

[9] Diagramă Model View Presenter

http://1.bp.blogspot.com/-d3GTR-

tSRsg/Vj3FwQyeyvI/AAAAAAAAAaU/QEZ71nnNbHw/s1600/mvp-diagram.png

[10] Ciclul de viață al unei activități

https://developer.android.com/reference/android/app/Activity.html

[11] Fragmente

https://developer.android.com/guide/components/fragments.html

[12] Android Studio

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