Razvoj mobilnega odjemalca za platformo Occapi · 2018-03-13 · Izjava o avtorstvu diplomskega dela Spodaj podpisani Rok Drinovec, z vpisno stevilko 63080089, sem avtor di-plomskega

Univerza v Ljubljani

Fakulteta za racunalnistvo in informatiko

Rok Drinovec

Razvoj mobilnega odjemalca za

platformo Occapi

DIPLOMSKO DELO

UNIVERZITETNI STUDIJSKI PROGRAM PRVE STOPNJE

RACUNALNISTVO IN INFORMATIKA

Mentor: doc. dr. Dejan Lavbic

Ljubljana 2014

Rezultati diplomskega dela so intelektualna lastnina avtorja in Fakultete za ra-

cunalnistvo in informatiko Univerze v Ljubljani. Za objavljanje ali izkoriscanje

rezultatov diplomskega dela je potrebno pisno soglasje avtorja, Fakultete za racu-

nalnistvo in informatiko ter mentorja.

Besedilo je oblikovano z urejevalnikom besedil LATEX.

Izjava o avtorstvu diplomskega dela

Spodaj podpisani Rok Drinovec, z vpisno stevilko 63080089, sem avtor di-

plomskega dela z naslovom:

Razvoj mobilnega odjemalca za platformo Occapi

S svojim podpisom zagotavljam, da:

• sem diplomsko delo izdelal samostojno pod mentorstvom doc. dr. De-

jana Lavbica;

• so elektronska oblika diplomskega dela, naslov (slov., angl.), povzetek

(slov., angl.) ter kljucne besede (slov., angl.) identicni s tiskano obliko

diplomskega dela;

• soglasam z javno objavo elektronske oblike diplomskega dela v zbirki

”Dela FRI”.

V Ljubljani, 15. marca 2014 Podpis avtorja:

Zahvaljujem se mentorju doc. dr. Dejanu Lavbicu za pomoc pri izdelavi

diplomskega dela. Zahvaljujem se tudi Mihu Radeju in Milanu Pevcu, ki sta

poskrbela za kar se da nemoteno delovanje storitev na strezniku. Najbolj pa

se zahvaljujem druzini in prijateljem, ki so me podpirali in spodbujali vsa ta

leta studija.

Druzini.

Seznam uporabljenih kratic

• ADB (angl. Android Debug Bridge) - orodje za razhroscevanje naprave

Android,

• ADT (angl. Android Development Tools) - razvojna orodja za An-

droid,

• API (angl. Application Programming Interface) - programski vmesnik,

ki opisuje, kako naj posamezne programske komponente komunicirajo

med seboj,

• CSS (angl. Cascading Style Sheets) - kaskadne stilske podloge za vi-

zualno predstavitev spletnih strani,

• DPI (angl. Dots Per Inch) - stevilo slikovnih pik na inco, mera gostote

pik,

• DOM (angl. Document Obect Model) - specificira prezentacijo in

interakcijo objektov v dokumentih HTML,

• HTML (angl. Hyper Text Markup Language) - oznacevalni jezik za

izdelavo spletnih strani,

• IDE (angl. Integrated Development Environment) - integrirano pro-

gramsko okolje za razvoj aplikacij, ki omogoca pisanje kode, prevajanje

in razhroscevanje,

• JSON (angl. JavaScript Object Notation) - cloveku razumljiv teks-

tovni format za opis podatkov, alternativa XML-ju,

• KPI (angl. Key Performance Indicator) - kljucni kazalnik uspesnosti,

vrsta merjenja uspesnosti,

• MVC (angl. Model-View-Controller) - model-pogled-kontroler, nacin

predstavitve uporabniskega vmesnika,

• PHP (angl. PHP Hypertext Preprocessor) - skriptni programski jezik

za razvoj dinamicnih spletnih strani,

• SDK (angl. Software Development Kit) - razvojni programski paket,

ki omogoca razvoj za dolocene programske pakete, operacijske sisteme,

konzole ali druge platforme,

• USB (angl. Universal Serial Bus) - standard kablov, konektorjev in

protokolov za prenos podatkov med racunalnikom in elektronskimi na-

pravami,

• XML (angl. Extensible Markup Language) - oznacevalni jezik za opis

podatkov v obliki, ki je razumljiva cloveku in racunalniku.

Kazalo

Povzetek

Abstract

1 Uvod 1

2 Uporabljene tehnologije 3

2.1 Mobilne naprave . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Sencha Touch . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Sencha Architect . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Android SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6 AChartEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.7 VMware Player . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.8 Xcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.9 ECSlidingViewController . . . . . . . . . . . . . . . . . . . . . 11

2.10 ios-linechart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.11 Occapi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Razvoj mobilne aplikacije 13

3.1 Mobilna aplikacija . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Realizacija zahtev . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2 Sencha Touch . . . . . . . . . . . . . . . . . . . . . . . 19

KAZALO

3.2.3 Android . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.4 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Primerjava kode . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Sencha Touch . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.3 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Razhroscevanje . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Posodabljanje aplikacije . . . . . . . . . . . . . . . . . . . . . 31

3.6 Podpiranje dodatnih naprav . . . . . . . . . . . . . . . . . . . 33

3.7 Graficno oblikovanje aplikacije . . . . . . . . . . . . . . . . . . 33

3.7.1 Simboli in ikone . . . . . . . . . . . . . . . . . . . . . . 33

4 Primerjava aplikacij 35

4.1 Delovanje aplikacije . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Primerjava razvoja in sredstev . . . . . . . . . . . . . . . . . . 37

4.2.1 Sencha Touch aplikacija . . . . . . . . . . . . . . . . . 37

4.2.2 Domorodni aplikaciji . . . . . . . . . . . . . . . . . . . 38

4.3 Koncna ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Sklepne ugotovitve 41

Literatura 43

Kazalo slik in tabel

2.1 Diagram prehodov med zaslonskimi maskami v programu Xcode 10

2.2 Spletni vmesnik platforme Occapi . . . . . . . . . . . . . . . . 12

3.1 Mobilna naprava, posrednik in streznik Occapi . . . . . . . . . 14

3.2 Domorodni Android meni . . . . . . . . . . . . . . . . . . . . 16

3.3 Sencha Touch meni . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Domorodni iOS meni . . . . . . . . . . . . . . . . . . . . . . . 16

3.5 Graf izdelan z AChartEngine . . . . . . . . . . . . . . . . . . 17

3.6 Sencha Touch graf . . . . . . . . . . . . . . . . . . . . . . . . 17

3.7 Graf izdelan z ios-linechart . . . . . . . . . . . . . . . . . . . . 17

3.8 Android nastavitve . . . . . . . . . . . . . . . . . . . . . . . . 18

3.9 Sencha Touch nastavitve . . . . . . . . . . . . . . . . . . . . . 18

3.10 iOS nastavitve . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.11 Google Maps v Sencha Touch aplikaciji . . . . . . . . . . . . . 32

3.12 Google Street View v Sencha Touch aplikaciji . . . . . . . . . 32

4.1 Primerjave hitrosti zagona aplikacije . . . . . . . . . . . . . . 36

4.2 Cene uporabljenih programov in knjiznic pri razvoju z upo-

rabo standarda HTML5 . . . . . . . . . . . . . . . . . . . . . 38

4.3 Cene uporabljenih programov in knjiznic pri razvoju domoro-

dnih aplikacij . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 Ocene bistvenih faktorjev pri aplikaciji in koncna ocena . . . . 40

KAZALO SLIK IN TABEL

Kazalo programskih kod

2.1 Nepravilna primerjava spemenljivk v JavaScriptu . . . . . . . 4

3.1 Pretvorba casovnega ziga v besedilo v Sencha Touchu . . . . . 28

3.2 Zahteva za prijavo in preverjanje prisotnosti zetona v Sencha

Touchu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Pretvorba casovnega ziga v besedilo v Javi . . . . . . . . . . . 29

3.4 Zahteva za prijavo in preverjanje prisotnosti zetona v Javi . . 29

3.5 Pretvorba casovnega ziga v besedilo v objektnem C-ju . . . . 30

3.6 Zahteva za prijavo in preverjanje prisotnosti zetona v objek-

tnem C-ju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

KAZALO PROGRAMSKIH KOD

Povzetek

Pred pricetkom izdelave mobilne aplikacije se moramo odlociti, kaksen pri-

stop bomo uporabili. Vedno vec je aplikacij, ki so izdelane z uporabo sple-

tnih tehnologij. Za razliko od domorodnih aplikacij nimajo neposrednega

dostopa do sistemskih funkcij in delujejo nekoliko pocasneje, ampak delu-

jejo na vecini operacijskih sistemov danasnjih mobilnih naprav. Skrajsa se

razvojni cas, prav tako pa nam ni potrebno poznati programskih jezikov, v

katerih so napisane domorodne aplikacije.

V diplomskem delu smo izvedli primerjavo med pristopoma razvoja z

izdelavo aplikacije za pregledovanje podatkov platforme Occapi, ki zbira po-

datke iz mnozice naprav in interneta ter jih predstavi na uporabniku prijazen

nacin v obliki kljucnih kazalcev uspesnosti. Podatki so prikazani s tekstov-

nimi seznami in crtnimi grafi.

Razvili smo tri aplikacije. Uporabili smo razvojno okolje Sencha Archi-

tect za razvoj HTML5 aplikacije. Za Android aplikacijo smo uporabili Eclipse

IDE skupaj z Android ADT. Za iOS aplikacijo pa smo uporabili XCode v vir-

tualiziranem okolju. Podrobno smo opisali razvoj v vseh razvojnih okoljih.

Podali smo zahteve in njihove realizacije. Na koncu smo vse tri aplikacije

tudi testirali in podali oceno obeh pristopov razvoja.

Kljucne besede:

platforma Occapi, HTML5, Sencha Touch, Android, iOS, mobilna aplikacija.

Abstract

Before developing mobile application we have to decide which approach to

use. More and more applications are made by using web technologies. Unlike

native applications they do not have direct access to system functions and

they work a bit slower but they work on most operating systems of today’s

mobile devices. Development time is shorter and we do not need to know

programming languages in which native applications are written.

In thesis we made comparison between two approaches of developing ap-

plication for viewing Occapi platform data, which collects data from many

