Fakulteta za raˇ cunalniˇ stvo in informatiko

(1)

Univerza v Ljubljani

Fakulteta za raˇ cunalniˇ stvo in informatiko

Anton Semprimoˇznik

Lokacijsko zavedna mobilna aplikacija z zalednim sistemom v oblaku

DIPLOMSKO DELO

VISOKOˇSOLSKI STROKOVNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE RA ˇCUNALNIˇSTVO IN INFORMATIKA

Mentor : dr. Igor Roˇ zanc

Ljubljana 2013

(2)

(3)

Rezultati diplomskega dela so intelektualna lastnina avtorja in Fakultete za ra- ˇcunalniˇstvo in informatiko Univerze v Ljubljani. Za objavljanje ali izkoriˇsˇcanje rezultatov diplomskega dela je potrebno pisno soglasje avtorja, Fakultete za raˇcu- nalniˇstvo in informatiko ter mentorja.

(4)

(5)

(6)

Izjava o avtorstvu diplomskega dela

Spodaj podpisani Anton Semprimoˇznik, z vpisno ˇstevilko 63100154, sem avtor diplomskega dela z naslovom:

Lokacijsko zavedna mobilna aplikacija z zalednim sistemom v oblaku

S svojim podpisom zagotavljam, da:

• sem diplomsko delo izdelal samostojno pod mentorstvom dr. Igorja Roˇzanca,

• so elektronska oblika diplomskega dela, naslov (slov., angl.), povzetek (slov., angl.) ter kljuˇcne besede (slov., angl.) identiˇcni s tiskano obliko diplomskega dela

• soglaˇsam z javno objavo elektronske oblike diplomskega dela v zbirki

”Dela FRI”.

V Ljubljani, dne 15. septembra 2013 Podpis avtorja:

(7)

(8)

Na tem mestu bi se rad zahvalil druˇzini za vso pomoˇc in podporo v ˇcasu ˇstudija. Zahvaljujem se mentorju dr. Igorju Roˇzancu za usmerjanje, nasvete pri izdelavi diplomske naloge in zavzeto mentorstvo. Rad bi se zahvalil tudi sodelavcem, Matjaˇzu Peˇcanu za tehniˇcne nasvete in ostale domiselne pre- dloge, Robertu Slaku za inovativne ideje ter punci za priganjanje k izdelavi in zakljuˇcku diplomske naloge.

(9)

(10)

Kazalo

Povzetek Abstract

1 Uvod 1

2 Raˇcunalniˇstvo v oblaku 3

2.1 Pomen raˇcunalniˇstva v oblaku . . . 3

2.2 Razvoj tehnologije . . . 4

2.3 Vpliv uveljavljanja raˇcunalniˇstva v oblaku . . . 5

2.4 Osnovna struktura oblaka . . . 5

2.5 Storitveni modeli . . . 8

2.5.1 Infrastruktura kot storitev . . . 8

2.5.2 Platforma kot storitev . . . 9

2.5.3 Programska oprema kot storitev . . . 11

2.6 Model z veˇc odjemalci . . . 12

2.7 Vezanost na ponudnika . . . 12

3 Zahteve naˇse aplikacije 15 3.1 Osnovne zahteve naˇse aplikacije . . . 15

3.2 Ponudniki oblaˇcnih storitev in primernost glede na naˇse zahteve 16 3.2.1 Microsoft Azure . . . 16

3.2.2 Amazon EC2 . . . 17

3.2.3 Google AppEngine . . . 17

(11)

KAZALO

3.3 Izbira ponudnika oblaˇcne storitve za zaledni sistem . . . 18

3.4 Razvojna okolja in uporabljena orodja . . . 20

3.4.1 Adobe Phothoshop . . . 20

3.4.2 Podatkovna baza MySql in MySQL Workbench . . . . 20

3.4.3 Razvojno okolje Eclipse . . . 20

3.4.4 Operacijski sistem Google - Android in Android SDK . 21 3.4.5 Programsko ogrodje Java Play . . . 23

3.4.6 GPS . . . 23

3.4.7 Google Play Services . . . 24

4 Razvoj aplikacije 25 4.1 Razvoj ˇcelnega sistema . . . 25

4.1.1 Grafiˇcni uporabniˇski vmesnik . . . 26

4.1.2 Upravljanje z uporabniˇskimi profili . . . 32

4.1.3 Upravljanje z geografsko lokacijo uporabnikov . . . 34

4.1.4 Komunikacija med fragmenti in aktivnostjo . . . 38

4.1.5 Osveˇzevanje podatkov in asinhronost . . . 39

4.1.6 Asinhrono nalaganje uporabniˇskih fotografij . . . 41

4.2 Razvoj zalednega sistema . . . 42

4.2.1 Podatkovni model . . . 42

4.2.2 Programski moduli . . . 44

4.3 Komunikacija odjemalec - streˇznik . . . 46

5 Umestitev v Amazon EC2 47 5.1 Postavitev mikro instance Ubuntu Linux . . . 47

5.2 Zagon aplikacije v oblaku . . . 48

5.3 Delovanje aplikacije v konˇcnem okolju . . . 48

5.4 Sprememba ponudnika oblaˇcnih storitev . . . 49

6 Sklepne ugotovitve 51

(12)

Povzetek

V diplomskem delu je predstavljen razvoj aplikacije, ki izkoriˇsˇca tako strojne zmogljivosti pametnih mobilnih naprav kot zmogljivosti oblaka. Aplikacija je neke vrste socialno omreˇzje, saj predstavi uporabnika vsem uporabnikom v njegovi geografski okolici, predstavi njegov uporabniˇski profil, njegove in- terese, fotografije, omogoˇca enostaven virtualen kontakt in olajˇsa morebiten prvi fiziˇcni kontakt. Razvita je bila z idejo, da omogoˇci enostavno migracijo zaledne reˇsitve med razliˇcnimi ponudniki oblaˇcnih storitev. Aplikacija sestoji iz dveh delov. ˇCelni del, ki ga predstavlja aplikacija v operacijskem sistemu Android, in zaledni del, ki ga ˇcelni del nujno potrebuje za svoje delovanje. Zaledni del aplikacije je razvit v programskem ogrodju Java Play in teˇce na JVM in HTTP streˇzniku Netty, za delovanje pa uporablja MySQL podatkovno bazo. ˇCelna aplikacija Android v doloˇcenih intervalih preverja lokacijo uporabnika, iz nje izraˇcuna koordinate kvadrantov ter to lokacijo stalno sporoˇca zalednemu sistemu, ki jo za slednjega posodobi. Vsak uporabnik v intervalih zahteva seznam bliˇznjih uporabnikov, s katerim posodobi svoj prikazan seznam. Aplikacija se je v praksi odrezala odliˇcno. Uporabniˇski vmesnik aplikacije Android je enostaven za uporabo in odziven, prav tako zaledni sistem.

Kljuˇcne besede: raˇcunalniˇstvo v oblaku, Amazon EC2, zaledni sistem v oblaku, socialno omreˇzje

(13)

(14)

Abstract

The diploma thesis describes the development of an application, some kind of a social network application that benefits from hardware capabilities of smart mobile phones and cloud computing. This application introduces the user to other users in their geographical region, it presents their user profile, their interests, photos, enables easy virtual contact to other users and facili- tates potential first physical contact. While in the application’s development phase, we focused on making sure that the application was agnostic of the cloud service provider, so it would be trivial to transfer the application to any server system. The application consists of two separate parts: the front-end part is represented by an Android application, and the back-end part, which the front-end needs to be able to function properly. The back-end has been developed using the Java Play Framework and runs with JVM with HTTP Netty and a MySQL server. The Android application is constantly checking for the user’s location and calculates tile coordinates from it. These coordinates are constantly sent to the back-end system, which updates users data in the database. Every online user requests a list of surrounding users in intervals, with which he updates his own users list. The Android application example is easy to use and responsive, as well as the back-end system.

Key words: cloud computing, Amazon EC2, cloud based backend system, social network

(15)

(16)

Poglavje 1 Uvod

Napredek tehnologije je omogoˇcil koncept lokalnega omreˇzja ter storitev, ki teˇcejo v tem omreˇzju oz. na njihovih streˇznikih prenesti na nivo sveta. Tu pridemo do izraza Raˇcunalniˇstvo v oblaku. Uporaba oblaka omogoˇca dostop do podatkov s kjerkoli in kadarkoli. Pri tem nismo omejeni na omreˇzje podjetja, na trdi disk posameznega raˇcunalnika, temveˇc lahko do svojih podatkov tako rekoˇc dostopamo s kateregakoli raˇcunalnika, ki ima internetno povezavo.

Uporaba oblaka tudi ne zahteva zmogljive strojne opreme, saj za vse potrebe po virih poskrbi oblak. Tako nam zadostuje ˇze osnoven sistem oz. terminal, ki je zmoˇzen poganjati potrebno vmesno programsko opremo (ang. middleware). Oblak lahko sestoji iz velikega ˇstevila streˇznikov oz. raˇcunalnikov, povezanih v mreˇzo in tako zagotavlja veliko procesorsko moˇc. Zahtevni algo- ritmi, ki bi na posameznem raˇcunalniku potrebovali ogromno ˇcasa za svojo izvedbo, se v oblaku zaradi velikih kapacitet izvedejo hitro in brez veˇcjih teˇzav.

Diplomsko delo se osredotoˇca na razvoj aplikacije Android z zalednim sistemom v oblaku. Aplikacija predstavi uporabnika vsem uporabnikom v njegovi geografski okolici, omogoˇca enostaven virtualen kontakt in olajˇsa morebiten prvi fiziˇcni kontakt. Uporabniku omogoˇca veˇcjo socializacijo v druˇzbi. Poudarek je na razvoju aplikacije z ozirom na njeno neodvisnost od ponudnika oblaˇcnih storitev in enostavnostjo prenosa na katerikoli streˇzniˇski

1

(17)

2 POGLAVJE 1. UVOD sistem.

Razlog za izvedbo z uporabo zalednega sistema v oblaku se skriva predvsem v enostavnosti vzdrˇzevanja zalednega sistema, stalni dostopnosti s strani velikega ˇstevila odjemalcev in hitrosti delovanja v primerjavi z uporabo lastnega streˇznika. Kljuˇcni faktor so finanˇcni stroˇski, saj investicija v streˇznik oz. strojno opremo za poganjanje zalednega sistema v naˇsem primeru ni rentabilna.

