SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

ZAVRŠNI RAD br. 5698

Primjena arhitekturnih koncepata za platformu Android na primjeru dječje

edukativne igre

Marko Sopčić

Zagreb, Lipanj 2018

Zahvala mentoru doc. dr. sc. Borisu Milašinoviću na savjetima oko izrade završnog rada.

Sadržaj

1. Uvod .......................................................................................................... 1

2. Funkcionalnosti ......................................................................................... 2

2.1. Korisnički zahtjevi ............................................................................... 2

2.1.1. Igra s riječima ............................................................................... 2

2.1.2. Igra s novčićima ........................................................................... 3

2.1.3. Postavke ...................................................................................... 3

2.1.4. Informacije .................................................................................... 3

2.2. Funkcionalni zahtjevi .......................................................................... 3

2.3. Nefunkcionalni zahtjevi ....................................................................... 4

3. Mapa mogućih prikaza .............................................................................. 5

4. Model podataka ....................................................................................... 13

4.1. ER model podataka .......................................................................... 13

4.1.1. Opis ER modela podataka ......................................................... 13

4.2. Fizički model podataka ..................................................................... 14

4.2.1. Opis fizičkog modela podataka .................................................. 14

4.3. Opisi entiteta ..................................................................................... 16

5. Baza podataka ........................................................................................ 18

5.1. Programska biblioteka Room ............................................................ 18

5.2. Struktura i dodavanje podataka ........................................................ 21

6. Arhitektura i tehnologija ........................................................................... 25

6.1. Android ............................................................................................. 25

6.1.1. Aktivnost..................................................................................... 25

6.1.2. Pogled ........................................................................................ 26

6.2. Primijenjeni arhitekturni koncepti ...................................................... 27

6.3. Čista arhitektura ................................................................................ 27

6.3.1. Pravilo o ovisnostima ................................................................. 28

6.3.2. Pravilo apstrakcije ...................................................................... 29

6.3.3. Pravilo komunikacije između slojeva .......................................... 29

6.4. Komponente čiste arhitekture ........................................................... 30

6.4.1. Entiteti ........................................................................................ 30

6.4.2. Slučajevi uporabe ....................................................................... 30

6.4.3. Repozitoriji ................................................................................. 30

6.4.4. Prezenteri ................................................................................... 30

6.4.5. Uređaj ........................................................................................ 31

6.4.6. Baza podataka i API ................................................................... 31

6.5. Primjena čiste arhitekture i moduli .................................................... 31

6.6. Oblikovni obrasci tvornica i jedinstveni objekt ................................... 34

6.7. Oblikovni obrazac promatrač i RxJava ............................................. 35

6.8. Oblikovni obrazac MVP .................................................................... 37

6.9. Oblikovni obrazac strategija .............................................................. 39

7. Zaključak ................................................................................................. 40

8. Literatura ................................................................................................. 41

9. Sažetak ................................................................................................... 42

1

1. Uvod

U moderno doba informacijskih tehnologija pametni telefoni su sastavni dio

svakodnevice. Djeci su takvi uređaji izrazito primamljivi jer sadrže njima hrpu

primamljivog materijala od raznog video sadržaja do video igrica, a roditelji često,

kako bi dobili nešto slobodnog vremena, djetetu predaju mobitel kako bi se dijete

zabavljalo za to vrijeme.

Kako bi djeca u takvim slučajevima uz igru ipak nešto i naučila, u sklopu predmeta

Projekt napravljena je aplikacija koja bi djeci uzrasta od 4 do 6 godina pružila

mogućnost da kroz igru nauče osnovne stvari kao što su slova i brojke. Aplikacija

koja je stvorena je načelno dobro funkcionirala, ali s obzirom da je kod pisala grupa

studenata koja nema bogato programsko iskustvo niti iskustvo rada u grupi

organizacija samog koda je bila nepraktično izvedena.

Kako bi se pokazala dobra organizacija koda, postojeća aplikacija je napisana

ponovno primjenjujući aktualne arhitekturne koncepte za platformu Android. Takva

organizacija razdvaja logički, podatkovni, prezentacijski i sloj uređaja koda. Na taj

način se pojedini sloj može lako razvijati u grupnom radu te je takav kod prikladan

za jednostavno testiranje pojedinog sloja neovisno o ostalim slojevima.

U ovom radu će biti opisane funkcionalnosti same aplikacije, pojedini slojevi,

njihova izvedba, korištene arhitekture i tehnologije. U idućem poglavlju su opisani

zahtjevi koje aplikacija mora implementirati, dok je u trećem poglavlju opisana mapa

dijaloga. Četvrto poglavlje opisuje konceptualni i fizički model podataka, dok peto

objašnjava konkretnu implementaciju baze podataka. U šestom poglavlju su opisani

arhitekturni koncepti i korištene tehnologija. Na kraju se nalazi sedmo poglavlje sa

zaključkom, osmo s popisom literature te deveto koje sadrži sažetak rada.

2

2. Funkcionalnosti

2.1. Korisnički zahtjevi

• Prilikom pokretanja aplikacije korisnik može birati između igre s riječima,

igre s novčićima, prikaza postavki i prikaza informacija o igri i autorima

2.1.1. Igra s riječima

• Biranjem igre s riječima korisniku se prezentira riječ na način da se prikaže

slika s opisom riječi i riječ se prikazuje slovo po slovo na zaslonu uz zvučni

izgovor pojedinog slova

• Korisnik mora moći povlačenjem po zaslonu pomicati slova po zaslonu

• Korisnik mora moći ubaciti slovo u polje otpuštanjem slova iznad polja

• U slučaju da je opcija prikaza točno ubačenog slova uključena, korisnik

dobiva potvrdu o istome promjenom boje polja na pola sekunde

• U slučaju da je opcija stvaranja dodatnih slova uključena, korisniku će se

osim slova koja sačinjavaju trenutnu riječ stvoriti dodatna slova koja može

pomicati

• Ako korisnik otpusti slovo nad poljem koje već sadrži neko drugo slovo,

sadržano slovo se mora izbaciti iz polja i otpušteno slovo umetnuti

• Korisniku mora u svakom trenutku igre biti vidljiva raspoloživa količina

sredstva za pomoć

• Ako ima dovoljno sredstva za pomoć, korisnik može pritisnuti novčić za

pomoć čime mu se promjenom boje slova i prvog polja koje nema točno

slovo pokazuje koje slovo u navedeno polje mora ubaciti

• Korisniku se kvačicom na zaslonu i zvučnom porukom dojavljuje točnost

rješenja

• Kada korisnik popuni sva polja, a rješenje nije točno, dojavljuje mu se

netočnost zvučnom porukom

• U slučaju točnog rješenja korisnikova količina sredstva za pomoć se

uvećava za dva i igra se prebacuje na novu riječ

3

2.1.2. Igra s novčićima

• Korisnik može povlačenjem prsta po ekranu pomicati novčiće

• Korisnik pomicanjem novčića u za to određeno područje slaže rješenje