devices and Internet and presents them in a user-friendly manner in form of

key performance indicators. Data is shown with text lists and line graphs.

We developed three applications. We used development enviroment Sen-

cha Touch for developing HTML5 application. For Android application we

used Eclipse IDE with Android ADT. For iOS application we used XCode in

virtualized enviroment. We described in detail the development in all of de-

velopment enviroments. We supplied the requirements and their implemen-

tation. At the end, we tested all three applications and gave an assessment

of the two approaches of development.

Keywords:

Occapi platform, HTML5, Sencha Touch, Android, iOS, mobile aplication.

Poglavje 1

Uvod

Zivimo v obdobju poplave mobilnih naprav. V zadnjih nekaj letih smo prica

ogromnega porasta stevila naprav, kot so pametni telefoni in tablice. Z

vecanjem stevila le-teh in visanjem njihovih zmogljivosti, pa se povecuje tudi

stevilo aplikacij zanje.

Uporabnik si vedno zeli, da bi obstajala aplikacija, ki bi ustregla njegovim

zahtevam. Od nje zeli cim bolj zanesljivo in cim hitrejse delovanje, poleg tega

pa je pozoren tudi na ceno aplikacije. Zeli dobiti najboljse za svoj denar, se

raje pa vidi, da je aplikacija brezplacna.

Kot razvijalci pa se moramo vprasati, ali se nam splaca izdelati aplikacijo

za potrebe uporabnika. Razvijalci morajo upostevati stroske razvoja, kamor

spadajo razvojni cas in cene licenc, ce uporablja orodja za razvoj, za katera

je potrebno placati licencnino. Pri razvoju je potrebno biti tudi pozoren na

zanesljivost, zmogljivost in seveda na prenosljivost aplikacije. Ce razvijamo

aplikacijo za sirsi trg, je dobro, da pokrijemo cim vec razlicnih mobilnih

naprav, le-te pa se zelo razlikujejo. Tudi ce razvijamo aplikacijo za stranko,

bo lahko ta zelela, da deluje na razlicnih mobilnih napravah.

Zelo pogosta mobilna naprava v danasnjih casih poganja operacijski sis-

tem Android. Aplikacije, ki tecejo na njem, so napisane v Javi. Zelo pri-

ljubljen operacijski sistem za mobilne aplikacije je tudi iOS (iPhone, iPad

...), le da so aplikacije zanj napisane v objektnem C-ju (angl. Objective C).

1

2 POGLAVJE 1. UVOD

Dandanes ne smemo spregledati tudi Windows mobilnih naprav, na trgu pa

so se BlackBerry mobilniki.

Ce bi hoteli izdelati aplikacijo, ki bi delovala na vseh teh napravah, bi

imeli zelo veliko dela, saj bi morali za vsako napravo razviti aplikacijo v

drugem jeziku.

Mobilne naprave so iz dneva v dan zmogljivejse. Skoraj vsak od nas s

seboj nosi napravo, ki je skoraj toliko zmogljiva kot stacionarni racunalniki

ali prenosniki. Tako zmogljive naprave tudi odlicno poganjajo spletne br-

skalnike, za katere pa vec ali manj veljajo standardi, ne glede na operacijski

sistem. Ce posposimo, lahko recemo, da razvijemo eno aplikacijo in ta potem

deluje na vseh (na vecini) mobilnih napravah.

Kdaj se odlociti za razvoj aplikacije v HTML5 (angl. Hyper Text Mar-

kup Language) standardu in kdaj se posluziti razvoja v domorodnem (angl.

native) jeziku? Preden se lotimo razvoja aplikacije je potrebno mocno pre-

misliti. S podobno tezavo so se na drugih problemskih domenah ukvarjali

tudi sorodna dela [17, 18, 19], ki prav tako obravnavajo primerjavo klasicnega

razvoja aplikacije z razvojem v standardu HTML5.

V diplomskem delu smo predstavili razvoj aplikacije v vec moznih stan-

dardih in za razlicne mobilne naprave. Razvili smo tri aplikacije, eno z

uporabo standarda HTML5, eno domorodno aplikacijo za Android in eno

domorodno aplikacijo za iOS. V drugem poglavju so opisane tehnologije, ki

smo jih uporabili v casu razvoja. Tretje poglavje predstavlja opredelitev mo-

bilne aplikacije in realizacijo njenih zahtev z uporabo razlicnih pristopov in

razvojnih okolij, cetrto poglavje pa opisuje koncno primerjavo vsakega izmed

pristopov, delovanje posamezne aplikacije in koncno oceno.

Poglavje 2

Uporabljene tehnologije

V nadaljevanju so predstavljena orodja in tehnologije, ki smo jih uporabili

pri izdelavi mobilnih aplikacij.

2.1 Mobilne naprave

Za cim bolj podrobno primerjavo nacinov razvoja je zazeleno imeti razlicne

naprave. Naprave pa naj se ne bi razlikovale samo po tehnicnih specifikacijah

ampak tudi po operacijskem sistemu, ki ga poganjajo.

Pri razvoju in testiranju aplikacij smo uporabili Samsung Galaxy Nexus,

Asus Nexus 7 (2012) in iPod Touch 5. Prvi dve napravi imata namescen

operacijski sistem Android 4.4 KitKat, zadnji pa iOS 7. V casu razvoja so

nam bile naprave v pomoc pri testiranju, saj aplikacija v emuliranem okolju

deluje nekoliko drugace, prav tako pa se klikanje z misko tezko primerja s

pritiskanjem in vlecenjem po zaslonu. Napravi z Androidovim operacijskim

sistemom sta bili nepogresljivi pri testiranju in razhroscevanju, saj aplikacija

v Androidovemu emulatorju deluje bistveno pocasneje. Bistveno vlogo pa so

igrale pri koncnem preizkusanju hitrosti in samem obcutku delovanja.

3

4 POGLAVJE 2. UPORABLJENE TEHNOLOGIJE

2.2 JavaScript

Tako kot PHP (angl. PHP Hypertext Preprocessor) je JavaScript skriptni

jezik za razvoj dinamicnih spletnih strani. Glavna razlika med njima je,

da se PHP program izvaja na strezniku, JavaScript program pa se izvaja

v uporabnikovemu brskalniku. V vseh sodobnih brskalnikih lahko odpremo

okno za razvijalce, kamor ze lahko pisemo kodo JavaScript.

JavaScript je netipiziran jezik, kar pomeni, da nam kot programerjem

ni potrebno dolociti tipa vrednosti, ki jo bo hranila spremenljivka. To je

pozitivna stvar, ker nam ni potrebno pri vsakem deklariranju spremenljivke

dolocati tipa, prav tako lahko eno spremenljivko uporabimo za shranjevanje

vec tipov. Ni potrebno ustvarjati vec funkcij, ki se razlikujejo samo v tipu

parametrov, ampak v funkciji preverimo tip parametra z uporabo typeof.

Negativna stvar netipiziranega jezika pa je otezeno razhroscevanje, saj se

nam lahko kar hitro zgodi, da na primer po nesreci primerjamo objekt z

besedilnim nizom, kar je seveda napacno in bo vedno neresnicno.

var string = "Besedilo";

var object = { value: "Besedilo" };

if(string == object) {

alert("Nemogoce");

}

Programska koda 2.1: Nepravilna primerjava spemenljivk v JavaScriptu

JavaScript dopusca precej svobode, do vseh funkcij in vrednosti lahko

brez tezav dostopamo od kjerkoli, prav tako jih lahko spreminjamo, privatne

spremenljivke ne obstajajo. To lahko privede do tega, da kaksno spremen-

ljivko ali funkcijo po nesreci prepisemo z drugo, ce nismo dovolj pozorni.

2.3. SENCHA TOUCH 5

2.3 Sencha Touch

Sencha Touch [2], v nadaljevanju tudi ST, je knjiznica za JavaScript, ki

omogoca enostavno izdelavo mobilnih spletnih aplikacij, ki izgledajo kot do-

morodne aplikacije. Uporablja standarde HTML5, CSS (angl. Cascading

Style Sheets) in JavaScript. Poenostavi interakcijo z DOM (angl. Docu-

ment Obect Model) objekti, vsebuje veliko pogosto uporabljenih funkcij in

elementov. Podpira mobilne naprave z operacijskim sistemi:

• BlackBerry,

• Android,

• iOS,

• Windows.

Azurni podatki o uradno podprtih operacijskih sistemih in napravah so ob-

javljeni na spletni strani [3]. Knjiznica podpira vecino sodobnih mobilnih

brskalnikov, prav tako pa lahko aplikacije uporabljamo z brskalniki na nami-

znih racunalnikih, kar omogoca hitrejsi razvoj in razhroscevanje.

2.4 Sencha Architect

Sencha Architect [4] je IDE (angl. Integrated Development Environment)

za izdelavo aplikacij Sencha Touch, ki so namenjene mobilnim napravam, in

Ext JS, ki so namenjene namiznemu racunalniku. Vsebuje orodja za izdelavo

graficnega vmesnika, urejevalnik besedila z dokoncevanjem kode in pakiranje

aplikacije za operacijska sistema Android in iOS. Sencha Architect podpira

MVC (angl. Model-View-Controller) pristop razvoja aplikacije. Vsaka apli-

kacija je razdeljena na vec skupin:

• pogledi,

• kontrolerji,


• shrambe,

• modeli,

• ostali viri (predloge CSS, datoteke s kodo, teme).

Pogledi vsebujejo vse vizualne komponente aplikacije, vsaj staticne, dinamicne

pa lahko ustvarimo tudi s kodo. Urejanje pogledov je precej preprosto, upo-

rablja se pristop “povleci in spusti”. Zacetni pogled aplikacije izberemo z

nastavljanjem lastnosti initialView. Za lazji dostop do komponent lahko

dolocimo njihovi lastnosti itemId in id. Pri uporabi id moramo biti pozorni,

saj se v DOM-u ne sme podvojiti. Vsaki komponenti lahko dolocimo tudi

kodo, ki naj se izvede ob dolocenih dogodkih, kot so na primer inicializacija,

prikaz, dotik in sprememba vrednosti, vendar raje celotno kodo zapisemo v

kontrolerje.

S kontrolerji dosezemo locitev pogledov in programske kode. Kontrolerji