Cilj je predstaviti aplikacijo, ki koristi tako strojne zmogljivosti pametnih mobilnih naprav kot zmogljivosti oblaka, s katerim preseˇze omejitve slednjih.

Najprej je opisano vse, kar potrebujemo vedeti za razumevanje raˇcunalni- ˇstva v oblaku; definicija raˇcunalniˇstva v oblaku, razlogi za uporabo, teˇzave, predstavljena je arhitektura oblaka in njegovi storitveni modeli, pomen vezanosti na ponudnika in podobno. V tretjem poglavju so predstavljene zahteve naˇse aplikacije, ponudniki oblaˇcnih storitev in vpraˇsanja, ki se pri vsakem ponudniku v povezavi z razvojem aplikacije pojavijo. Prav tako so predstavljena orodja, ki so bila pri razvoju uporabljena. V ˇcetrtem poglavju je predstavljen razvoj aplikacije, tako ˇcelnega kot zalednega sistema, in komunikacija med njima. V petem poglavju je prikazana postavitev mikro instance z operacijskim sistemom Ubuntu Linux in zagon razvite aplikacije v oblaku.

(18)

Poglavje 2

Raˇ cunalniˇ stvo v oblaku

Cilj raˇcunalniˇstva v oblaku je nudenje storitev uporabnikom. Storitev v tem pomenu besede pomeni nudenje storitve na zahtevo in plaˇcilo glede na uporabo, v skladu s pravilom, da veˇc virov kot potrebujemo, veˇc plaˇcamo.

Arhitekturno poznamo tri vrste storitvenih modelov: infrastrukturo kot storitev, platformo kot storitev in programsko opremo kot storitev. Pri razvoju storitev se uporablja arhitekturni pristop modela z veˇc odjemalci, kjer ena instanca aplikacije sluˇzi veˇcjemu ˇstevilu odjemalcev. Aplikacije, razvite za delovanje v oblaku, imajo razliˇcno stopnjo vezanosti na ponudnika, saj nji- hova migracija k drugemu ponudniku ni enostavna zaradi teˇzav tehnoloˇske ali pogodbene narave.

2.1 Pomen raˇ cunalniˇ stva v oblaku

Raˇcunalniˇstvo v oblaku poenostavi upravljanje in uporabo poslovnih aplikacij. Namesto, da aplikacije poganjamo sami, lahko te prenesemo v deljeni podatkovni center. Na aplikacije se priklopimo kot na storitve in takoj zaˇcnemo z delom. Kot primer lahko omenimo Gmail in Microsoft Exchange. V primeru uporabe Gmail-a ne potrebujemo nobenih streˇznikov in podatkovnih skladiˇsˇc, nobene specifiˇcne programske opreme razen preprostega spletnega brskalnika, ne tehniˇcne ekipe, ki bi nam zagotavljala njegovo delovanje in

3

(19)

4 POGLAVJE 2. RA ˇCUNALNIˇSTVO V OBLAKU

uporabo, enako ni potrebno skrbeti za nadgraditve in vzdrˇzevanje. Potrebu- jemo se le vpisati in izbrati ustrezne nastavitve. Ta model uporabe spreminja naˇse razmiˇsljanje o programski opremi nasploh, tudi v primeru aplikacijskih programskih reˇsitvev v poslovnem svetu [7].

Podjetja v oblakih poganjanjo vse vrste aplikacij, tako standardne aplikacije nekega ponudnika (npr. Google-a) kot aplikacije, ki so specifiˇcne za neko podjetje/stranko ali aplikacije po naroˇcilu in ˇzeljah naroˇcnika. V primeru uporabe aplikacij nekega ponudnika je razlog uporabe zniˇzanje stroˇskov saj ne potrebujemo tako velike ekipe za zagotavljanje delovanja. Aplikacije so bolj varne, bolj stabilne, bolj skalabilne. Vse to omogoˇca model z veˇc odjemalci. V tem modelu nimamo kopije aplikacije za vsako podjetje, ki to aplikacijo uporablja, ampak eno aplikacijo, ki si jo vsi delijo. Le-ta omogoˇca takˇsen nivo prilagoditve za vsako podjetje, da ustreza njihovim zahtevam.

2.2 Razvoj tehnologije

Razvoj omreˇzne infrastrukture je pripeljal do faze, v kateri je mogoˇce koncept streˇznikov ter lahkih odjemalcev razˇsiriti z lokalne na globalno raven.

Raˇcunalniˇstvo v oblaku ni v osnovi niˇc novega ali takˇsnega, ˇcesar prej ne bi poznali. Podjetja streˇznike in odjemalce poznajo ˇze od zaˇcetka t.i. in- formacijske dobe. Napredek same tehnologije je omogoˇcil koncept lokalnega omreˇzja ter storitev, ki teˇcejo v tem omreˇzju, natanˇcneje na streˇznikih, prenesti na nivo sveta. Za razvoj v tej smeri bi lahko krivili mobilne naprave (pametne telefone, tabliˇcne raˇcunalnike in podobno), od katerih je tudi odvisen razvoj infromacijsko-telekomunikacijskih tehnologij, saj vse vedno bolj temelji na stalni povezljivosti, dostopu do elektronske poˇste, fotografij, do- kumentov ter seveda znancev ter prijateljev. Razvoj tehnologij sovpada z razvojem socialnih omreˇzij oz. druˇzbenega spleta. Splet ne pomeni veˇc tehnologije, temveˇc povezanost s konkretnimi osebami, ker splet tvorijo ljudje.

Splet poslediˇcno izgublja pridih tehnoloˇskega in postaja nekaj vsakdanjega, samoumevnega, podobno kot ostale ˇzivljenjske dobrine. Sama tehnologija je

(20)

2.3. VPLIV UVELJAVLJANJA RA ˇCUNALNIˇSTVA V OBLAKU 5

nared ˇze dolgo, vendar je bil potreben premik v glavah, s tem mislimo na spremembo v dojemanju interneta samega ter storitev, ki jih ta ponuja [7].

Eno izmed vpraˇsanj v povezavi s to tehnologijo je varnost v oblaku. ˇCe izbiramo med uveljavljenimi ponudniki, je strah popolnoma odveˇc, saj je oblak v veˇcini primerov zanesljivejˇsa opcija kot uporaba lastne infrastrukture, v veˇcini primerov pa tudi cenejˇsa [7].

2.3 Vpliv uveljavljanja raˇ cunalniˇ stva v oblaku

S prihodom raˇcunalniˇstva v oblaku je priˇslo do velike spremembe v obre- menitvi odjemalcev oz. koliˇcini procesiranja na strani odjemalca. Osebnim raˇcunalnikom ni potrebno opravljati veˇc zahtevnih operacij, ki pridejo skupaj s poganjanjem aplikacij, ampak za te poskrbijo raˇcunalniki, ki so sestavni del oblaka. Poslediˇcno se zmanjˇsajo tudi strojne in programske zahteve na strani uporabnikov/odjemalcev, saj uporabniˇski raˇcunalniki sedaj potrebujejo le ˇse vmesnik do oblaka. Obiˇcajno zadostuje ˇze spletni brskalnik. Med storitve v oblaku lahko ˇstejemo spletne storitve kot so Hotmail, Yahoo! Mail ali Gmail in podobne. Namesto poganjanja programa za spletno poˇsto na svojem raˇcunalniku se preprosto prijavimo v spletni poˇstni odjemalec na da- ljavo. Vsa sporoˇcila se tako ne nahajajo na naˇsem osebnem raˇcunalniku, temveˇc na raˇcunalnikih, ki sestavljajo oblak [6].

2.4 Osnovna struktura oblaka

Raˇcunalniˇstvo v oblaku oz. sam oblak sestoji iz dveh delov: ˇcelni (ang. fron- tend) inzaledni (ang. backend) sistem. ˇCelni sistem predstavlja uporabniˇski vmesnik, ki ga vidi uporabnik in ga ima nameˇsˇcenega na svojem raˇcunalniku.

Obiˇcajno gre za posebno aplikacijo, ki je potrebna za omogoˇcanje dostopa do samega oblaka. Sistemi so med seboj razliˇcni. Za dostop do elektronske poˇste lahko uporabljamo brskalnik ali pa imamo nameˇsˇcen namenski program, ki zagotavlja dostop do oblaka. Zaledni sistem sestavlja veliko ˇstevilo

(21)

Slika 2.1: Pogled na raˇcunalniˇstvo v oblaku

raˇcunalnikov in podatkovnih skladiˇsˇc. Oblak lahko vsebuje kakrˇsnokoli aplikacijo, ki si jo lahko zamislimo. Obiˇcajno je, da vsaka aplikacija teˇce na svojem streˇzniku. Oba dela se med sabo povezujeta preko omreˇzja. Vsak oblak ima centralni streˇznik, ki nadzoruje sistem, promet in zahteve odjemalcev ter zagotavlja, da vse teˇce gladko. Za vse te naloge uporablja protokole ter vmesno programsko opremo (ang. middleware), ki omogoˇca raˇcunalnikom v omreˇzju komuniciranje drug z drugim. Za te sisteme je znaˇcilna virtualiza- cija, s katero se doseˇze boljˇsi izkoristek fiziˇcnih streˇznikov oz. njegovih kapacitet ter zmanjˇsa potrebo po veˇcjem ˇstevilu fiziˇcnih streˇznikov, saj le ti veˇcino ˇcasa niso polno obremenjeni. Prav tako morajo podjetja, ki se ukvarjajo z raˇcunalniˇstvom v oblaku zagotoviti vsaj dvakrat toliko diskovnega prostora, kot ga potrebujejo za shranjevanje vseh uporabniˇskih podatkov. Razlog so predvsem napake na napravah, ki lahko povzroˇcijo izpad sistema, prenehanje delovanja, napake in okvare diskovnih pogonov ter podobno. Sistem v oblaku mora zato hraniti kopije vseh uporabniˇskih podatkov, ki jih lahko uporabi v

(22)

2.4. OSNOVNA STRUKTURA OBLAKA 7

Slika 2.2: Modeli storitev

primeru izpada oz. okvare [2].