• Korisniku u svakom trenutku igre mora biti vidljiv trenutni cilj igre

• Korisniku u svakom trenutku igre mora biti vidljiva trenutna suma unesenih

novčića

• Korisniku u svakom trenutku igre mora biti vidljiva količina sredstva za

pomoć

• Korisniku se pored novčića koji su dio optimalnog rješenja generiraju

dodatni nasumični novčići

• Ako korisnik unese rješenje koje je točno, ali ne i optimalno dojavljuje se

zvučnom porukom

• Ako korisnik unese optimalno rješenje prikazuje mu se kvačica na zaslonu

te zvučna poruka koja dojavljuje točnost rješenja

2.1.3. Postavke

• Korisnik mora moći uključiti/isključiti postavku za generiranje dodatnih

slova

• Korisnik mora moći uključiti/isključiti postavku za vizualnu potvrdu točno

unesenog slova

• Korisnik mora moći mijenjati jezik grafičkog sučelja

• Korisnik mora moći mijenjati jezik riječi u igri s riječima

• Korisnik mora moći odabrati kategorije riječi za igru s riječima

• Korisnik mora moći mijenjati raspoloživi broj sredstva za pomoć

2.1.4. Informacije

• Korisnik mora moći vidjeti informacije o nastanku aplikacije

2.2. Funkcionalni zahtjevi

• Nemogućnost odvlačenja slova ili novčića van ekrana

• Pritisak na objekt za pomoć ako je pomoć već uključena neće rezultirati

smanjenjem novčića

• Kod odabira kategorija barem jedna kategorija mora biti odabrana

4

• Mogućnost povlačenja više slova, odnosno novčića odjednom (ako uređaj

podržava navedenu funkcionalnost)

• Odabrani jezici moraju biti pohranjeni lokalno

• Trenutna količina novčića za pomoć mora biti pohranjena lokalno

• Odabrane kategorije za igru riječima moraju biti pohranjene lokalno

• Baza se mora učitati samo kod prvog pokretanja aplikacije

2.3. Nefunkcionalni zahtjevi

• Dohvaćanje podataka iz lokalne baze

• Dodavanjem novih jezika uređivanjem tekstualnih datoteka i dodavanjem

slikovnih i zvučnih datoteka

• Promjena slika novčića i riječi promjenom slikovnih datoteka

• Promjena zvukova izgovora riječi i pojedinog slova promjenom zvučnih

datoteka

• Lokalizacija aplikacije

• Broj novčića u postavkama može biti samo cijeli broj

• Slike i zvukovi moraju biti prikladne veličine kako bi instalacija aplikacije

bila što manja (maksimalno nekoliko kilobajta)

5

Slika 1 Biranje igre s riječima i prezentacija riječi

3. Mapa mogućih prikaza

Pritiskom na sliku novca pokreće se igra s riječima koja počinje prezentacijom

same riječi. Prezentacija se sastoji od prikaza slike koja predstavlja trenutnu riječ i

vremenski periodičnog slovkanja iste riječi.

6

Nakon prezentacije riječi slijedi sama igra. Korisnik povlačenjem prsta po ekranu

može micati slova. Otpuštanje slova iznad polja rezultira ubacivanjem istog slova u

navedeno polje.

Slika 2 Ubacivanje slova u polja

7

Pritiskom na novčić u gornjem lijevom kutu korisnik traži pomoć. Pomoć se sastoji

od periodične promjene boje prvog polja koje, ili ne sadrži slovo, ili sadrži netočno

slovo te svih slova koja odgovaraju tom polju. Pomoć prestaje kada korisnik ubaci

točno slovo na spomenuto polje. Kada korisnik unese točno rješenje sva polja

postanu zelena te se na zaslonu prikazuje kvačica.

Slika 3 Korištenje pomoći pritiskom na novčić

Slika 4 Prikaz prilikom unesenih svih točnih slova

8

Pritiskom na sliku novca korisnik bira igru s novčićima. Igra počinje prikazom

trenutne količine sredstva za pomoć, trenutnog cilja u zelenom kvadratu, sume

trenutnog rješenja u žutom kvadratu, novčića koji se mogu micati povlačenjem prsta

po zaslonu te polja u koje se ubacuju navedeni novčići.

Slika 5 Biranje igre s novčićima

Slika 6 Ubacivanje novčića

9

Kada korisnik unese optimalno rješenje na zaslonu se prikazuje kvačica te se igra

prebacuje na novu rundu.

Pritiskom na sliku zupčanika korisniku se prikazuje zaslon s postavkama koje

može mijenjati.

Slika 7 Prikaz nakon točno unesenih novčića

Slika 8 Biranje prikaza postavki

10

Pritiskom na tipke postavki „Zazeleni točno slovo“ i „Stvori više slova“ se

uključuje, odnosno isključuje pojedina postavka što je signalizirano promjenom boje

pozadine pojedine tipke. Pritiskom na tipku „Jezik“ se mijenja jezik sučelja dok se

pritiskom na tipku „Riječi“ mijenja jezik riječi u igri s riječima.

Slika 9 Promjena postavki pritiskom na gumb

Slika 10 Promjena jezika sučelja

11

Pritiskom na broj pored oznake „Broj novčića“ korisnik može mijenjati broj

raspoloživih sredstava za pomoć. Pritiskom na tipku „Kategorije“ korisniku se

prikazuje popis kategorija koje može odabrati. Pritiskom na zadane tipke može

označiti sve, označiti ništa i pohraniti trenutni odabir.

Slika 11 Promjena trenutne količine novčića za pomoć

Slika 12 Biranje kategorija riječiSlika 13 Promjena trenutne

količine novčića za pomoć

Slika 14 Biranje kategorija riječi

12

Slika 15 Biranje i prikaz informacija

Pritiskom na tipku sa slovom „i“ korisniku se prikazuju informacije o aplikaciji i

njenom nastanku.

13

Slika 16 Prikaz ER modela podataka

4. Model podataka

4.1. ER model podataka

4.1.1. Opis ER modela podataka

Najvažniji entiteti gore prikazanog modela su Word i Letter. Svaki entitet Word je

opisan svojom vrijednosti (value) kao i slikom koja je opisuje (Image).Također,

svaka riječ može biti prevedena na više jezika (Language). Pojedina riječ može

pripadati u više kategorija (Category). Ovisno o tome o kojem je jeziku riječ, svaka

riječ sadrži i putanju do zvučnog zapisa (soundPath u WordSound entitetu).

Slično je oblikovan i entitet Letter. On sadrži vrijednost slova (value) i referencu

na entitet Image s putanjom do slike navedenog slova. Pojedino slovo može

pripadati više jezika (Language). Ovisno o tome o kojem je jeziku riječ, entitet

također preko veze LetterSound sadrži putanju do zvučnog zapisa koje predstavlja

to slovo na zadanom jeziku (soundPath u LetterSound entitetu).

14

Slika 17 Prikaz fizičkog modela podataka