vsebujejo akcije, funkcije in reference na komponente. Akcije se izvedejo ob

dogodku neke komponente ali vecih komponent. Ce selektor akcije nastavimo

na: #formId button, lahko izdelamo formo z vec gumbi, ki vsi sprozijo eno

akcijo.

Shrambe sluzijo za enostavnejse nalaganje in predstavitev niza podatkov.

Vsaki shrambi je potrebno dolociti model, v katerem so dolocena vsebovana

polja skupaj z njihovimi tipi. Ce zelimo podatke v shrambi spreminjati in

jih poslati nazaj na streznik, moramo modelu nastaviti lastnost idProperty,

ki mora biti unikatni identifikator. Shramba je mnozica record-ov, katerih

vrednosti polj dobimo z record.get("imePolja") in nastavimo z record-

.set("imePolja", vrednost). Shramba zazna spremembe v record-u,

prav tako zazna dodajanje ali brisanje novega vnosa. Spremembe v shrambi

sinhroniziramo s streznikom z uporabo ukaza store.sync(). Shrambe so

nadvse uporabne za sezname. Vsebujejo funkcije za filtriranje, iskanje in

grupiranje. Vsaka od teh operacij pa se takoj odraza tudi v seznamu.

V novi verziji 3.0 je podprto tudi spreminjanje teme. Podprte teme:

• Sencha,

2.5. ANDROID SDK 7

• Cupertino (za iOS 7),

• Cupertino Classic (za iOS 6 in nizje),

• Mountain View (za Android),

• BlackBerry 10,

• Windows 8.

Aplikacija ob menjavi takoj dobi obliko domorodne aplikacije izbranega ope-

racijskega sistema. Barve in oblike komponent lahko v vsaki temi tudi rocno

spreminjamo. Celoten izgled aplikacije tako lahko bistveno spremenimo ze

samo z dolocanjem dveh barv, to sta $active-color in $base-color.

Izdelava aplikacije je z uporabo Sencha Architecta enostavnejsa kot izde-

lava z rocnim pisanjem kode. Program je dostopen za uporabnike operacij-

skih sistemov Windows, Mac in Linux.

Na voljo imamo 30-dnevno preizkusno razlicico, s katero smo tudi izdelali

aplikacijo. Za nadaljnjo uporabo pa je potrebno za Sencha Architect odsteti

399.00 ameriskih dolarjev. Aktualne cene in ponudbe so dostopne na trgovini

Sencha Architect [5].

2.5 Android SDK

Android SDK [6] (angl. Software Development Kit) je skupek vseh potrebnih

razvojnih orodij za izdelavo Android aplikacije. Paket vkljucuje:

• Eclipse + vticnik ADT (angl. Android Development Tools),

• platformna orodja za Android,

• najnovejso razlicico Androida,

• najnovejso razlicico sistemske slike Androida za emulator.


Android SKD uporablja programski jezik Java. Pri razvoju ne potrebujemo

fizicne naprave, ampak lahko uporabimo prilozen emulator. Kar hitro pa smo

ugotovili, da deluje emulator zelo pocasi in smo za testiranje in razhroscevanje

uporabljali fizicno napravo, priklopljeno preko kabla USB (angl. Universal

Serial Bus).

Vsak Android projekt je razdeljen na mape:

• src - vsebuje programsko kodo Java;

• libs - kamor vstavimo dodatne knjiznice;

• res - kamor vstavimo razlicne vire, po vecini so to datoteke .xml; vse-

buje mape:

– anim - vsebuje opis animacij;

– drawable - vsebuje slike, stile seznamov, gumbov in ostalih kom-

ponent;

– layout - kjer so doloceni pogledi, prav tako pa izgled celic seznama;

– menu - vsebujejo elemente spustnih seznamov;

– values - tu se dolocijo staticni napisi, ki se uporabijo v pogledih,

barve, teme;

– xml - mapa za splosne datoteke .xml, vanjo smo shranili definicijo

nastavitev.

Android SDK deluje na operacijskih sistemih Windows, Mac in Linux.

2.6 AChartEngine

Knjiznica AChartEngine [7] omogoca risanje razlicnih grafov, kar ni podprto s

strani Android SDK, razen ce bi to implementirali sami z risanjem preprostih

likov. Knjiznica omogoca preprosto predstavitev grafikonov v obliki tock, crt,

stolpcev, tortnih diagramov in podobno. Omogoca tudi precej oblikovnih

nastavitev.

2.7. VMWARE PLAYER 9

2.7 VMware Player

Ker si ne lastimo strojne opreme, na kateri bi deloval OS X, smo morali ta

operacijski sistem virtualizirati. V ta namen smo uporabili program VMware

Player [8]. Program ustvari navidezno okolje, ki deluje kot locena strojna

oprema. Omejimo ji velikost diska, pomnilnika in procesorsko moc.

2.8 Xcode

Xcode je prav tako IDE, v katerem lahko razvijamo aplikacije za iOS in OS

X. V operacijskih sistemih OS X se Xcode nalozi preko programa Appstore.

Aplikacije se razvija v objektnem C-ju. Za razliko od Sencha Architecta

in Android SDK-ja, kjer je viden en pogled naenkrat, imamo tu eno veliko

povrsino imenovano “Storyboard”, na kateri so razvidni vsi pogledi. Le-ta je

prikazana na sliki 2.1. To se nam zdi bolj uporabno, saj je takoj razvidno,

kako se pogledi povezujejo med seboj. Za udoben pregled pa je potrebno

imeti precej visoko resolucijo zaslona, saj se pri nizki ne vidi kaj dosti. Tudi

samo logicno povezovanje pogledov je zelo intuitivno. Ce hocemo ob dotiku

neke celice v seznamu odpreti nov pogled, samo z misko povlecemo iz celice na

nov pogled. Ce hocemo ob prehodu kaj postoriti, kodo zapisemo v funkcijo:

- (void) prepareForSegue:(UIStoryboardSegue *)segue

sender:(id)sender {

/* ... */

}

Uporabna zadeva, ki jo lahko naredimo pri urejanju pogledov, so tudi

staticni seznami, ki graficno niso podprti ne v Sencha Architectu ne v Android

SDK-ju.

Vsakemu pogledu lahko dolocimo prirejen kontroler. Koda je zapisana v

dveh datotekah, v eni zaglavni datoteki s koncnico .h, ki vsebuje deklaracije

in mikro definicije, ter v datoteki s koncnico .m, ki vsebuje izvorno kodo.


Pri preizkusanju in razhroscevanju aplikacije smo uporabljali emulator,

nad katerim smo bili zelo pozitivno preseneceni, saj je deloval zelo hitro, kot

bi bila naprava fizicna. Za razliko od Sencha Architecta in Android SKD-ja

pa Xcode deluje samo na operacijskem sistemu OS X. Program je, kljub temu

da smo OS X virtualizirali, deloval presenetljivo tekoce.

Slika 2.1: Diagram prehodov med zaslonskimi maskami v programu Xcode

2.9. ECSLIDINGVIEWCONTROLLER 11

2.9 ECSlidingViewController

Na iOS-u drsni meni ni podprt s strani sistema. V ta namen smo uporabili

zunanjo odprtokodno knjiznico ECSlidingViewController [14], katerega smo

malce dodelali. Meni se od ostalih dveh, pri Sencha Touch in aplikaciji za

Android, razlikuje po tem, da se za prikaz odmakne glavni pogled, namesto

da bi se meni pojavil cez glavni pogled.

2.10 ios-linechart

Tako kot pri Androidu, smo tudi pri iOS-u uporabili knjiznico za izdelavo gra-

fov, ker to sistemsko ni podprto. Za razliko od AChartEngine, ios-linechart

podpira ustvarjanje samo crtnih grafov. Izgled grafa pa se skoraj popolnoma

ujema s tistim pri spletnem vmesniku Occapi.

2.11 Occapi

Platforma Occapi [1] na najnizjem nivoju zbira podatke iz mnozice naprav

kot so senzorji, omrezne naprave, merilniki, terminalna oprema in druge na-

prave. Te podatke obogati s podatki s spleta in drugih baz ter z uporabo

naprednih analiz na podlagi strojnega ucenja izboljsa uporabno vrednost po-

datkov. Rezultate predstavi s KPI-ji (angl. Key Performance Indicator) na

uporabniku razumljiv nacin v obliki vizualnih podatkov kot so crtni grafikoni

in seznami.

Spletna aplikacija platforme Occapi je bila ze razvita. Glavni pogled je

viden na sliki 2.2. To smo vzeli za izhodiscni izgled nase aplikacije.


Slika 2.2: Spletni vmesnik platforme Occapi

Poglavje 3

Razvoj mobilne aplikacije

To poglavje opisuje zastavitev funkcionalnosti aplikacije, podroben opis po-

stopkov, tezav in resitev v posameznem IDE in primerjavo med njimi.

3.1 Mobilna aplikacija

Za primerjavo razlicnih pristopov razvoja mobilne aplikacije smo morali naj-

prej dolociti, kaksno aplikacijo bomo izdelali. Odlocili smo se, da bomo iz-

delali mobilno aplikacijo za spremljanje podatkov platforme Occapi. Spletni

vmesnik za pregledovanje v realnem casu ze obstaja, a ni uporaben na mo-

bilnih napravah zaradi prevelike zahtevnosti in postavitve pogledov. S tem

namenom smo izdelali aplikacijo, ki omogoca vse bistvene funkcionalnosti kot

jih ima spletni vmesnik, le da so le-te dostopne na mobilnih napravah.

Podatki, ki jih potrebuje aplikacija za delovanje, so dostopni preko API

(angl. Application Programming Interface). Ker smo izdelali tudi HTML5

aplikacijo, smo se odlocili, da bodo datoteke zanjo na spletnemu strezniku

PHP in ne na napravi sami. Tako je mogoce enostavnejse popravljanje apli-

kacije brez ponovnega nalaganja na napravo. Povezava med komponentami

je vidna na sliki 3.1.

13

14 POGLAVJE 3. RAZVOJ MOBILNE APLIKACIJE

Uporabnik Posrednik Occapi

Podatkovni strežnikz API dostopom

Podatkovni strežnikz API dostopom

PHP strežnik s SenchaTouch aplikacijo

PHP strežnik s SenchaTouch aplikacijo