Raˇcunalniˇstvo v oblaku v sploˇsnem omogoˇca nudenje storitev uporabnikom. Storitev v tem pomenu besede pomeni nudenje storitve na zahtevo in plaˇcilo glede na uporabo, v skladu s pravilom, da veˇc virov kot potrebujemo, veˇc plaˇcamo. Samo raˇcunalniˇstvo v oblaku nam lahko nudi veliko ˇstevilo razliˇcnih storitev, ki so organizirane v model SPI (ang. Software, Platform, Infrastructure) oz. programsko opremo, platformo, infrastrukturo. Model je sestavljen iz infrastrukture kot storitve, platforme kot storitve, programske opreme kot storitve. Konˇcni uporabniki tipiˇcno uporabljajo programsko opremo kot storitev, razvijalci programske opreme platformo kot storitev in informatiki oz. IT oddelki infrastrukturo kot storitev (slika 2.2). Pri oblaˇcnih storitvah ne gre le za skalabilno infrastrukturo ter prenosljivo platformo. Ta koncept prinaˇsa v razvoj programske opreme velike spremembe [4].

(23)

2.5 Storitveni modeli

2.5.1 Infrastruktura kot storitev

Infrastruktura kot storitev (ang. Infrastructure as a Service) predstavlja prvo in najniˇzjo plast raˇcunalniˇstva v oblaku. Predstavlja uporabo virtualnih virov, kot so virtualna okolja, operacijski sistemi, omreˇzje, procesorski ˇcas, pomnilnik ter diskovni prostor. V uporabi je s strani sistemskih operater- jev. Zakupljene kapacitete uporabljamo na isti naˇcin, kot bi fiziˇcni streˇznik, aplikacije ter operacijski sistem imeli pri sebi v podjetju in bi kapacitete poljubno prilagajali naˇsim potrebam (slika 2.2). Najviˇsja dodana vrednost infrastrukture kot storitve se skriva v uporabi oblaka le v primerih, ko je po- treba po virih zelo velika. To pomeni, da podjetja ne potrebujejo investicij v velike raˇcunske zmogljivosti streˇznikov oz. veˇcje ˇstevilo streˇznikov, ki bi se v polni moˇci uporabili le sem ter tja, preostali ˇcas pa delovali pod minimalnim bremenom. Tako imamo osnovno opremo, ki za veˇcino operacij zadostuje, ob redkem poveˇcanju potreb pa za preseˇzek dela poskrbi oblak. V sploˇsnem imamo pri uporabi infrastrukture kot storitve moˇznost koriˇsˇcenja procesiranja, shranjevanja podatkov in drugih raˇcunalniˇskih virov, kamor namestimo oz. kjer deluje naˇsa aplikacija. Primer uporabe je takˇsen kot pri ˇze uve- ljavljenih praksah. Programska oprema se namesti na zgornjih plasteh, kjer tudi teˇce [8].

Primer IaaS je Amazon Cloud [25], kjer uporabimo svoj operacijski sistem in poljubni programski jezik. Imamo omogoˇcen poln dostop do konzole in upravljanja z naˇsim sistemom. V zakupu imamo v grobem le strojno opremo, ki se prilagaja po zmogljivosti in naˇsim potrebam.

(24)

2.5. STORITVENI MODELI 9

Kdo so uporabniki Katere storitve ponuja Zakaj uporabiti Sistemski operaterji Virtualna okolja, opera-

cijski sistemi, sporoˇcilne vrste, omreˇzje, procesor- ska moˇc/ˇcas, pomnilnik, diskovni prostor, varno- stne kopije

Kreiranje platform za izvajanje storitev in aplikacijskih testov, razvoj, integracijo in uvajanje

2.5.2 Platforma kot storitev

Platforma kot storitev (ang. Platform as a Service) predstavlja drugo plast raˇcunalniˇstva v oblaku. Ta omogoˇca delovanje uporabniˇskih aplikacij v oblaku.

Na tej platformi uporabnik/razvijalci razvijejo svoje aplikacije. Kar storitev omogoˇca je razvoj lastnih aplikacij, pri ˇcemer za njihovo delovanje ne potrebujemo lastne strojne opreme, programske infrastrukture ter vzdrˇzevanja le-te (slika 2.3).

Meje med vsemi tremi plastmi so pogosto precej zamegljene. Tako je teˇzko doloˇciti, kaj toˇcno definira platformo kot storitev. Platforma kot storitev omogoˇca razvijalcem razvoj uporabniˇskih aplikacij v infrastrukturi ter doseg do praktiˇcno neomejenih virov raˇcunalniˇstva v oblaku. Oblak se prilagaja naˇsim potrebam ter se razˇsiri do te mere, da zagotovi dovolj raˇcunskih zmogljivosti, ki jih potrebujemo.

Uporaba platforme kot storitve znatno doprinese k udobnosti razvoja apliakcije s staliˇsˇca razvojnih ekip. Ob razvoju aplikacij je mnogokrat potrebno postaviti veˇc okolij za serviranje aplikacij, kot so na primer testno okolje, razvojno okolje ali produkcijsko okolje. Postavitev posameznega okolja zahteva od omreˇznega administratorja uvedbo (ang. deploy) streˇznika, namestitev opracijskega sistema, vseh potrebnih knjiˇznic, nadzora razliˇcic, konfiguracije, testiranja in ˇse marsikaj drugega. Prav tako mora imeti vsak razvijalec pri sebi okolje za razvoj aplikacije. Ves opisan postopek se pri uporabi PaaS poenostavi, saj imamo v primeru uporabe le-tega ˇze virtualno okolje, ki si ga razvijalci preprosto izmenjajo z USB kljuˇckom [9].

(25)

Slika 2.3: Sestavni deli PaaS

Kdo so uporabniki Katere storitve ponuja Zakaj uporabiti Razvijalci programske

opreme

Razvoj, integracija ter uvajanje aplikacij. testiranje aplikacij in storitev

Razvoj/kreiranje, uvajanje aplikacij ter storitev za konˇcne uporabnike

Struktura platoforme kot storitve tipiˇcno sestoji iz dveh vidnih delov:

platforme in storitvenega paketa. Storitveni paket si lahko predstavljamo kot nekaj, kar se nudi na zahtevo, platformo pa kot raˇcunsko moˇc, ki nudenje storitve omogoˇca.

Platforma se nanaˇsa na zmoˇznost poganjanja programske opreme ne- prenehoma, dokler le-ta ustreza standardom platforme. Platforma je tipiˇcno operacijski sistem, na katerem teˇce uporabniˇska programska oprema (OS Windows, Apple Mac OS X, OS Linux) s programskih ogrodjem. Sploˇsno govorimo o plaformi, v okviru katere je uporabniˇski program narejen oziroma na kateri teˇce ter ne o operacijskem sistemu samem. Storitveni paket v tem sklopu predstavlja aplikacije, ki sodelujejo pri procesu razvoja ter na koncu uvedbe. Te aplikacije potrebujejo za delovanje platformo (operacijski sistemi ali programsko ogrodje) [9].

(26)

2.5. STORITVENI MODELI 11

2.5.3 Programska oprema kot storitev

Programska oprema kot storitev (ang. Software as a Service) predstavlja tretjo plast raˇcunalniˇstva v oblaku. Tu aplikacij na lokalni uporabniˇski raˇcunalnik ni potrebno namestiti, prav tako vzdrˇzevanje in nadgrajevanje aplikacij ni potrebno. Razvoj lastnih aplikacij tu ni mogoˇc, saj gre za dostop do ˇze razvitih aplikacij, obiˇcajno preko spletnega vmesnika v spletnem brskalniku, nameˇsˇcenem na uporabnikovem raˇcunalniku.

Kdo so uporabniki Katere storitve ponuja Zakaj uporabiti Poslovni uporabniki,

naivni uporabniki

Elektronska poˇsta, pi- sarniˇska orodja, wiki, blog, CRM, spletne aplikacije

Uporaba v poslovnih okoljih za potrebe za- poslenih, uporaba pri zasebnih uporabnikih

SaaS omogoˇca uporabnikom dostop do poslovne programske opreme preko omreˇzja. Programska oprema je nameˇsˇcena na oddaljenem streˇzniku, ki se obiˇcajno nahaja pri ponudniku oblaˇcnih storitev. Tam se izvaja vzdrˇzeva- nje, upravljanje aplikacij, nadgradnje in podobno. Uporabnik zaradi naˇcina implementacije nima potrebe po vlaganju v svojo infrastrukturo. Uporaba se zaraˇcunava po ˇstevilu uporabnikov ter porabi virov. Storitev zagotavlja tudi arhiviranje, varnostno kopiranje ter uvoze in izvoze podatkov. Sam naˇcin uporabe omogoˇca podjetjem manjˇse stroˇske pri uporabi programske opreme, saj je uporaba programske opreme na zahtevo mnogo cenejˇsa kot nakup licenc za vsak raˇcunalnik posebej.

Prednosti s staliˇsˇca povrnjene investicije so v poveˇcani hitrosti uvedbe aplikacije, mnogo laˇzjega nadgrajevanja ter vzdrˇzevanja, manjˇse cene razvoja in implementacije ter poveˇcane uporabe s strani uporabnikov. Programska oprema kot storitev omogoˇca boljˇso dostopnost do programske opreme nava- dnim uporabnikom. Prav tako so zmanjˇsani stroˇski povezani s podporo, saj ni veˇc podpore veˇc razliˇcnim operacijskim sistemom [5].

(27)

2.6 Model z veˇ c odjemalci

Model z veˇc odjemalci (ang. multi-tenancy) je arhitekturni pristop k razvoju programske opreme, kjer ena instanca aplikacije sluˇzi veˇcjemu ˇstevilu odjemalcev (ang. tenant). Vsak odjemalec ima moˇznost prilagoditve aplikacije v doloˇceni meri, npr. prilagoditev izgleda ali poslovnih pravil v okviru aplikacije. Koda v tem primeru ne more biti prilagojena.

Ko govorimo o raˇcunalniˇstvu v oblaku, je odjemalec aplikacija, ki potrebuje svojo varno, izolirano virtualno okolje. Sam arhitekturni pristop je ekonomiˇcen, saj so razvoj programske opreme ter stroˇski za vzdrˇzevanje deljeni. Npr. ponudnik posodobi programsko opremo le enkrat, spremembe pa so vidne pri vseh uporabnikih. Oblak uporablja model z veˇc odjemalci za deljenje IT virov varno med veˇc aplikacij in odjemalci. Izolacija odjemalcev je nekje realizirana s pomoˇcjo virtualizacije, drugje pa s posebno programsko opremo [10].

2.7 Vezanost na ponudnika

Vezanost na ponudnika (ang. vendor lock-in) je situacija, pri kateri uporabnik, ki ima v uporabi nek produkt ali storitev (v naˇsem primeru gre za gostovanje v oblaku oz. uporabo oblaka prej izbranega ponudnika), ne more enostavno preiti k storitvi konkurenta trenutnega gostiteljskega pod- jejta brez stroˇskov, ki so potrebni za preskok. V tem primeru gre lahko za teˇzave tehnoloˇske narave (koda ni kompatibilna) ali teˇzave pogodbene narave oz. dogovora med ponudnikom in stranko. Problem je pogost predvsem pri novih tehnologijah, med katere spada tudi raˇcunalniˇstvo v oblaku.