Osim toga model sadrži i entitet Message koji predstavlja zvučnu poruku.

Entitet je predstavljen tipom (type), jezikom kojem pripada (Language) te putanjom

do zvučnog zapisa poruke na navedenom jeziku (soundPath).

Zadnji entitet je Coin koji predstavlja novčić s nekom vrijednosti i putanjom do

slike.

4.2. Fizički model podataka

4.2.1. Opis fizičkog modela podataka

Prema ER modelu napravljen je fizički model baze podataka koja je zatim

normalizirana, to jest svedena na treću normalnu formu. Dodatno, baza je

oblikovana na taj način da se minimizira količina novih podataka prilikom dodavanja

novih jezika i riječi, kao što su na primjer slova čiji zapis s vrijednosti i slikom već

postoji, ili riječ koja je predstavljena uvijek istom slikom.

15

Kao i u ER modelu, sve kreće od entiteta Letter i Word.

Entitet Letter modelira slovo koje se sastoji od slike i njegove vrijednosti, koja je

zbog dvoglasa, kao na primjer u hrvatskom jeziku nj, lj i dž postavljena na tip String.

Slova istih vrijednosti, ali različitih jezika se pohranjuju s istom slikom kako bi uštedili

na memorijskom prostoru.

Language predstavlja pojedini jezik koji aplikacija podržava u smislu grafičkog

sučelja kao i samih riječi u igri s riječima.

LetterLanguageRelation entitet omogućuje kombinaciju svakog Letter entiteta s

bilo kojim jezikom iz Language tablice, što nam omogućuje dohvaćanje slova koja

postoje samo u određenom jeziku.

Entitet Word modelira pojedinu riječ koja postoji u igri s riječima. Kako bi smanjili

količinu podataka koja se pohranjuje odvojili smo dio riječi sa slikom i dio riječi s

izgovorom pošto je neovisno o jeziku slika uvijek ista za određenu riječ.

Entitet Category predstavlja kategorije koje su dostupne u igri s riječima.

Veza između entiteta Word i Category je predstavljena entitetom

WordCategoriesRelation koja predstavlja n-n tip veze što omogućuje da jedna riječ

može pripadati u više kategorija.

Entitet WordLanguageRelation modelira n-n vezu između pojedinih entiteta Word i

Language te sadrži vrijednost same riječi.

Radi jednostavnosti entiteti iz ER modela tipa Message su podijeljeni u tri zasebna

entiteta ovisno o tipu poruke. Tako postoje CorrectMessage, IncorrectMessage i

TryAgainMessage entiteti. Svaki sadrži strani ključ na jezik te putanju do zvučnog

zapisa za pojedini jezik.

Entitet Coin modelira novčić koji se koristi za igru s novčićima.

Posljednji entitet je DatabaseVersion koji pohranjuje trenutnu verziju baze kako bi

jednostavno mogli provjeriti je li baza ažurna.

16

4.3. Opisi entiteta

Letter – entitet s kojim su povezani entiteti vezani za slova i jezik.

• letterId – primarni ključ entiteta (automatski generirano polje)

• imageId – strani ključ entiteta Image

• value – vrijednost pojedinog slova

Language – predstavlja podržane jezike

• languageId – primarni ključ entiteta (automatski generirano polje)

• name – naziv jezika

LetterLanguageRelation – entitet koji povezuje entitete Letter i Language

• letterId – ujedno dio primarnog i strani ključ na entitet Letter

• languageId – ujedno dio primarnog i strani ključ na entitet Language

• soundPath – putanja do zvučnog zapisa koji predstavlja izgovor slova na

jeziku predstavljenim stranim ključem languageId

Image – entitet koji pohranjuje putanju do slikovnog zapisa

• imageId – primarni ključ entiteta (automatski generirano polje)

• imagePath – putanja do slikovnog zapisa

Word – entitet koji modelira pojedinu riječ u igri s riječima

• wordId – primarni ključ entiteta (automatski generirano polje)

• imageId – strani ključ na slikovni zapis riječi

Category – entitet koji modelira pojedinu kategoriju riječi

• categoryId – primarni ključ entiteta (automatski generirano polje)

• name – ime kategorije

WordCategoriesRelation – entitet koji modelira više – više vezu između entiteta

Word i Category

• wordId – strani ključ na entitet Word

• categoryId – strani ključ na entitet Category

17

WordLanguageRelation – entitet koji modelira vezu između entiteta Word i

entiteta Language

• wordId – ujedno dio primarnog i strani ključ entiteta Word

• languageId – ujedno dio primarnog i strani ključ entiteta Language

• value – vrijednost riječi predstavljene ključem wordId u jeziku

predstavljenog ključem languageId

• soundPath – putanja do zvučnog zapisa koji predstavlja riječ na jeziku

predstavljenim stranim ključem languageId

CorrectMessage, IncorrectMessage, TryAgainMessage – entiteti koji

predstavljaju zvučne poruke vezane za pojedini jezik

• id – primarni ključ pojedine poruke (automatski generirano polje)

• languageId – strani ključ na entitet Language

• soundPath – putanja do zvučnog zapisa pojedine poruke

DbVersion – entitet koji pohranjuje trenutnu verziju baze kako bi se lako

provjerilo je li baza ažurna

• id – primarni ključ entiteta (automatski generirano polje)

• version – verzija baze

Coin – entitet koji modelira novčić u igri s novčićima

• id – primarni ključ entiteta (automatski generirano polje)

• value – vrijednost novčića

• imagePath – putanja do slike novčića s navedenom vrijednosti

18

Slika 18 Primjer bilješke za Database komponentu

5. Baza podataka

5.1. Programska biblioteka Room

Room je biblioteka koja pruža sloj apstrakcije nad SQLite bazom podataka i time

omogućava jednostavan pristup bazi podataka i iskorištavanje punog potencijala

SQLite baze podataka. Room se sastoji od 3 glavne komponente:

• Database – glavna komponenta koja služi kao pristupna točka preko koje

se odvijaju sve radnje kao što su umetanje, dohvaćanje, modificiranje i

brisanja podataka i sadrži reference na DAO objekte

• Entity – komponenta koja predstavlja tablicu određenih entiteta

• DAO (Data Access Object) – komponente preko kojih se obavljaju radnje

umetanja, dohvaćanja, ažuriranja i brisanja podataka

I komponentu Database i komponente DAO implementiramo apstraktno –

komponenta Database se implementira kao apstraktna klasa dok se DAO objekti

implementiraju kao sučelja. Na klasu koja modelira komponentu Database potrebno

je staviti bilješku (engl. annotation) „@Database“, dok na DAO sučelja stavljamo

bilješke „@Dao“. Uz anotaciju „@Database“ potrebno je staviti popis klasa koje

modeliraju entitete koji će biti sadržani u bazi kao i verziju baze.

19

Slika 19 Primjer DAO sučelja

Slika 20 Primjer entiteta

Metode DAO sučelja mogu se označiti bilješkama „@Insert“, „@Query“, „@Delete“

