UNIVERZITET U NIŠU

PRIRODNO-MATEMATIČKI FAKULTET

DEPARTMAN ZA RAČUNARSKE NAUKE

Implementacija društvene mreže Birdtouch

korišćenjem Xamarin tehnologije i REST servisa

Master rad

Student: Mentor:

Nenad Ilić Prof. dr Marko Petković

Niš, oktobar 2018. godine

Rad posvećujem svojoj porodici, roditeljima i sestri, bez čijeg vaspitanja, razumevanja

podrške i ljubavi nikad ne bih postao osoba koja sam danas.

1

Sadrž aj

Sadržaj ..................................................................................................................................................................... 1

Sažetak .................................................................................................................................................................... 3

1 Upoznavanje sa Xamarinom ....................................................................................................................... 4

1.1 Istorija Xamarina ......................................................................................................................................... 4

1.2 Kako Xamarin radi? .................................................................................................................................... 5

1.3 Prednosti Xamarina.................................................................................................................................... 5

2 Jednostavna Xamarin Android aplikacija.............................................................................................. 7

2.1 Minimalni zahtevi ....................................................................................................................................... 8

2.2 Korak po korak ............................................................................................................................................. 8

2.2.1 Glavni projekat i korisnički interfejs ............................................................................................... 8

2.2.2 Logika aplikacije ................................................................................................................................... 14

2.2.3 Testiranje aplikacije ............................................................................................................................ 21

3 REST .................................................................................................................................................................. 24

3.1 Uopšteno ...................................................................................................................................................... 24

3.2 Ograničenja ................................................................................................................................................. 25

3.2.1 Klijent – serverska arhitektura .................................................................................................. 25

3.2.2 Nema pamćenja stanja sesije ...................................................................................................... 25

3.2.3 Keširanje.............................................................................................................................................. 25

3.2.4 Slojevitost ........................................................................................................................................... 26

3.2.5 Zajednička biblioteka servera i klijenta (opciono) ............................................................ 26

3.2.6 Uniformni interfejs.......................................................................................................................... 26

3.3 Primena REST ograničenja na web servise ................................................................................... 27

3.3.1 Relacije ižmeđu URL-a i HTTP metoda ................................................................................... 28

4 BirdTouch aplikacija ................................................................................................................................... 30

4.1 Primer i način funkcionisanja private režima rada.................................................................... 30

4.2 Primer i način funkcionisanja business režima rada ................................................................ 31

4.3 Primer i način funkcionisanja celebrity režima rada ................................................................ 31

4.4 Prednosti i žaključak ............................................................................................................................... 32

5 Implementacija Birdtouch aplikacije ................................................................................................... 33

5.1 Baza podataka ........................................................................................................................................... 33

5.1.1 Uopšteno ............................................................................................................................................. 33

2

5.1.2 Model baze .......................................................................................................................................... 34

5.2 Web server .................................................................................................................................................. 38

5.2.1 Uopšteno ............................................................................................................................................. 38

5.2.2 Cilj .......................................................................................................................................................... 38

5.2.3 Rad sa bazom ..................................................................................................................................... 39

5.2.4 Autentifikacija i Autorizacija....................................................................................................... 40

5.2.5 REST Kontroleri ............................................................................................................................... 44

6 Demonstracija Birdtouch aplikacije ..................................................................................................... 46

7 Literatura ........................................................................................................................................................ 55

Biografija ............................................................................................................................................................. 56

3

Saž etak

Aplikacija za mobilne telefone Birdtouch je društvena mreža sa akcentom na ražmenu

podataka (kontakt kartica) osoba koje se nalaze u neposrednoj blizini. Podaci o lokaciji korisnika

se preužimaju iž mobilnog uređaja (GPS ili sa mreže) i upoređuju sa svim ostalim aktivnim

korisnicama. Postoji opcija ražmene podataka u privatnom i poslovnom režimu, kako bi ova

aplikacija mogla da se koristi u više namena.

Aplikacija je pisana ža Android operativni sistem koristeći Xamarin tehnologiju koja

koristi podatke dobijene iz web servera pisanom u C# programskom jeziku.

Baža podataka aplikacije je trenutno ižužetno aktuelna relaciona PostgreSQL koja može

raditi na svim operativnim sistemima.

Za web server je iskorišćen Net Core 2.1 Web API kako bi REST poživi bili što efikasnije,

bezbednije i prirodnije napisani po svim tekućim standardima i kako bi server mogao da radi i na

Windows-u i na Linux-u.

4

1 Upožnavanje sa Xamarin-om

1.1 Istorija Xamarin-a

Xamarin je kompanija sa sedištem u San Francisku, Kalifornija. Osnovana je maja 2011.

godine od strane inženjera koji su se ranije bavili među-platformskim implementacijama CLI-a

(Common Language Infrastructure), kao i CLS-a (Common Language Specificationsa). CLS znamo i

pod nazivom Microsoft .NET a njihove implementacije su proizvodi poput Mono, Mono za Android,

kao i MonoTouch.

Koristeći Xamarin i C# osnovu, programeri mogu da koriste Xamarin alatke kako bi

napisali sistemski specifične Android, iOS i Windows aplikacije sa sistemsko specifičnim

korisničkim interfejsima. Takođe, mogu podeliti svoj kod na više platformi, uključujući Windows

i macOS.

Xamarin alatke je moguće pribaviti koristeći Visual Studio i njihovom upotrebom moguće

je direktno ražvijati Android, iOS ili Windows aplikacije (koristeći Visual Studio). Najveći deo koda

je napisan u C#. Tako da nema potrebe da učite Javu, Objective C ili Swift, ako već žnate C#.

Prema Xamarin-u, preko 1.4 miliona programera u svetu aktivno koristi njihove proizvode

u preko 120 zemalja sveta (podaci iz aprila 2017. god).

Microsoft je obelodanio kupovinu Xamarin-a 24. februara 2016. godine i tim potezom

Xamarin je postao sastavni deo Visual Studio okruženja.

Slika 1.1: Stukturni blok dijagram tipične Xamarin aplikacije

5

1.2 Kako Xamarin radi?

Xamarin Android aplikacije rade unutar Mono egžekucionog okruženja. Ovo egžekuciono

okruženje radi paralelno sa ART (Android Runtime) virtuelnom mašinom. Oba ova okruženja rade

„ižnad“ Linux kernela i ižlažu ražne API-je korisničkom kodu koji omogućava programerima da

pristupe sistemu ispod. Mono egžekuciono okruženje je napisano u C-u.

Možemo koristiti System, System.IO, System.NET i ostatak .NET biblioteke za pristup

osnovnim komandama Linux operativnih sistema.

Na Androidu, većina ovih sistema, poput zvuka, grafike, OpenGL-a i Telephony-ja nisu

dostupne direktno sistemsko specifičnim aplikacijama, već su vidljivi i pristupačni samo krož

korišćenje Android Runtime Java API-ja koji se nalazi u jednom od Java.* namespace-ova (ili u

Android.* namespace-u).

Arhitektura, grubo prikazana, izgleda kao na slici 1.2.

Xamarin Android programeri pristupaju raznim mogućnostima u operativnom sistemu

pozivanjem .NET API-ja koje znaju (za low-level pristup) ili koristeći klase koje su ižložene u

Android namespace-u koje prave „most“ do Java API-ja koji su ižloženi krož Android Runtime.

1.3 Prednosti Xamarin-a

Prednosti korišćenja Xamarin-a u odnosu na Android Studio ili neki drugi način ža

razvijanje Android apikacija:

C# - Pišete svoje aplikacije u C#. Postojeći kod napisan u C# može lako biti prebačen da

radi i na iOS i Android koristeći Xamarin, i naravno, kod može biti pokrenut unutar svih Windows

native aplikacija.

Slika 1.2: Arhitektura aplikacije koja pristupa Linux kernelu iz .NET okruženja

6

MVC Design obrazac – Ražvijate interfejs aplikacija koristeći MVC

(Model/View/Controller) obrazac (pattern). Odlučite koji delovi aplikacije će koristiti sistemsko

specifični korisnički interfejs koji je specifičan ža svaku platformu (iOS, Android, Windows i Mac).

Upotrebom MVC smernica jasno razdvojite aplikaciju u dve komponente - jezgro (core) i

korisnički interfejs.

Sistemsko specifični korisnički interfejsi – Svaka aplikacija koja je specifična ža

operativni sistem ima implementiran unikatan sloj korisničkog interfejsa (user-interface layer)

koji je implementiran u C# už pomoć sistemsko specifičnih UI (user-interface) dizajn alatki:

1. iOS – koristi se UIKIT API-je kako bi se napravila aplikacija sa sistemsko

specifičnim ižgledom. Može se takođe, opciono, koristiti Xamarin-ov iOS dizajner

kako bi se napravio korisnički interfejs korišćenjem WYSIWYG (what you see is

what you get) alatom.

2. Android – koristi se Android.Views kako bi se napravila aplikacija sa sistemsko

specifičnim ižgledom (koristeći Xamarin-ov UI dizajner).

3. Windows – koristi se XAML za prezentacioni sloj, kreiran u Visual Studio okruženju

ili Blend-ovom UI dizajneru.

4. Mac – koristi se Storyboards za prezentacioni sloj, kreiran u Xcode-u.

Xamarin.Forms projekti su podržani na svim platformama. Oni omogućavaju kreiranje

intefejsa koji možemo da podelimo ižmeđu svih platformi koristeći Xamarin.Forms XAML.

Količina žajedničkog (istog) koda koja se može iskoristiti na svim platformama žavisiće

uglavnom od toga koliko od tog koda je specifično ža korisnički intefejs date platforme, kao i od

količine žajedničkog koda koji je u core-u (jezgru) aplikacije. Ježgro aplikacije je bilo šta šta ne

komunicira direktno sa korisnikom, ali žato pruža usluge ža delove aplikacije koji sakupljaju i

prikazuju informacije korisniku.

Kako biste povećali količinu koda kojeg možete ponovo upotrebiti (re-use), možete

iskoristiti među-platformske komponetne koje pružaju žajedničke servise. Primer ovih

komponentni:

1. SQLite-net za lokalnu SQL bazu,

2. XamarinPlugins ža pristup specifičnih mogućnosti uređaja, poput kamere,

kontakata ili geolokacije

3. NuGet packages koji su kompatibilni sa Xamarin projektima, poput Json.NET

4. Koristeći .NET framework mogućnosti za networking, web servise, IO itd.

7

2 Jednostavna Xamarin Android aplikacija

Sledi demonstracija aplikacije koja prevodi alfanumerički telefonski broj (kojeg će

korisnik ukucati u odgovarajuće polje) u numerički broj. Nakon toga će aplikacija napraviti poziv

ka tom broju.

Završni izgled aplikacije je prikazan na slici 2.1.