Zapletenost storitev v oblaku sili stranke, da kljub pomankljivim storitvam trenutnega ponudnika in teˇzavam zaradi velikih stroˇskov migracije, ne preha- jajo h konkurentom oz. drugim, morebiti boljˇsim ponudnikom. Smiselno je dobro preuˇciti ponudbe posameznih ponudnikov: preberemo pravila uporabe ponudnika, po potrebi poizvedemo neposredno, ˇse posebej z vpraˇsanji, ki se nanaˇsajo na prehod k drugemu ponudniku. Pri ponudniku preverimo, ali so

(28)

2.7. VEZANOST NA PONUDNIKA 13

v ponudbi zajeta tudi orodja, ki omogoˇcajo migracije, recimo izvoz podatkov ter podobno. Stremimo k izbiri ponudnikov, ki so zavezani k upoˇstevanju in- dustrijskih standardov, kot je na primer standard ’Cloud Data Management Interface (CDMI)’ in podobni [11].

(29)

(30)

Poglavje 3

Zahteve naˇ se aplikacije

Izdelati ˇzelimo aplikacijo na Android platformi, ki za svoje delovanje uporablja zaledni sistem v oblaku. Razlog uporabe zalednega sistema v oblaku se skriva v enostavnosti vzdrˇzevanja, stalni dostopnosti s strani velikega ˇstevila odjemalcev na sistemih Android do zalednega sistema in hitrosti delovanja v primerjavi z uporabo lastnega streˇznika. Na izbiro ponudnika oblaˇcne storitve vpliva veˇc faktorjev, tako tehniˇcni kot finanˇcni. Zanimajo nas tudi orodja, ki jih bomo za razvoj uporabili.

3.1 Osnovne zahteve naˇ se aplikacije

Aplikacija je v osnovi socialno omreˇzje, ki omogoˇca komunikacijo med uporabniki glede na njihovo geografsko lokacijo. Ob prvem zagonu aplikacije na uporabnikovi napravi se je za uporabo polne funkcionalnosti aplikacije potrebno uporabniku prijaviti. V kolikor uporabnik ˇse nima uporabniˇskega profila, se je potrebno registrirati. Brez slednjega je vseeno mogoˇc pogled uporabnikov, ki se nahajajo v naˇsi bliˇzini. Po prijavi lahko pregledujemo listo uporabnikov, ki se nahajajo v naˇsi bliˇzini, njihove detajlne podatke, ki so jih ti uporabniki vnesli ter jih preko sporoˇcil kontaktiramo. Osnovne tehniˇcne zahteve naˇse aplikacije (tako ˇcelni kot zaledni sistem):

• podpora relacijski podatkovni bazi, 15

(31)

16 POGLAVJE 3. ZAHTEVE NAˇSE APLIKACIJE

• poljubna podatkovna baza,

• podpora programskemu jeziku Java,

• poljubna izbira vrste streˇznika (Java Play, Apache, Tomcat ipd.),

• moˇznost delovanja kot streˇznik z vtiˇcniki,

• skalabilnost, moˇznost samodejnega prilagajanja virov potrebam,

• moˇzen razvoj veˇc-nitnih programov,

• odzivnost sistema, v katerem bo implementiran zaledni sistem,

• hiter razvoj reˇsitev,

• ugodna cena.

.

Na tem podroˇcju ˇze obstaja nekaj aplikacij, vendar so slednje veˇcinoma lokacijski klepetalniki, ki pa se na trgu niso prijeli. Podobnih aplikacij, kot so na primer lokacijski zmenkovalniki pa na trgu aplikacij Android ˇse ni. Izjema je mobilni operacijski sistem iOS, kjer je moˇc zaslediti aplikacijo WeMeet - GPS Radius Map Dating [24] za iskanje partnerjev. Aplikacijo bi lahko brez teˇzav predelali v enostavni lokacijski zmenkovalnik in s tem mogoˇce dosegli veˇcjo ciljno publiko.

3.2 Ponudniki oblaˇ cnih storitev in primernost glede na naˇ se zahteve

3.2.1 Microsoft Azure

Microsoft ponuja reˇsitev, ki cilja predvsem na skupnost razvijalcev .Net platforme. Veliko programskih reˇsitev, predvsem v veˇcjih podjetjih, je bilo v preteklosti narejeno in je narejeno v tehnologiji .NET z IIS7 in streˇznikom SQL [14]. Microsoft Azure omogoˇca enostavno migracijo obstojeˇcih reˇsitev v

(32)

3.2. PONUDNIKI OBLA ˇCNIH STORITEV IN PRIMERNOST GLEDE

NA NAˇSE ZAHTEVE 17

to oblaˇcno storitev. Sestoji iz velikega ˇstevila virualnih okolij z operacijskim sistemom Windows 2008 Server. Omogoˇca visoko avtomatizirano skalabilno okolje. Je zelo striktno orientiran v podporo Microsoftovega programskega paketa, kljub temu pa ponuja moˇznost poganjanja aplikacij razvitih v drugih tehnologijah (PHP, Java). Najbolj je uporaben v poslovnem (ang. enter- prise) okolju [3].

3.2.2 Amazon EC2

Amazon [25] je na trgu ponudnikov oblaˇcnih storitev najdlje. Ponuja zrelo in stabilno oblaˇcno reˇsitev. Amazonove reˇsitve se precej razlikujejo od Googlo- vih in Microsoftovih. Amazonova reˇsitev je gotovo najlaˇzja za nov zaˇcetek oziroma najbolj poznana in domaˇca obstojeˇcim praksam razvoja. Velika prednost je majhna vezanost na ponudnika, saj pri Amazonu zakupimo le virtualno rezino raˇcunalniˇske infrastrukture (IaaS) oz. streˇznik ter nekaj pe- rifernih tehnologij, ki skrbijo za skalabilnost in nadzor nad okoljem. Naˇcin implementacije Amazonove oblaˇcne storitve omogoˇca izkuˇsnjo podobno kot pri uporabi lastne infrastrukture. Izberemo lahko operacijski sistem, jezike, moˇznosti je tako rekoˇc ogromno. Omogoˇcena nam je popolna kontrola nad naˇso virtualno rezino [3].

3.2.3 Google AppEngine

Google AppEngine [26] je pogosta izbira start-up podjetij. Googlova infrastruktura je tako moˇcna, da bi lahko na njej brez teˇzav poganjali tudi naslednji facebook ali podobno platformo. Za razvijalce sta na voljo dva programska jezika, Java ter Python, pri ˇcemer dela s streˇzniki, operacijskim sistemom in podobnim tu nimamo. Google App Engine je predvsem primeren za manjˇsa podjetja, ki ˇzelijo ˇcim niˇzje stroˇske s strojno opremo ter optimizirano platformsko reˇsitev s popolnoma samodejno skalabilnostjo. V primeru veˇcjih podjetij je slika drugaˇcna. .Net platforma je moˇcno prisotna v teh okoljih, prav tako so razvijalci v tej tehnologiji verjetno bolj izkuˇseni.

(33)

V primeru uporabe App Engina tudi nimamo nadzora nad sistemom samim v taki meri kot pri uporabi lastne infrastrukture.

Google App Engine omogoˇca razvoj spletnih aplikacij na isti infrastrukturi, ki poganja tudi preostale, ˇze znane aplikacije Googla. Aplikacije so enostavne za razvoj in vzdrˇzevanje, sistemski viri pa se prilagajajo naˇsim potrebam in potrebam po poveˇcevanju prostora podatkovnega skladiˇsˇca. Ska- labilnost je ˇze del samega Engina, mi samo razvijemo naˇso aplikacijo, jo naloˇzimo v oblak in ˇze lahko sluˇzi uporabnikom.

Google App Engine je ponudnik platforme kot storitve. Upravljanja s streˇzniki tu ni, prav tako ne vemo niti koliko streˇznikov naˇsa apikacija uporablja, saj aplikacijo le damo v gostovanje. App Engine ima dostop do velike infrastukture, kar olajˇsa razvoj skalabilnih aplikacij. Dela s sistemsko admi- nistracijo ni, prav tako nam je olajˇsan razvoj aplikacij, ki morajo biti zelo odzivne zaradi velikega ˇstevila zahtev na sekundo [3].

Veliko je poudarka na varnosti. Aplikacije teˇcejo v zaˇsˇcitenem okolju, tako imenovanem peskovniku. Posledica je onemogoˇcena uporaba doloˇcenih akcij, kot je na primer odpiranje lokalnih datotek, pisanje ter branje iz njih, odpiranje vtiˇcnikov in izvajanje sistemskih klicev [12].

3.3 Izbira ponudnika oblaˇ cne storitve za za- ledni sistem

Zaledni sistem naˇse aplikacije bo razvit za delovanje v instanci operacijskega sistema Linux ponudnika Amazon EC2 s programskim jezikom Java in uporabo relacijske podatkovne baze MySql. Razlogi so ugodna cena storitve v primeru velike porabe virov in zahtevane procesorske moˇci, zmogljivost, razvoj v ˇze preizkuˇsenih tehnologijah in velika neodvisnost naˇse konˇcne reˇsitve od ponudnika oblaˇcne storitve. Razvito reˇsitev lahko poganjamo tudi na sa- mostojnem streˇzniku katerekoli vrste, drugih ponudnikih oblaˇcnih storitev in podobno.

Amazon EC2 je poleg klasiˇcne uporabe aplikacij, ki temeljijo na spletnih

(34)

3.3. IZBIRA PONUDNIKA OBLA ˇCNE STORITVE ZA ZALEDNI

SISTEM 19

Tabela 3.1: Primerjava ponudnikov oblaˇcnih storitev

tehnologijah, primeren tudi za zaledne sisteme mobilnih aplikacij, kar je pomembno v naˇsem primeru. Shranjevanje podatkov na oddaljenem streˇzniku je bolj varno v primeru izgube naprave, kraje in podobno, obenem pa kako- vostno razˇsiri podroˇcje uporabe mobilnih naprav oziroma uˇcinkovito odpravi njihove omejitve.

(35)

3.4 Razvojna okolja in uporabljena orodja

3.4.1 Adobe Phothoshop