ili “@Update“ ovisno o radnji koju želimo izvesti. Uz bilješku „@Query“ potrebno je

napisati i SQL upit kojim se označava koje podatke želimo dohvatiti.

Jedine komponente koje nisu apstraktne su komponente Entity – njih se može

označiti bilješkama „@Entity“ i implementirati ih kao obične java klase. Uz bilješku

„@Entity“ se mogu dodati atributi kao što su naziv tablice entiteta, popis primarnih

ključeva, popis stranih ključeva te popis indeksa. Kako bi DAO objekti upitom mogli

vratiti entitete njihove varijable moraju biti javne ili mogu biti privatne s

implementiranim metodama za postavljanje i dohvaćanje pojedinih varijabli.

Dodatno, pojedine varijable mogu se obilježiti bilješkama „@PrimaryKey“, da bi se

naznačilo da je varijabla primarni ključ entiteta, „@ColumnInfo“, da bi se dodale

dodatne informacije o stupcu u bazi, na primjer ime stupca ili „@Ignore“ kako bi se

naznačilo da se ta varijabla ne sprema u bazu.

20

Slika 21 Primjer podataka u bazi

Pošto su i DAO i Database komponente apstraktne, prilikom prevođenja Room

će sam stvoriti implementacije tih objekata koji će implementirati modeliranu bazu

pomoću SQLite baze podataka.

Pristupanje implementiranim metodama je jednostavno. Za početak, potrebno je

stvoriti instancu Database komponente. To se radi pozivanjem statičke metode

„Room.databaseBuilder“ kojoj se predaje kontekst, klasa Database komponente te

ime baze. Metoda vraća konkretnu implementaciju Database komponente koja

sadrži konkretne implementacije DAO komponenti koje su navedene unutar nje.

Zbog Liskovina načela supstitucije konkretna implementacija se može spremiti u

referencu koja je apstraktnog tipa.

21

Slika 22 Prikaz komunikacije između komponenata baze podataka

Slika 23 Datoteka languages.txt

Slika 24 Dio datoteke "croatian.txt"

5.2. Struktura i dodavanje podataka

Sama baza podataka je formirana na takav način da je jednostavno dodati nove

jezike, pa takvi moraju biti i sami podaci koji se učitavaju u bazu. Podaci su prema

tome podijeljeni u podmape ovisno o tome je li riječ o slovima, riječima ili zvukovima.

Ostale datoteke, kao što su datoteke s kategorijama, jezicima i verzijom nalaze se

u vršnom „database“ direktoriju.

Postupak dodavanja novog jezika bi izgledao ovako:

• Dodati novi redak u datoteku „languages.txt“ s nazivom jezika

• Dodati novu datoteku u mapu „letters“ u formatu „naziv_jezika.txt“ koja

sadrži slova tog jezika gdje je svako slovo u novom retku

22

• U datoteku „letters.txt“ po potrebi dodati zapise slova kojih još nema

• Po potrebi, ako navedenih slika nema, dodati slike slova u mapu

„letter_images“, gdje se svaka slika zove po slovu i jednog je od formata

koje podržava android sustav.

Slika 25 Primjer slika u direktoriju "letter_images"

• U podmapu „alphabet“ mape „sound“ dodati novu mapu imena novog

jezika koja sadrži zvučne zapise izgovora pojedinog slova tog jezika. Ime

zapisa mora biti slovo kojeg predstavlja a format mora biti podržan u

sustavu android

• U mapu „messages“ potrebno je dodati novu mapu imena novog jezika. U

stvorenu mapu dodati podmape „again“, “correct“, “incorrect“ i u svaku

dodati proizvoljan broj (ali barem jedan) zvučnih zapisa za poruke tipa

„točno, ali može bolje“, „točno“ i „netočno“ u formatu koji android podržava

Slika 26 Primjer hijerarhije direktorija "sound"

23

Slika 29 Primjer datoteke "croatian.properties"

• U podmapama mape „words“, gdje svaka mapa predstavlja po jednu riječ,

u datoteku „spelling.properties“ dodati uređeni par oblika

„naziv_jezika=riječ_na_tom_jeziku“ i u samu mapu dodati zvučni zapis koji

predstavlja izgovor te riječi na tom jeziku koja mora biti imena tog jezika

Slika 27 Primjer direktorija jedne riječi

Slika 28 Primjer datoteke "spelling.properties"

• U mapu „translations“ dodati novu datoteku imena „ime_jezika.properties“

koja sadrži uređene parove za prijevode kategorija, jezika i elemenata

grafičkog sučelja

• Zaključno, promijeniti verziju u datoteci „version.txt“ kako bi se baza

prilikom idućeg pokretanja aplikacije ažurirala

24

U slučaju dodavanja novih kategorija, potrebno je u datoteku „categories.txt“

dodati nove zapise s nazivima kategorija i u enumeraciju Category u modulu

Domain dodati iste. Za jezike vrijedi isto, samo se oni dodaju u datoteku

„languages.txt“ i enumeraciju Language. Ako postoje posebna pravila kako se riječ

razdvaja na slova, to jest više znakova tvori jedno slovo, potrebno je u modulu

Domain implementirati sučelje WordSplitter s pravilima razdvajanja slova u tom

jeziku, te u klasi WordGameUtil povezati jezik s instancom WordSplitter.

Ako se dodaju nove riječi, potrebno je u mapu „words“ dodati novu podmapu sa

slikom riječi, tekstualnom datotekom s popisom kategorija, zvučnim zapisima i

datotekom koja sadrži prijevode prema gore navedenom formatu.

Kako bi se osiguralo da će se sva slova, riječi i slično pravilno pohraniti sve

datoteke s ekstenzijama „.txt“ i „.properties“ se moraju kodirati s „UTF-8“ kodiranjem.

Također, potrebno je osigurati da se zvučni zapisi mogu izvesti na android

sustavu. Android podržava mnoge audio formate, kao što su na primjer „.3gp“,

„.flac“, „.midi“, „.mp3“, „.wav“ itd.

Sve slike također moraju biti formata koje podržava android, od kojih su

najpoznatiji „.bmp“, „.gif“, „.jpg“ i „.png“ .

25

6. Arhitektura i tehnologija

6.1. Android

Android je operacijski sustav za razne uređaje kao što su mobiteli, tableti,

televizori, pametni satovi pa čak i automobili. Android je razvila tvrtka Google, a

temelji se na modificiranoj verziji Linux-a i ostalom otvorenom kodu. U svijetu

mobilnih uređaja Android je uz IOS među najpoznatijim sustavima. Najnovija verzija

Androida je 8.1 pod imenom Oreo. Prema podacima iz Svibnja 2018. Oreo verzija

je instalirana na 5,7% Android uređaja. Kako bi se maksimizirala količina uređaja na

kojima se aplikacija može pokrenuti, podržavat će se verzije od 4.4 Kitkat (jedna od

najpopularnijih verzija) do 8.1 Oreo. Time će se osigurati da se naša aplikacija može