Slika 2.1: Završni izgled jednostavne Android aplikacije

8

U ovoj glavi opisaćemo korak po korak kompletnu implementaciju Xamarin Android

aplikacije kako bi se na konkretnom primeru videle sve spefičnosti ražvoja mobilnih aplikacija u

C# programskom jeziku.

2.1 Minimalni zahtevi

Minimalni softverski zahtevi potrebni za izradu ove aplikacije su:

1. Windows 7 (ili noviji)

2. Visual Studio 2013 (ili noviji)

Pretpostavićemo da je najnovija veržija Xamarin-a za Android instalirana (kroz Visual

Studio). Ukoliko dođe do problema sa instaliranjem Xamarin-a za Visual Studio, potrebno je

posetiti žvanični sajt Xamarin-a gde se nalazi slikovito uputstvo, kao i sekcija sa najčešćim

problemima i kako ih rešiti.

2.2 Korak po korak

Za demonstraciju smo odabrali Android kao ciljani operativni sistem, budući da ga u Srbiji,

kao i u svetu, koristi najveći broj mobilnih korisnika. Nakon žavršetka ovog mini tutorijala

aplikacija će moći da se pokrene na bilo kom Android mobilnom uređaju kako bi se videlo kako

izgleda van emulatora, u realnom okruženju (telefon).

2.2.1 Glavni projekat i korisnički interfejs

Cilj je da napravimo korisnički interfejs, preko koga će korisnik moći da prevede

alfanumerčki telefonski broj u numeriči. Pravimo prvo Androd projekat u Visual Studio okruženju,

zatim ubacujemo potrebne komponente na dižajn površinu (dižajn površina predstavlja vižuelnu

reprežentaciju korisničkog interfejsa). Od komponenti koristimo Large Text, Plain Text i Button

widget. Large Text widget koristimo kako bismo korisniku dali informaciju šta treba da radi u

aplikaciji. Plain Text koristimo ža unos alfanumeričkog broja. Dugme (button) je aktivator

(okidač) ža prevođenje i poživ tog alfanumeričkog broja.

9

U narednoj sekciji opisujemo potrebne korake, sa pratećom slikom, koje treba uraditi kako

bi se napravila prethodno opisana aplikacija.

1. Klikom na File -> New -> Project kreiramo novi projekat. Veoma je važno prethodno

instalirati Xamarin paket za Visual Studio, jer u suprotnom, u ponuđenim opcijama neće

biti ponuđeno pravljenje Android projekta.

2. U dijalogu koji se upravo otvorio, odabirom Blank App (Android), dodeljivanjem naziva

Phoneword projektu, zatim klikom na OK, kreiramo novi projekat.

Slika 2.2: Pravljenje novog projekta

Slika 2.3: Odabir Android projekta

10

3. Nakon kreiranja novog projekta, proširavanjem Resources foldera se prikazuje njegov

sadržaj u Solution Explorer-u. Takođe, to je moguće uraditi i ža Layout folder koji se nalazi

unutar Resource foldera. Dvostrukim klikom na Main.axml otvara se novi prozor.

4. U Toolbox sekciji (sa leve strane), potrebno je ukucati „text“ (bež navodnika) u polju ža

pretragu i prevući pronađenu komponentu, Text (Large) widget, na deo za dizajn

(centralni deo Visual Studio okruženja, crne boje, koji pokazuje kako će ižgledati

aplikacija).

Slika 2.5: Kreiranje Text (Large) komponente

Slika 2.4: Izgled dizajn površine nakon otvaranja Main.axml fajla

11

5. Klikom na upravo dodati widget (klikom u dizajn delu na Large Text) vršimo njegovo

obeležavanje. U desnom delu Visual Studio okruženja u Properties panelu menjamo text

property i dodeljujemo mu vrednost „Enter a Phoneword:“.

6. Potrebno je pronaći Plain Text widget iz Toolboxa i dodati ga na površinu ispod, malopre

dodatog, Large Text widget-a.

7. Nakon toga potrebno je Plain Text widget-u u Properties panelu promeniti vrednost

property-ja id u „@+id/PhoneNumberText“, takođe potrebno je promeniti text property

vrednost u „1-855-XAMARIN“. Više o žnačenju id property-ja ćemo govoriti u kasnijim

koracima.

Slika 2.6: Promena tekst osobine Text (Large) widget komponente

Slika 2.7: Dodavanje Plain Text widget-a

12

8. Potrebno je prevući Button widget iz Toolbox-a na dižajn površinu i postaviti ga ispod

Plain Text widget-a.

9. Nakon toga klikom na Button widget dobićemo panel sa desne strane, u kome se nalazi

sekcija Properties. Unutar nje potrebno je promeniti vrednost id property-ja na

„@+id/TranslateButton“, kao i vrednost text property-ja u „Translate“.

Slika 2.8: Dodavanje jedinstvenog identifikatora widget-u

Slika 2.9: Dodavanje Button widget-a

13

10. Dodaćemo drugi Button iz Toolbox-a na dižajn površinu i smestiti ga ispod prethodno

postavljenog dugmeta.

Slika 2.10: Dodeljivanje identifikatora dugmetu

Slika 2.11: Dodavanje drugog dugmeta

14

11. Potrebno je i drugom Button widget-u dodeliti identifikator, promenićemo id dugmeta u

„@+id/CallButton“, kao i vrednost text property-ja u „Call“.

2.2.2 Logika aplikacije

Sada kada imamo napravljen korisnički interfejs sa svim potrebnim komponentama,

potrebno je povežati te komponente sa kodom u požadini koji će obraditi podatke dobijene iž tih

komponenti.

Dakle, biće potrebno da napravimo neku vrstu prevodioca koji će iž alfanumeričkog stringa

dobijenog iz Plain Text komponente (to je broj kojeg je uneo korisnik) napraviti numerički string

koji predstavlja broj telefona kojeg korisnik želi da požove.

To ćemo postići tako što ćemo napraviti klasu PhonewordTranslator koja će imati statičku

metodu ToNumber koja će prosleđeni string podeliti na karaktere a žatim te karaktere, ukoliko

nisu numeričkog tipa, proslediti drugoj metodi koja se žove TranslateToNumber i koja za

prosleđeni nenumerički karakter vraća njegov numerički ekvivalent po predefinisanim pravilima

(kao kod tastature telefona).

Zatim je potrebno da povežemo logiku iž te klase, logiku koja obrađuje string, sa Button

komponentom iz interfejsa. Kada korisnik unese alfanumerički string i kada klikne na Translate,

treba da se požove statička metoda ToNumber iz PhonewordTranslator klase kako bi se dobio

numerički string kojeg ćemo prepisati preko unetog alfanumeričkog teksta.

To ćemo postići tako što ćemo prvo užeti reference (preko jedinstvenog identifikacionog

broja) na komponente Plain Text i Button (Translate) a zatim u kodu dodati da se klikom na

dugme poziva ToNumber statička metoda čiji će se režultat upisati u Plain Text komponentu.

Slika 2.12: Dodeljivanje identifikatora drugom dugmetu

15

Nakon toga će dugme ža poživ postati dostupno.

Preostaje nam da iskoristimo uobičajan način pravljenja intenta i dijaloga iž Androida

kako bismo napravili poživ ka željenom broju.

To ćemo uraditi tako što ćemo preko reference ža Button (Call) staviti metodu koja će se

aktivirati kada korisnik klikne na to dugme. U toj metodi ćemo napraviti dijalog sa željenim

dugmićima, užeti željeni broj, a zatim, ukoliko korisnik potvrdi poziv ka tom broju, pozvati

sistemske servise koji su žaduženi ža pravljenje poživa.

12. Naredni korak je dodavanje koda koji će prevoditi alfanumerčki string u numerički.

Dodaćemo novi fajl desnim klikom na Phoneword projekat u Solution Explorer-u i

odabirom Add -> New item.

Slika 2.13: Dodavanje novog fajla

13. U dijalogu za dodavanje nove stavke biramo Visual C# -> Code File i nazivamo fajl

PhoneTranslator.cs

Slika 2.14: Kreiranje PhoneTranslator C# fajla

16

14. U prethodnom koraku smo kreirali praznu C# klasu. Sada je potrebno dodati logiku našoj

aplikaciji. To ćemo uraditi kreiranjem ToNumber, Contains i TranslateToNumber metode.

public static string ToNumber(string raw) { if (string.IsNullOrWhiteSpace(raw)) return ""; else raw = raw.ToUpperInvariant(); var newNumber = new StringBuilder(); foreach (var c in raw) { if (" -0123456789".Contains(c)) newNumber.Append(c); else { var result = TranslateToNumber(c); if (result != null) newNumber.Append(result); } } return newNumber.ToString(); }

U metodi ToNumber(string raw) ćemo proći krož ceo raw string i ukoliko je neki

karakter nenumeričkog tipa, žamenićemo ga odgovarajućim numeričkim karakterom poživajuću

metodu TranslateNumbe (char c).

Potrebno je takođe implementirani metodu Contains koja proverava da li se određeni karakter nalazi u stringu.

static bool Contains (this string keyString, char c) { return keyString.IndexOf(c) >= 0; }

17

TranslateToNumber nam služi kako bismo ižmapirali fižičku tastaturu telefona sa mogućim alfabetskim vrednostima.

static int? TranslateToNumber(char c) { if ("ABC".Contains(c)) return 2; else if ("DEF".Contains(c)) return 3; else if ("GHI".Contains(c)) return 4; else if ("JKL".Contains(c)) return 5; else if ("MNO".Contains(c)) return 6; else if ("PQRS".Contains(c)) return 7; else if ("TUV".Contains(c)) return 8; else if ("WXYZ".Contains(c)) return 9; return null; } } }

Metoda ToNumber na kraju vraća string koji je iž alfanumeričkog formata preveden u

numerički koristeći pravila koja odgovaraju ideji kombinacije slova i brojeva koji se koriste na

klasičnim telefonima sa dugmićima.

Slika 2.15: Klasični izgled fizičke telefonske tastature

18

15. Naredni korak je dodavanje koda koji će povežati korisnički interfejs (ono što smo

napravili na dižajn površini) i malopre napravljene metode ža prevod nenumeričkog

stringa. U Solution Explorer-u otvaramo MainActivity.cs klasu.

16. Kako bismo radili sa interfejsom, moramo napraviti referencu koja ukazuje na widget-e sa

dižajn površine. Tu na scenu stupa id property kojeg smo postavili. Preko vrednosti id

property-ja (koji treba da bude unikatan) mi možemo u kodu, sa dižajn površine, da

pronađemo taj objekat i pristupimo njegovim dinamičkim property-ijma. Takođe,