Adobe Photoshop [13] je najbolj poznan in razˇsirjen profesionalni raˇcunalniˇski program za obdelavo fotografij ter ostalih grafik. Vsebuje veliko ˇstevilo orodij za doseganje najrazliˇcnejˇsih efektov nad fotografijami in podobno [13].

Uporabljen je bil za izdelavo izgleda naˇse aplikacije in njegov razrez, pri katerem smo sliko aplikacije loˇcili v razliˇcne sekcije, od katerih je bil nato vsak del uporabljen kot del designa aplikacije.

3.4.2 Podatkovna baza MySql in MySQL Workbench

Podatkovna baza MySql [27] je najbolj priljubljena odprtokodna podatkovna baza, ki omogoˇca uporabo deklerativnega poizvedovalnega jezika SQL.

MySql Workbench [14] je vizualno orodje za laˇzje upravljanje s streˇzniki in podatkovnimi bazami MySql (slika 3.1). Omogoˇca ustvarjanje in nadzorovanje povezav na podatkovne streˇznike, izvajanje poizvedb nad podatkovnimi bazami, omogoˇca grafiˇcno kreiranje podatkovnih modelov entiteta-relacija, v okviru tega pa urejanje entitet, stolpcev, indeksev, sproˇzilcev, delitve na particije, rutin in podobno. Poenostavlja nadzorovanje instanc streˇznikov, poenostavlja migracije med razliˇcnimi podatkovnimi streˇzniki in podobno [14].

Ti orodji sta bili uporabljeni za upravljanje in administriranje podatkovne baze zalednega sistema.

3.4.3 Razvojno okolje Eclipse

Eclipse[15] je odprtokodno integrirano razvojno okolje (ang. Integrated development environment - IDE), napisano v programskem jeziku Java, z velikim naborom uporabnih vtiˇcnikov, ki znantno poveˇcajo njegovo uporabnost pri razvoju razliˇcnih vrst aplikacij (slika 3.2). Prednost uporabe okolja Eclipse se pokaˇze pri razvoju zahtevnejˇsih programov, ki uporabljajo veliko ˇstevilo

(36)

3.4. RAZVOJNA OKOLJA IN UPORABLJENA ORODJA 21

Slika 3.1: MySQL Workbench

razliˇcnih knjiˇznic v programih, kjer je potrebno dobro poznavanje delovanja in hierarhije razredov. Vgrajenih ima veˇc razliˇcnih brskalnikov kode in podporo za razliˇcne razhroˇsˇcevalnike [15].

Eclipse je bil uporabljen za razvoj zalednega sistema in aplikacije za operacijski sistem Android.

3.4.4 Operacijski sistem Google - Android in Android SDK

Operacijski sistem Google - Android [34] (slika 3.3) je razˇsirjen odprtokodni operacijski sistem za pametne mobilne telefone, ki temelji na linuxovem je- dru. Razvija ga Google v sodelovanju s podjetji zdruˇzenja Open Handset Alliance (OHA). Operacijski sistem je najpogosteje nameˇsˇcen na mobilnih napravah, katerim je v prvi vrsti tudi namenjen, vendar ga kljub temu naj- demo tudi na drugih napravah, kot so recimo tabliˇcni raˇcunalniki, roˇcne ure in podobno. Android ponuja platformo za izdelavo aplikacij in iger ter od- prt trg za delitev le-teh. Razvojna orodja ponujajo vse, kar potrebujemo za razvoj odliˇcnih, uporabniˇsko prijaznih aplikacij, ki uˇcinkovito uporabljajo strojne zmogljivosti uporabniˇskih naprav. Android je odprtokoden in pov-

(37)

Slika 3.2: Razvojno okolje Eclipse

sem brezplaˇcen. Razvijalcem omogoˇca veˇc moˇznosti pri razvoju programske opreme. Ponaˇsa se z odliˇcnim uporabniˇskim vmesnikom. Naprave z operacijskim sistemom Android se samodejno sihronizirajo z Googlovimi storitvami, nalaganje aplikacij je zelo enostavno, pravtako je tudi z posodobitvami operacijskega sistema.

Android SDK [28] je zbirka knjiˇznic in razvojnih orodij, ki jih potrebujemo za izdelavo, testiranje in razhroˇsˇcevanje aplikacij za operacijski sistem Android.

Slika 3.3: Operacijski sistem Android

(38)

3.4. RAZVOJNA OKOLJA IN UPORABLJENA ORODJA 23

3.4.5 Programsko ogrodje Java Play

Programsko ogrodje Java Play [16] je javansko programsko ogrodje (slika 3.4 prikazuje konzolo streˇznika Play). Temelji na lahki, brezstanjski arhitekturi in vmesni programski opremi Akka [29]. Ima majhno porabo virov, tako procesorja, pomnilnika kot niti in je kot tako veˇc kot primerno za uporabo in razvoj visoko skalabilnih aplikacij. Play uporablja polno asinhroni model, ki temelji na vmesni programski opremi Akka. Zaradi svoje brezstanjske zasnove je zelo skalabilen. Ciljne aplikacije so moderne spletne aplikacije in zaledni sistemi mobilnih aplikacij [16].

Slika 3.4: Konzola streˇznika Play

3.4.6 GPS

Sistem GPS [17] je sistem satelitske navigacije, ki je bil sprva razvit za potrebe obrambnega sistema Zdruˇzenih Drˇzav Amerike. Mehanizem temelji na mreˇzi vsaj 24 satelitov v orbiti, ki se v kroˇznih tirnicah gibljejo okoli Zemlje in le to obkroˇzijo v 12 urah. Posamezen satelit ima zelo natanˇcno atomsko uro ter stalno oddaja ˇcas in podatke o tirnici gibanja, ki se doloˇca s kontrolnimi zemeljskimi toˇckami. Za doloˇcitev zemljepisne dolˇzine in ˇsirine potrebujemo signal z vsaj treh satelitov, v kolikor ˇzelimo doloˇciti tudi nadmorsko viˇsino,

(39)

pa potrebujemo ˇse ˇcetrtega. Vsak satelit oddaja elektromagnetni signal, ki uporabnikom z vklopljenim sprejemnikom sporoˇca svojo prisotnost. Spreje- mnik stalno zaznava signale 4 satelitov. Vgrajen raˇcunalnik natanˇcno doloˇci oddaljenost od posameznega satelita, nato pa na osnovi razdalj doloˇci toˇcen poloˇzaj na planetu na nekaj metrov natanˇcno [17].

3.4.7 Google Play Services

Google Play Storitve [18] (ang. Google Play Services) so uporabniˇska knjiˇzni- ca, ki vsebuje vmesnike za dostop do posameznih googlovih storitev. Apli- kacijam dodaja veˇc funkcionalnosti, s ˇcimer posredno privablja veˇcje ˇstevilo (novih) uporabnikov. Uporabniˇske aplikacije pridobijo funkcionalnosti na po- droˇzju socialnih omreˇzij, zemljevidov, navigacije in nekaterih drugih. Google Play Storitve omogoˇcajo laˇzji dostop do ostalih googlovih storitev in so te- sno integrirane z operacijskim sistemom Android, kar poslediˇcno omogoˇca hitro in enostavno integracijo. Vse storitve uporabljajo skupno obstojeˇco avtorizacijo z googlovimi uporabniˇskimi raˇcuni in avtomatske posodobitve programske opreme s trgovine Google Play [18].

Google Play Services APK (ang. Android Package File) je format za distribucijo datotek Android (kot na primer .jar v Javi). Vsebuje posamezne googlove storitve in na napravi deluje kot storitev v ozadju (ang.

background service). V sami aplikaciji dostopamo do storitev preko upo- rabniˇskih knjiˇznic. Najpomembnejˇsa stvar pri uporabi knjiˇznic je moˇznost uporabe novih knjiˇznic, ki omogoˇcajo podporo razliˇcnim napravam. Storitve Google Play so distribuirane avtomatizirano s strani Googla, nove verzije uporabniˇskih knjiˇznic pa so uporabnikom dostavljene preko Android SDK Managerja.

(40)

Poglavje 4

Razvoj aplikacije

Uporabniˇska aplikacija je razvita v programskem jeziku Java za operacijski sistem Android. Za svoje delovanje v ozadju potrebuje zaledni sistem v oblaku Amazon EC2, razvit v programskem ogrodju Java Play. Uporabnik si v aplikaciji kreira svoj osebni profil, izbere prikazno sliko in napiˇse nekaj o sebi. Aplikacija omogoˇca pregled nad vsemi ostalimi uporabniˇskimi profili, ki se nahajajo okoli njega v doloˇcenem radiju. Pregleduje lahko uporabniˇske profile, v kolikor je prijavljen, pa lahko posamezne uporabnike tudi kontaktira na naˇcin, da jim poˇslje zasebno sporoˇcilo.

Celni sistem je namenjen komunikaciji uporabnika s sistemom, zaledni paˇ ga podpira. Brez zalednega sistema aplikacija Android ne deluje v celoti.

Razvoj je predstavljal teˇzave zaradi velike porabe virov zalednega sistema, saj mora biti ta sposoben izraˇcunavati razdalje med uporabniki, tvoriti od- govore s seznami uporabnikov, njihovimi posodobitvami za vse uporabnike aplikacije v zelo kratkih ˇcasovnih intervalih.

4.1 Razvoj ˇ celnega sistema

Celni sistem predstavlja aplikacijo Android, s katero uporabnik komunicira.ˇ Aplikacija je sestavljena iz ene aktivnosti, ki upravlja z veˇc uporabniˇskimi pogledi. Poglede sestavljajo razliˇcni gradniki operacijskega sistema Android.

25

(41)

26 POGLAVJE 4. RAZVOJ APLIKACIJE

Aplikacija upravlja z uporabniˇskimi profili s pomoˇcjo posebnih struktur operacijskega sistema. Jedro aplikacije skrbi za upravljanje z lokacijskimi podatki. Preraˇcunavanje lokacijskih podatkov (tako na napravi, kot na zalednem sistemu) predstavlja ˇcasovno zahtevno operacijo, zato je asinhronost aplikacije poglavitnega pomena. Uporabniku s pomoˇcjo razliˇcnih programskih delov operacijskega sistema omogoˇcimo nemoteno komunikacijo z upo- rabniˇskim vmesnikom.

4.1.1 Grafiˇ cni uporabniˇ ski vmesnik

Operacijski sistem Android omogoˇca uporabo mnogih vgrajenih grafiˇcnih komponent, ki omogoˇcajo enostavno grajenje uporabniˇskih vmesnikov. Osnov- na gradnika aplikacije sta aktivnost (ang. activity) in fragment (ang. fragment).