pokrenuti na 95% posto uređaja koji koriste sustav Android.

Kako je Android postao jako popularan, Google je napravio Android Studio,

integriranu okolinu za razvijanje, koja se besplatno može skinuti s njihovih stranica.

Time je omogućeno da svatko može stvoriti aplikaciju i objaviti je u Trgovini Play,

aplikaciji koja se nalazi na svakoj inačici Androida pomoću koje se mogu skidati

ostale objavljene aplikacije, čime je dodatno pridoneseno popularnosti Androida.

6.1.1. Aktivnost

Kako bi se bolje razumio način na koji Android aplikacija funkcionira, potrebno je

razumjeti osnovne pojmove kao što je aktivnost. Aktivnost je jedna fokusirana stvar

koju korisnik može raditi a predstavljena je grafičkim sučeljem na uređaju. Korisnik

može djelovati nad tom aktivnosti i time prelaziti između više aktivnosti.

Sama aktivnost ima poprilično složen životni ciklus. Kod pokretanja aktivnosti,

bilo od strane korisnika ili same aplikacije, poziva se njezina metoda onCreate(), u

kojoj je potrebno pozvati metodu setContentView() koja definira izgled same

aktivnosti. Toj metodi se predaje resurs koji označava xml datoteku u kojoj je

definiran izgled same aktivnosti. Kada se izvrši metoda onCreate() poziva se

metoda onStart(), koja inicijalizira kod koji će održavati grafičko sučelje. Nakon što

onStart() završi, poziva se metoda onResume(), u kojoj komponente životnog

26

Slika 30 Životni ciklus aktivnosti

ciklusa mogu omogućiti funkcionalnosti koje se moraju pokretati dok je aktivnost

vidljiva.

Kada se dogodi neki nagli izlazak iz aktivnosti, kao na primjer dolazni poziv ili

pritisak na tipku home, poziva se metoda onPause() i aktivnost ulazi u stanje

Paused. Ako se aktivnost vraća u stanje Resumed iz stanja Paused, sustav opet

poziva metodu onResume().

6.1.2. Pogled

Pogled je jedan od osnovnih komponenata aktivnosti. On je apstraktna

komponenta koja omogućuje prikaz pojedinih elemenata grafičkog sučelja, ali i

odlučuje o tome što će se dogoditi pritiskom na zaslon ili sami element. Sadrži

27

metodu draw(), koja služi za prikazivanje komponente na zaslonu i metodu

onTouchEvent(), koja omogućuje definiranje događaja nakon pritiska na zaslon.

Kako bi se u igri olakšalo stvaranje vlastitih grafičkih elemenata i njihovo

prikazivanje te obradili dodiri na zaslonu, proširena je klasa SurfaceView koja to

omogućuje. Nakon toga, nadjačana je metoda draw kako bi se prikazali vlastiti

elementi, i metoda onTouchEvent() kako bi se definiralo ponašanje prilikom pritiska

na zaslon.

6.2. Primijenjeni arhitekturni koncepti

Kao što je rečeno nije jednostavno napisati dobro organiziran kod. Kako bi kod

bio organiziran potrebno je primijeniti neke arhitekturne koncepte koji su dobro

utvrđeni i koji su se pokazali efikasnima u procesu razvijanja programske potpore.

Kao rezultat toga u ovom su radu primijenjeni idući koncepti:

• Čista arhitektura

• Oblikovni obrasci tvornica i jedinstveni objekt

• Oblikovni obrazac promatrač

• MVP obrazac (model-pogled-prezenter)

• Oblikovni obrazac strategija

6.3. Čista arhitektura

Budući da danas više-manje svi ljudi imaju pristup internetu, svatko može naučiti

programirati, neovisno na kojoj razini, i svatko tko radi u sektoru informacijskih

tehnologija vjerojatno zna nekoliko programskih jezika, no nije dovoljno znati

programirati, potrebno je programirati pametno. Vrlo je jednostavno napisati

program koji radi, ali čiji kod je isprepleten, popularno nazivan „špageti kod“. Takav

kod je jako teško testirati, nadograditi, izmijeniti i slično. Kako bi se izbjegle takve

situacije potrebno je pisati kod prateći neku od dobro poznatih i isprobanih

arhitektura. Kako je trenutno na dobrom glasu i jako popularna čista arhitektura,

odlučeno je primijeniti je i u ovom radu. Čista arhitektura nalaže tri pravila:

28

• Pravilo o ovisnostima

• Pravilo apstrakcije

• Pravilo komunikacije između slojeva

6.3.1. Pravilo o ovisnostima

Pravilo o ovisnostima definira strukturu ovisnosti slojeva. Slojevi se najlakše

mogu objasniti sljedećom slikom.

U središtu strukture se nalaze entiteti poslovne logike. Oni definiraju samu logiku

programa neovisno o sustavu na kojem će se program izvoditi. Odmah pored njih

nalaze se slučajevi upotrebe koji definiraju sve moguće radnje koje korisnik može

raditi i također su dio poslovne logike. Vanjski slojevi strukture su implementacije

apstraktnih sučelja definiranih u unutarnjim slojevima, na primjer upravljači i

prezenteri implementiraju prikaz poslovne logike, dok najviši sloj implementira

detalje baze podataka. Slojeve možemo razdvojiti u različite pakete, ali onda treba

paziti da se vanjski paketi ne koriste u unutarnjim paketima. U našem slučaju, kako

Slika 31 Slojevi čiste arhitekture

29

Slika 32 Primjer komunikacije između slojeva

ne bi pomiješali poslovnu logiku s androidom, slojevi entiteta i slučaja upotrebe

stavljeni su u zasebni modul koji je čisti java modul imena Domain (hrv. Domena),

dakle može se pokrenuti na bilo kojem uređaju koji može pokretati java kod.

6.3.2. Pravilo apstrakcije

Pravilo apstrakcije nalaže da kretanjem prema unutrašnjosti strukture i prema

unutrašnjim slojevima stvari postaju sve apstraktnije. Kao što smo rekli, vanjski

slojevi sadrže implementacijske detalje koje poslovna logika ne može

implementirati, kao što je prikaz na zaslon, pohrana podataka i slično.

Kada se spoji pravilo apstrakcije i pravilo o ovisnostima, lako je primijetiti da slojevi

koji sadrže poslovnu logiku ne znaju ništa o slojevima koji sadrže implementacijske

detalje apstraktnih sučelja. Na ovaj način jednostavno se mogu zamijeniti konkretne

implementacije neovisno o poslovnoj logici.

6.3.3. Pravilo komunikacije između slojeva

Podjelom koda na module je odvojena poslovna logika od slojeva upravljača i

podatkovnog sloja. Preostaje samo posložiti način na koji će slojevi, odnosno

moduli, međusobno komunicirati. Podsjećanjem na pravilo o ovisnostima, primijetit

će se da unutarnji slojevi ne smiju znati ništa o vanjskim slojevima. Kao dobar