Mobilna napravaz aplikacijo

Mobilna napravaz aplikacijo

Podatki

Sencha Touch aplikacija

Podatki

Slika 3.1: Mobilna naprava, posrednik in streznik Occapi

Aplikacija je morala podpirati:

• prijavo v sistem,

• prikazovanje KPI-jev v obliki tekstovnih seznamov in crnih grafikonov,

• avtomatsko osvezevanje KPI-jev,

• uporabniske nastavitve.

Zaradi manjsega zaslona in nizjih zmogljivosti mobilnih naprav v pri-

merjavi z namiznimi racunalniki smo takoj dolocili omejitev za prikaz enega

KPI-ja naenkrat, to je en grafikon ali tekstovni seznam.

Danes poznamo vec nacinov razvoja:

• domorodni, kjer aplikacija deluje na operacijskem sistemu, za katerega

je bila razvita;

• HTML5, kjer aplikacija deluje v vecini danasnjih brskalnikov;

• hibridni, v katerem domorodna aplikacija z uporabo komponente br-

skalnika prikaze spletno vsebino.

Ker smo primerjali razlicne nacine razvoja, smo morali pravzaprav razviti vec

aplikacij. Izdelali smo tri aplikacije. Najprej smo razvili aplikacijo z uporabo

3.2. REALIZACIJA ZAHTEV 15

standarda HTML5. Pri tem smo uporabili IDE Sencha Architect. Kasneje

smo izdelali domorodno aplikacijo za Android in nazadnje se domorodno

aplikacijo za iOS. Sencha Architect nam ponuja pakiranje v domorodni ovoj

in tako omogoca dostop do raznih funkcionalnosti operacijskega sistema, ki

samemu brskalniku niso dostopne. Teh funkcionalnosti v nasem primeru

nismo uporabljali in zato tega nacina nismo obravnavali kot hibridni. V iOS-

ovemu Safariju pa je mogoce ustvariti bliznjico aplikacije na namizje, kjer se

ob zagonu nalozi spletna aplikacija brez Safarijevih orodnih vrstic, tako da

pakiranje aplikacije ni bilo potrebno.

3.2 Realizacija zahtev

Zastavili smo principe delovanja in izgleda aplikacije, ki pa se v casu razvoja

niso bistveno spreminjali. Zeleli smo, da bi bil izgled aplikacije podoben

spletnemu vmesniku za platformo Occapi, prav tako pa bi aplikacija v vseh

nacinih razvoja delovala in izgledala podobno, pri tem pa bi uporabili cim

vec sistemskih komponent.

Za prvi pogled smo izdelali prijavno masko z logotipom, vnosnimi polji in

gumbom za prijavo. Privzeto se shrani samo elektronska posta prijavljenega

uporabnika, v nastavitvah pa se lahko nastavi tudi shranjevanje gesla in

avtomatsko prijavljanje.

Pri uspesni prijavi se pojavi pogled s seznamom vseh skupin KPI. V tem

pogledu smo na levi strani izdelali drsni meni, ki je poznan uporabnikom

Androida in iOS-a. Izgled menija je viden na slikah 3.2, 3.3 in 3.4. Meni se

lahko odpre z dotikom tipke na levi strani orodne vrstice ali s potegom z leve

proti desni.


Slika 3.2: Domorodni

Android meni

Slika 3.3: Sencha Touch

meni

Slika 3.4: Domorodni

iOS meni

Z izbiro skupine KPI preidemo v pogled s seznamom KPI-jev. Ti imajo

na desni strani ikono, ki pove, ali je KPI predstavljen kot seznam ali crtni

graf.

Z izbiro prvega se pomaknemo na tekstovni seznam, iz katerega so raz-

vidni datum in cas vnosa, sporocilo in pomembnost, ki je dolocena z barvo.

Rdeca barva pomeni, da je sporocilo bolj pomembno. Ti KPI-ji imajo med

drugim lahko tudi podatke o zemljepisni dolzini in sirini ter radiju, ampak

takih KPI-jev v nasem primeru nismo zasledili. Podprli smo avtomatsko

osvezevanje seznamov. Casovne premore med osvezevanji je mogoce spreme-

niti v nastavitvah, prav tako pa lahko osvezevanje popolnoma onemogocimo.

Ce se vrnemo nazaj in izberemo drugi tip KPI-ja, se pomaknemo v po-

gled s crtnim grafom, ki lahko vsebuje vec serij tock. Abscisna os predstavlja

datum in cas, ordinatna pa vrednost posamezne serije KPI-ja. Graf vsebuje

tudi legendo, iz katere so razvidne prisotne serije. Pri grafu smo se odlocili

uporabiti izgled, ki bo cim bolj podoben tistemu s spletnega vmesnika plat-

forme Occapi. Za tocke smo uporabili kroge brez polnila, ki so med seboj


povezani s crto. Barve osi, ozadja in tock smo prav tako uporabili skladno s

spletnim vmesnikom. Tako kot seznami se tudi grafi avtomatsko osvezujejo.

Slika 3.5: Graf izdelan z

AChartEngine


graf

Slika 3.7: Graf izdelan z

ios-linechart

Za razliko od spletnih strani je pri mobilnih aplikacijah ponavadi po-

trebna samo enkratna prijava, kar smo tudi realizirali. V drsnem meniju

smo omogocili tudi opcijo za pregled informacij o aplikaciji, nastavitve in

odjavo. Izgled pogleda z nastavitvami je viden na slikah 3.8, 3.9 in 3.10. V

nastavitvah smo podprli:

• shranjevanje uporabniskih vstopnih podatkov,

• avtomatsko prijavo v sistem ob zagonu aplikacije,

• vklop in izklop avtomatskega osvezevanja seznamov in grafov,

• casovni premor med posamezno osvezitvijo,

• spremembo spletnega naslova za API.


Slika 3.8: Android na-

stavitve


nastavitve

Slika 3.10: iOS nastavi-

tve

3.2.1 API

Platforma Occapi ima API, ki nam omogoca dostop do funkcij platforme iz

drugih aplikacij. API vse podatke vraca v obliki JSON (angl. JavaScript

Object Notation). Podpira naslednje funkcionalnosti:

• prijavo z elektronskim naslovom in geslom, odgovor vsebuje zeton, ki

se uporablja pri vseh naslednjih poizvedbah;

• prenos skupin KPI-jev;

• prenos KPI-jev, ki spadajo pod podano skupino, katere ime podamo

kot parameter;

• prenos seznama alarmov za vse KPI-je;

• prenos serij dvodimenzionalnih tock za posamezen KPI.


3.2.2 Sencha Touch

Razvoja smo se najprej lotili v Sencha Architectu, ker nam je od uporabljenih

programskih okolij slednji se najbolj domac. Ze takoj na zacetku pa smo

naleteli na problem pri dostopu do streznika. Pri poskusu prijave v sistem

smo naleteli na napako:

XMLHttpRequest cannot load http://212.235.191.163:8080...

Origin http://localhost:8888...

is not allowed by Access-Control-Allow-Origin.

To se zgodi, ker gre za zahtevo, ki ni v domeni trenutne strani. Brskalnik

ne dovoli, da bi zahtevali stran, ki ni v isti domeni kot trenutna stran. To

lahko v brskalniku Chrome zaobidemo tako, da ga zazenemo s parametrom

--disable-web-security. To pa je bila samo zacasna resitev v samem

zacetku razvoja.

Nato smo namesto zahteve Ajax uporabili zahtevo JsonP, ki pa je ome-

jena samo na metodo GET (branje). Takoj smo naleteli na nov problem, ker

streznik ne podpira formata zahteve JsonP. Ceprav se nam je uspelo prijaviti,

brskalnik ni razumel odgovora. Pri zahtevi JsonP mora vsaka zahteva vse-

bovati parameter callback in ce je ta enak Ext.data.JsonP.callback123,

potem mora streznik vrniti podatke v obliki:

Ext.data.JsonP.callback123({

token : "9a479be6f0730e77e08b372633ac0baa",

status : true,

message : "Login successful"

})

Kasneje smo napisali preprosto skripto PHP, ki je sluzila kot posrednik.

Skripta je sprejemala zahteve aplikacije, prenesla podatke s streznika in jih

posredovala aplikaciji. Ker smo pri skripti dolocili, da lahko sprejema zah-

teve iz vseh domen, ni bilo vec tezav pri prenosu podatkov, edino, kar se je

spremenilo, je bila povecana latenca, ki jo je povzrocil posrednik. Nazadnje


smo posegli v API in v glave odgovorov dodali navodila, da se lahko zahteve

berejo iz poljubne domene.

Za glavni pogled aplikacije smo uporabili komponento Ext.navigation.-

View, v katero dodajamo poglede programsko s klicem metode push, ki ji po-

damo pogled in besedilo naslova. Pri pogledu z menijem smo uporabili kom-

ponento Ext.Container, ki ima parameter za razporeditev otrok nastavljen

na card. Tako je viden samo eden od pogledov, poglede pa preklapljamo s

klicem metode setActiveItem. Meni smo izdelali s komponento Ext.Sheet,

ki je plovna in modalna. Vsebuje seznam, ki smo ga stilsko prilagodili, da je

bolj podoben Androidovemu drsnemu meniju. Seznam uporablja shrambo,

v kateri so staticni vnosi. Vsak vnos vsebuje besedilo naslova, identifikator

pogleda, barvo ikone in crko, ki se uporablja za prikaz ikone.

Prehodi med pogledi so animirani. Zeleli smo uporabiti identicen prehod

pri vseh treh aplikacijah. Navigacijski komponenti smo lastnost animation

nastavili na slide. Pogledom, ki pa se ne uporabljajo v navigacijski kompo-

nenti, pa je bilo potrebno nastaviti animacijo za prikaz in skrivanje:

hideAnimation: {

type: "slideOut",

direction: "right"

},

showAnimation: {

type: "slide",

direction: "left"

}

Za prenos podatkov preko razlicnih pogledov smo uporabili globalno spre-

menljivko App, ki smo jo definirali ob zagonu aplikacije. Tako se zeton, ki ga

prejmemo pri prijavi, shrani in ga lahko uporabljamo povsod v aplikaciji:

var t = App.user.token;

Ker API vraca podatke v obliki JSON, je to idealno za JavaScript. Prav