Aktivnost je samostojna enota uporabniˇskega vmesnika, s katero uporabnik v doloˇcenem trenutku ˇzivljenjske dobe aplikacije komunicira. Pri veˇcini aktivnosti gre za komunikacijo z uporabnikom. Aktivnost poskrbi za kreiranje okna, kjer postavimo uporabniˇski vmesnik. Aktivnosti so obiˇcajno uporabnikom celozaslonsko. Vsaka aktivnost ima ˇstiri glavna stanja. ˇCe je aktivnost v ospredju ekrana, pravimo, da je aktivna oz. v izvajanju (ang.

active). Ko aktivnost izgubi fokus, vendar je ˇse vedno vidna, ker je npr.

nad njo prosojna aktivnost oz. aktivnost, ki ne zavzema celotnega ekrana, pravimo, da je aktivnost v ˇcakanju (ang. on pause). Ko je aktivnost popolnoma prekrita z drugo, je ustavljena (ang. stopped). V tem stanju ˇse vedno vzdrˇzuje podatke o stanju, vendar za uporabnika ni vidna. ˇCetrta moˇznost je, da je uniˇcena s strani sistema zaradi poveˇcanih potreb virov. ˇCe je aktivnost v premoru ali ustavljena, jo lahko sistem izloˇci iz spomina, bodisi tako, da jo uniˇci ali pa sproˇzi proˇsnjo za njen zakljuˇcek (slika 4.1).

Fragment predstavlja delˇcek aktivnosti, ki ima svoj ˇzivljenjski cikel, upravlja s svojimi dogodki in je lahko odstranjen ali dodan med ˇzivljenjskim ciklom aktivnosti. Fragment mora vedno obstajati znotraj aktivnosti. Nje- gov ˇzivljenjski cikel je neposredno odvisen od ˇzivljenjskega cikla gostiteljske

(42)

4.1. RAZVOJ ˇCELNEGA SISTEMA 27

Slika 4.1: ˇZivljenski cikel aktivnosti Android aktivnosti.

Aplikacija je sestavljena iz ene aktivnosti, ki operira s petimi fragmenti in vsemi pojavnimi okni.

Fragmenti predstavljajo razliˇcne poglede v aplikaciji:

• navigacijski meni prikazuje vse opcije v odvisnosti od statusa upo- rabniˇskega raˇcuna (prijavljeni uporabnik, anonimni uporabnik),

• glavni pogled aplikacije (Find Nearby) prikazuje vse uporabnike, ki jih je mogoˇce najti v doloˇcenem radiju okoli naˇse trenutne pozicije,

(43)

• pogled na uporabniˇska sporoˇcila prikazuje vsa odhodna in dohodna sporoˇcila uporabnika (Inbox),

• prijavno okno oz. obrazec za prijavo uporabnika (Sign In),

• obrazec z uporabniˇskimi nastavitvami (Profile Settings) je uporabljen kot okno za novo regristracijo oz. popravljanje uporabniˇskih nastavitev.

.

Glava aplikacije

Glavo aplikacije sestavlja ikona aplikacije, ki hkrati ob dotiku odpre navigacijski meni (ta se lahko odpre tudi z vodoravnim potegom po zaslonu) in napis trenutno odprtega pogleda.

Slika 4.2: Navigacijski meni, ko je uporabnik odjavljen

Slika 4.3: Navigacijski meni, ko je uporabnik prijavljen

Drseˇci navigacijski meni

Navigacijski meni je sestavljen iz drseˇcega navigacijskega menija, ki ga s potegom po ekranu izvleˇcemo iz levega roba ekrana (ang. sliding drawer). Meni

(44)

ima dva moˇzna pogleda oziroma prikaz opcij glede na status uporabnika.

Pogled za anonimnega uporabnika se pokaˇze, ko je ta iz aplikacije odjavljen (slika 4.2) in mu omogoˇca izbiro opcije za vpis (Sign In), pogled uporabnikov v naˇsi geografski bliˇzini (Find Nearby) ter pogled uporabniˇskih sporoˇcil (Inbox).

Ko se uporabnik uspeˇsno vpiˇse v sistem (oziroma opravi registracijo, v kolikor uporabniˇskega profila ˇse nima kreiranega), se navigacijski meni pri- lagodi novemu statusu uporabnika (slika 4.3). Opcija za vpis v sistem je zamenjana z opcijo za odjavo iz sistema (Log out), prav tako pa je dodana tudi opcija za urejanje uporabniˇskega profila.

Gradnik mreˇza - pogled na uporabnike v naˇsi okolici

Pogled na uporabnike v naˇsi okolici (uporabnike, ki se nahajajo v naˇsi geografski bliˇzini doloˇceni z nekim radijem) je sestavljen iz gradnika mreˇza (ang.

grid giew). Mreˇza prikazuje elemente v dvo-dimenzionalni drseˇci mreˇzi. Vsak element mreˇze predstavlja posameznega uporabnika. Ta je predstavljen z uporabniˇsko sliko, imenom ter zelenim notifikatorjem, ki nam pove, ali je uporabnik prisoten ali ne. Klik na posamezni element mreˇze prikaˇze podatke o izbranem uporabniku (slika 4.4).

Slika 4.4: Pogled na uporabnike v naˇsi okolici

(45)

Gradnik pojavno okno - pregled uporabniˇskega profila

Pregled uporabniˇskega profila prikazuje podrobne podatke nekega uporabnika, ki se nahaja v naˇsi bliˇzini. Pogled je sestavljen iz pojavnega okna, veˇcje prikazne slika uporabnika, njegovega imena, spola, interesa ter poljub- nega besedila, ki ga posamezen uporabnik ˇzeli deliti z drugimi. Ob vsem imamo tudi tekstovno polje za pisanje sporoˇcil ter gumb, s katerim potrdimo poˇsiljanje napisanega sporoˇcila (slika 4.5).

Gradnik seznam - pogled uporabniˇskih sporoˇcil

Pogled uporabniˇskih sporoˇcil je pogled nad vsemi odhodnimi in prejetimi sporoˇcili. Sestavljen je iz seznama (ang. list view). Vsak element lista predstavlja eno sporoˇcilo. Element je sestavljen iz slike poˇsiljatelja, ko smo mi prejemnik ali slike prejemnika, ko smo mi poˇsiljatelj ter datuma poslanega sporoˇcila in kratkega odseka sporoˇcila. Klik na posamezni element mreˇze prikaˇze sporoˇcilo (slika 4.6).

Slika 4.5: Pogled uporabniˇskega profila

Slika 4.6: Pogled na uporabniˇska sporoˇcila

(46)

Gradnik pojavno okno - pogled poslanega in prejetega sporoˇcila Pogled poslanega in prejetega sporoˇcila prikazuje podrobne podatke uporabnika, ki se nahaja v naˇsi bliˇzini, ter odhodno oziroma dohodno sporoˇcilo, povezano z njim. Pogled je sestavljen iz pojavnega okna, veˇcje prikazne slika uporabnika, njegovega imena, spola, uporabnikovega zanimanja (moˇski, ˇzenske) ter poslanega sporoˇcila. Ob vsem imamo tudi tekstovno polje za odgovor na prejeto sporoˇcilo ter gumb, s katerim potrdimo poˇsiljanje le-tega.

V kolikor je sporoˇcilo odhodno, je ob njem tudi slika naˇsega profila (slika 4.7 in 4.8).

Slika 4.7: Pogled poslanega sporoˇcila Slika 4.8: Pogled prejetega sporoˇcila

Prijava v sistem

Prijava v sistem je navaden pogled z dvema tekstovnima poljema, gumbom za prijavo in gumbom za registracijo, v kolikor uporabniˇskega profila ˇse nimamo ustvarjenega.

Uporabniˇske nastavitve

Pogled na uporabniˇske nastavitve je navaden pogled z veˇc tekstovnimi polji za vnos (ang. edit text), izvleˇcnimi meniji (ang. spinner), gumbom za izbiro

(47)

Slika 4.9: Prijava v sistem

slike, ki odpre naˇso galerijo, ter gumbi za potrditev oz. preklic sprememb.

Slika 4.10: Pogled na uporabniˇske nastavitve

4.1.2 Upravljanje z uporabniˇ skimi profili

Aplikacija za dostop uporabnika do polne funkcionalnosti zahteva prijavo z ustvarjenim profilom. Ob vsakem zagonu aplikacija preveri, ali je uporabnik ˇze prijavljen. Ti podatki so shranjeni v okviru aplikacije kot stalni

(48)

aplikacijski podatki. Android ponuja veˇc moˇznosti za shranjevanje stalnih aplikacijskih podatkov. Reˇsitev, ki jo izberemo, je odvisna od naˇsih potreb, vrste podatkov, koliˇcine prostora, ki ga potrebujemo, pogostosti dostopov in podobno. V naˇsem primeru smo za hranjenje uporabniˇskih podatkov uporabili Shared Preferences [30]. Shared Preferences je sploˇsen programski okvir, ki omogoˇca shranjevanje stalno dosegljivih (obstojeˇcih) podatkov v parih kljuˇc - vrednost. Podatki so dosegljivi v celotni uporabniˇski seji, tudi ˇce se je aplikacija prenehala izvajati oziroma je bila uniˇcena. Uporabnik aplikacije je predstavljen kot objekt tipaAccount, ki vsebuje podatke o statusu raˇcuna (prijavljen, odjavljen ali napaka) ter objektomUser, ki vsebuje podrobne podatke o uporabniku (identifikacijska ˇstevilka, uporabniˇsko ime, geslo, spol, slika, status, zabeleˇzeni ˇcasi posameznih dogodkov, natanˇcna lokacija v objektuLocationipd.). Ker tu ne gre za primitivni tip, smo razvili poseben programski del, ki skrbi za shranjevanje takˇsnih podatkov v Shared Preferences. Funkcija save() (koda 4.1) podatke tipa T shrani v Shared- Preferences kot objekt v JSON formatu, funkcija retreive() (koda 4.1) pa slednjega pretvori nazaj v objekt tipa T.

public void save(String key, T sharedPreferencesEntryObject) { SharedPreferences appSharedPrefs = PreferenceManager.

getDefaultSharedPreferences(context.getApplicationContext());

Editor prefsEditor = appSharedPrefs.edit();

String json = gson.toJson(sharedPreferencesEntryObject);

prefsEditor.putString(key, json);

prefsEditor.commit();

}