primjer poslužit će iduća slika.

30

Recimo da se želi dohvatiti podatak iz baze, obraditi i prikazati na zaslonu. Zbog

pravila o ovisnostima ne smiju se dohvaćati podaci iz baze i slati poslovnoj logici

nego ih poslovna logika mora sama dohvatiti. Ako pogledamo sliku, primijetit ćemo

da su zaslon i baza implementacije viših slojeva, dok je obrada dio poslovne logike.

Kada korisnik izvrši neku radnju na zaslonu, upravljač, koji sadrži referencu na

ulazno sučelje slučaja uporabe, će preko sučelja poslati ulazne podatke slučaju

uporabe u poslovnu logiku. Slučaj uporabe će unutar poslovne logike obraditi

podatke i vratiti podatke preko apstraktnog izlaznog sučelja. Kako bi podatke mogao

primiti, prezenter implementira izlazno sučelje i time dobiva obrađene podatke iz

poslovne logike. Pošto je izlazno sučelje slučaja uporabe apstraktno, ono ne zna

što se dalje događa s podacima koje šalje na njega čime i dalje poštujemo pravilo

apstrakcije i pravilo o ovisnostima.

6.4. Komponente čiste arhitekture

6.4.1. Entiteti

Entiteti su poslovni objekti koji modeliraju glavnu funkcionalnost aplikacije.

Samim pogledom na entitete se može zaključiti smisao aplikacije. Oni sadrže

poslovnu logiku i nemaju nikakvu interakciju s ostalim implementacijskim detaljima.

6.4.2. Slučajevi uporabe

Slučajevi uporabe su proširenje entiteta i poslovne logike. Oni sadrže logiku koja je

vezana za više Entiteta i svaki slučaj uporabe modelira jednu specifičnu radnju koju

korisnik može napraviti, na primjer ubacivanje slova u polje ili korištenje pomoći.

6.4.3. Repozitoriji

Svrha repozitorija je pohrana entiteta. Svaki repozitorij je definiran kao sučelje i

služi kao ulazno i izlazno sučelje slučajevima uporabe koji žele obaviti radnje nad

entitetima. Konkretne implementacije repozitorija se nalaze u podatkovnom sloju.

6.4.4. Prezenteri

Smisao prezentera je upravo – prezentiranje. Oni obrađuju korisničke interakcije,

pozivaju određenu poslovnu logiku i šalju podatke grafičkom sučelju kako bi ih

prikazao. Često je između raznih tipova modela (modeli poslovne logike, modeli

podatkovnog sloja, modeli grafičkog sloja…) potrebno mapirati modele. Naravno,

31

potrebno je pratiti pravilo o ovisnostima i mapirati modele nižih slojeva u modele

viših slojeva isključivo u višim slojevima.

6.4.5. Uređaj

Ova komponenta implementira sve što nije dio grafičkog sučelja niti poslovne

logike, kao na primjer dohvaćanje podataka raznih senzora, upravljanje vibracijama,

produciranjem zvukova, slanjem obavijesti i slično. Naravno, ako ovakvi podaci

trebaju u sloju poslovne logike, on će sadržavati apstraktna sučelja koja će se potom

implementirati u vanjskom sloju. Tako se na primjer može implementirati slanje

obavijesti na konzolu, spremanje obavijesti u datoteku ili prikazivanje obavijesti na

ekranu.

6.4.6. Baza podataka i API

Ova komponenta sadrži implementacije apstraktnih repozitorija iz sloja poslovne

logike. Slično kao s komponentom uređaja, nije bitno na koji način se implementira

pohrana, odnosno dohvaćanje podataka. Implementacije mogu spremati podatke u

datoteke, dohvaćati ih s interneta ili iz lokalne baze. Sloju poslovne logike je bitno

da ih može dohvatiti, ne i kako.

6.5. Primjena čiste arhitekture i moduli

Primjenom čiste arhitekture u ovom radu je dobiven kod koji je podijeljen u

module gdje svaki modul sadrži odgovornost za jedan dio aplikacije. Kao što je već

rečeno, sve što ima veze s poslovnom logikom smješteno je u modul Domain koji je

čisti java modul. Modul Device sadrži implementacije apstraktnih sučelja poslovne

logike koji nisu vezani za dohvaćanje i spremanje podataka niti grafičko sučelje.

Budući da su takve stvari vezane uz sami sustav android, ovaj modul se stvara kao

Android biblioteka. Modul Data sadrži implementacije repozitorija i implementira

dohvaćanje i pohranu podataka. Budući da je dohvat podataka također često vezan

za sami sustav Android, i ovaj modul se stvara kao Android biblioteka. Posljednji,

ali ne najmanje bitan je modul app. U njega ide sve vezano za grafičko sučelje.

Ovom podjelom dobiven je kod kojeg se pojedini modul lako testira neovisno o

ostalim modulima, i kao što sam riječ „modul“ govori kod je postao modularan,

odnosno pojedini modul se može izvaditi i zamijeniti drugim modulom.

32

Slika 33 Lijevo - organizacija koda s predmeta projekt , desno -

organizacija koda u ovom radu

Kao što se može vidjeti na slici lijevo, organizacija koda s predmeta projekt praktički

ne postoji. Većina klasa se nalazi u jednom paketu uz iznimku nekoliko ostalih

paketa. Suprotno tome, desno na slici se nalazi organizacija koda u ovome radu.

Kod je raspodijeljen u prikladne module prateći čistu arhitekturu te dodatno u

određene pakete ovisno o tome koji dio funkcionalnosti unutarnje implementacije

pružaju. Rješenje rada je pisano prateći princip jedinstvene odgovornosti, dok na

primjer klasa GamePanel iz implementacije koda na predmetu projekt ima previše

odgovornosti. Ona upravlja samom logikom igre, događajima dodira, produciranjem

zvuka, kreiranjem objekata i slično.

Kao primjer komunikacije između raznih slojeva može se dati započinjanje nove

igre. Kada se odabere igra s novčićem, u pogledu se pretplaćuje na Observable koji

šalje događaje svakih trideset milisekundi, prilikom kojih će se pogled ažurirati i

iscrtati modele koje mu je zadao prezenter na zaslon. Bez RxJave, ovaj dio se

morao izvoditi na zasebnoj dretvi što je stvaralo dodatne probleme. Nakon toga,

33

pozove se metoda prezentera nextRound(). Ta metoda će inicijalizirati potrebne

modele te zatražiti listu novčića od CoinGameManager-a. CoinGameManager

generira nasumični broj koji će biti cilj igre te od objekta ProblemGenerator traži

optimalno rješenje i dodatne nasumične novčiće. Kada dobije sve te podatke,

zatražit će od CoinGameRepository-a listu novčića s pridruženim putanjama do

slika. Repozitorij je implementiran u podatkovnom sloju gdje je definirana baza

Room. Repozitorij će dohvatiti modele iz baze podataka, ali prije nego ih vrati mora

ih mapirati u modele iz sloja domene. CoinGameManager će preko izlaznog sučelja