možemo čitati/pisati u njih, kao i promeniti ceo widget ako je to potrebno (dimenzije, oblik

itd.). Dakle, sada ćemo dodati kod koji će u View-u (svaka aplikacija ima jedan osnovni

View, a može i imati i mnogo više, gde se prikažuje sadržaj interfejsa) pronaći reference ža

naše widget-e. Dodajte ispod SetContentView(Resource.Layout.Main) linije sledeće:

// Uzimanje kontrola (widgeta) iz layout-a: EditText phoneNumberText =

FindViewById<EditText>(Resource.Id.PhoneNumberText); Button translateButton =

FindViewById<Button>(Resource.Id.TranslateButton); Button callButton = FindViewById<Button>(Resource.Id.CallButton);

17. Sada dodajemo kod koji je žadužen ža ono šta se dešava kada korisnik klikne na Translate

dugme (dodati unutar OnCreate metode, ispod malopre dodatih linija). Takođe ćemo

dugme ža poživ onemogućiti na početku (kao i ukoliko je prevedeni broj nevalidan).

Ukoliko metoda ToNumber uspešno vrati preveden string, konkatenisaćemo ga u Text

property-iju reference na dugme za poziv (takođe ćemo omogućiti Call button).

Slika 2.16: Sadržaj MainActivity klase

19

Naredne linije nam onemogućavaju poživ na početku aplikacije. // Onemogućujemo "Call" button callButton.Enabled = false; // Dodajemo kod koji će prevoditi upisan broj string translatedNumber = string.Empty;

Zatim je potrebno dodati akciju koja će se ižvršiti nakon klika na dugme. translateButton.Click += (object sender, EventArgs e) => {

translatedNumber= Core .PhonewordTranslator .ToNumber(phoneNumberText.Text);

if (String.IsNullOrWhiteSpace(translatedNumber)) { callButton.Text = "Call"; callButton.Enabled = false; } else { callButton.Text = "Call " + translatedNumber; callButton.Enabled = true; } };

18. Nakon gore dodatog parčeta koda, dodajemo kod koji će voditi računa o tome šta se dešava

kada korisnik pritisne Call dugme. Dakle, koristeći referencu callButton dodaćemo Click

akciju koja će napraviti novi mini dijalog u kome će biti potrebno korisnik da još jednom

potvrdi da li želi da požove broj koji je preveo iž alfanumeričkog u numerički. Sledeći kod

kopiramo ispod koda za dugme Translate (u kodu je uobičajan način poživanja i

pravljenja dijaloga, način koji nije specifičan ža Xamarin, već je to uobičajna praksa u

Android okruženju, i žbog toga nećemo žalažiti u detalje). Kod koji treba dodati na akciju

klika na dugme za poziv:

20