public T retreive(String key, Class<T> clazz) {

SharedPreferences appSharedPrefs = PreferenceManager.

getDefaultSharedPreferences(context.getApplicationContext());

String json = appSharedPrefs.getString(key, "");

return (T) gson.fromJson(json, clazz);

}

Koda 4.1: Logika upravljanja s podatkovnimi tipi v SharedPreferences

(49)

Ob zagonu aplikacije se raˇcun inicializira iz shranjenih podatkov v Shared Preferences. Uporabniku poslediˇcno ob zagonu aplikacije ni potrebno opraviti postopka prijave, ampak to stori le ob prvem zagonu in zagonih, ki sledijo po njegovi zavestni odjavi iz aplikacije (moˇznost Log Out v navigacijskem meniju). Raˇcun se posodablja med ˇzivljenjskim ciklom aplikacije ob vsaki spremembi uporabniˇskih podatkov v uporabniˇskih nastavitvah, ob prijavi v sistem in spremembi geografske lokacije uporabnika.

4.1.3 Upravljanje z geografsko lokacijo uporabnikov

Aplikacija uporablja za lociranje uporabnikov oziroma sporoˇcanje uporabniˇske lokacije sprejemnik GPS [17] in Google Play Services - Location API [18]. V zadnjem ˇcasu je vedno veˇc mobnilnih telefonov opremljenih z GPS sprejemnikom, uporaba te storitve pa brezplaˇcna. Razˇsirjenost GPS-a med mobilnimi napravami nam v primeru naˇse aplikacije zagotavlja podporo naˇse aplikacije razliˇcnim napravam.

Podatke pridobimo s pomoˇcjo Location API-ja. Ta omogoˇca enostavno izdelavo aplikacij, ki se morajo zavedati svoje lokacije in zmanjˇsuje porabo energije z uporabo vseh zmoˇznosti strojne opreme naprave.

Lokacijske storitve (ang. location services) v naˇsi aplikaciji samodejno vzdrˇzujejo uporabniˇsko lokacijo, tako da aplikacija le povpraˇsuje za te podatke. Aplikacija mora imeti za uporabo teh storitev lokacijsko dovoljenje (ACCESS FINE LOCATION) ter dovoljenje za uporabo omreˇzja. Lokacijske storitve poˇsljejo trenutno lokacijo naˇsi aplikaciji preko lokacijskega odjemalca (ang. Location Client), ki predstavlja instanco razreda lokacijskih storitev LocationClient. Lokacija se mora v ˇzivljenjskem ciklu aplikacije stalno po- sodabljati. To zahteva periodiˇcno osveˇzevanje s strani lokacijskih storitev.

Lokacijske storitve avtomatiˇcno osveˇzujejo aplikacijo z najbolj natanˇcno lokacijo v nekem trenutku (tako z uporabo WiFi kot GPS).

V naˇsi aplikaciji opisan pristop deluje na naslednji naˇcin: aplikacija ob zagonu zaˇcne samodejno pridobivati lokacijo, bodisi s pomoˇcjo brezˇziˇcnega omreˇzja ali GPS sprejemnika, pri tem uporabi vir, ki v tistem trenutku

(50)

omogoˇca najbolj natanˇcen rezultat uporabnikovega poloˇzaja. Ob kreiranju aktivnosti najprej objektu LocationRequest nastavimo parametre, ki doloˇcajo interval osveˇzevanja uporabniˇske lokacije (koda 4.2), prioriteto tega izraˇcuna in najkrajˇsi interval osveˇzitve. Prav tako izvedemo inicializacijo razreda LocationClient, ki predstavlja instanco razreda lokacijskih storitev.

Po uspeˇsnem kreiranju aktivnosti, se ta zaˇzene (ang. on start). Tu zahte- vamo vzpostavitev povezave s strani lokacijskega klienta do storitve (ang.

connect).

// nastavimo parametre, ki doloˇcajo interval // osveˇzevanja uporabniˇske lokacije

mLocationRequest = LocationRequest.create();

mLocationRequest.setInterval(

LocationUtils.UPDATE_INTERVAL_IN_MILLISECONDS);

mLocationRequest.setPriority(

LocationRequest.PRIORITY_HIGH_ACCURACY);

mLocationRequest.setFastestInterval(

LocationUtils.FAST_INTERVAL_CEILING_IN_MILLISECONDS);

// inicializacija razreda LocationClient

mLocationClient = new LocationClient(this, this, this);

Koda 4.2: Zaˇcetna inicializacija posluˇsalcev Location API-ja

V akvivnosti dodamo posluˇsalca dogodkaonLocationChanged(Location location). Ta se proˇzi ob vsaki spremembi lokacije s strani lokacijskih storitev. Ob sproˇzitvi dogodka osveˇzimo lokacijsko stanje uporabnika. Pridobimo geografsko ˇsirino in dolˇzino ter z razvitim algoritmom izraˇcunamo kvadrante, v katere naj bi pridobljena lokacija spadala (opisano v nadaljevanju). Najprej s pridobljenimi in izraˇcunanimi podatki posodobimo/osveˇzimo stanje uporabnika lokalno, nato spremembe asinhrono uveljavimo tudi v podatkovni bazi zalednega sistema (opisano v poglavju 4.1.5).

Vsak fragment, ki potrebuje dostop do teh podatkov, v fazi kreiranja samega sebe povpraˇsa za lokacijo, ki se hrani v glavni aktivnosti (koda 4.3).

(51)

Ce lokacija ˇse ni na voljo, zaˇˇ cne fragment v loˇceni niti poizvedovati za lokacijo, saj pridobivanje lokacije v aktivnosti lahko vzame nekaj ˇcasa. Uporaba loˇcene niti prepreˇci zamrznitev uporabniˇskega vmesnika v ˇcasu ˇcakanja na lokacijo s strani glavne aktivnosti.

locationReceivedDataTimer = new Thread() { public void run () {

//preverimo, ali smo lokacijo ˇze pridobili while (!isLocationAvailable) {

// klic vmesnika, ki iz glavne aktivnosti // poskusi pridobiti lokacijo

location = fragmentToActivityDataRetrievers .getUserLocation();

if (isLocationAvailable == false) { isLocationAvailable = true;

// po pridobitvi lokacije priˇcnemo // z osveˇzevanjem vsebine fragmenta // NASTAVITEV ˇCASOVNIKOV ZA OSVEˇZEVANJE // VSEBINE FRAGMENTA

}

try {

Thread.sleep(1000);

} catch (InterruptedException e) { e.printStackTrace();

} }}

};

Koda 4.3: Logika pridobivanja lokacije uporabnika Poenostavitev lokacijskih podatkov

Pridobivanje seznama uporabnikov, ki se v doloˇceni oddaljenosti nahajajo okoli nas, zna v primeru uporabe koordinat GPS predstavljati ˇcasovno po- tratno operacijo. Pridobivanje seznama se opravi v zalednem sistemu. Del

(52)

Slika 4.11: Projekcija sveta Mercator (vir: [20])

logike, ki naj bi se izvedla na zalednem sistemu, smo zato prenesli na ˇcelno aplikacijo. ˇCelna aplikacija namreˇc opravi pred zahtevo za seznam bliˇznjih uporabnikov izraˇcun, ki pretvori GPS koordinate v koordinate kvadrantov zemljevida.

Za osnovo umeˇsˇcanja GPS koordinat so izbrali zemljevide Bing (ang. Bing Maps). Pri uporabi drugih zemljevidov (kot so googlovi ali podobni), bi rezultat bil isti, tako da izbira ciljnega zemljevida na delovanje naˇse aplikacije nima vpliva. Bing nudi svetovne zemljevide, s katerimi lahko uporabnik di- rektno upravlja. Da bi bila ta interakcija hitra in odzivna, je zemljevid ˇze predhodno izrisan pri razliˇcnih nivojih podrobnosti ter razrezan na posamezne ploˇsˇcice oz. kvadrante (ang. tiles) za hitro pridobivanje in prikaz.

Sestava posameznih ploˇsˇcic oziroma kvadrantov se izvede tako, da se za predstavitev celotnega sveta uporabi enotna projekcija - v primeru uporabe zemljevidov Bing uporaba projekcije Mercator. Ker gre projekcija Mercator v polih v neskonˇcnost, je maksimalna zemljepisna ˇsirina 85^◦, kar je tudi upoˇstevano v naˇsem izraˇcunu [20].

Za performanˇcno optimizacijo prikazovanja zemljevida, je zemljevid sestavljen iz ploˇsˇcic velikosti 256 krat 256 pikslov. V naˇsi aplikaciji smo kot nivo podrobnosti izbrali nivo 13. Ploˇsˇcica, v katero umestimo uporabnikovo GPS lokacijo, tako pokrije velikost pribliˇzno enako centru Ljubljane. Vsaka

(53)

Slika 4.12: Zemljevid razdeljen na ploˇsˇcice - nivo podrobnosti 0 (vir: [20]) ploˇsˇcica ima koordinate XY (v rangu od (0,0) zgoraj levo do (8192, 8192) spodaj desno).

Aplikacija torej ob vsakem osveˇzevanju uporabnikove lokacije preveri, ali je ta kaj drugaˇcna od predhodne. ˇCe je, potem izraˇcunamo iz prejetih novih GPS koordinat naprej par slikovnih toˇck na zemljevidu. Ta par pretvorimo v koordinate ploˇsˇcic. Iz dane koordinate ploˇsˇcice nato izraˇcunamo koordiate vseh 8 sosednjih ploˇsˇcic. Vseh 9 koordinat poˇsljemo streˇzniku, ki iz podatkovne baze uporabnikov izbere vse uporabnike, ki se ujemajo z eno izmed teh devetih koordinat.

4.1.4 Komunikacija med fragmenti in aktivnostjo

Komunikacija med fragmenti in aktivnostjo poteka s pomoˇcjo klasiˇcnih ja- vanskih vmesnikov, ki so definirani z naˇse strani. Funkcije smo logiˇcno razporedili med vmesnike, katerih funkcije smo implementirali znotraj glavne aktivnosti. Funkcije vraˇcajo podatke aktivnosti, ki jih v vmesnikih potrebujemo. Ob pridobivanju podatkov starˇsevske aktivnosti iz vmesnika moramo biti pozorni na inicializacijo vmesnika znotraj fragmenta. Vsak vmesnik se na fragment pripne v fazi vzpostavljanja oz. kreiranja fragmenta v procesu imenovanemon attach.

(54)

Slika 4.13: Grob pogled na urejanje razpoˇsiljanja dogodkov

4.1.5 Osveˇ zevanje podatkov in asinhronost