tako ni bilo nobene potrebe po obdelavi podatkov, vse odgovore smo lahko


neposredno uporabili, le pri prijavi in grafih je bilo potrebno rocno izlusciti

podatke. Tu smo uporabili zahtevo Ajax in odgovor v obliki niza pretvorili v

objekt, kar lahko storimo s klicem metode Ext.decode(odgovor). Pri sezna-

mih smo uporabili pristop s shrambo, ki smo ji dolocili parameter naslova,

s katerega prenese podatke, ter model s primernimi polji in njihovimi tipi.

Seznami, ki uporabljajo shrambe, se sami osvezijo ob spremembi podatkov.

Vse, kar je bilo potrebno dolociti, je bila predloga celice seznama, s katero

smo dolocili, kateri podatki naj se pokazejo, in stil, kjer je bilo to potrebno.

Zahteva za prenos podatkov s streznika se izvede ob klicu shrambine metode

load, tako smo pri avtomatskem osvezevanju samo ponavljali klic te metode.

Klic metode z zamikom je zelo preprost. Uporabili smo Ext.defer, podali

metodo, ki naj se izvede, casovno zakasnitev v milisekundah, po potrebi pa se

obmocje (angl. scope) in argumente. Pri podani metodi smo na koncu opra-

vili ponovni klic le-te, s cimer smo dosegli ponavljanje osvezevanja. Metoda

Ext.defer vrne identifikator, ki smo ga uporabili za prekinitev osvezevanja

z uporabo brskalnikove metode clearTimeout(identifikator).

Grafi za vir podatkov prav tako uporabljajo shrambe. Pri modelih ni

podprt tip objekta, zato nismo mogli neposredno uporabiti shrambe, ker so

podatki o tockah grafa globlje v objektovi hierarhiji. Podatke smo s streznika

prenesli z zahtevo Ajax, nato smo izluscili potrebne podatke o tockah in jih

rocno dodali v shrambo. Ker abscisna os predstavlja cas, smo uporabili

casovni tip osi, ki je ze podprt, potrebno je bilo samo dolociti format prikaza

casa. S samim stilom ni bilo nobenih tezav, hitro smo izgled priblizali grafu

s spletnega vmesnika.

Sencha Touch sam po sebi ne ponuja uporabniskih nastavitev. Izdelali

smo pogled s potrebnimi polji za nastavitve. Njihove vrednosti smo kot

JSON shranili v piskotek brskalnika. Alternativa bi bila uporaba brskalnikove

lokalne shrambe ali baze SQLite.

Sencha Architect je vseboval vse komponente, ki so bile potrebne za reali-

zacijo zahtev, tako da smo aplikacijo izdelali brez uporabe dodatnih knjiznic.

Logotip, ikona za pomik naprej v seznamu ter ikoni za seznam in graf so edine


stvari, ki niso izdelane v Sencha Architectu. Za izdelavo nase aplikacije je bil

ta nacin razvoja popoln.

3.2.3 Android

Za prenos podatkov med pogledi smo na zacetku uporabili pristop, ki je

znacilen za Android, preko dodatkov (angl. extras). Pri zacetni verziji smo

najprej prenesli podatke in jih preko dodatkov posredovali naslednjemu po-

gledu. Pri seznamu alarmov, kjer gre za malce vecjo kolicino podatkov, smo

naleteli na napake, kot so sesutje aplikacije in prazni seznami, ki pa nam jih

ni uspelo takoj odkriti. Ugotovili smo, da obstaja neka zgornja meja kolicine

podatkov, ki se lahko prenasa preko dodatkov, ki smo jo ocitno prekoracili.

Nato smo se lotili podobnega pristopa kot pri Sencha Touch aplikaciji. Iz-

delali smo razred App, ki je razsirjal razred Application, ki smo mu dodali

spremenljivke za hranjenje podatkov. Tako smo lahko prav tako od povsod

dostopali do zetona, ki ga prejmemo ob prijavi:

String t = ((App)getApplicationContext()).getUser().getToken();

Za razliko od Sencha Architecta je bilo potrebno vse podatke, ki smo

jih prejeli s streznika pretvoriti v obliko, ki jo lahko uporabimo v programu.

Uporabili smo za to namenjeno knjiznico JSON-Simple [11]. Sprva je vse

delovalo hitro, ko pa je bilo potrebno 1 MB velik niz s podatki pretvoriti

v objekt, je operacija new JSONObject(niz) trajala 5 sekund. Na spletnih

forumih smo zasledili, da naj bi bila Googlova knjiznica Gson [12] pri tem

hitrejsa. Izkazalo se je, da to drzi, vendar je pretvorba se vedno trajala 4 se-

kunde. Nazadnje smo uporabili knjiznico Jackson [13], ki naj bi bila pri tem

najhitrejsa. Ta knjiznica pa sploh ni podpirala pretvarjanja niza v JSON.

Namesto tega smo morali izdelati javanske razrede, skladne s tistimi v pre-

jetih odgovorih. Pri grafih je bilo to precej nerodno, saj smo morali izdelati

tri razrede, da smo prisli do podatkov o tockah. Knjiznica je pri pretvorbi

za parameter zahtevala vhodni tok in vrnila podatke kot javanski objekt.

S takim pristopom pa je bila razlika obcutna, saj se je pretvorba izvedla v


trenutku. Prav tako smo lahko ta javanski objekt neposredno uporabili v

adapterju za seznam.

Vse prenose podatkov s streznika smo izvedli asinhrono, ker bi bila drugace

aplikacija med prenosom neodzivna. Pri Sencha Touch aplikaciji se ze vsi pre-

nosi podatkov izvajajo asinhrono, zato za prenose le-teh nismo potrebovali

veliko casa. Tu pa smo za vsak prenos podatkov ustvarili razred, ki razsirja

razred AsyncTask. Metodi doInBackground podamo seznam parametrov, ki

so potrebni za prenos podatkov, po koncanem prenosu pa s stavkom return

posredujemo podatke metodi onPostExecute, kjer jih uporabimo za pred-

stavitev v aplikaciji (posodobimo seznam ali graf). Avtomatsko osvezevanje

smo izvedli z uporabo razreda Handler s klicem metode postDelayed, kjer

v argumentih podamo metodo, ki naj se izvede, in casovni zamik v milise-

kundah.

Android podpira izdelavo navigacijskega drsnega menija (angl. Naviga-

tion Drawer). Meni za prikazovanje pogledov ne uporablja aktivnosti, ampak

delcke (angl. Fragments). Pri seznamih se je to izkazalo za zelo uporabno za-

devo. Na zacetku smo za vsak seznam ustvarili novo aktivnost, v pripadajoci

datoteki .xml smo dodali komponento in sicer seznam in nato se datoteke za

definiranje izgleda posamezne celice. Prav tako je potrebno za vsak seznam

izdelati se adapter, ki napolni vsako celico z vsebino. Z uporabo delcka pa je

bilo potrebno izdelati razred, ki je razsirjal ListFragment, in ob njegovem

nastanku dolociti adapter s klicem metode setListAdapter(adapter). S

tem smo se znebili nepotrebne datoteke .xml.

Ostali pogledi, ki se ne uporabljajo v meniju, se povezujejo samo s pomocjo

programskega klica. Na mestu, kjer zelimo prikazati zeljen pogled, izvedemo:

Intent intent = new Intent(KpisActivity.this,

ChartActivity.class);

startActivity(intent);

overridePendingTransition(R.anim.right_to_left,

R.anim.right_to_left_exit);


Potrebno je bilo tudi definirati podrobnosti animacij v datotekah .xml. Pri-

mer definiranja animacije za prikaz naslednje aktivnosti (datoteka right -

to left.xml):

<set xmlns:android="http://schemas.android.com/apk/res/android"

android:shareInterpolator="false">

<translate

android:fromXDelta="100%"

android:toXDelta="0%"

android:fromYDelta="0%"

android:toYDelta="0%"

android:duration="250" />

</set>

Android SDK sam po sebi ne podpira izdelave grafov, zato smo upora-

bili knjiznico AChartEngine. Abscisna os grafa predstavlja cas, kar nam ni

povzrocalo tezav, ker knjiznica to podpira. Namesto navadnih serij tock smo

ustvarili casovne serije (new TimeSeries(nazivSerije)). Seriji preprosto

podamo tocko s klicem metode serija.add(cas, y). Kar knjiznica ne pod-

pira, je barva polnila tock. Kljub temu pa smo dosegli izgled, ki je zelo

podoben grafu platforme Occapi.

Nastavitve, kakrsne podpira Android, so bile za nase potrebe uporabne.

Nismo uporabili nastavitev, ki se jih ustvari preko carovnika, ker bi nastale

nepotrebne datoteke. Ustvarili smo aktivnost za nastavitve in .xml datoteko,

v kateri so definirane skupine in njihove nastavitve. Na zalost v nastavitvah ni

podprt drsnik, zato smo za nastavitev casovnih zamikov uporabili tekstovno

polje, ki smo mu dolocili, da lahko sprejema samo stevilke in mu omejili

dolzino na dve stevki.

Pri razvoju v Android SDK smo uporabili se najvec knjiznic izmed vseh

treh nacinov, to pa zaradi tezav pri pretvarjanju JSON objektov. Uporabna

funkcija razvojnega okolja Eclipse je bilo ustvarjanje ikon, tako jih ni bilo

potrebno ustvariti v drugem programu ali prenasati s spleta. Kar nas je


motilo, je pocasnost emulatorja, zato smo namesto tega uporabili fizicno

napravo, kar je olajsalo preizkusanje in razhroscevanje aplikacije.

3.2.4 iOS

Domorodno aplikacijo za iOS smo razvijali prvic, zato nam je vzela najvec

casa. Pri prenosu podatkov s streznika smo uporabili delegate. Ustvarili

smo datoteko API.m, v kateri smo napisali celotno kodo za prenos podatkov

s streznika. Na mestih, kjer potrebujemo podatke s streznika, poklicemo

metodo iz te datoteke. Pri prijavi klic iz kontrolerja izgleda takole:

API *api = [[API alloc] init];

api.delegate = self;

[api login:tfEmail.text :tfPassword.text];

Metoda login prenese podatke s streznika, nato pa jih posreduje prijavnemu