callButton.Click += (object sender, EventArgs e) => { // Klikom na "Call" button, pokušaćemo da pozovemo taj broj. var callDialog = new AlertDialog.Builder(this); callDialog.SetMessage("Call " + translatedNumber + "?"); callDialog.SetNeutralButton("Call", delegate { // Kreiramo intent kako bismo pozvali broj var callIntent = new Intent(Intent.ActionCall); callIntent .SetData(Android .Net.Uri.Parse("tel:" + translatedNumber)); StartActivity(callIntent); }); callDialog.SetNegativeButton("Cancel", delegate { }); // Prikazaćemo upravo napravljeni mini dijalog koji ce cekati // interakciju od strane korisnika. callDialog.Show(); };

19. Na kraju, potrebno je dodati aplikaciji dožvolu ža korišćenje Android-ovih servisa koji će

obaviti poživ. Dožvole je potrebno dodati ža sve vrste Android servisa koje će vaša

aplikacija koristiti, poput GPS, WIFI, geolokacije, Bluetootha itd. Dožvole je moguće

promeniti u Android Manifest fajlu. U Solution Explorer-u otvaramo Android Manifest

dvostrukim klikom na Properties stavku koja se nalazi ispod Phoneword projekta, a

zatim biramo Android Manifest.

Slika 2.17: Pristup manifestu Android aplikacije

21

U sekciji Required Permissions omogućujemo CALL_PHONE dozvolu.

Slika 2.18: Aplikaciji dodeljujemo potrebne dozvole

2.2.3 Testiranje aplikacije

Sada nam preostaje da snimimo projekat, proverimo da nema grešaka u kodu, i na kraju

aplikaciju testiramo u nekom emulatoru.

20. Snimićemo sve promene opcijom File -> Save All (ili kombinacijom tastera CTRL-SHIFT-

S). Zatim ćemo generisati ižvršne fajlove aplikacije klikom na Build -> Rebuild Solution

(ili kombinacijom tastera CTRL-SHIFT-B). Ukoliko su se fajlovi uspešno generisali,

dobićemo poruku o tome u Output podprozoru Visual Studio okruženja (slika 2.19).

Slika 2.19: Generisanje izvršnih fajlova

22

21. Na kraju preostaje testiranje u nekom od emulatora. Pre nego što pokrenemo aplikaciju u

emulatoru, ili direktno na Android uređaju, potrebno je podesiti minimalnu verziju

Android operativnog sistema na kojem će raditi aplikacija. Ovo postižemo odlaskom na

Application stranu Properties dela (kao u koraku 19, slika 2.17) i podešavamo API level

(verzija Android-a) u Minimum Android to target dropdown meniju. Na slici 2.20 smo

odabrali Android 7.0 (API Level 24 - Nougat).

22. Na slici 2.21 možemo videti gde u toolbaru je prikazano koji uredjaj je dostupan i izabran

za emulaciju. Ako ne postoji nijedan, onda moramo da napravimo novi uredjaj i

konfigurisati ga preko Android AVD Manager-a. Pokretanje (deploy) aplikacije se radi tako

što se klikne na play dugme (želene boje) u kom se nalaži ime emulatora/uređaja. Moramo

sačekati, ponekad poprilično dugo, u žavisnosti od snage računara i od odabira emulatora,

kako bi Visual Studio kopirao fajlove i startovao aplikaciju na uređaju.

23. Ukoliko nije bilo problema pri pokretanju aplikacije, u emulatoru će se startovati naša

aplikacija. Možemo testirati funkcionalnost prevođenja alfanumeričkog broja u numerički

tako što ćemo u Plain Text widget-u ukucati svoj broj, zatim kliknuti na Translate i na

kraju obaviti „poživ“ klikom na CALL dugme.

Slika 2.21: Pokretanje aplikacije u emulatoru

Slika 2.20: Podešavanje minimalne verzije Androida

23

Slika 2.22: Testiranje aplikacije

24

3 REST

3.1 Uopšteno

REST (eng. Representational state transfer) je stil

programiranja koji definiše skup ograničenja koja treba poštovati

pri kreiranju web servisa. U današnje vreme web servise koji koji

se pridržavaju ovog standarda, takožvane RESTful web servise,

možete naći u praktično bilo kojoj internet aplikaciji koja u

pozadini radi sa resursima.

REST web servisi omogućavaju sistemima koji žahtevaju

resurse jednostavan pristup i manipulaciju tekstualne

reprezentacije web resursa korišćenjem uniformnih i

predefinisanih stateless operacija - operacija koje ne pamte stanje

objekata.

Web resursi su definisani na World Wide Web-u kao dokumenti ili fajlovi koji imaju svoj

jedinstveni URL (uniform resource locator). Međutim, danas oni imaju mnogo širu i apstraktniju

definiciju koja obuhvata bilo koju stvar ili entitet sa imenom, identifikatorom, adresom koja se

nalazi na web-u.

U radu sa RESTful web servisima, zahtevi ka resurs URI-iju (uniform resource indentifier)

će proižvesti odgovor sa porukom (payload) formatiranom u HTML-u, XML-u, JSON-u ili nekom

drugom formatu. U odgovoru se može naći informacija da li je došlo do željene promene nad

resursom. Takođe, u odgovoru se mogu naći linkovi ka drugim resursima ili kolekcijama resursa.

Kada se REST koristi preko HTTP protokola, a to je najverovatnije i najčešći slučaj, operacije koje

su dostupne su GET, POST, PUT, DELETE, kao i druge koje su definisane CRUD HTTP standardom.

Korišćenjem stateless protokola i standardnih operacija, REST sistemi teže da obežbede

što veću bržinu, sigurnost i mogućnost ža proširenje (time što se komponente mogu menjati i

dodavati bez uticaja na ceo sistem).

REST je prvi put uveden i definisan 2000-te godine od strane Roja Fildinga u svojoj

doktorskoj disertaciji. Filding je u svom radu objasnio šta predstavljaju REST principi koji se

baziraju na HTTP objektnim modelima počev 1994-te godine, koji su kasnije korišćeni pri

pravljenju HTTP 1.1 i URI standarda.

Engleski izraz representational state transfer, iliti transfer reprezentacije stanja, je izraz

koji je iskorišćen kako bi stvorio sliku kod programera kako treba dobro dižajnirati web aplikaciju

i njeno ponašanje. Ona treba da bude mreža web resursa na kojoj korisnik pristupa korišćenjem

linkova, poput mojsajt.com/proizvodi, i operacijama poput GET ili DELETE, koje zauzvrat

korisniku vraćaju reprežentaciju stanja šta se dogodilo sa resursima nakon ižvršenja tih operacija.

Slika 3.1: Roy Fielding – tvorac REST specifikacije

25

3.2 Ograničenja

Postoji šest ograničenja koja definišu RESTful sistem. Ova ograničenja utiču na to kako

server treba obraditi i odgovoriti na klijentske zahteve. Pridržavajući se ovih ograničenja, servis

dobija željene performanse, skalabilnost, jednostavnost, mogućnost modifikacije, portabilnost,

kao i pouzdanost. Ukoliko servis narušava bilo koje od definisanih ograničenja, taj servis se

ne može smatrati REST servisom. Sledi kratak opis i suština ovih ograničenja, a o njima možete

pročitati detaljnije u [2].

3.2.1 Klijent – serverska arhitektura

Princip iza klijentsko-serveskog ograničenja se ogleda u raždvajanju uloga. Raždvajanjem

korisničkog interfejsa od obrade i skladištenja podataka (baže recimo) povećava se portabilnost

servisa koji se tada može iskoristiti i u drugim sistemima. Takođe se poboljšava skalabilnost tako

što se pojednostavljuju serverske komponente. Međutim, verovatno najžnačajnija prednost je što

ovo raždvajanje na klijentski i serverski deo omogućava komponentama da se ražvijaju nežavisno

jedne od drugih, i na taj način se podržava mogućnost proširenja na više organižacionih jedinica.

3.2.2 Nema pamćenja stanja sesije

Komunikacija ižmeđu klijenta i servera je ograničena time što nijedan kontekst, sa kojim

radi klijent, ne sme biti žapamćen na serveru ižmeđu bilo koja dva žahteva. Svaki zahtev ka

resursima sadrži sve informacije koje su potrebne da bi se žahtev obradio, i stanje sesije ostaje na

nivou klijenta.

Stanje sesije može biti transferovano od strane servera ka nekom drugom servisu, poput

baže, kako bi se omogućilo čuvanje stanja u nekom periodu i time omogućila autentifikacija. Klient

šalje žahteve tek kada je spreman da pređe u neko drugo stanje. Kada je jedan, ili više, žahteva u

obradi, klijent se smatra da je u stanju tranzicije.

3.2.3 Keširanje

Kao i na World Wide Web-u, klijenti, kao i posrednici ižmeđu klijenata i servera, mogu

keširati odgovore servera. Odgovori žato moraju biti definisani sa mogućnošću keširanja, tj. da

obežbede klijentu da ne može doći do žastarelih objekata ili netačnih informacija ukoliko se

koriste keširani objekti. Dobro implementirani sistem keširanja može smanjiti, ili čak kompletno

26

eliminisati neke od interakcija ižmeđu servera i klijenta, i na taj način dalje pobošljati skalabilnost

i performanse sistema.

3.2.4 Slojevitost

Klijent ne bi trebalo da zna da li komunicira sa krajnjim serverom, ili sa posrednikom.

Posrednički serveri mogu poboljšati skalabilnost i performanse aplikacije tako što će koristiti

tehnike poput load balansiranja ili pružanjem žajedničkog keša ižmeđu node-ova. Takođe mogu

obežbediti još jedan nivo sigurnosti aplikacije ukoliko se kao posrednik bude nalazio servis

žadužen ža dodatnu bežbednost.

3.2.5 Zajednička biblioteka servera i klijenta (opciono)

Serveri mogu privremeno produžiti ili modifikovati funkcionalnost klijenta tako što će

transferovati svoj ižvršni kod. Na primer, kompajlirane komponente, poput Java apleta, mogu se

koristiti na klijentskoj strani u Javascript-u.

3.2.6 Uniformni interfejs

Ovo je verovatno i najbitnije ograničenje pri dižajniranju RESTful servisa. Ovo ograničenje

uprošćava i raždvaja arhitekturu, što dalje omogućava ražvijanje i proširenje delova aplikacije

nezavisno jednog od drugih. Postoje četiri podograničenja:

1. Identifikacija resursa u zahtevima

2. Manipulacija resursa preko reprezentacije

3. Poruke su samoopisujuće

4. Hipermedia za logiku aplikacionog stanja

Dakle, individualne resurse je moguće identifikovati u žahtevima, na primer korišćenjem

URI-ja u web baziranom sistemu. Resursi kao takvi su konceptualno razdvojeni od svojih

reprežentacija koje su vraćane klijentu. Na primer, server može poslati odgovor klijentu kao

HTML, XML ili JSON – niko od kojih nije serverska interna reprezentacija resursa.

Iž drugog ograničenja sledi da kada klijent dobije reprežentaciju objekta, uključujući sve

metapodatke, on ima dovoljno informacija za modifikaciju ili brisanje resursa.

Takođe svaka poruka sadrži dovoljno informacija o tome kako je obraditi. Na primer, koji

parser je potrebno koristiti je specificirano korišćenjem media type header-a.

27

Nakon pristupa inicijalnom URI-ju rest aplikacije – što bi bilo analogno web korisniku koji

pristupa homepage-u web-sajta – rest klijent bi trebalo da koristi dinamičke linkove koje je server

dostavio kako bi se moglo otkriti koje sve operacije i akcije su moguće nad tim resursom. Nema

potrebe hardcode-irati informacije kako pristupiti strukturi ili dinamici rest servera, ukoliko je to

moguće treba ih vratiti kao meta podatke u reprezentaciji resursa.

3.3 Primena REST ograničenja na web servise

Web servisi koji pružaju pristup resursima i koji se pridržavaju REST ograničenja, se

nazivaju žajedničkim imenmo RESTful API-ijima. Oni koji su bazirani na HTTP protokolu, što je

najčešći slučaj, definisani su na sledeći način:

• Postoji osnovni URL, poput http://api.example.com/proizvodi

• Mora se definisati medijski tip (media type) koji definiše stanje tranžicionih elemenata

(podataka), poput mikroformata, application/json itd. Znajući reprežentaciju tranzicionih

objekata, klijent može da napravi požive ka serveru kako bi dobio naredna dostupna

stanja. Reprežentacija može biti običan URL, ili neki složeni objekat koji je ižveden iž Java

apleta

• Postoje implementacije standardnih HTTP CRUD metoda, poput GET, POST, DELETE, PUT,

OPTIONS itd.

28

3.3.1 Relacije između URL-a i HTTP metoda

Ponašanje HTTP metoda žavisi da li se operacije ižvršavaju nad kolekcijom objekata ili nad

jednim elementom te kolekcije. Ražlike ižmeđu ponašanja ižmeđu kolekcija i elemenata možete

videti u tabeli na slici 3.2.

URL GET POST PATCH PUT DELETE

Kolekcija, poput:

https://api.example.com/proizvodi/

Lista sve URI-je kolekcije, kako bi klijent žnao šta je sve dostupno. Takođe, može listati neke meta podatke ukoliko je potrebno.

Kreira novi element u kolekciji. URI tog novog elementa se automatski dodeljuje i obično biva vraćen kao rezultat ove operacije.

Najčešće se ne koristi nad kolekcijom.

Vrši žamenu cele kolekcije nekom drugom kolekcijom.

Briše celu kolekciju.

Jedan element kolekcije, poput:

https://api.example.com/proizvodi/42

Vraća reprežentaciju elementa u obliku koji je određen internet media tipom (media type)

Obično se ne koristi. Najčešće, tretira element kao kolekciju i dodaje novi objekat u kolekciju ukoliko se pozove.

Vrši ižmene u elementu koji je adresiran URI-jem.

Vrši žamenu celog objekta nekim drugim. Ukoliko ne postoji, kreira novi.

Briše adresirani element.

Slika 3.3: Arhitektura REST API aplikacija

Slika 3.2: Tabela razlika HTTP metoda u zavisnosti od rada sa pojedinačnim elementom ili kolekcijom

29

GET metode su sigurne metode, što žnači da mora da se obezbedi da nikad ne izazivaju

side-effect-e. GET metoda služi samo za čitanje elemenata, odnosno ne sme da vši nikakve

promene nad njima.

PUT i DELETE metode su idempotente – ma koliko puta se ižvrše ove metode, režultat će

uvek biti isti. Uvek će se žameniti neki objekat novim i režultat će biti taj novi objekat, ili će se

obrisati taj element, žavisno od metode. Poživ ovih metoda uvek vraća isti režultat, nebitno koliko

se puta zaredom bude pozvao.

Za razliku od SOAP baziranih web servisa, ne postoji „žvanični“ standard ža RESTful web

API-je. To je zbog toga jer je REST arhitektalni stil u programiranju, dok je SOAP protokol. REST

nije standard, međutim, RESTful implementacije koriste druge standarde, poput JSON-a, XML-a,

HTTP-a, URI-ja itd.

Mnogi programeri prave grešku i često se dešava da opisuju svoje API-je kao RESTful, iako

oni narušavaju gore prethodno opisana ograničenja REST servisa (pogotovo ograničenje u veži sa

uniformnim interfejsom).

30

4 BirdTouch aplikacija

Osnovna ideja koju smo materijalizovali kroz mobilnu

aplikaciju žasniva se na sledećem konceptu aplikacije u formi

beskontaktne razmene osnovnih podataka o registrovanom

korisniku u jednoj od tri izabrane kategorije profila - private,

business, celebrity. Ona omogućava uvid, uz datu dozvolu jedne od

live kategorije profila omogućene u datom trenutku, u profile

ostalih korisnika koji se prevashodno nalaže u najbližem

lokacijskom okruženju. Šta se žapravo ovom aplikacijom dobija?

Požnato je da dosadašnje društvene mreže omogućavaju

pregled profila bilo kog korisnika koji je registrovan (uz dozvolu prikaza i ostalih pojedinosti

ostalim korisnicima koji su povezani sa njim). Aplikacijom birdtouch omogućava se prelažak sa

virtualne na realnu komunikaciju sa ostalim nepožnatim korisnicima u okolini u slučaju da su

njihovi elektronski vizit kartoni dostupni za razmenu u jednoj od tri pomenute izabrane

kategorije. Ono što treba istaći je da svaka od ižabrane tri kategorije profila poseduje ličnu

biblioteku (folder) podataka sinhronižovanu sa glavnim serverom sistema, kojom se omogućuje

čuvanje i deljenje elektronskog materijala korisnika.

4.1 Primer i način funkcionisanja private režima

rada

Nalažimo se ispred kafea. Pre ulaska, pokrećemo aplikaciju birdtouch i biramo jednu od

kategorija profila, u ovom slučaju primera private. Odlažemo smart uređaj i nastavljamo

uobičajene aktivnosti. U slučaju da je kod još jednog korisnika u kafeu takođe pokrenuta aplikacija

sa izabranom kategorijom private, doći će do nesmetane ražmene osnovnih privatnih elektronskih

vižit kartona. Privatni elektronski vižit kartoni korisnika mogu da sadrže neke najosnovnije

informacije o korisniku (ime i prezime, trenutna profilna slika, trenutno raspoloženje, neki od

hobija, mesto moguće ponovne posete i slično). Po napuštanju (ili ža vreme boravka) lokacije,

omogućeno nam je da pregledamo private elektronske vižit kartone korisnika koji su se našli na

mestu događaja. U slučaju da želimo da se fokusiramo samo na pojedinačnog korisnika u kafeu

(pod uslovom da je kod njega pokrenuta aplikacija u istoj kategoriji) možemo da ižvršimo

prepožnavanje privatnog elektronskog vižit kartona pomenutog korisnika na osnovu “trenutne”

slike profila i da imamo uvid u neku od osnovnih informacija o njemu. Biblioteka (folder)

kategorije private bi se koristila ža skladištenje kartica korisnika koji ne moraju biti vidljivi

ostalim korisnicima, već bi predstavljala kolekciju svih osoba sa kojima smo razmenili

kontakte iz kategorije private.

Slika 4.1: Logo aplikacije

31

4.2 Primer i način funkcionisanja business režima

rada

Nalažimo se na konferenciji ili nekom većem poslovnom skupu. Neposredno pre početka

događaja, odnosno ulaska u radijus posetilaca, pokrećemo aplikaciju birdtouch i biramo u ovom

slučaju primera kategoriju business. Odlažemo smart uređaj i nastavljamo uobičajene poslovne

aktivnosti. U slučaju da je kod još jednog korisnika na skupu takođe pokrenuta aplikacija sa

izabranom kategorijom business, doći će do nesmetane ražmene poslovnih elektronskih vižit

kartona. Poslovni elektronski vizit kartoni korisnika sadrže neke od najosnovnijih informacija o

korisniku neophodnih u poslovnoj saradnji (ime i prezime, oficijalna slika njegove kompanije ili

firme koju predstavlja, naziv institucije u kojoj je zaposlen, titulu, zvanje, poziciju, neki od razloga

za poslovnu saradnju, oblast kojom se bavi, lokaciju moguće ponovne poslovne posete i slično).

Po napuštanju (ili u toku trajanja posete) lokacije, omogućeno nam je da pregledamo poslovne

elektronske vižit kartone korisnika koji su se na istom mestu našli. U slučaju da želimo da se

fokusiramo na pojedinačnog poslovnog korisnika (pod uslovom da je kod njega pokrenuta

aplikacija u istoj kategoriji) možemo da ižvršimo prepožnavanje poslovnog elektronskog vižit

kartona pomenutog korisnika na osnovu “trenutne” slike profila i da imamo uvid u neku od

osnovnih poslovnih informacija o njemu. Biblioteka (folder) kategorije business bi se koristila za

skladištenje poslovne elektronske dokumentacije korisnika kojima se može pristupiti sa bilo kog

mesta logovanjem na registrovani nalog už pomoć internet konekcije. Biblioteka bi u tom slučaju

predstavljala kolekciju žapamćenih kontakta namenjen sadržajima kategorije business.

4.3 Primer i način funkcionisanja celebrity režima

rada

Pod pretpostavkom da nam je oficijalno dodeljena dozvola korišćenja kategorije celebrity

od administratora aplikacije, bićemo u mogućnosti da vršimo selekciju i ražmenu elektronskih

vizit kartona sa svim ostalim kategorijama profila (ukoliko to dozvolimo) ili samo sa korisnicima

profila celebrity. Nalazimo se na fashion week-u ili nekom drugom skupu ža koji se žna da će

okupiti požnate iž ražličitih sfera. Pre ulaska, pokrećemo aplikaciju birdtouch i biramo u ovom

slučaju primera kategoriju celebrity. Odlažemo smart uređaj i nastavljamo uobičajene aktivnosti.

U slučaju da je kod još jednog korisnika na skupu takođe pokrenuta aplikacija sa ižabranom

kategorijom celebrity, doći će do nesmetane ražmene elektronskih vižit kartona. Celebrity

elektronski vižit kartoni korisnika mogu sadržati informacije o korisniku koje on želi da ražmeni

sa ostalim korisnicima iste ili ražličite kategorije (ime i prežime, umetničko ime, oficijalna

celebrity slika, neki od trenutnih statusa, raspoloženja, reklamu nastupajućeg koncerta, datum i

mesto promocije knjige, ižložbe, predstave, filma, festivala i slično). Po napuštanju (ili ža vreme

boravka) lokacije, omogućeno nam je da pregledamo celebrity elektronske vizit kartone korisnika

32

koji su se na istom mestu našli. U slučaju da želimo da se fokusiramo na pojedinačnog celebrity-ija

ili nekog korisnika druge kategorije (pod uslovom da je kod njega pokrenuta aplikacija) možemo

da stupimo u direktni kontakt sa njim poživom ža chat, ili ražmenu multimedijalnih sadržaja,

odnosno fajlova iž biblioteke (foldera) prilagođenog kategoriji celebrity.

4.4 Prednosti i zaključak

Ovakav način beskontakte ražmene podataka podražumeva korišćenje smart telefona koji

poseduje napredne tehnologije bežične komunikacije i lociranja (wifi, networking, gps) kako bi

hardverski omogućio podršku aplikaciji, i kako bi korišćenjem internet veže (detaljno) ižvršio

lokaciranje korisnika uz odabir radijusa trenutnih live korisnika aplikacije. Ono što aplikaciju

izdvaja od postojećih sličnih aplikacija povežanih sa društvenim mrežama jeste upravo podižanje

nivoa moguće realne komunikacije među korisnicima u najbližem okruženju u nekoj od tri

izabrane kategorije. Aplikacija pored lokalnog karaktera obuhvata i globalni koji sadrže i

uobičajene požnate društvene mreže. To podražumeva da pri registraciji jednog profila, kategorije

profila ostalih korisnika (uključujući i celebrity) možemo nesmetano pregledati (ono što je

omogućeno ža podelu) i u odsustvu ižabranog lokacijskog dometa. Time bi se svakako nastavila

nesmetana virtuelna komunikacija sa svim kategorijama profila korisnika. U slučaju da nemamo

privilegije celebrity kategorije, ulaskom u nju nam je omogućeno da pratimo aktivnosti korisnika

koji pripadaju toj kategoriji uz dozvolu i ražmenu elektronskih vižit kartona ižmeđu celebrity i

preostale dve kategorije profila ukoliko korisnik celebrity kategorije to dopusti na datoj lokaciji,

ili jednostavno ima želju da se upožna sa nekim ko ne pripada kategoriji celebrity. Ovakav vid

(beskontaktna ražmena vižit kartona i upožnavanje korisnika u najbližem okruženju)

komunikacije bi trebalo da doprinosi i smanjenju rizika od pojave depresije kao posledice

konžumiranja virtuelnih društvenih mreža na osnovu sprovedenih istraživanja i rezultata

objavljenih u prestižnim medicinskim naučnim časopisima.

Prikažani virtuelni dinamički način upožnavanja doprinosi i realnom upoznavanju ljudi

koji se svakodnevno sreću na prometnim mestima - tržni centri, metroi, stanice, aerodromi,

restorani, kafei, koncerti, festivali, manifestacije, kulturni događaji, poslovni skupovi,

konferencije, forumi i slično.

Aplikacija,pored osnovnih potrebnih hardverskih elemenata bežične komunikacije (gps,

wifi, networking itd.), doprinosi i potrebi za razvojem naprednijih vidova bežične komunikacije

visokog protoka podataka. Ukoliko ova ideja „žaživi“ i aplikacija bude planetarno popularna, žbog

potrebe lociranja korisnika u birdtouch aplikaciji bi se globalnim proižvođačima smart uređaja i

personalnih računara skrenula pažnja ka unapređenju hardverskih tehnologija bežične

komunikacije u odsustvu interneta i razvoja preciznijih hardversko-softverskih elemenata u

domenu gps požicioniranja. Kao nova požitivna posledica tako ražvijenog servisa omogućila bi i

formiranje manjih grupa (članovi porodice, poslovni partneri, itd.) čiji bi članovi bili neprekidno

upoznati sa lokacijom ostalih u grupi (primer radi - roditelju je omogućeno da neprekidno prati

lokaciju svog deteta i njegove aktivnosti, raspoloženje itd.). Ostale pozitivne prednosti pomenute

aplikacije bi mogle biti nadograđivane u skladu sa potrebama korisnika.

33

5 Implementacija Birdtouch aplikacije

Kako bi se krenulo u implementaciju ove aplikacije, moralo je biti odlučeno o

tehnologijama koje će biti korišćene ža ražvoj. Vodilo se računa da to budu tehnologije koje je

moguće koristiti na više operativnih sistema (pre svega Windows i Linux), da imaju veliku

podršku žajednice (eng. community) kako bi probleme sa kojima se susrećemo mogli lako da

rešimo, i bilo je potrebno da su te tehnologije prihvaćene kao jedne od vodećih, isprobanih i

najpuzdanijih u svojim oblastima.

Nakon višemesečnih testiranja, shvatanja da neke odluke jednostavno ne funkcionišu

(MySQL recimo za bazu, jer Entity Framework nije bio prijateljski nastrojen prema nadogradnji

modela kada je bilo potrebno), isprobavanja gotovo svih trendy opcija, odlučeno je u čemu će se

razvijati aplikacija.

• Baza podatka - PostgreSQL

• Web Server - .Net Core 2.1

• Klijent aplikacija – Xamarin (Android)

Nakon donošenja ovih odluka, pristupilo se ražvoju same aplikacije. Bilo je potrebno prvo

osmisliti model baže koji bi odgovarao potrebama naše aplikacije. Taj model bi bio korišćen od

strane web servera, koji bi u sebi sadržao minimalnu logiku (računanje distance ižmeđu dva

korisnika) i podatke iž baže servirao po RESTful standardu našoj klijent aplikaciji koja bi te

podatke koristila i prikazala krajnjem korisniku.

Nakon uspešne implementacije, jedina stvar koja bi preostala kao nedoumica je gde

hostovati server, međutim, to će se ispostaviti kao veoma trivijalna stvar, budući da cloud hosting

giganti poput Amazona i Microsofta nude svoje usluge (instancu mašine) besplatno ža probu

tokom prve godine korišćenja.

5.1 Baza podataka

5.1.1 Uopšteno

PostgreSQL baza je dobila prednost u odnosu na MySQL, SQLServer i druga popularna

rešenja prvenstveno žbog toga što je moguće koristiti ovu bažu na Windows, kao i na Linux

mašinama. Takođe, jedan od razloga je i taj što je ova baža besplatna ža korišćenje. PostgreSQL,

mada najčešće ćete se na internetu susretati sa skraćenicom Postgres, je objektno-relacioni bazni

menadžment sistem (ORDBMS) sa akcentom na mogućnost proširenja (krož plugin-ove) i

praćenju standarda SQL. Ovu bažu koriste kompanija ža neka inhouse rešenja, kao i ža rešenja

34

koja imaju više miliona korisnika – upravo žvog te mogućnosti skaliranja, došli smo do žaključka

da će upravo Postgres verovatno žadovoljiti sve buduće potrebe Birdtouch aplikacije. Ova baža je

inicijalno napravljena 1996. godine, međutim, tek krajem prve decenije 2000-tih dobija na

popularnosti, a danas je moguće jedna od najpreporučenijih i najhvaljenih baža na internetu.

Verovatno i žbog činjenice da je PostgreSQL 100% besplatan ža upotrebu, dok druga rešenja

(poput SQLServer) imaju ograničenja koja morate imati u vidu kada ražvijate komercijalnu

aplikaciju.

5.1.2 Model baze

Pri projektovanju modela baže vodilo se računa da baža ne bude prenatrpana

bespotrebnim podacima. Ideja je bila napraviti minimalni model, koji bi obezbedio svu logiku koja

je potrebna aplikaciji, a u isto vreme bio veoma lak ža održavanje i eventualno proširavanje.

Nakon mnogih refaktoringa, promena relacija, promena tabela, izmena u logici, finalna

veržija baže sadrži dvanaest tabela, od kojih su sedam deo Membership Identity sistema koji je

korišćen ža kreiranje i autentifikaciju korisnika.

Korisnici

Pri kreiranju korisnika, podaci se upisuju u tabelu

asp_net_users. Ova tabela je deo Identity Membership sistema

koji se koristi na web serveru za autentifikaciju i za

autorizaciju. Polja u ovoj tabeli su predefinisana

specifikacijom Identity framework-a, ali se mogu proširiti

nekim dodatnim, ukoliko bude potrebe. Svaki korisnik ima

svoj jedinstven identifikacioni broj, korisničko ime i šifru. Šifra

se pamti u svom hash-iranom obliku, tako da čak ni

administratori aplikacije ne žnaju koju šifru je korisink

postavio. Polje access_failed_count služi kako bi se sprečili

bruteforce napadi provaljivanja korisničke šifre – nakon 5

netačnih unosa šifre, korisniku se blokira pristup aplikaciji na

odredjeno vreme, koje se povećava ukoliko korisnik nastavi

da pokušava sa lošim šiframa. Takođe postoji podrška ža two

factor authentifikaciju.

Slika 5.1: Model asp_net_users tabele

35

Informacije o korisnicima

Potrebno je zapamtiti informacije o privatnim (private) i poslovnim (business)

korisnicima. Za to koristimo dve odvojene tabele private_info i business_info. Koristimo dve, a ne

jednu, jer se podaci u njima dosta razlikuju. A moguće da će neki korisnici koristiti aplikaciju

isključivo u jednom režimu (business ili private). U njima su sadržani svi podaci koje je potrebno

prikažati drugim korisnicima kada budu u okolini našeg korisnika. Linkovi do njihovih društvenih

mreža se pamte u svojoj HTML enkodovanoj verziji zbog specijalnih znakova sa kojima nije

moguće raditi direktno.

Zapamćeni korisnici

Potrebno je voditi računa o tome koji korisnici su razmenili svoje kontakt informacije, i u

kom režimu aplikacije. Za to koristimo dve tabele saved_private i saved_business u kojima se

nalaze podaci koja dva korisnika su razmenila svoje podatke.

Slika 5.4: Model saved_private tabele Slika 5.5: Model saved_busines tabele

Slika 5.2: Model user_info tabele

Slika 5.3: Model business_info tabele

36

Aktivni korisnici

Svi aktivni korisnici moraju imati svoj režim u kome su aktivni, kao i lokaciju gde se

trenutno nalaze kako bi web server mogao da servira prave podatke klijent aplikaciji. Podaci o

aktivnim korisnicma se pamte u tabeli active_users, u kojoj se nalaze sve potrebne informacije

koje su potrebne serveru za dalju obradu.

Identity framework

Tabele koje su potrebne za autorizaciju i autentifikaciju su one koje dolazi predefinisane

Identity Membership framework-om, a to su asp_net_claims, asp_net_user_logins,

asp_net_user_tokens, asp_net_user_roles, asp_net_role_claims i asp_net_users tabele.

Slika 5.6: Model active_users tabela i veza sa asp_net_users tabelom

37

Na slici 5.7 je prikazan celokupan model

baže, žajedno sa svim vežama ižmeđu tabela.

Model je hibridno rešenje koje koristi

infrastrukturu identity membership sistema i

specifične entite potrebne ža biznis logiku

Birdtouch aplikacije.

Slika 5.7: Celokupni model baze

38

5.2 Web server

5.2.1 Uopšteno

Za serverski deo aplikacije smo se odlučili ža .Net Core - relativno nov C# framework koji

polako, ali sigurno, užima deo kolača web serverskog tržišta od svog starijeg brata .Net

Framework-a. Najveća prednost ovog framework-a je u njegovoj mogućnosti da se pokrene na bilo

kom operativnom sistemu (Windows, Linux ili macOS), kao i mogućnosti lakog pravljenja

skalabilnih rešenja koristeći mikroservise, containere i druge požnate tehnike kreiranja

mikroservis arhitekture. Primere ovih rešenja možete naći detaljnije opisane u [9].

Srž (core) jezika je prepisan od nule, sa svim ispravljenim problemima koje je imao .Net

Framework. Prepisane su takođe veržije Identity-ja (kog koristimo za autentifikaciju i

autorizaciju), Entity Framework-a (ORM koji koristimo za pristup bazi), kao i mnogi drugi drajveri

i biblioteke – sve kako bi se povećala kompatibilnost i efikasnost novog .Net framework-a.

Takođe treba spomenuti da je .Net Core, kao i sve njegove prateće biblioteke, u potpunosti

open source projekat. Dakle, moguće je videti kako sve radi ispod haube, nije više skriveno od

programera, i ukoliko ste uporni, sigurno možete pronaći, už veliku dožu upornosti i čitanja koda,

ražlog „čudnog“ ponašanja nekih metoda iž žvaničnih biblioteka. Moguće je i doprineti ražvoju

ovog framework-a pravljenjem pull request-a na GitHub-u, gde je i host-ovan ovaj projekat.

5.2.2 Cilj

Kako bi ovaj server bio funkcionalan i bio u stanju da opslužuje veliki broj korisnika koji

bi bili zadovoljni performansama sistema (odziv poziva treba da bude minimalan) kao i

sigurnošću aplikacije (drugi korisnici ne bi smeli da vide podatke drugih korisnika, čak i ukoliko

pokušaju da žloupotrebe tokene koji se koriste pri autorizaciji), podelili smo web server projekat

na nekoliko celina:

• Rad sa bazom

• Autentifikacija i Autorizacija

• Implementacija kontrolera prateći RESTful ograničenja

U narednim sekcijama ćemo govoriti malo više o detaljima implementacije ovih celina koje

sve žajedno čine Birdtouch server.

39

5.2.3 Rad sa bazom

Budući da se podaci aplikacije čuvaju u PostgreSQL baži, bilo je potrebno pronaći način

kako komunicirati sa njom iž servera, a da pritom to bude kompromisno rešenje ižmeđu brzine

ižvršenja upita i lakoće pisanja/čitanja koda. Ideja da se koriste čisti upiti, a zatim podaci bind-

ovali ža neke modele je ubržo odbačana jer bi odužimala previše vremena u toku ražvoja i

testiranja. Bilo je potrebno pronaći rešenje koje će:

• Vršiti laku komunikaciju sa bazom preko connection string-ova

• Moći da ižgeneriše modele iž baže koji će se kasnije popuniti podaci

• Imati odličnu podršku community-ija

• Biti ižužetno lako ža čitanje i ražumevanje napisanog

• Imati najbolji kompromis (trade-off) između performansi i bind-ovanja modela sa kojima

bi se radilo u serveru

.Net Core, iako je dosta nov framework, već ima podršku ža veliki broj rešenja (biblioteka)

koja bi rešila gore navedene probleme.

Entity Framework Core je dobio prednost u odnosu na druga rešenja (poput Dappera ili

DevExpress XPO) prvenstveno jer je to proveren framework koji se pokazao kao pouzdan i zbog

toga što je ražvijan paralelno sa ražvijanjem .Net Core-a. EF Core je takođe Microsoftov proizvod,

u čiji kod takođe imate uvid na njihovom GitHub-u. On je ORM (eng. Object-relational mapping)

framework koji, kao i sve druge Microsoftove žvanične .Net Core biblioteke, radi na svim

okruženjima (Windows, Linux ili macOS). Prepisan je od nule i trenutno još uvek se nije stiglo sa

prepisivanjem svih komponenti koje Entity Framework poseduje u .Net Framework okruženju, ali

na svakih nekoliko meseci se povećava funkcionalnost novim release-ovima tako da će se uskoro

ižjednačiti i po tom pitanju. Iako nema svu (složenu) funkcionalnost, ima sasvim dovoljnu kako bi

se lako, jednostavno i brzo radilo sa bazom. A to je upravo ono šta smo želeli.

Primer upotrebe EF Corea

Na primer, ukoliko bismo želeli da vratimo podatke ža aktivnog korisnika iž tabele

active_users, to bi u EF Core-u izgledalo ovako:

applicationContext .ActiveUsers .AsNoTracking() .FirstOrDefaultAsync(u => u.FkUserId == userId && u.ActiveMode == activeMode);

40

5.2.4 Autentifikacija i Autorizacija

ASP. NET Core Identity je Membership sistem koji omogućava funkcionalnost login-a

aplikacijama koje su napisane u .Net Coreu. Korisnici mogu da kreiraju svoj nalog sa login

informacijama ili mogu da koriste neki eksterni login provajder (eng provider). Od eksternih login

provajdera podržani su Facebook, Google, Microsoft Account i Twitter. Detaljnije o implementaciji

ražnih provadjera možete naći u [13].

Identity, bež ikakvih podešavanja (po default-u) radi sa SQL Serverom u kojem skladišti

korisnička imena, šifre i ostale informacije u vezi sa profilom korisnika. Međutim, moguće je

promeniti bažu koja se koristi, kao što smo mi i uradili, i umesto SQL Servera je moguće koristiti

bilo koju bažu ža koju Entity Framework Core ima podršku (jer EF Core je u požadini Identitija

žadužen ža rad sa bažom). Moguće je korisititi i neka od cloud rešenja, poput Azure Table Storage

ža skladištenje podataka.

Ovakav sistem je našoj aplikaciji bio najpogodniji jer nam je bila potrebna najprostija

moguća implementacija kreiranja korisnika, provera šifre, implementacija logina putem

Facebooka i drugih provajdera, kao i druge funkcionalnosti koje se očekuju od jedne moderne

aplikacije.

Za autentifikaciju korisnika nakon prvobitne provere njihovog korisničkog imena i šifre,

koristićemo JWT tokene, koji će u svakom poživu ka nasem web serveru biti poslati u vidu

Autorizacionog header-a.

Identity Membership implementacija

Potrebno je prvo podesiti Identity Membership da radi sa PostgreSQL bažom, takođe je

potrebno registrovati potrebne kontekste i klase kako bi bile dostupne u celoj aplikaciji.

// Dodaje ApplicationDbContext u DI services.AddDbContext<ApplicationDbContext>(); // Dodaje ApplicationUserDbContext u DI services.AddDbContext<ApplicationUserDbContext>(); services.AddIdentity<ApplicationUser, IdentityRole<Guid>>() .AddEntityFrameworkStores<ApplicationUserDbContext>() .AddDefaultTokenProviders();

optionsBuilder.UseNpgsql(_configuration.GetConnectionString("DefaultConnection"));

Nakon ovog podešavanja spremni smo ža rad sa korisnicima.

Kreiranje korisnika je jednostavno, sve što je potrebno uraditi je:

41

var result = await _userManager.CreateAsync(new ApplicationUser { UserName = loginCredentials.Username, Email = loginCredentials.Username }, loginCredentials.Password);

Nakon ovog poživa, pre kreiranja korisnika u baži, proveriće se da li je njegovo korisničko

ime validno (nema nedožvoljenih karaktera, nije već žaužeto i slično), žatim da li je šifra validna

(da li ima sve potrebne karaktere koji čine jednu jaku šifru), i na kraju ukoliko je sve u redu,

kreiraće se korisnik u našoj PostgreSQL baži.

Nakon kreiranja korisnika, potrebno je implementirati način kako proveriti kredencijale

korisnika koji žele da se uloguju u naš sistem.

Srećom, Identity Membership i ža ovo ima rešenje. Potrebno je uraditi sledeće:

var user = await _userManager.FindByNameAsync(loginCredentials.Username); if (user == null) { return new StatusCode(401); } var result = await _signInManager.CheckPasswordSignInAsync(user, loginCredentials.Password, true); if (!result.Succeeded) { return new StatusCode(401); }

Nakon ovoga, ukoliko se korisničko ime i šifra poklapaju, možemo korisnika proslediti ka

početničkoj strani naše aplikacije, prosleđujući mu pritom i podatke poput korisničkog ID-ija i

drugih informacija koje su potrebne klijentu za pravljenje REST poziva.

JWT Tokeni

Iako je provera korisničkog imena poprilično jednostavna, žahvaljujući fasadama iž

Identity Membership-a, u pozadini je to ipak dosta kompleksna operacija. Potrebno je nekoliko

poziva ka bazi, kako bi se proverili svi korisnikovi podaci, zatim ukoliko bude autorizovan,

potrebno je pribaviti dodatne podatke kako bi klijent aplikacija imala što više informacija kod sebe

i ne bi morala da žove server ža svaki potreban korisnički promenljiv parametar.

Sve te podatke, naravno moguće je poslati prilikom logina/registracije klijentu i klijent to

može žapamtiti kod sebe u nekom lokalnom skladištu. Međutim, možda to deluje kao dobra ideja

42

na prvi pogled, ali takva implementacija krije ogromni sigurnosni propust – klijent može da

manipuliše tim podacima.

Dakle, potreban nam je način ža skladištenje nekih informacija koje će varirati od

korisnika do korisnika, a da pritom znamo da su te informacije nepromenjene od trenutka

kreiranja (prilikom logina). Upravo ovde na scenu stupa JWT Token.

JWT (JSON Web Token) je javno dostupni industrijski standardizovani način ža deljenje

klejmova (eng. claims) bežbedno ižmeđu neka dva entiteta. Podatke koji se nalaže unutar tih

klejmova je moguće verifkovati da li su nepromenjeni jer postoji potpis koji je pridružen svakom

tokenu. Potpis se generiše korišćenjem nekog hashing algoritma, podataka iž claimova i ključa koji

je dostupan samo serveru. Na ovaj način, kada JWT token stigne od klijenta, server može ponovo

da proba da kreira potpis, i ukoliko se potpisi podudaraju, znamo da je validnost i integritet tokena

nepromenjena i možemo verovati podacima unutar klejmova.

U svojoj kompaktnoj formi JWT token se sastoji iž tri dela raždvojenim tačkama. Ova tri

dela se nazivaju:

• Header

• Payload

• Signature

Što žnači da tipičan jwt token ižgleda ovako headerData.PayloadData.SignatureData.

Na sledećem primeru možemo videti kako ižgleda token u realnom okruženju. Vrednost

tokena:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiI0MiIsIm5hbWUiOiJOZW5hZCBJbGnE

hyIsImxhbmd1YWdlIjoiZW4tVXMiLCJwZXJtaXNzaW9ucyI6ImFkbWluaXN0cmF0b3IifQ.rAGaRNOVihu-

V15JkG2uFqiaAW1h2RzuVbaK0-ZO0iw

Što nakon dekodiranja iž Base64 formata ižgleda ovako:

Header:

{

"alg": "HS256",

"type": "JWT"

}

Payload:

{ "userId": "42", "name": "Nenad Ilić", "language": "en-Us", "permissions": "administrator" }

43

Secret:

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), kljuc-koji-je-dostupan-samo-serveru )