vratiti prezenteru listu novčića preuzetih od repozitorija koji će ih dalje predati

objektu zaduženom za mapiranje objekata iz sloja domene u sloj aplikacije. Nakon

toga prezenter dobivene modele predaje pogledu koji ih prikazuje na zaslonu. Kada

korisnik povlačenjem prsta po zaslonu unese novčić u zadano polje, pogled šalje

informaciju o unesenom novčiću prezenteru koji poziva slučaj uporabe

InsertCoinIntoField koji preko ulaznog sučelja dobiva vrijednost novčića koji je

unesen u polje. Slučaj uporabe prenosi informaciju CoinGameManager-u koji

odlučuje je li odgovor točan ili nije i vraća informaciju slučaju uporabe, koji je opet

vraća preko izlaznog sučelja prezenteru. Ako je odgovor točan, prezenter prikazuje

kraj trenutne runde, zatraži novu rundu od CoinGameManager-a i ciklus se

nastavlja.

Zaslon

Pogled/

CoinGameView

Prezenter/

CoinGamePresenter

Maper

poslovnog

sloja

CoinGameManager/

InsertCoinIntoFieldUseCase

Repozitorij/

CoinGameRepository

Baza

podataka

Maper

podatkovnog

sloja

Slika 34 Primjer komunikacije između slojeva aplikacije

Sloj uređaja/ modul app Prezenterski sloj/modul app

Logički sloj/modul domain

Podatkovni sloj/ modul data

34

6.6. Oblikovni obrasci tvornica i jedinstveni objekt

Često prilikom pisanja koda postoje razne ovisnosti između više objekata. Kako

kod postaje sve složeniji broj tih ovisnosti raste i postaje ih teško pratiti. Također,

često je dovoljna samo jedna instanca nekog objekta, ali i taj objekt postaje ovisnost

i potrebno ga je prosljeđivati svim ostalim objektima koji ga trebaju. Prateći oblikovni

obrazac tvornice može se poprilično olakšati posao. Obrazac tvornice omogućuje

stvaranje objekata bez da se zna na koji način se oni zapravo stvaraju. Tako se

može zatražiti neki objekt i dobiti već postojeća instanca a da se to ni ne zna. Što

se tiče androida, posao se može dodatno olakšati koristeći biblioteku Dagger2.

Biblioteka od korisnika traži da definira module i komponente. Moduli sadrže

dobavljače za određene objekte, dok komponente definiraju raspon u kojem će se

određeni objekti dijeliti odnosno kreirati. Dagger2 će, kada se prvi put zatraži neki

objekt kreirati instancu metodom definiranom u modulu. Ako je navedeni objekt

označen kao jedinstveni objekt (engl. Singleton) Dagger2 pamti referencu na njega

i kada se opet zatraži vrati isti objekt. Rješenje s predmeta projekt je po ovom pitanju

poprilično neodgovorno. Na primjer, klasa koja je upravljala igrom riječi GamePanel

je bila odgovorna za objekte koji su joj potrebni kao što su slova, slike i zvukovi i

samu bazu podataka. Budući da je u ovome radu korištena Room baza podataka

koja je apstrakcija nad SQLite-om, ona sama brine o višedretvenoj sigurnosti. Zbog

toga u kontekstu cijele aplikacije je dovoljno da postoji jedna instanca objekta kojim

se pristupa navedenoj bazi. U sklopu ovog završnog je primijenjen oblikovni obrazac

jedinstveni objekt na mnogim objektima koji se koriste kroz aplikaciju od kojih je

jedan i baza podataka, dok se je u rješenju koje nudi kod s predmeta projekt uvijek

stvarala nova instanca objekta kada god je bilo potrebno pristupiti istoj, što naravno

nepotrebno zauzima resurse uređaja. Na idućoj slici se može vidjeti primjer korišten

u ovom radu. Slika prikazuje dio klase CoinGameModule koji sadrži definicije za

stvaranje objekata, pomoću kojih će biblioteka Dagger2 generirati konkretne

implementacije tvornica. Također se može vidjeti da su stvoreni objekti označeni sa

„@Singleton“ odnosno kao jedinstveni objekt, što znači da će generirane tvornice

pamtiti reference na te objekte i idući put kada se zatraži objekt tog tipa vratiti već

postojeći objekt.

35

Slika 35 Primjer obrazaca tvornice i jedinstveni objekt

6.7. Oblikovni obrazac promatrač i RxJava

Oblikovni obrazac promatrač definira subjekte i promatrače. Svaki promatrač se

može pretplatiti na subjekte kako bi saznao kada je pojedini subjekt napravio nešto

što promatrača zanima.

RxJava je biblioteka koja proširuje oblikovni obrazac promatrač. Jako je korisna

prilikom asinkronog i vremenski određenog rada. Postoji pet vrsti baznih objekata

koje nudi RxJava: Flowable, Observable, Single, Completable, Maybe.

Observable je objekt na koji se može pretplatiti i definirati kako će se reagirati na

događaje koje radi Observable. Single je isti kao Observable, ali on šalje samo jedan

događaj. Completable je radnja koja će se ili izvršiti ili će vratiti grešku. Flowable je

sličan Observable-u, ali on može pohranjivati događaje koji nisu obrađeni kako bi

se naknadno mogli obraditi. Maybe je unija Single-a i Completable-a, što dopušta

da se šalje nula, jedan događaj ili greška. Na svaki od ovih objekata se može

pretplatiti kako bi definirali što će se događa prilikom događaja ili greške.

36

Slika 36 Primjer koda RxJave koji upravlja prezentiranjem riječi

Slika 37 Primjer koda s predmeta projekt koji ažurira pomoć u igri s

riječima

Primjer pokazuje dio koda koji prezentira riječ u igri s riječima. Kreira se objekt tipa

Observable koji će u intervalima definiranima u metodi interval() slati događaje.

Također, u metodi takeWhile() se definira do kada će se događaji slati. Nakon toga

se pretplaćuje na same događaje s anonimnim razredom koji je tipa Subscriber i

koji definira tri metode – onSubscribe(), onNext() i onCompleted(). Također se

može vidjeti da se događaji mogu ugnijezditi. Tako je unutar metode onCompleted()

vanjskog objekta definiran novi Observable.

Kao suprotnost tome prikazan je dio koda iz implementacije s predmeta projekt.

Metoda sa slike updateHint() se poziva svaki put kada se zaslon osvježi, u našem

slučaju trideset puta u sekundi te svaki put provjerava je li prošlo određeno vrijeme

kako bi nešto napravila. Ovo je samo jedan od mnogih primjera gdje se je mogao

37

Slika 38 Prikaz MVP obrasca

primijeniti obrazac promatrača i time poprilično smanjiti broj operacija koje se

izvode.

6.8. Oblikovni obrazac MVP

Kako bi se pokazala izvedba obrasca MVP u aplikaciji napravit će se pregled

strukture igre s novčićima. Igra je, kao i igra s riječima, organizirana prema MVP