kontrolerju s klicem njegove metode [self.delegate loginCompleted:YES

: message]. S tem pristopom smo dosegli bolj pregledno kodo, saj je koda

za dostop do streznika locena od ostale kode.

Prav tako kot pri Androidu, smo morali tudi tu vse podatke prejete s

streznika pretvoriti v obliko, ki smo jo lahko uporabili v aplikaciji. Prejete

podatke smo v slovar NSDictionary pretvorili s klicem metode [NSJSON-

Serialization JSONObjectWithData:podatki options:kNilOptions

error:&error]. Pri uporabi nismo zasledili, da bi bilo pretvarjanje pocasno,

kot je bilo na Androidu, zato ni bilo potrebno izdelati razredov za vse objekte

JSON. Vrednost dobimo iz slovarja z uporabo metode [json objectForKey:-

kljuc].

Prenasanja podatkov med pogledi smo se lotili na nacin, ki smo ga upo-

rabili pri prejsnjih dveh aplikacijah. Ustvarili smo edinski (angs. singleton)

globalni razred, ki smo ga uporabili v vseh kontrolerjih. Tako smo lahko

zeton, ki ga prejmemo ob prijavi, uporabili na naslednji nacin:

DataClass *d = [DataClass instance];

NSString *t = d.token;


Za razliko od prejsnjih dveh aplikacij smo tu za izdelavo drsnega menija

morali uporabiti dodatno knjiznico, ker tega iOS sam po sebi ne podpira.

Uporabili smo knjiznico ECSlidingViewController.

Za risanje grafov smo prav tako uporabili dodatno knjiznico in sicer ios-

linechart. Izmed vseh treh aplikacij je bilo tu potrebno najvec dela, vendar

je bilo pri tem tudi vec nadzora in tako je graf najbolj podoben tistemu iz

platforme Occapi. Knjiznica za abscisno os ne podpira casa, ampak samo

decimalna stevila z enojno natancnostjo (float), zato smo morali to imple-

mentirati sami. Problem se je pojavil, ker je dobljen cas zapisan v obliki

casovnega ziga (stevilo milisekund od leta 1970), kar se ne da shraniti kot

float. Tip float je 32-bitno decimalno stevilo, pri katerem se uporablja 1

bit za predznak, 8 za eksponent in 23 za mantiso, torej imamo 23 bitov za

natancnost. Casovni zig do danasnjega dne pa za zapis potrebuje najmanj

41 bitov, kar pomeni, da manjka 18 bitov za doseganje take natancnosti, ozi-

roma 8 bitov, ker smo stevilko delili s 1000, saj v nasem primeru milisekunde

lahko zanemarimo. Tezavo smo resili tako, da smo za referenco vzeli naj-

manjsi casovni zig, ki smo ga potem odsteli od vseh vrednosti. Na ta nacin

se je stevilo potrebnih bitov na primer zmanjsalo na 17 bitov, ce so tocke

v razponu enega dneva, zato smo lahko te vrednosti uporabili v grafu. Pri

prikazu dejanske vrednosti v grafu pa smo dodali vrednost najmanjsega ziga

in nato pretvorili v uporabniku razumljivo obliko.

Avtomatsko osvezevanje smo izvedli z zakasnjenim klicem metode za pre-

nos podatkov o alarmih oziroma grafih. Pri tem smo uporabili perform-

Selector, ki ji podamo metodo, ki naj se izvede, in casovni zamik v sekun-

dah.

Pogled z nastavitvami smo izdelali sami, ker tako omogoca vec kontrole,

poleg tega pa je bila standardna lokacija nastavitev pri iOS-u, skozi sistem-

ske nastavitve, nesprejemljiva, ker smo hoteli doseci cim vecjo podobnost

med vsemi tremi aplikacijami. Izdelava staticnih seznamov je bila tu se

najlazja. Preprosto smo nastavili stevilo skupin, skupaj z njihovim nazivom,

dodali celice in vanje vstavili potrebne elemente kot so labele, stikala, be-

3.3. PRIMERJAVA KODE 27

sedilna polja in drsniki. Ob odpiranju pogleda smo nastavili vsebine polj

glede na pripadajoco vrednost v nastavitvah. Pri spremembi vsebine polj

pa se spremenjene vrednosti zapisejo v nastavitve. Vrednost posamezne na-

stavitve preberemo z ukazom [[NSUserDefaults standardUserDefaults]

objectForKey: IME NASTAVITVE], shranjevanje nastavitev pa je prav tako

preprosto. Za privzete vrednosti nastavitev smo ustvarili datoteko default-

Prefs.plist, ki vsebuje kljuce in vrednosti v formatu XML (angl. Exten-

sible Markup Language). Privzete nastavitve je bilo potrebno pri vsakem

zagonu aplikacije registrirati.

NSString *defaultPrefsFile = [[NSBundle mainBundle]

pathForResource:@"defaultPrefs" ofType:@"plist"];

NSDictionary *defaultPreferences = [NSDictionary

dictionaryWithContentsOfFile:defaultPrefsFile];

[[NSUserDefaults standardUserDefaults]

registerDefaults:defaultPreferences];

3.3 Primerjava kode

Naredili smo kratko primerjavo programske kode iz vsakega razvojnega oko-

lja. Pri primerjavi smo bili se posebej pozorni na obseg in razumljivost kode.

Celotne izvorne kode vseh treh aplikacij so dostopne na spletni strani

GitHub [20, 21, 22].

3.3.1 Sencha Touch

Tu je koda se najmanj obsezna in tudi najbolj razumljiva. V programski

kodi 3.1 je razvidna pretvorba casovnega ziga v datum, ki vsebuje leto, mesec

in dan. Zahteva podatkov s streznika, razvidna v programski kodi 3.2, se

izvede asinhrono, ob uspesnem prenosu pa se izvede funkcija podana kot

parameter success, v kateri se prejeti tekst pretvori v objekt.


var date = new Date(timestamp);

return Ext.Date.format(date, "Y-d-m");

Programska koda 3.1: Pretvorba casovnega ziga v besedilo v Sencha Touchu

Ext.Ajax.request({

url: settings.get("apiUrl") + "login/" + user + "/" + pass,

success: function(response, opts) {

var obj = Ext.decode(response.responseText);

if (obj.token) { /* ... */ }

}

});

Programska koda 3.2: Zahteva za prijavo in preverjanje prisotnosti zetona v

Sencha Touchu

Za vecino klicev funkcij se uporablja poimenovane parametre (angl. na-

med parameters), kar lahko vidimo v programski kodi 3.2. Funkciji pravza-

prav podamo objekt, ki vsebuje parametre, v nasem primeru url in success.

Priporocljivo je vsak parameter zapisati v novo vrstico, da dosezemo pregle-

dno programsko kodo.

3.3.2 Android

Koda se po obseznosti in razumljivosti bistveno ne razlikuje od prejsnje,

vendar moramo upostevati, da smo morali pred tem ustvariti razred User,

ki vsebuje vse potrebne spremenljivke ter njihove set in get metode. Prav

tako je potrebno ustvariti asinhrono opravilo, drugace bi bila aplikacija med

prenosom neodzivna.

3.3. PRIMERJAVA KODE 29

Date date = new Date(timestamp);

return new SimpleDateFormat("yyyy-MM-dd", Locale.US)

.format(dateTime);

Programska koda 3.3: Pretvorba casovnega ziga v besedilo v Javi

public class Login extends AsyncTask<Void, String, Void> {

@Override

protected Void doInBackground(Void... params) {

String apiUrl = sharedPref.getString(

SettingsActivity.KEY_PREF_API_URL,

C.DEFAULT_API_URL);

URL url = new URL(C.apiURL + "login/"

+ mEmail + "/" + mPassword);

ObjectMapper mapper = new ObjectMapper();

User user = mapper.readValue(new InputStreamReader(

url.openStream()), User.class);

if(user.getToken()) { /* ... */ }

}

}


Javi

3.3.3 iOS

Koda je tu se najbolj obsezna, ni pa bistvene razlike v razumljivosti. Pre-

tvarjanje casovnega ziga v datum (vrstica 3.5) tu zahteva dodatno deljenje

s 1000, podamo ga metodi namesto konstruktorju datuma in potrebno je

ustvariti formatter. Pri prenosu podatkov s streznika (vrstica 3.6) so klici

metod nekoliko daljsi kot pri Androidu, ker zahtevajo vec parametrov. Ce

primerjamo obseg kode pri Androidu in iOS-u z obsegom le-teh v Sencha To-

uchu, lahko recemo, da je koda pri Androidu in iOS-u nekoliko daljsa, razlog


za to pa je v tipiziranem programskem jeziku.

NSDate *date = [NSDate dateWithTimeIntervalSince1970:

(timestamp / 1000)];

NSDateFormatter *formatter = [[NSDateFormatter alloc] init];

return [formatter setDateFormat:@"yyyy-MM-dd"];

Programska koda 3.5: Pretvorba casovnega ziga v besedilo v objektnem C-ju