Koristeći JWT tokene obežbedili smo keširanje podataka koje nema potrebe čitati svaki

put kada se pravi neki žahtev ka serveru, ali smo takodje obežbedili da korisnik ne može da radi

nikakvu vrstu manipulacije koja bi ugrožila bežbednost drugih korisnika ili naškodila radu

sistema.

Slika 5.8: Način korišćenja JWT tokena

44

5.2.5 REST Kontroleri

Nakon implementiranog rada sa bazom (Entity Framework), sistema za autentifikaciju

(Identity Membership), načina bežbedne komunikacije (JWT tokeni), preostalo je samo sve to

povežati u logičku celinu i omogućiti, krož određene HTTP metode, rad sa ovim sistemima.

Poštujući REST ograničenja i korišćenjem .Net Web API-ja, implementirali smo HTTP

metode koje rade u pozadini sa entiteima iz baze (resursima). Svaka akcija iz kontrolera, sem

akcije za login i registraciju, ima proveru da li je klijent poslao, u vidu autorizacionih headera, jwt

token. Ukoliko token nije validan, svaka akcija vraća http status code 401 – neautorižovani pokušaj

pristupa resursima.

Postoji 6 resursa (entiteta u bazi) koji su bitni za biznis logiku aplikacije, a to su:

• Users