oblikovnom obrascu. MVP nalaže korištenje tri komponente: modela, pogleda i

prezentera. Model predstavlja podatak koji se prikazuje na grafičkom sučelju. U

našem slučaju, model predstavlja novčiće, polje za unos novčića, labele s trenutnom

vrijednosti unesenih novčića, labele s ciljanom vrijednosti te novčić s brojem

sredstava za pomoć. Pogled prikazuje model na zaslonu, reagira na radnje korisnika

te dojavljuje prezenteru o izvršenim radnjama. Prezenter obavještava modele o

promjenama, modeli naprave potrebne izmjene, prezenter zatim javlja pogledu kako

da promijeni grafičko sučelje. Na taj način maksimiziramo količinu koda koja se

može testirati neovisno o ostalim komponentama.

U nastavku je kao primjer prikazan MVP dio koda igre s novčićima. Svi razredi

modela su izvedeni iz apstraktnog razreda GameDrawable koji definira način na koji

će se pojedini model prikazati na zaslonu. Pogled sadrži listu referenci na

38

Slika 41 Primjer apstraktnog modela

Slika 40 Primjer metode pogleda koja

u intervalima poziva crtanje modela

GameDrawable i svakih trideset milisekundi ih crta na zaslon. Pogled, ako mu

prezenter to dopušta, obrađuje svaki događaj dodirivanja zaslona. Ako je novčić

povučen u polje, pogled dojavljuje prezenteru o tome. Prezenter će ažurirati

vrijednost sume u polju te provjeriti pozivajući metode CoinGameManager-a je li

rješenje točno. Ako je rješenje točno, prezenter dojavljuje pogledu da treba prikazati

kvačicu na zaslonu i zabranjuje obradu dodira dok se ne pokrene iduća runda.

Kao protuprimjer je opet uzeta klasa GamePanel iz implementacije s predmeta

projekt. Klasa je bila ujedno i prezenter i pogled – definirala je na koji način će se

prikazivati podaci iz modela, prikazivala je podatke na zaslonu te upravljala

događajima dodira na zaslonu. Samim time je prekršeno pravilo jedinstvene

odgovornosti.

Slika 39 Primjer modela novčića

Slika 42 Primjer metoda prezentera

39

Slika 43 Primjer strategije i konkretnih implementacija

6.9. Oblikovni obrazac strategija

Oblikovni obrazac strategija omogućuje jednostavnu izmjenu implementacije

određene funkcionalnosti. Potrebno je definirati apstraktnu klasu ili sučelje koje

definira određenu funkcionalnost. Nakon toga se dodaju konkretne implementacije

tih apstraktnih sučelja. Zbog Liskovina načela supstitucije konkretne implementacije

se mogu pohraniti u reference apstraktnog tipa. Na primjer, recimo da postoji klasa

koja simulira izvlačenje nekih brojeva. Ta klasa sadrži referencu na apstraktni tip

koji ima metodu za dobivanje idućeg broja. Mogu biti implementirani razni načini

dobivanja broja kao što je nasumično ili ovisno o nekoj razdiobi, ali klasi kojoj treba

broj to nije bitno, bitno je samo da dobije broj. Prateći ovaj obrazac ispunjava se

načelo nadogradnje bez promjene što također omogućuje da se u stari kod doda

nova konkretna implementacija nekog apstraktnog sučelja i da stari kod svejedno

radi.

Gledajući raspored koda ovog rada u module može se reći da je pojedini modul

zapravo jedna velika strategija. Na primjer modul data je jedna strategija koja

omogućuje dobivanje i pohranu podataka. Dodatno svaki modul sadrži druge

strategije, kao na primjer strategija za razdvajanje riječi na slova.

Ovaj obrazac je korišten na svakom mjestu gdje je bilo moguće kako bi se

maksimizirala modularnost samog koda. Gledajući kod s predmeta projekt uočeno

je da postoje samo dvije strategije, od kojih jedna pruža samo jednu konkretnu

implementaciju.

40

7. Zaključak

Prateći koncepte čiste arhitekture, osnovna načela oblikovanja i oblikovne

obrasce uspješno je programirana aplikacija. Aplikaciju bi idealno bilo testirati na

čim više uređaja kako bi se otkrili moguću previdi, ali u suštini je spremna za objavu

na Google Play. Aplikacija u trenutnom obliku podržava dva jezika, hrvatski i

engleski, ali naravno mogu se dodati novi jezici. U planu su također dodatne

funkcionalnosti kao promjena slika novčića u igri s novčićima vezana za trenutno

odabrani jezik i korištenje pomoći u istoj.

Samim radom sam stekao popriličnu količinu što iskustva, što znanja. Pišući

aplikaciju prema konceptima čiste arhitekture i oblikovnim obrascima sam stekao

znanja o iznimno korisnim bibliotekama Dagger2 i RxJava, ali i o samom androidu

kao sustavu.

41

8. Literatura

1. The clean architecture

https://five.agency/android-architecture-part-2-clean-architecture/

datum pristupa dokumentu: 2.6.2018

2. The clean architecture

https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-

architecture.html

datum pristupa dokumentu: 2.6.2018

3. Applying clean architecture on android

https://five.agency/android-architecture-part-3-applying-clean-

architecture-android/

datum pristupa dokumentu: 2.6.2018

4. Applying clean architecture on android, hands on

https://five.agency/android-architecture-part-4-applying-clean-

architecture-on-android-hands-on/

datum pristupa dokumentu: 2.6.2018

5. Introduction to activities

https://developer.android.com/guide/components/activities/intro-activities

datum pristupa dokumentu: 3.6.2018

6. Android View Documentation

https://developer.android.com/reference/android/view/View

datum pristupa: 3.6.2018

7. RxJava documentation

https://github.com/ReactiveX/RxJava

datum pristupa: 3.6.2018

8. Dagger2 documentation

https://github.com/google/dagger

datum pristupa: 3.6.2018

9. Room Persistence Library

https://developer.android.com/training/data-storage/room/

datum pristupa: 3.6.2018

42

9. Sažetak

Naslov: Primjena arhitekturnih koncepata za platformu Android na primjeru dječje edukativne igre

Sažetak:

Programiranje je jednostavno naučiti i lako je nešto programirati, ali kod valja pisati

prateći koncepte arhitektura čija primjena se pokazala uspješnom. Na primjeru

android aplikacije za djecu su primijenjeni koncepti čiste arhitekture kao i oblikovni

obrasci kako bi sam kod bio čim jasniji, efikasniji i podložan testiranju.

Ključne riječi: Android, čista, arhitektura, igra, edukativno

Title:

Application of architectural concepts for the platform Android using a educational

game for children as example

Abstract:

Coding is simple to learn and it is simple to code something, but code must be

written with respect to architectural concepts whose usage has been shown to be

successful. The concepts of clean architecture and design patterns were applied

on a educational game for children making the code clear, effective and testable.

Keywords:

Android, clean, architecture, game, educational