- (void) login:(NSString*)email password:(NSString*)password {

NSString *apiUrl = [[NSUserDefaults standardUserDefaults]

objectForKey:API_URL];

NSString *urlAsString = [NSString stringWithFormat:

@"%@login/%@/%@", apiUrl, email, password];

NSURL *url = [[NSURL alloc] initWithString:urlAsString];

[NSURLConnection sendAsynchronousRequest:[[NSURLRequest

alloc] initWithURL:url] queue:[NSOperationQueue

mainQueue] completionHandler:^(NSURLResponse

*response, NSData *data, NSError *connectionError){

NSError *error;

NSDictionary *json = [NSJSONSerialization

JSONObjectWithData:data options:kNilOptions

error:&error];

NSString *token = [json objectForKey:@"token"];

if((NSNull*)token == [NSNull null]) { /* ... */ }

}

}


objektnem C-ju

3.4. RAZHROSCEVANJE 31

3.4 Razhroscevanje

Najprirocnejse je razhroscevanje Sencha Touch aplikacije, saj vecino dela

lahko opravimo kar v enem izmed podprtih spletnih brskalnikov na oseb-

nem racunalniku. Prav tako ni vecjih tezav pri razhroscevanju aplikacije

na Android in iOS napravah. Pri iOS napravi omogocimo razhroscevanje

v nastavitvah brskalnika Safari. Prav tako moramo omogociti razvijalski

nacin v brskalniku Safari na osebnem racunalniku. Napravo priklopimo na

racunalnik preko kabla USB in v meniju Safarija izberemo Develop > iOS

naprava > aplikacija. Sedaj je razhroscevanje identicno tistemu v Sa-

fariju na osebnem racunalniku. Podobno kot v Safariju je enostavno raz-

hroscevanje aplikacije na Androidu v brskalniku Chrome. Najprej moramo

omogociti razvijalski nacin v nastavitvah naprave. Nato priklopimo napravo

preko kabla USB na osebni racunalnik in v brskalnik Chrome vpisemo naslov

about:inspect. Izberemo odprto spletno stran in kliknemo inspect.

Razhroscevanje domorodnih aplikacij je preprosto, vendar moramo imeti

pri razvoju za Android priklopljeno napravo preko kabla USB, saj je ze samo

poganjanje aplikacije v emulatorju pocasno, kaj sele razhroscevanje. Eclipse

vsebuje vsa orodja za kvalitetno razhroscevanje aplikacije. Za razhroscevanje

domorodne aplikacije, kot tudi Sencha Touch aplikacije, na napravi Android

moramo pred tem namestiti ADB (angl. Android Debug Bridge).

Pri iOS razvoju lahko uporabimo iOS simulator, ker deluje zelo hitro, se

bolje pa je, ce uporabimo napravo priklopljeno preko kabla USB.

3.5 Posodabljanje aplikacije

Predpostavimo, da zelimo nasi aplikaciji dodati novo funkcionalnost. Omenili

smo ze, da imajo lahko KPI alarmi podano lokacijo. To lokacijo bi lahko po-

kazali na zemljevidu. Pri Androidu je bilo potrebno uporabiti Google Maps

Android API v2 [15], pri iOS-u pa Google Maps SDK for iOS [16]. Imple-

mentacija sicer ni zahtevna, ampak jo je potrebno narediti na dveh mestih.

Ce bi bila aplikacija na trgovini Google Play in Appstore, bi se tudi sama


posodobila na vseh napravah, kjer je namescena, ker pa je aplikacija rocno

nalozena na napravo, je potrebno pri vsakem popravku posodobiti aplika-

cijo. Ce pa uporabimo HTML5 pristop, je potrebno dodatno funkcionalnost

izdelati samo enkrat in deluje na vseh podprtih napravah. Ce uporabimo

pristop, kjer se vse datoteke nalagajo s streznika, potem dejansko ni po-

trebna posodobitev aplikacije, ker se ob zagonu prenesejo nove datoteke, kjer

je funkcionalnost ze podprta. V Sencha Touchu so Googlovi zemljevidi ze

podprti, kar nam se olajsa izdelavo. Na sliki 3.11 vidite, da smo to tudi

preizkusili. Po novem je v Sloveniji podprt Google Street View, prikazan na

sliki 3.12, ki deluje tudi v aplikaciji.

Slika 3.11: Google Maps v Sencha To-

uch aplikaciji

Slika 3.12: Google Street View v Sen-

cha Touch aplikaciji

3.6. PODPIRANJE DODATNIH NAPRAV 33

3.6 Podpiranje dodatnih naprav

Zamislimo si scenarij, kjer bi radi naso aplikacijo podprli se na nekem do-

datnem operacijskem sistemu, na primer Windows 8, ker zelimo, da nasa

naprava deluje na cim vec mobilnih napravah. Za razvoj potrebujemo Visual

Studio. Aplikacijo lahko razvijamo v programskem jeziku VisualBasic, C++

ali C#, zadnji je se najbolj podoben programskemu jeziku Java, v katerem

se programira aplikacije za Android. Potrebno bi se bilo nauciti vseh novih

pristopov izdelave aplikacije za Windows 8. Poleg razvojnega casa, bi se

povecal tudi cas, ki ga potrebujemo za vzdrzevanje aplikacije. Potrebno bi

bilo vzdrzevanje ze kar treh aplikacij. Potem je pa tu se BlackBerry.

Aplikacija razvita s Sencha Touchem pa je podprta na Windows 8 in

BlackBerry, saj so standardi HTML5 vec ali manj podprti na vseh mobilnih

brskalnikih. Potrebno bi bilo izdelati preprosto domorodno lupino in izve-

sti dodatno testiranje. BlackBerry ze sam ponuja razvoj aplikacij v HTML5,

brskalnik IE 10 na Windows 8 pa prav tako podpira standarde HTML5. Pod-

piranje novih naprav na ta nacin ni tako zahtevno kot pri razvoju domorodne

aplikacije.

3.7 Graficno oblikovanje aplikacije

3.7.1 Simboli in ikone

Pri Sencha Touchu so v verziji 2.2 uvedli nov nacin uporabe simbolov. Upo-

rabili so pisavo, ki namesto crk vsebuje simbole. Prilozena je pisava z 94-imi

osnovnimi simboli. Tako na primer crka ”H”predstavlja simbol ”Domov”.

Prednost tega pristopa je, da so simboli v pisavi predstavljeni vektorsko, kar

pomeni, da lahko simbol poljubno povecamo in ne bomo izgubili kvalitete,

kot se to zgodi pri binarnih slikah. Prav tako lahko s pomocjo podloge CSS

preprosto spreminjamo barvo simbola, enako, kot bi spreminjali barvo pisave.

Zaradi vseh prednosti smo ikone v stranskem meniju izdelali na ta nacin,

barve pa smo lahko nastavili neposredno v brskalniku in takoj videli rezultat


ter dobljene vrednosti prekopirali v datoteko CSS.

Android SKD podpira izdelavo ikon. Lahko uvozimo lastne slike, sesta-

vimo tekst ali pa uporabimo simbole, ki so prilozeni. Ko koncamo postopek

se izdela vec binarnih slik za podporo razlicnih DPI-jev (angl. Dots Per

Inch). Ko je ikona, spreminjanje velikosti in barve ni vec mogoce.

Xcode podpira samo uvoz ikon. Tako moramo vse ikone rocno izdelati v

drugem programu ali pa poiskati primeren paket le-teh.

Da bi si pomagali pri izdelavi ikone aplikacije, smo uporabili predlogo

App Icon Template [10].

Poglavje 4

Primerjava aplikacij

Po koncanem razvoju smo opravili testiranje delovanja posamezne aplikacije.

Primerjali smo tudi koncno dolzino kode, ki smo jo napisali. Pri koncni

primerjavi smo upostevali vse naslednje kriterije:

• hitrost zagona,

• odzivnost dotikov,

• gladkost prehodov,

• hitrost delovanja funkcij,

• obseznost kode (stevilo vrstic),

• potrebno tehnicno znanje,

• cene potrebne programske opreme.

4.1 Delovanje aplikacije

V tabeli 4.1 so izmerjeni casi, ki so potrebni za zagon aplikacije. Za merjenje

casa smo uporabili sistemsko stoparico na Androidu, ki je natancna na sto-

tinko sekunde. Vsako verzijo aplikacije smo zagnali petkrat in vzeli povprecje

petih casov zagona. V primerih, kjer se je aplikacija zaganjala eno sekundo

35

36 POGLAVJE 4. PRIMERJAVA APLIKACIJ

ali manj, so rezultati zaokrozeni na desetinko sekunde natancno. Kjer pa je

aplikacija za zagon potrebovala vec kot eno sekundo, so rezultati zaokrozeni

na pol sekunde natancno.

Casi so bili izmerjeni od pritiska ikone aplikacije do pojava prijavnega

zaslona. Prvi zagon je izmerjen takoj po namestitvi aplikacije, brez upo-

rabniskih nastavitev in predpomnenja (angl. caching). Aplikacija, ki je raz-

vita s Sencha Touchem, pri prvem zagonu potrebuje vec casa kot pri nasle-

dnjih zagonih, saj je aplikacija izdelana tako, da se vse datoteke nahajajo na

strezniku in se ob prvem zagonu v celoti prenesejo. Pri nadaljnjih zagonih

brskalnik ne nalozi datotek, ce se te niso spremenile, zato je zagon hitrejsi.

Prav tako pa je zagon se vedno bistveno pocasnejsi od domorodnih aplikacij.

To je zaradi zahtev na streznik in ustvarjanja vseh funkcij in objektov ob

zagonu. Zaganjanje aplikacije si lahko predstavljamo kot zagon brskalnika in

odpiranje nekoliko kompleksnejse strani, odvisno je tudi od kvalitete inter-

netne povezave. Hitrejsi zagon bi lahko dosegli tako, da ne bi vseh pogledov

ustvarili na zacetku, ampak sele, ko se potrebujejo, kar pa bi upocasnilo

samo delovanje aplikacije. Opazili smo tudi, da se aplikacija na iOS-u zazene

hitreje kot na Androidu, to pa zaradi brskalnika Safari.

Tip aplikacije in testna naprava prvi zagon nasl. zagon

Sencha Touch (Samsung Galaxy Nexus) 8.0 s 5.5 s

Sencha Touch (Asus Nexus 7 (2012)) 7.5 s 4.5 s

Sencha Touch (iPod Touch 5) 5.5 s 5.0 s

domorodna (Samsung Galaxy Nexus) 1.0 s 1.0 s

domorodna (Asus Nexus 7 (2012)) 1.0 s 1.0 s

domorodna (iPod Touch 5) 0.8 s 0.8 s

Tabela 4.1: Primerjave hitrosti zagona aplikacije

Zagon aplikacije bi bil hitrejsi, ce bi programsko kodo skrajsali, z uporabo

build funkcije. To bi zmanjsalo velikost datotek s programsko kodo in tudi

datoteko Sencha Touch knjiznice.

4.2. PRIMERJAVA RAZVOJA IN SREDSTEV 37

Odzivnost dotikov je pri Sencha Touch aplikaciji malce slabsa, kar je bolj

opazno na Androidu. Pri seznamih se prav tako opazi majhna razlika v od-

zivnosti dotikov in gladkosti pomikanja, spet se to bolj pozna na Androidu.

Na iOS-u aplikacija deluje kot domorodna, ce izvzamemo daljsi cas zagona.

Domorodni aplikaciji pa delujeta z odlicno odzivnostjo, tako kot smo nava-

jeni.

Prehodi so gladki tako v Sencha Touch aplikaciji kot v domorodnih apli-

kacijah in se izvedejo brez zatikanja in s priblizno enako hitrostjo. Nalaganje

seznama alarmov deluje pri domorodnih aplikacijah hitreje, za prenos potre-

buje povprecno 2.5 sekunde. Izris grafov povsod deluje tekoce, pri Sencha

Touch aplikaciji mogoce le prvo nalaganje potrebuje nekoliko vec casa.

Domorodne aplikacije dajejo veliko prijetnejsi obcutek zaradi skoraj ta-

kojsnjega zagona, hitrih prenosov podatkov s streznika, odzivnih dotikov in

hitrega listanja seznamov. Razlike med domorodno in Sencha Touch aplika-

cijo niso velike, vendar se vsekakor obcuti razlika, ki je vecja na Androidu.

Na iOS-u pa je bistvena razlika samo pri zagonu, drugace pa Sencha Touch

aplikacija daje obcutek domorodne aplikacije.

4.2 Primerjava razvoja in sredstev

Cene programov in knjiznic smo zapisali v ameriskih dolarjih, ker so cene

najveckrat podane v tej valuti. Upostevali smo, da programe uporabljamo

vec kot 30 dni. Upostevali smo tudi, da si ne lastimo racunalnika z operacij-

skim sistemom OS X.

4.2.1 Sencha Touch aplikacija

Pri razvoju smo uporabili preizkusno razlicico Sencha Architecta, ki jo lahko

uporabljamo 30 dni. Po tem je potrebno kupiti licenco. Cene so razvidne v

tabeli 4.2.


Program / knjiznica cena

Sencha Touch $0.00

Sencha Architect $399.00

skupaj $399.00

Tabela 4.2: Cene uporabljenih programov in knjiznic pri razvoju z uporabo

standarda HTML5

Pri stetju vrstic kode smo upostevali samo kodo, ki je v kontrolerjih in

funkcijah aplikacije, nismo pa upostevali kode, ki jo generira Architect. Torej

smo upostevali samo kodo, ki smo jo napisali rocno. Upostevati pa moramo,

da zaradi uporabe poimenovanih parametrov ena vrstica kode vsebuje manj

znakov kot pri Javi in objektnem C-ju. Programska koda v celoti obsega 502

vrstici. Stilska podloga CSS za izgled aplikacije pa obsega 146 vrstic.

4.2.2 Domorodni aplikaciji

Pri razvoju domorodnih aplikacij smo uporabili samo programe in knjiznice,

ki so popolnoma brezplacni, kot je razvidno v tabeli 4.3.

Program / knjiznica cena

Android SDK $0.00

AChartEngine $0.00

VMWare Player $0.00

XCode $0.00

ECSlidingViewController $0.00

ios-linechart $0.00

skupaj $0.00

Tabela 4.3: Cene uporabljenih programov in knjiznic pri razvoju domorodnih

aplikacij

Tako kot pri Sencha Touch aplikaciji smo tudi tu upostevali samo na rocno

4.3. KONCNA OCENA 39

napisano kodo. Pri aplikaciji za Android smo izvzeli kodo za razrede, ki defi-

nirajo strukturo objektov JSON, saj smo v Sencha Architectu prav tako izde-

lali modele za uporabo v shrambah, ki pa jih nismo upostevali pri dolzini kode

aplikacije. Pri uporabi razvojnega okolja Eclipse nam ni bilo potrebno rocno

pisati ukazov za uvoz razredov (primer: import android.app.Activity;),

ker za to poskrbi IDE sam, zato tudi teh nismo steli. Programska koda ob-

sega 1426 vrstic. Datoteke z oblikami, barvami in stili pa obsegajo 163

vrstic. Ker smo uporabili knjiznico AChartEngine, moramo upostevati, da

smo morali programsko dolociti obliko grafa, kar poveca obseznost kode.

Pri aplikaciji za iOS se pri ustvarjanju novega kontrolerja avtomatsko

generirajo prazne funkcije, ki jih kontroler uporablja. Pri stetju smo izvzeli

datoteke koncnice .h, saj ne vsebujejo nobene dejanske kode. Programska

koda obsega 1210 vrstic. Spremembe izgleda aplikacije so se izdelale z

uporabo graficnega urejevalnika, zato obsega nismo mogli dolociti. Prav

tako kot pri aplikaciji za Android, smo morali tudi tu dolociti obliko grafa

programsko.

Programska koda obsega skupno 2636 vrstic, kar je pet krat toliko kot

pri Sencha Touch aplikaciji.

4.3 Koncna ocena

Koncno oceno smo podali na podlagi razlicnih faktorjev, ki so po nasem

mnenju pomembni pri razvoju in vzdrzevanju aplikacije. Vsakega izmed

faktorjev smo ocenili od 1 do 10, kjer je 1 najnizja ocena, 10 pa je najvisja

ocena. Ocene so razvidne v tabeli 4.4.

Domorodne aplikacije definitivno delujejo malce hitreje kot Sencha Touch

aplikacija, prav tako so malce bolj zanesljive. Sencha Touch aplikacija pa je

hitrejsa za razvoj, potrebnega je manj tehnicnega znanja, saj je potrebno

znanje samo enega programskega jezika, potrebno je manj zunanjih knjiznic,

poleg tega pa so podprte tudi druge naprave, kot so Blackberry in Windows

naprave.


ST aplikacija domorodna aplikacija

hitrost zagona 4 10

gladkost prehodov 8 10

hitrost delovanja funkcij 8 10

obseznost kode 9 3

preglednost kode 9 5

potrebne zunanje knjiznice 10 6

potrebno tehnicno znanje 8 5

cas razvoja 9 3

zanesljivost 7 9

pokritost mobilnih naprav 8 6

koncna ocena 8.0 6.5

Tabela 4.4: Ocene bistvenih faktorjev pri aplikaciji in koncna ocena

Poglavje 5

Sklepne ugotovitve

Razvili smo tri aplikacije, dve z uporabo klasicnega domorodnega pristopa,

tretjo pa z uporabo standarda HTML5. Razvoj aplikacij z uporabo standarda

HTML5 je vse bolj uporaben, ker so mobilne naprave vedno zmogljivejse.

Tudi razlika v hitrosti delovanja teh aplikacij je v primerjavi z domorodnimi

aplikacijami vedno manjsa. Prav tako pravzaprav razvijamo in vzdrzujemo

le eno aplikacijo. Vse vec je podjetjih, ki ponujajo svoje resitve za poe-

nostavljen razvoj HTML5 aplikacije. Tako podjetje je tudi Sencha, katerih

resitev Sencha Touch smo uporabili za izdelavo nase aplikacije. Razvoj je

bil veliko hitrejsi, kot razvijanje dveh domorodnih aplikacij za Android in

iOS. Sencha Touch ima podprte vse funkcionalnosti, ki smo jih potrebovali

v nasi aplikaciji. Prav tako je koda krajsa in bolj pregledna, vzdrzevanje pa

je preprostejse. Razlika v hitrosti delovanja je se opazna, a se bo s casom

zmanjsala, ker vse stremi k izdelovanju HTML5 aplikacij.

V nasem primeru bi se definitivno odlocili za ta nacin razvoja. Ce pa bi

izdelovali aplikacijo, ki bi uporabljala veliko sistemskih funkcij, kompleksnih

izracunov ali graficnih operacij, bi bil razvoj domorodne aplikacije primer-

nejsi.

41

Literatura

[1] Platforma Occapi. Dostopno na:

http://www.opcomm.eu/sl/resitve/platforma-occapi

[2] Knjiznica Sencha Touch. Dostopno na:

http://www.sencha.com/products/touch

[3] Uradno podprte naprave kjiznice Sencha Touch. Dostopno na:

http://www.sencha.com/products/touch/features

[4] Sencha Architect IDE. Dostopno na:

http://www.sencha.com/products/architect

[5] Trgovina Sencha Architect. Dostopno na:

https://www.sencha.com/store/architect

[6] Android SDK. Dostopno na:

http://developer.android.com/sdk

[7] Knjiznica AChartEngine za izdelavo grafov na Androidu. Dostopno na:

https://code.google.com/p/achartengine

[8] VMWare Player, program za virtualizacijo. Dostopno na:

https://my.vmware.com/web/vmware/downloads

[9] Knjiznica za izdelavo grafov ios-linechart. Dostopno na:

https://github.com/mruegenberg/ios-linechart

43

44 LITERATURA

[10] Predloga App Icon Template za izdelavo iOS ikone. Dostopno na:

http://appicontemplate.com

[11] Knjiznica JSON-Simple. Dostopno na:

https://code.google.com/p/json-simple

[12] Knjiznica Google-Gson. Dostopno na:

https://code.google.com/p/google-gson

[13] Knjiznica Jackson. Dostopno na:

http://jackson.codehaus.org

[14] ECSlidingViewController 2. Dostopno na:

https://github.com/ECSlidingViewController/ECSlidingView-

Controller

[15] Google Maps Android API v2. Dostopno na:

https://developers.google.com/maps/documentation/android

[16] Google Maps SDK for iOS. Dostopno na:

https://developers.google.com/maps/documentation/ios

[17] Primoz Becan, Razvoj medplatformne mobilne aplikacije v ogrodju Mo-

Sync, 2013. Dostopno na:

http://eprints.fri.uni-lj.si/2134

[18] Aleksander Gregorka, Platforma Trafika v HTML5, 2013. Dostopno na:


[19] Sasa Nebojsa Potezica, Razvoj aplikacij za pametne telefone, 2009. Do-

stopno na:


[20] Izvorna koda Sencha Touch aplikacije, objavljena na GitHubu. Dostopno

na:

https://github.com/drinovc/occapiMobile-html5

LITERATURA 45

[21] Izvorna koda aplikacije za Android, objavljena na GitHubu. Dostopno

na:

https://github.com/drinovc/occapiMobile-android

[22] Izvorna koda aplikacije za iOS, objavljena na GitHubu. Dostopno na:

https://github.com/drinovc/occapiMobile-ios

Documents

Razvoj mobilnega odjemalca za platformo Occapi · 2018-03-13 · Izjava o avtorstvu diplomskega dela Spodaj podpisani Rok Drinovec, z vpisno stevilko 63080089, sem avtor di-plomskega