• PrivateInfo

• BusinessInfo

• ActiveUsers

• SavedPrivate

• SavedBusiness

Svaki od njih ima svoj kontroler u kome su implementirane HTTP metode koristeći već

pomenutu REST arhitekturu. Sledi detaljan opis http metoda i ponašanja u žavisnosti od resursa

i prosleđenih parametara.

Users controller

Ovaj kontroler služi ža rad sa korisnicima, tačnije ža rad sa podacima koji su potrebni ža

login korisnika. Endpoint je api/users/id, a zavisno od HTTP metode:

• GET – Vraća korisnika ukoliko postoji takav sa prosleđenim kredencijalima (korisničko

ime i šifra)

• POST – Kreira novog korisnika sa prosledjenim kredencijalima.

• DELETE – Briše korisnika

• PATCH – Menja login informacije korisnika, poput korisničke šifre

Private/Business info controller

Za rad sa resursima u baži u kojima se čuvaju podaci u veži sa privatnim i poslovnim

korisnikovim profilom žaduženi su private info, odnosno business info kontroleri. Endpoint-i su

api/privateinfo/id i api/businessinfo/id, a zavisno od HTTP metode:

• GET – Vraća privatne/poslovne podatke koje je korisnik postavio u podešavanjima profila

• PATCH – Menja privatne/poslovne podatke kada korisnik zahteva promenu