Naˇcin osveˇzevanja podatkov in poˇsiljanja poizvedb v zaledni sistem v oblaku igra v naˇsi aplikaciji pomembno vlogo. S strani aplikacije Android (ˇcelnega sistema) se na zaledni sistem poˇsiljajo zahtevki za podatke, ki zahtevajo na zalednem sistemu veliko procesorske moˇci (in poslediˇcno ˇcasa) za odgovor ˇcelnemu sistemu. Zaradi tega je nedopustno, da bi posamezen zahtevek ˇcelnega sistema blokiral uporabniˇski vmesnik, med tem ko ˇcaka na odgovor zalednega sistema.

Ob zagonu aplikacije Android se avtomatsko kreira nit, imenovana glavna nit oz. nit uporabniˇskega vmesnika. Nit skrbi za razpoˇsiljanje dogodkov (ang.

events) aplikacijskim gradnikom. Prav tako je to tudi nit, ki je v uporabi ob uporabniˇski interakciji z grafiˇcnimi gradniki aplikacije Android. Nit zlaga dogodke v vrsto in obveˇsˇca grafiˇcne gradnike, naj se ponovno nariˇsejo oz.

posodobijo (slika 4.13).

Opisan naˇcin se lahko odraˇza v slabˇsi zmogljivosti aplikacij, ki ne upoˇsteva- jo teh znaˇcilnosti. Ker se vse izvaja v eni niti, vse daljˇse operacije (kot so na primer dostopi do podatkovne baze ali omreˇzni zahtevki) blokirajo celoten uporabniˇski vmesnik. Vse se izvaja striktno zaporedno, saj se dogodki je- mljejo iz vrste (slika 4.13). Noben dogodek ne mora biti obdelan, preden se ne zakljuˇci dolga operacija, ki je trenutno v izvajanju. S staliˇsˇca uporabniˇskega vmesnika oz. uporabnika je aplikacija v tem primeru zamrznila. To je razlog, da se daljˇsim operacijam na niti uporabniˇskega vmesnika izogibamo in uporabimo dodatne niti za njihovo izvajanje [19].

(55)

Za zagotavljanje dobre uporabniˇske izkuˇsnje torej operacije izvajamo zaporedno, asinhrono s pomoˇcjo konstruktov programskega jezika Java in programskega ogrodja Android.

Vzporednost izvajanja smo v naˇsi aplikaciji dosegli z uporabo nitenja v Javi in uporabe razredaAsyncTask.

Razred Thread

Android za izvajanje asinhronih operacij nudi podporo razredu Thread. V primeru uporabe konstruktaThread, moramo aplikaciji zagotoviti sinhrozni- zacijo z nitjo uporabniˇskega vmesnika oz. glavno nitjo, v kolikor rezultate nove niti poˇsiljamo glavni niti oziroma jih slednja prikaˇze uporaniku. Ta konstrukt smo uporabili v primeru enostavnih zahtev, za preverjanje prisotnosti vrednosti neke spremenljivke, ki se nahaja v drugi aktivnosti (v prejˇsnjem poglavju omenjeno preverjanje prisotnosti uporabniˇske lokacije, kjer smo znotraj fragmenta poizvedovali po lokaciji, ki se je izraˇcunala v glavni aktivnosti).

Razred AsyncTask

Zahtevnejˇse in dalj trajajoˇce operacije (kot so na primer zahtevki na zaledni sistem v oblaku) so v aplikaciji reˇsene z uporabo kontrukta AsyncTask. Ta zdruˇzuje kreiranje novega procesa/niti in sinhronizacije z glavno nitjo. Prav tako omogoˇca sporoˇcanje statusa trenutne niti v izvajanju. Implementacija tega razreda je vedno podrazred aktivnosti ali fragmenta. Njegovo izvajanje se zaˇcne s klicem implementirane metodeexecute(), ki pokliˇce metodi doInBackground()inonPostExecute(). MetodadoInBackground()je metoda, ki vsebuje logiko, ki bo avtomatiˇcno/samodejno izvedena v novi niti.

MetodaonPostExecute()je metoda namenjena sinhronizaciji z glavno nitjo oz. nitjo uporabniˇskega vmesnika. Metoda je poklicana s strani progamskega ogrodja samodejno, ko se izvajanje metodedoInBackground()zakljuˇci. Im- plementiranemu podrazredu lahko definiramo tudi konstruktor, s pomoˇcjo katerega prednastavimo spremenljivke, ki jih bomo uporabljali v navedenih

(56)

metodah.

Primer uporabe AsnycTask vidimo v spodnjem primeru (koda 4.4).

private class RequestLoginServiceTask

extends AsyncTask < Void, Void, Void > { // DEFINIRAMO PRIVATEN SPREMENLJIVKE

public RequestLoginServiceTask(/*SPREMEMNLJVIKE*/) { //NASTAVIMO PRIVATNE SPREMENLJIVKE

}

protected void onPreExecute() { //POKAˇZEMO LOADER

}

protected Void doInBackground(Void... params) { //IZVEDEMO DOLGO TRAJAJOˇCO OPERACIJO

}

protected void onPostExecute(Void unused) { // SKRIJEMO LOADER

// POˇSLJEMO PODATKE PREKO VMESNIKA AKTIVNOSTI/INTERFACU // TJ. NA GLAVNO NIT

} }

Koda 4.4: Primer uporabe razreda AsyncTask

4.1.6 Asinhrono nalaganje uporabniˇ skih fotografij

Vsak uporabnik si izbere poljubno profilno fotografijo. Te fotografije se ob kreiranju profila naloˇzijo na streˇznik, s katerega se potem prenesejo oz.

prikaˇzejo pri uporabnikih, ki se nahajajo nekje v naˇsi bliˇzini. Velikost slik se pred nalaganjem na streˇznik ustrezno zmanjˇsa, da pospeˇsimo njihovo kasnejˇse prikazovanje v aplikaciji in zmanjˇsamo prostor, ki ga zasedejo na streˇzniku oziroma zalednem sistemu. Ker lahko nalaganje slik v aplikaciji pri velikem ˇstevilu uporabnikov v seznamu vzame nekaj ˇcasa, slike naloˇzimo loˇceno v drugi niti. Ta problem smo enostavno reˇsili z uporabo obstojeˇce knjiˇznice

(57)

UrlImageViewHelper, ki smo jo dodali v naˇs projekt. Vsak uporabnik v seznamu, ki ga pridobimo s streˇznika, poseduje tudi enoliˇcno ime njegove profilne fotografije. To ime in naslov streˇznika podamo kot vhodni podatek razreduUrlImageViewHelper, ki nato avtomatiˇcno upravlja z vsemi slikami s spleta in androidImageViewkomponentami v naˇsi aplikaciji. Izloˇci tudi vse podvojene spletne naslove, tako da se slike, ki so ˇze bile preneˇsene, ne prenesejo znova. Knjiˇznica omogoˇca tudi predpomnenje slik za doloˇceno ˇstevilo sekund [21].

4.2 Razvoj zalednega sistema

Zaledni sistem je razvit v programskem ogrodju Java Play. Skrbi za celotno upravljanje s podatki v naˇsi aplikaciji. Vse kar se zgodi v ˇcelnem sistemu, gre preko zalednega sistema oziroma le temu spremeni stanje. Sistem sestavlja veˇc programskih modulov, ki skrbijo za razliˇcna podroˇcja funkcionalnosti.

4.2.1 Podatkovni model

Podatkovni model je preprost, sestavljen le iz treh entitet, ki skupaj zajemajo vse potrebne podatke v naˇsi aplikaciji. Prikazane so na sliki 4.14.

Glavna entiteta je User, ki hrani osebne podatke uporabnikov, kot so uporabniˇsko ime, spol, osebni opis in podobno. Pomembne so tudi informa- cije o stanju uporabnika, kot je stanje profila (prijavljen, odjavljen), njegova lokacija ter ˇcasi razliˇcnih akcij (npr. ˇcas zadnje prijave, ˇcas zadnje spremembe lokacije ipd). Vse te podatke uporablja ˇcelni sistem za prilagajanje uporabniˇskega vmesnika, zaledni sistem pa na podlagi teh podatkov izbere primerne uporabnike za seznam bliˇznjih uporabnikov ob zahtevi ˇcelnega sistema.

Entiteta Interest hrani uporabniˇske nastavitve iskanja, ali uporabnik ˇzeli spoznati nove ljudi moˇskega spola, ˇzenskega ali obeh.

EntitetaMessagehrani vsa sporoˇcila uporabnikov. Vsakemu sporoˇcilu se zabeleˇzi poˇsiljatelj (entitetaUser), naslovnik sporoˇcila, ter ˇcasi poˇsiljanja in

(58)

4.2. RAZVOJ ZALEDNEGA SISTEMA 43

Slika 4.14: Podatkovni model

(59)

branja sporoˇcila. Zastavici sender deleted in receiver deleted povesta, ali je kateri od sodelujoˇcih v pogovoru pobrisal sporoˇcilo, da ga slednji ne vidi veˇc.

4.2.2 Programski moduli

Zaledni sistem posluˇsa na naslovih, definiranih v datoteki routes. Tam za vsak naslov, ki ga imamo, doloˇcimo kontroler in njegovo metodo, ki zahtevo obdela. Kontroler je servlet - razred v javi, ki zna obdelati zahtevo HTTP.

Metode smo namensko razporedili po veˇc razliˇcnih servletih glede na njihov namen.

Vsak servlet si lahko predstavljamo kot vhodno toˇcko v en programski modul. Imamo naslednje programske module:

• avtentikacijski modul,

• modul za upravljanje s sporoˇcili,

• modul za upravljanje z uporabniˇskimi profili,

• modul za nalaganje multimedijskih vsebin.

Celotno arhitekturo smo razvili v smeri, da je njena razˇsiritev nadvse preprosta. Poudarek razvoja zalednega sistema je bil na sploˇsnosti in ponovni uporabi programske kode, zato je velik del programske kode razdeljen po razliˇcnih razredih, ki se mnoˇziˇcno uporabljajo na razliˇcnih mestih. Prav tako smo upravljanje s podatkovno bazo popolnoma loˇcili od programske logike.

Avtentikacijski modul

Avtentikacijski modul skrbi za vse akcije v povezavi s stanjem uporabniˇskih raˇcunov.

V primeru zahteve po vpisu uporabnika v ˇcelnem sistemu, zaledni sistem v ta modul prejme objekt Login z uporabniˇskim imenom in ˇze kriptiranim