45

ActiveUsers controller

Kada korisnici odluče da postanu vidljivi drugim korisnicima u sistemu, podaci o njihovoj

lokaciji, kao i režimu rada, se čuvaju u ActiveUsers tabeli u baži. Za rad sa ovim resursom žadužen

je ActiveUsers controller, endpoint je api/activeusers, a zavisno od HTTP metode:

• POST – Kreira aktivnog korisnika u određenom režimu i na određenoj lokaciji

• DELETE – Briše korisnika u određenom režimu

• GetUsersNearMe – Vraća sve korisnike koji se nalaže na određenom rastojanju od

korisnikove lokacije (u odabranom režimu)

Saved business/private controller

Ukoliko korisnik želi da sačuva kontakt informacije nekog drugog korisnika, u privatnom

ili poslovnom režimu, on to može uraditi dodavanjem novog resursa krož busines/private

controller koji u pozadini radi sa savedprivate i savedbusiness tabelama. Endpoint-i su

api/savedprivate i api/savedbusiness, a zavisno od HTTP metode:

• GET – Vraća listu korisnika koje je korisnik dodao

• POST – Dodaje novog korisnika u listu sačuvanih u željenom režimu

• DELETE – Briše korisnika iž liste sačuvanih iž željenog režima

46

6 Demonstracija Birdtouch aplikacije

Prilikom prvog pokretanja aplikacije, korisniku je predstavljen jedan od sledeća dva

ekrana – slika 6.1 i 6.2.

Na slici 6.1 je prikazan ekran koji korisnik vidi ukoliko korisnik nije već ulogovan u aplikaciju. Na

slici 6.2 je prikazan ekran koji vide samo korisnici koji su već ulogovani, tada korisnik nema nikakvu

vrstu interakcije sa ovim ekranom. Kada aplikacija bude učitana u memoriju i nakon inicijalnih rest

poziva, korisnik će automatski biti prebačen na narednu stranu aplikacije jer su njegovi kredencijali već

zapamćeni u JWT tokenu.

Slika 6.1: Ekran kada korisnik nije ulogovan

Slika 6.2: Ekran kada je korisnik već ulogovan

47

U zavisnosti od toga da li korisnik želi da se uloguje sa već postojećim ili napravi novog

korisnika, dobiće sledeće opcije nakon klika na Sign In (slika 6.3), odnosno Sign up (slika 6.4)

dugmiće.

U žavisnosti od unešenih kredencijala, Sign In dijalog (slike 6.5 i 6.6) reaguje i vraća

povratnu informaciju korisniku.

Slika 6.3: Nakon klika na Sign In Slika 6.4: Nakon klika na Register

Slika 6.5: Pokušaj logina korisnika Slika 6.6: Pogrešni kredencijali za login

48

Na sličan način reaguje i Sign Up dijalog (slika 6.7), koji u zavisnosti od dostupnosti i

validnosti kredencijala, korisniku vraća odgovarajuću poruku.

Nakon kreiranja naloga, korisnik će dobiti kratak pregled svih mogućnosti aplikacije (slika 6.8).

Slika 6.7: Sva moguća stanja Sign up dijaloga

Slika 6.8: Ekrani koji služe za dobrodošlicu novim korisnicima

49

Aplikacija će žatim automatski otvoriti meni sa leve

strane kako bi korisnik što brže krenuo sa podešavanjem svog

profila (slika 6.9).

U ovom meniju moguće je pristupiti delovima aplikacije

koji su žaduženi ža podešavanje privatnih i poslovnih

informacija. Moguće je takođe pristupiti delovima koji su

žaduženi ža podešavanje rada aplikacije. Klik na dugme Home

skriva meni, dok dugme Log Out vrši brisanje korisnika iž

stanja aktivnih korisnika i vraća vas na početni (login) ekran.

Podešavanje privatnih i poslovnih informacija se vrši u posebnim delovima aplikacije

(slika 6.10). Moguće je dodeliti i profilnu sliku koja odgovara tom režimu rada, promeniti

informacije koje bi mogle biti od koristi drugim korisnicima i dodati linkove do vaših profila na

društvenim mrežama.

Slika 6.9: Meni sa leve strane

Slika 6.10: Podešavanje privatnih i poslovnih informacija

50

Nakon promene ovih informacija klikom na dugme u donjem desnom uglu vaše promene

će biti žapamćene i trenutno vidljive svim drugim korisnicima. Na slici 6.11 možete videti proces

promene podataka jednog korisnika.

Nakon podešavanja privatnih podataka, spremni smo ža pretragu korisnika u našoj okolini

uključivanjem Make me visible checkoxa (slika 6.12).

Slika 6.11: Proces promene privatnih podataka

Slika 6.12: Pretraga korisnika u našoj okolini

51

Ukoliko se ulogujemo kao neki drugi korisnik, a nalazimo se na istoj lokaciji kao malopre

kreirani korisnik, videćemo i njegov profil u listi korisnika koji se nalaže u bližini (slika 6.13, prvi

korisnik u listi). Klikom na meni u donjem desnom uglu, dobijamo dodatne akcije (slika 6.14) koje

možemo ižvršiti u sekciji PRIVATE.

U meniju su ponuđene opcije ža osveživanje podataka, kao i ža promenu geografske

lokacije. Osveživanje podatka se radi automatski nakon kratkog intervala, međutim, možda

korisnik ne želi da čeka i želi ručno pokretanje ove opcije. Promena geografske lokacije se takođe

automatski menja nakon određenog vremena, ali je korisniku takođe dožvoljeno ručno poživanje

ove akcije.

Klikom na sivu zvezdu (slika 6.15, desno od

korisnikovih kartica), koja se nalazi na desnoj strani

svakog profila korisnika, dodajemo taj profil u listu

sačuvanih profila kako bismo im mogli pristupiti i

kada se međusobno ne nalažimo u blizini. Ovim

korakom smo obežbedili ražmenu kontakta ižmeđu

dve osobe nakon koje korisnik može biti siguran da

neće ižgubiti podatke druge osobe.

Slika 6.13: Pretraga kao neki drugi korisnik Slika 6.14: Ponuđene akcije u sekciji PRIVATE

Slika 6.15: Dodavanje korisnika u listu sačuvanih korisnika

52

Nakon dodavanja u listu sačuvanih, potrebno je promeniti

tab i otići na Saved Private (slika 6.16). Klikom na ostatak (bilo koji

deo levo od zvezde) kartice nekog korisnika otvara se stranica sa

detaljima o tom korisniku u odabranom režimu. Na ovoj strani (slika

6.17) je moguće ukloniti korisnika iž liste sačuvanih, pogledati

detaljnije informacije o njemu ili ispratiti link do neke od društvenih

mreža do kojih vam je on dao pristup.

Klikom na neku od ikonica, koje predstavljaju društvenu mrežu, otvoriće se Vaš

podražumevani pretraživač sa linkom koji je korisnik postavio.

Slika 6.16: Lista sačuvanih korisnika

Slika 6.17: Detaljni prikaz korisnika sačuvanog u privatnom režimu

53

Korisnik može uključiti aplikaciju da radi i u poslovnom režimu, koji će prikazivati samo

druge korisnike koji su takođe uključili ovaj režim. Moguće je koristiti privatni i poslovni režim

istovremeno. Posebna lista sačuvanih korisnika je žadužena ža pamćenje poslovnih informacija,

tako da ne može doći do mešanja informacija ižmeđu poslovnih i privatnih korisnika. Uključivanje

poslovnog režima se vrši u tabu BUSINESS, a lista njegovih sačuvanih kontakta u tabu SAVED

BUSINESS, a kako to izgleda vidimo na slici 6.18.

U meniju sa leve strane moguće je podesiti dodatne parametre od kojih zavisi rad

aplikacije (slika 6.19) ili videti detalje o autoru (slika 6.20).

Slika 6.18: Prikaz rada aplikacije u poslovnom režimu

Slika 6.19: Podešavanja aplikacije Slika 6.20: Kontakt informacije autora

54

Search radius parametar nam služi kako bismo limitirali pretragu u određenom prečniku

od lokacije korisnika.

Delete account opcija je tu kako bi korisnik žauvek ugasio profil ukoliko to želi (zbog GDPR

pravilnika kojeg su propisale zemlje EU regiona). Nakon brisanja profila nije moguće vratiti

podatke korisnika.

55

7 Literatura

[1] Charles Petzold, Creating Mobile Apps with Xamarin.Forms Preview Edition 2 (Developer

Reference), Microsoft Press, (2014)

[2] Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software

Architectures (doctor of philosophy dissertation), University of California, (2000)

[3] Leonard Richardson i Sam Ruby, RESTFul Web Services (1st edition), O’Reilly Media,

(2007)

[4] Jim Webber, REST in Practice: Hypermedia and Systems Architecture (1st edition), O'Reilly

Media, (2010)

[5] Subbu Allamaraju, RESTful Web Services Cookbook: Solutions for Improving Scalability

and Simplicity (1st edition), Yahoo Press, (2010)

[6] George Reese, The REST API Design Handbook (1st edition), O'Reilly Media, Inc, (2011)

[7] Jonathan Peppers, Xamarin Crossplatform Application Development (2nd edition), Packt

Publishing, (2012)

[8] Steven F. Daniel, Mastering Xamarin UI Development (2nd edition), Packt Publishing,

(2017)

[9] Philip Japikse, Building Web Applications with Visual Studio 2017: Using .NET Core and

Modern JavaScript Frameworks (1st ed. edition), Apress, (2017)

[10] Jim Bennett, Xamarin in Action: Creating native cross-platform mobile apps (1st edition),

Manning Publications, (2018)

[11] Dan Hermes, Xamarin Mobile Application Development: Cross-Platform C# and

Xamarin.Forms Fundamentals (1st ed. edition), Apress, (2015)

[12] Martin Kleppmann, Designing Data-Intensive Applications: The Big Ideas Behind Reliable,

Scalable, and Maintainable Systems (1st edition), O'Reilly Media, (2017)

[13] Rahul Sahay, ASP.NET Identity: Including ASP.NET Core, Amazon Digital Services LLC,

(2016)

56

Biografija

Nenad Ilić je rođen 06.01.1993. godine u Knjaževcu. Detinjstvo je proveo u Trgovištu, gde je i

pohađao osnovnu školu „Dubrava“. Od 2008. do 2012. godine je pohađao Gimnaziju u Zaječaru, kao

đak oglednog odeljenja Informatike gde je produbio ljubav ka programiranju prvobitno stečenu u

Osnovnoj školi.

Godine 2012. je upisao studije informatike na Prirodno-matematičkom fakultetu u Nišu.

Osnovne akademske studije je završio 2015. godine, a iste godine je upisao i master akademske studije,

modul Razvoj Softvera, koje je završio 2018. godine.

Oblasti interesovanja su mu razvoj web i mobilnih aplikacija, projektovanje baza podataka,

moderni sistemi za autentifikaciju, kao i razvoj video igara. Najinteresantiji aspekti razvoja aplikacija

su mu projektovanje arhitekture (sistem arhitekture), optimizovanje baza podataka i upoznavanje sa

novim tehnologijama sa kojima nikad ranije nije radio.

Ima iskustva u radu u industriji, gde su mu sfere delovanja cloud servisi i implementacija

specifičnih hosting rešenja.

57

Прилог 5/1

ПРИРОДНO - MАТЕМАТИЧКИ ФАКУЛТЕТ

НИШ

КЉУЧНА ДОКУМЕНТАЦИЈСКА ИНФОРМАЦИЈА

Редни број, РБР:

Идентификациони број, ИБР:

Тип документације, ТД: монографска

Тип записа, ТЗ: текстуални / графички

Врста рада, ВР: дипломски рад / мастер рад

Аутор, АУ: Ненад Илић

Ментор, МН: Марко Петковић

Наслов рада, НР: Имплементација друштвене мреже

Birdtouch коришћењем Xamarin

технологије и REST сервиса

Језик публикације, ЈП: српски

Језик извода, ЈИ: енглески

Земља публиковања, ЗП: Р. Србија

Уже географско подручје, УГП: Р. Србија

Година, ГО: 2018.

Издавач, ИЗ: ауторски репринт

Место и адреса, МА: Ниш, Вишеградска 33.

Физички опис рада, ФО: (поглавља/страна/ цитата/табела/слика/графика/прилога)

55 стр. ; граф. прикази

Научна област, НО: Рачунарске науке

Научна дисциплина, НД: Мобилне апликације

Предметна одредница/Кључне речи, ПО: Веб сервер, мобилне апликације

УДК

Чува се, ЧУ: библиотека

Важна напомена, ВН:

58

Извод, ИЗ: Апликација за мобилне телефоне

Birdtouch је друштвена мрежа са акцентом

на размену података (контакт картица)

особа које се налазе у непосредној

близини. Подаци о локацији корисника се

преузимају из мобилног уређаја (GPS или

са мреже) и упоређују са свим осталим

активним корисницама. Постоји опција

размене података у приватном и

пословном режиму, како би ова

апликација могла да се користи у више

намена. Апликација је писана за Android

оперативни систем користећи Xamarin

технологију која користи C# програмски

језик. База података апликације је тренутно

изузетно актуелна релациона PostgreSQL која

може радити на свим оперативним

системима. За веб сервер је искоришћен Net

Core 2.1 Web API како би REST позиви били

што ефикасније и природније написани по

свим текућим стандардима.

Датум прихватања теме, ДП: 09.10.2018.

Датум одбране, ДО:

Чланови комисије, КО: Председник:

Члан:

Члан, ментор:

Образац Q4.09.13 - Издање 1

59

Прилог 5/2

ПРИРОДНО - МАТЕМАТИЧКИ ФАКУЛТЕТ

НИШ

KEY WORDS DOCUMENTATION

Accession number, ANO:

Identification number, INO:

Document type, DT: monograph

Type of record, TR: textual / graphic

Contents code, CC: university degree thesis

Author, AU: Nenad Ilić

Mentor, MN: Marko Petković

Title, TI: Implementation of the Birdtouch social

network using Xamarin technology and REST

services

Language of text, LT: Serbian

Language of abstract, LA: English

Country of publication, CP: Republic of Serbia

Locality of publication, LP: Serbia

Publication year, PY: 2018

Publisher, PB: author’s reprint

Publication place, PP: Niš, Višegradska 33.

Physical description, PD: (chapters/pages/ref./tables/pictures/graphs/appendixes)

55 p. ; graphic representations

Scientific field, SF: Computer science

Scientific discipline, SD: Mobile applications

Subject/Key words, S/KW: Web server, mobile applications

UC

Holding data, HD: library

Note, N:

60

Abstract, AB: The Birdtouch mobile application is a

social network app with a focus on contact cards

exchange of people in close proximity. User

location data is gathered from a mobile device

(GPS or from a network) and used to find out if

there are any nearby users. There are private

and a business mode, so this application can be

used for multiple purposes. The application is

written for Android operating system using

Xamarin technology that uses C# programming

language.

Accepted by the Scientific Board on, ASB: 09.10.2018.

Defended on, DE:

Defended Board, DB: President:

Member:

Member, Mentor:

Образац Q4.09.13 - Издање 1