Presentation of Web API Data in Windows 8 Application

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INFORMA ˇ

CN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

WINDOWS 8 APLIKACE PRO PREZENTACI DAT Z

WEBOV ´

EHO API

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JI ˇ

R´I KALUS

AUTHOR

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INFORMA ˇ

CN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

WINDOWS 8 APLIKACE PRO PREZENTACI DAT Z

WEBOV ´

EHO API

PRESENTATION OF WEB API DATA IN WINDOWS 8 APPLICATION

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JI ˇ

R´I KALUS

AUTHOR

VEDOUC´I PR ´

ACE

Ing. MARTIN MILI ˇ

CKA

Abstrakt

C´ılem t´eto bakal´aˇrsk´e pr´ace je n´avrh a implementace Windows 8 aplikace pro prezentaci dat z webov´eho API. Pˇrenesen´a data jsou pro uˇzivatele citliv´a a je zde kladen d˚uraz na auto-rizaci a bezpeˇcnost. Data jsou zobrazov´ana v re´aln´em ˇcase. Pr´ace obsahuje popis moˇznost´ı v´yvoje aplikace pro architekturu WinRT, komunikaci aplikace s webov´ym API, autorizaci a zabezpeˇcen´ı pˇren´aˇsen´ych i offline dat. Byla vytvoˇrena aplikace typu dashboard, kter´a zobrazuje data z r˚uzn´ych finanˇcn´ıch kategori´ı. Pro zobrazen´ı byly vyuˇzity z´akladn´ı grafick´e komponenty, pˇriˇcemˇz nˇekter´e jsou obohaceny o animace.

Abstract

The aim of this bachelor’s thesis is to design and implement a Windows 8 application that can provide data from web API. Transferred data are sensitive for the user with an emphasis for authorization and security. Data is displayed in real time. The thesis decribes possibilities for development of the application for WinRT architecture, communication of the application with web API, authorization and security of transffered and offline data. The application of dashboard type was created that display data from various financial categories. For the visualization basic graphic components were used, some of them includes animations.

Kl´ıˇ

cov´

a slova

Windows 8, WinRT, zabezpeˇcen´ı, zobrazov´an´ı v re´aln´em ˇcase, webov´e API, animace

Keywords

Windows 8, WinRT, security, real time dislplayed data, web API, animations

Citace

Jiˇr´ı Kalus: Windows 8 aplikace pro prezentaci dat z webov´eho API, bakal´aˇrsk´a pr´ace, Brno, FIT VUT v Brnˇe, 2015

Windows 8 aplikace pro prezentaci dat z webov´

eho

API

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇe pod veden´ım pana Ing. Martina Miliˇcky. Informace k pr´aci jsem ˇcerpal ze zdroj˚u uveden´ych v seznamu li-teratury a od z´astupce firmy C´ıgler Software, pana Proch´azky.

. . . . Jiˇr´ı Kalus 14. kvˇetna 2015

Podˇ

ekov´

an´ı

T´ımto bych r´ad podˇekoval m´emu vedouc´ımu bakal´aˇrsk´e pr´ace za odborn´e konzultace a zejm´ena rychl´e reakce na m´e poˇzadavky.

c

Jiˇr´ı Kalus, 2015.

Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Pr´ace je chr´anˇena autorsk´ym z´akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´avnˇen´ı

Obsah

1 Uvod´ 2

2 Zp˚usoby reprezentace dat a vybran´e technologie 3

2.1 Dashboard . . . 3

2.2 Komponenty pro reprezentaci dat . . . 4

2.3 V´yvojov´e prostˇred´ı a jazyk . . . 6

2.4 S´ıt’ov´a komunikace . . . 8

2.4.1 HTTPS . . . 8

2.4.2 Architektura REST . . . 8

2.4.3 JSON . . . 10

2.4.4 OAuth . . . 11

3 Architektura syst´emu 13 3.1 Sch´ema a ´uloha jednotliv´ych element˚u . . . 13

3.2 Notifikace . . . 14

4 Komunikaˇcn´ı protokol 16 4.1 Z´akladn´ı prvky komunikace . . . 16

4.2 Autorizace . . . 16

4.3 Metody webov´eho API . . . 18

4.4 Aktualizace dat . . . 21

4.5 Struktura pˇrenesen´ych dat . . . 21

5 Implementace 22 5.1 Push notifikace . . . 22 5.2 Autorizace . . . 24 5.3 Security Vault . . . 25 5.4 Offline stav . . . 25 6 Rozˇs´ıˇren´ı 27 6.1 Universal Apps . . . 27

6.2 Ziv´ˇ e dlaˇzdice a interakce s uˇzivatelem . . . 28

7 Z´avˇer 30

A Obsah CD 32

B Screenshoty z aplikace 33

Kapitola 1

´

Uvod

N´apln´ı t´eto pr´ace je navrhnout a realizovat Windows 8 aplikaci pro prezentaci dat z webo-v´eho API. Konkr´etnˇe produkt Dashboard Money S5 pro spoleˇcnost C´ıgler Software, kter´y oˇcek´av´a ostr´e nasazen´ı. Aplikace vyuˇz´ıv´a architekturu klient-server. Server obsahuje webov´e API, kter´e poskytuje data aplikaci. Webov´e API m´a pˇr´ıstup k datab´azi konkr´etn´ıho z´ aka-zn´ıka. Jedn´a se o odlehˇcenou verzi ´uˇcetnick´eho programu Money S5 pro Windows, pˇrednostnˇe urˇcenou pro pˇrenosn´a zaˇr´ızen´ı. Inspirac´ı byla pˇredevˇs´ım konkurenˇcn´ı aplikace Inform Mo-tion Dashboard, kter´a se nach´az´ı naApp store od spoleˇcnosti Apple. Textov´e zad´an´ı spolu s demonstraˇcn´ımi obr´azky mi bylo zveˇrejnˇeno na priv´atn´ıch str´ank´ach firmy C´ıgler Soft-ware.

´

Uˇcelem produktu je vhodn´ym zp˚usobem uˇzivateli zobrazit poˇzadovan´a data z r˚uzn´ych finanˇcn´ıch odvˇetv´ı. D˚uraz byl kladen na jednoduchost a srozumitelnost grafick´ych kom-ponent, kter´e byly vybr´any na z´akladˇe datov´ych struktur. Vyjma autorizace je aplikace zcela pasivn´ı a uˇzivatel je informov´an jen o ˇcasu posledn´ı aktualizace. Aplikace byla opti-malizov´ana pro ztr´atu internetov´eho pˇripojen´ı a pokud je to moˇzn´e, naˇcte lok´alnˇe uloˇzen´a data.

Z´akladn´ı varianta je pro zaˇr´ızen´ı, na kter´ych je nainstalov´an minim´alnˇe operaˇcn´ı syst´em Windows 8. V r´amci rozˇs´ıˇren´ı byla prostudov´ana i varianta pro chytr´e mobily. Nutnou podm´ınkou pro bˇeh aplikace na mobilu je minim´alnˇe Windows Phone 8.1. Datov´y pˇrenos je na pˇrenosn´ych zaˇr´ızen´ıch ˇcasto limitov´an, a proto byla velikost pˇren´aˇsen´ych dat minimali-zov´ana zvolen´ım vhodn´eho form´atu serializace. S ohledem na v´ykon a pˇredevˇs´ım omezenou kapacitu bateri´ı prov´ad´ı aplikace aktualizaci jen na z´akladˇe pˇrijmut´ı notifikace ze serveru.

´

Uˇcelem n´asleduj´ıc´ıho textu je poskytnout ˇcten´aˇri informace o v´yvoji Windows 8 apli-kac´ı, moˇznostech reprezentace dat a prostˇredc´ıch pro rychlou a bezpeˇcnou komunikaci na s´ıti. V ´uvodu pr´ace lze nal´ezt z´akladn´ı informace o reprezentaci dat a technologi´ıch, kter´e byly pouˇzity pro v´yvoj aplikace. Architektura syst´emu, notifikace aplikace vˇcetnˇe autori-zace s moˇznost´ı naˇcten´ı offline dat je obsaˇzena v kapitole Architektura syst´emu. V ka-pitole Komunikaˇcn´ı protokol je ˇcten´aˇr sezn´amen s rozhran´ım webov´eho API, aktualizac´ı dat a struktuˇre pˇrenesen´ych dat. Implementaˇcnˇe netrivi´aln´ı t´emata jako push notifikace, zabezpeˇcen´ı lok´aln´ıch dat ˇci autorizace je pops´ana v kapitole Implementace. V koneˇcn´e kapitole jsou pops´ana moˇzn´a rozˇs´ıˇren´ı aplikace.

Kapitola 2

Zp˚

usoby reprezentace dat a

vybran´

e technologie

2.1

Dashboard

Data jsou uˇzivateli zobrazena v podobˇe dashboardu. Dashboard v informaˇcn´ıch techno-logi´ıch vyjadˇruje generalizovanou kolekci dat. Typicky se jedn´a o jednoduch´e a pˇrehledn´e uˇzivatelsk´e rozhran´ı, kde zobrazen´a data jsou odrazem aktu´aln´ıho stavu syst´emu. Velk´y d˚uraz je kladen na srozumitelnost a zobrazen´ı jen uˇziteˇcn´ych informac´ı. Reprezentace dat silnˇe z´avis´ı na druhu a sloˇzitosti zobrazovan´e informace. V praxi se pro zobrazen´ı vyuˇz´ıv´a nˇekolik typ˚u komponent, kter´e jsou pops´any n´ıˇze v t´eto kapitole. ´Uˇcelem dashboardu je zobrazit uˇzivateli data z komplexnˇejˇs´ıho syst´emu.

Aplikace Dashboard Money S5 zobrazuje data z r˚uzn´ych finanˇcn´ıch kategori´ı, jako je napˇr´ıklad seznam dluˇzn´ık˚u, seznam neuhrazen´ych faktur nebo stav bankovn´ıho ´uˇctu. Kaˇzd´a kategorie je zastoupena grafem, tabulkou ˇci prost´ym zobrazen´ım pˇripom´ınaj´ıc´ım dlaˇzdici. Po kliknut´ı na pˇr´ısluˇsnou kategorii je uˇzivateli zobrazen jej´ı detail. Je-li dan´e zaˇr´ızen´ı pˇripojen´e k internetov´e s´ıti, pak jsou prezentovan´a data vˇzdy aktu´aln´ı. Pokud aplikace projde autorizac´ı a pot´e ztrat´ı spojen´ı, je moˇzn´e naˇc´ıst offline data, kter´a byla ve stavu online uloˇzena viz 5.4.

Obr´azek 2.1: P˚uvodn´ı n´avrh Dashboard Money S5 aplikace

Aplikace bude um´ıstˇena v digit´aln´ı distribuˇcn´ı platformˇe Windows Store. Pro zobra-zen´ı dat je nutn´e, aby mˇel uˇzivatel ´uˇcet u spoleˇcnosti C´ıgler Software. ˇSirok´e veˇrejnosti je umoˇznˇeno aplikaci st´ahnout, ale bez pˇrihlaˇsovac´ıch ´udaj˚u jim z˚ustane zobrazena pouze

´

uvodn´ı obrazovka vyz´yvaj´ıc´ı k zad´an´ı autorizaˇcn´ıho kl´ıˇce. Dle poˇzadavk˚u firmy je aplikace urˇcena pro osoby z vyˇsˇs´ıho managementu, kter´e si budou zobrazovat data sv´e, pˇr´ıpadnˇe ciz´ı spoleˇcnosti.

2.2

Komponenty pro reprezentaci dat

Dashboard aplikace se skl´ad´a z nˇekolika typ˚u grafick´ych komponent. V´yhody a nev´yhody komponent pouˇzit´ych v aplikaci spolu s detailnˇejˇs´ım popisem jejich vzhledu a chov´an´ı na-leznete v n´asleduj´ıc´ıch podkapitol´ach. Pˇred samotn´ym v´yvojem aplikace byly nastudov´any moˇznosti zobrazen´ı r˚uzn´ych datov´ych struktur [3]. Mezi nejpouˇz´ıvanˇejˇs´ı patˇr´ı sloupcov´y, kol´aˇcov´y graf a tabulky. Podnˇety ke vzhledu a chov´an´ı komponent byly inspirov´any pro-dukty spoleˇcnosti Telerik Kendo UI. Veˇsker´e grafick´e prvky spoleˇcnˇe s jejich chov´an´ım byly od z´akladu implementov´any. Nebyly tedy pouˇzity ˇz´adn´e komponenty tˇret´ıch stran.

Graf

Grafy typicky reprezentuj´ı strukturovan´y datov´y typ kolekce. U tohoto typu zobrazen´ı nejsou poˇzadov´any rozs´ahlejˇs´ı filtrace dat. V aplikaci byl pouˇzit sloupcov´y a stacked bar graf. Stacked bar graf nem´a v ˇceˇstinˇe zaveden´y ekvivalent a proto je zde uveden anglick´y n´azev. Pˇr´ıklady obou graf˚u jsou uvedeny n´ıˇze.

Obr´azek 2.2: Pouˇzit´e grafy v aplikaci: Sloupcov´y (vlevo) a stacked bar (vpravo) Na zaˇc´atku v´yvoje aplikace byly grafy pos´ıl´any do aplikace formou obr´azku. Aplikace poslala informaci o sv´em rozliˇsen´ı a pot´e j´ı byl zasl´an odpov´ıdaj´ıc´ı graf. Tato forma pˇrenosu a zobrazen´ı sice umoˇzˇnuje centr´aln´ı a pˇredevˇs´ım dynamickou spr´avu, ale je zde absence animac´ı a zvyˇsuje se datov´y pˇrenos. Dalˇs´ı moˇznost´ı je vytvoˇrit graf pomoc´ı HTML / CSS / JS a vystavit tento graf na internetu. Aplikace by pak pouˇzila vestavˇen´y prohl´ıˇzeˇc a graf zobrazila. Razantnˇe se ale zvyˇsuje velikost pˇrenesen´ych dat. Fin´aln´ı ˇreˇsen´ı je zasl´an´ı hodnot pˇr´ımo do aplikace, kter´a je zpracuje a zobraz´ı.

N´ahled grafu zobrazuje posledn´ı pˇrijat´e hodnoty. Po kliknut´ı na n´ahled se zobraz´ı graf pˇres celou obrazovku, kdy je uˇzivateli umoˇznˇeno filtrovat data. Pˇri zobrazen´ı byly vyuˇzity v´yˇse zmiˇnovan´e animace hodnot. Pˇrenos dat je tak´e minimalizov´an, protoˇze se pˇren´aˇs´ı hodnoty, nikoliv vzhled. Pouˇzit´ı graf˚u m˚uˇze v´est k problematick´emu zobrazen´ı na zaˇr´ızen´ı s menˇs´ı zobrazovac´ı plochou.

Tabulky

Tabulka je vhodn´a pro datov´e objekty, u nichˇz potˇrebujeme podrobnˇejˇs´ı informace. Vizuali-zuje kolekci struktur. Profity tabulkov´eho zobrazen´ı je moˇzn´a filtrace dat pro danou kolekci

Obr´azek 2.3: Tabulka pouˇzit´a v aplikaci

V aplikaci je data moˇzn´e filtrovat dvˇema zp˚usoby. Prvn´ı zp˚usob je v´ysuvn´e menu, kde jsou jednotliv´e poloˇzky pro filtraci. Druh´y zp˚usob filtrace je kliknut´ı na n´azev sloupce. V z´avislosti na poˇrad´ı kliknut´ı jsou hodnoty dan´eho sloupce setˇr´ıdˇeny (po smˇeru abecedy, proti smˇeru abecedy a p˚uvodn´ı stav). Oba typy filtrac´ı se navz´ajem ovlivˇnuj´ı a lze tedy filtrovat data z´aroveˇn. N´ahled tabulky obsahuje prvn´ıch pˇet poloˇzek z kategorie, kterou zastupuj´ı. Po kliknut´ı na n´ahled se zobraz´ı tabulka pˇres celou obrazovku, ve kter´e je moˇzn´e listovat a filtrovat. Stejnˇe jako u graf˚u m˚uˇze pouˇzit´ı tabulky v´est k problematick´emu zob-razen´ı na zaˇr´ızen´ı s menˇs´ı zobrazovac´ı plochou.

Dlaˇzdice

Dlaˇzdic´ı ch´apeme obd´eln´ıkovˇe ˇci ˇctvercovˇe vymezen´e m´ısto zobrazovac´ı plochy, kde jsou uˇzivateli pˇred´ana data pomoc´ı prost´eho textu nebo piktogramu/ikony (zisk, rozd´ıl, stav, poˇcet, . . . ). Dlaˇzdice lze obecnˇe rozdˇelit na statick´e a ˇziv´e. Statick´e zobrazuj´ı nemˇenn´a data jako napˇr´ıklad piktogram a jeho struˇcn´y popis. ˇZiv´e dlaˇzdice mˇen´ı v ˇcase sv˚uj ob-sah, jako napˇr´ıklad n´ahledy fotek nebo ˇc´ıslo reprezentuj´ıc´ı poˇcet novˇe pˇr´ıchoz´ıch email˚u. Dlaˇzdice se zaˇcaly ˇsiroce pouˇz´ıvat s pˇr´ıchodem Windows 8 a rozhran´ım Modern UI. Z´akladn´ı dlaˇzdice v aplikaci Dashboard Money S5 maj´ı ˇctvercov´y tvar a zobrazuj´ı agrego-van´e hodnoty pro finanˇcn´ı kategorii, kterou zastupuj´ı. Dlaˇzdice obsahuje ikonu, jednoduch´y n´azev a agregovan´e hodnoty z kategorie, kterou zastupuje. Po kliknut´ı na dlaˇzdici jsou uˇzivateli zobrazeny detailnˇejˇs´ı informace, nejˇcastˇeji formou tabulky. Jako dalˇs´ı pˇr´ıklad lze uv´est posuvn´y kontejner, kter´y sdruˇzuje bankovn´ı ´uˇcty a uv´ad´ı k nim logo pˇr´ısluˇsn´e banky.

Obr´azek 2.5: Dlaˇzdice v aplikaci

V aplikaci je tak´e dlaˇzdice, kter´a infor-muje uˇzivatele o zpr´av´ach. Dlaˇzdice dispo-nuje dvˇema odr´aˇzkami, u kter´ych se perio-dicky mˇen´ı text. Kliknut´ım na dlaˇzdici jsou uˇzivateli zobrazeny interaktivn´ı str´anky ze serveru. D´ıky vestavˇen´emu prohl´ıˇzeˇci je tak uˇzivatel st´ale v aplikaci. V´yhoda tohoto zobrazen´ı je hlavnˇe v jednoduch´e a centr´aln´ı spr´avˇe.

2.3

V´

yvojov´

e prostˇ

red´ı a jazyk

Aplikace

• Visual Studio

Integrovan´e v´yvoj´aˇrsk´e prostˇred´ı pˇr´ımo od spoleˇcnosti Microsoft. Pro v´yvojUniversal Apps je nutn´e m´ıt Visual Studio 2013 Update 2 a vyˇsˇs´ı.

• Windows RunTime

Operaˇcn´ı syst´em mus´ı obsahovat architekturuWindows RuntTime, d´ale jenWinRT, kter´a je podporov´ana Windows 8 a vyˇsˇs´ı.

WinRT

WinRT je homogenn´ı architektura pro aplikace bˇeˇz´ıc´ı na operaˇcn´ım syst´emu Windows 8 a vyˇsˇs´ıch verz´ıch [10]. WinRT je implementovan´e v C++_{a je to nejvyˇsˇs´ı softwarov´a vrstva}

naˇs´ı aplikace, kter´a komunikuje s operaˇcn´ım syst´emem. Tento typ architektury je urˇcen pro

Modern UI aplikace, zn´am´e jako Metro. Aplikace vytvoˇren´e pod touto architekturou bˇeˇz´ı vsandboxu.

Bˇehov´e prostˇred´ı sandbox pˇrin´aˇs´ı v´yhodu hlavnˇe v oddˇelen´em pamˇet’ov´em prostoru. Ostatn´ı aplikace tedy nemohou pˇristoupit k pamˇeti, kter´a pro nˇe nen´ı alokov´ana. Je zde kladen vyˇsˇs´ı d˚uraz na bezpeˇcnost. To s sebou pˇrin´aˇs´ı i urˇcit´e nev´yhody. Nem˚uˇzeme vo-lat syst´emov´e funkce, kter´e nejsou implicitnˇe povolen´e, napˇr. vypnut´ı nebo restartov´an´ı zaˇr´ızen´ı.

Pro tvorbuWinRT [5] aplikac´ı jsou uˇzivateli umoˇznˇeny dvˇe kategorie volby jazyka. Prvn´ı kategorie je za podpory .NET technologie, kdy je moˇzn´e pouˇz´ıt pro chov´an´ı aplikace C#_,

VB.NET nebo C++a pro vzhled aplikace je pot´e nutn´y XAML. Druhou moˇznost´ı je pouˇz´ıt

Javascript pro chov´an´ı aplikace a vzhled je nutn´y implementovat v CSS/HTML. Pˇr´ıkladem prvn´ı kategorie jsou ve Windows store Mapy, Kontakty nebo OneDrive, pˇr´ıkladem druh´e kategorie je Skype nebo Poˇcas´ı.

Obr´azek 2.6: Architektura aplikac´ı Windows 8 [2]

Presentation Foundation a XAML

TechnologieWindows Presentation Foundation, d´ale jen WPF, je framework pro komplexn´ı tvorbu obs´ahl´ych formul´aˇrov´ych aplikac´ı, kter´y je souˇc´ast´ı .NET frameworku od verze 3.0. WPF je logick´y n´astupce dˇr´ıve pouˇz´ıvan´e technologie Windows Forms. Tato technologie je Microsoftem st´ale podporov´ana a lze tedy vyv´ıjet aplikace i na nejnovˇejˇs´ıch operaˇcn´ıch syst´emech (Windows 8, 8.1 nebo 10), avˇsak vhledem k rozsahu r˚uzn´ych zobrazen´ı aplikac´ı nen´ı vhodn´e v dneˇsn´ı dobˇe Windows Forms pouˇz´ıvat [12].

D˚uvodem vzniku WPF je unifikovat zp˚usob n´avrhu mezi platformami. Pro Windows Forms aplikace je probl´em pˇrizp˚usobit se rozd´ıln´e fyzick´e velikosti koncov´eho zaˇr´ızen´ı z d˚uvodu slab´e podpory DPI1. Nelze pouˇz´ıt stejnou aplikaci na zaˇr´ızen´ıch s rozd´ıln´ym rozliˇsen´ım. WPF zav´ad´ı nez´avislou jednotku d´elky DIP a vˇsechny elementy vytv´aˇr´ı vekto-rovˇe. D´ıky tˇemto dvˇema aspekt˚um je v´ysledn´a aplikace nez´avisl´a na rozliˇsen´ı zobrazovac´ıho zaˇr´ızen´ı. P˚uvodn´ı grafick´e rozhran´ı (GDI) veWindows Forms je nahrazeno a pro vykres-lov´an´ı formul´aˇr˚u se pouˇz´ıv´a DirectX. V d˚usledku akcelerovan´e grafiky m´a aplikace menˇs´ı v´ypoˇcetn´ı reˇzii na procesor a aplikace je sviˇznˇejˇs´ı.

Pro uˇzivatelsk´e rozhran´ı je ve WPF pouˇz´ıv´an jazyk XAML, kter´y je odvozen´y od znaˇckovac´ıho jazyka XML. Vˇsechny prvky, kter´e definujeme v jazyce XAML lze zapsat i v jazyce C#_{ˇci Visual Basic.WinRT aplikace maj´ı vyjma standardn´ı funkcionality}

(desk-topov´e aplikace) tak´e podporu pro dotykov´e ud´alosti.

Webov´e API a datab´aze

Pro tvorbu logiky webov´eho API je moˇzn´e pouˇz´ıt nˇekolik programovac´ıch jazyk˚u. Mezi z´akladn´ı pouˇz´ıvan´e patˇr´ı PHP, PERL, JAVA nebo ASP.NET. V´ybˇer jazyka z´avis´ı na poˇzadavc´ıch zadavatele a zkuˇsenosti v´yvoj´aˇre. Webov´e API pro aplikaci Money Dashboard S5 bylo implementov´ano v jazyce PHP 5. Datab´aze byla zvolena MySQL. Kombinace PHP a MySQL byla pouˇzita, protoˇze existuje mnoho n´avod˚u a je zdarma. Vzhled a jeho chov´an´ı bylo implementov´ano v jazyce HTML / CSS / JS.

1

2.4

S´ıt’ov´

a komunikace

N´asleduj´ıc´ı sekce popisuj´ı s´ıt’ov´e technologie, kter´e byly pouˇzity pˇri implementaci aplikace. Pˇrenos dat je ˇsifrov´an pˇres HTTPS, samotn´a data jsou ve form´atu JSON a autorizace prob´ıh´a pomoc´ı protokolu OAuth.

2.4.1 HTTPS

HTTPS je nadstavba aplikaˇcn´ıho protokolu HTTP. Jedn´a se o klient-server komunikaci, kdy se typicky klient dotazuje a webov´y server mu odpov´ıd´a. HTTP je nestavov´y protokol, coˇz znamen´a, ˇze webov´y server nev´ı, kter´emu klientovi odpov´ıd´a. V d˚usledku toho server nezn´a kontext klienta, coˇz je v nˇekter´ych pˇr´ıpadech kl´ıˇcov´e. Stav klienta se d´a zaruˇcit pouˇzit´ım doˇcasn´ych soubor˚u na stranˇe klienta (cookies) nebo sezen´ım na stranˇe serveru (sessions).

U HTTPS je prohl´ıˇzeˇci typicky pˇred´an poˇzadavek, aby pouˇzil kryptovac´ı protokoly SSL/TLS k pˇrenosu dat, kter´e vyuˇz´ıvaj´ı asymetrick´e ˇsifrov´an´ı. Protokoly SSL/TLS za-braˇnuj´ı podvrhnut´ı zpr´av ˇci jejich odposlech. Nejˇcastˇeji je autentizov´an pouze server a klient z˚ust´av´a neautentizov´an. Pro autentizaci obou komunikuj´ıc´ıch stran je potˇreba nasazen´ı in-frastruktury veˇrejn´ych kl´ıˇc˚u pro klienty.

HTTP poˇzadavek

Protokol HTTPS pracuje s HTTP poˇzadavky a disponuje dvˇema typy zpr´av: poˇzadavek a odpovˇed’. Ve verzi HTTP/1.1 jsou z´akladn´ı metody:

• GET- z´ısk´an´ı obsahu objektu. Data jsou pˇrenesena v ˇc´asti URL jako poˇzadavek

• POST - pˇrid´an´ı dat k obsahu objektu. Data jsou pˇrenesena v tˇele zpr´avy

• HEAD - z´ısk´an´ı hlaviˇcky objektu. Poskytuje metadata o poˇzadovan´em c´ıli

• PUT- nahr´an´ı obsahu souboru na server

• DELETE- smaz´an´ı (ˇc´asti) objektu

MetodyHEADaGETjsou oznaˇcov´any jako bezpeˇcn´e, protoˇze by nemˇely zmˇenit stav serveru. Slouˇz´ı pouze k z´ısk´av´an´ı informac´ı. MetodyPOST,PUTaDELETEjsou urˇceny pro akce, kter´e mohou zmˇenit stav serveru. MetodyPUTaDELETEjsou nav´ıc oznaˇcov´any jako idempotentn´ı, coˇz znamen´a, ˇze v´ıce shodn´ych poˇzadavk˚u by mˇelo m´ıt stejn´y ´uˇcinek jako jeden poˇzadavek. Zasl´an´ı totoˇzn´eho post poˇzadavku v´ıcekr´at za sebou m˚uˇze zp˚usobit neˇz´adouc´ı ´uˇcinky na serveru.

2.4.2 Architektura REST

Architektura rozhran´ı REST (Representational State Transfer) pro distribuovan´e prostˇred´ı je zp˚usob, jak jednoduˇse vytvoˇrit, ˇc´ıst, editovat nebo smazat data pomoc´ı HTTP vol´an´ı. Styl komunikace mus´ı dodrˇzovat tˇechto 6 omezen´ı, viz. [8]:

1. Jednotn´e rozhran´ı (Uniform interface) - rozhran´ı mezi klientem a serverem mus´ı b´yt definov´ano takov´ych zp˚usobem, aby mohly b´yt tyto dvˇe ˇc´asti implementov´any nez´avisle

Z´akladn´ı principy pro jednotn´e rozhran´ı:

• Zdroje dat - jsou koncepˇcnˇe oddˇelen´e od reprezentac´ı, kter´e jsou vr´aceny klien-tovi. Napˇr´ıklad server neodes´ıl´a svou datab´azi, ale poˇsle data serializovan´a do jazyka XML nebo JSON

• Manipulace se zdroji dat - pokud m´a klient opr´avnˇen´ı, tak by mˇel m´ıt dostatek informac´ı k tomu, aby mohl zmˇenit nebo vymazat data na serveru

• Zpracov´an´ı zpr´avy - kaˇzd´a zpr´ava obsahuje i popis, jak ji zpracovat

2. Bezstavovost (State-less) - komunikace mezi klientem a serverem je bezstavov´a. V kaˇzd´em poˇzadavku klienta je specifikov´ano, co pˇresnˇe poˇzaduje. Nevyuˇz´ıv´ame tedy

sessions. To n´am zaruˇc´ı, ˇze stav zdroje dat je konstantn´ı pro kaˇzd´eho klienta, kter´y si o nˇej poˇz´ad´a

3. Mezipamˇet’ (Cacheable) - klienti mohou data ukl´adat do mezipamˇeti. Odpovˇed’ serveru ale mus´ı obsahovat informaci, zda tato data mohou b´yt ukl´ad´ana nebo ne. Spr´avnˇe nastaven´e ukl´ad´an´ı ˇc´asteˇcnˇe eliminuje nˇekter´e klient - server operace

4. Klient - server (Client - server) - rozhran´ı klienta a serveru na sobˇe nejsou z´avisl´a. Klienti nejsou propojeni pˇr´ımo se zdrojem dat a servery tak´e nejsou informov´any o uˇzivatelov´ych stavech

5. Syst´em vrstev (Layered system) - klient nesdˇeluje, zda komunikuje pˇr´ımo s kon-cov´ym serverem. Architektura na stranˇe serveru tak m˚uˇze l´epe rozloˇzit z´atˇeˇz nebo zvyˇsovat ´uroveˇn zabezpeˇcen´ı

6. K´od na poˇz´ad´an´ı(Code on demand) - server tak´e m˚uˇze doˇcasnˇe mˇenit logiku klienta napˇr´ıklad pomoc´ı Java applet˚u nebo Javascriptu. Toto omezen´ı je pouze voliteln´e. Pokud nen´ı v odpovˇedi serveru takto oznaˇcen´e, nem˚uˇzeme komunikaci oznaˇcit jako

RESTfull2.

Vˇsechny zdroje maj´ı vlastn´ı identifik´ator URI, kde REST definuje ˇctyˇri z´akladn´ı ope-race (CRUD) pro manipulaci se zdroji: Create, Read,Update a Delete. Tyto operace jsou namapov´any na HTTP operacePOST,GET,PUTaDELETE. Zdroje mohou m´ıt r˚uzn´e reprezen-tace (JSON, XML, SVG, PDF). REST architektura umoˇzˇnuje snadn´y pˇr´ıstup ke zdroj˚um, kter´ymi mohou b´yt data i stavy aplikace. REST je tedy orientov´an datovˇe, nikoliv pro-cedur´alnˇe (RPC3_).

Moˇznosti autorizace

Vˇetˇsina sluˇzeb typicky vyˇzaduje autorizaci pˇred pˇr´ıstupem ke zdroji dat. Vyuˇz´ıvatsessions

nen´ı povolen´e. Prov´adˇet autorizaci pˇri kaˇzd´em poˇzadavku aˇz na v´yjimeˇcn´e pˇr´ıpady nen´ı spr´avn´a volba. Existuj´ı dva z´akladn´ı koncepty autorizace:

1. Jednoduch´e ovˇeˇren´ı pˇr´ıstupu (HTTP Authentication) - server vyzve pˇristupuj´ıc´ıho klienta, aby v HTTP poˇzadavku poslal tak´e pˇr´ıstupov´e ´udaje (jm´eno a heslo). ´Udaje jsou posl´any jako jeden ˇretˇezec, kter´y je zak´odov´an metodou Base64 a odesl´an s v r´amci HTTP poˇzadavku. Jedn´a se o z´akladn´ı ovˇeˇren´ı pˇr´ıstupu. Data se k´oduj´ı, aby

2

REST je architektonick´e paradigma. Restfull popisuje sluˇzby, kter´e se t´ımto paradigmatem ˇr´ıd´ı 3

se nahradily znaky nepatˇr´ıc´ı do mnoˇziny povolen´ych znak˚u4 _{HTTP. Nejedn´a se tedy}

o zabezpeˇcenou komunikaci.

2. Pouˇz´ıt vestavˇenou sluˇzbu, kter´a v z´asadˇe autorizuje uˇzivatele a vr´at´ı pˇr´ıstupov´ytoken. Tento styl autorizace je pops´an n´ıˇze v t´eto kapitole viz. 2.4.4

Obˇe moˇznosti autorizace maj´ı sv´e v´yhody a nev´yhody. V´yhoda prvn´ıho zp˚usobu je snadn´a implementace a ˇsirok´a podpora napˇr´ıˇc webov´ymi prohl´ıˇzeˇci. V´yhoda druh´eho zp˚usobu je omezen´ı doby pˇr´ıstupu. Pˇr´ıstupov´y kl´ıˇc jednoduˇse vyprˇs´ı a uˇzivatel je nucen prov´est au-torizaci znovu.

2.4.3 JSON

JavaScript Object Notation je form´at pro v´ymˇenu dat. Je zaloˇzen na podmnoˇzinˇe progra-movac´ıho jazyka JavaScript, Standard ECMA-262 3rd Edition - December 1999 [1]. Jedn´a se o ˇst´ıhlejˇs´ı variantu XML form´atu a typicky se pouˇz´ıv´a pro v´ymˇenu dat mezi klientem a serverem ve webov´ych aplikac´ıch. Pˇrestoˇze je JSON odvozen z JavaScriptu, je jazykovˇe nez´avisl´y. Z´apis v JSON je liter´alem v jazyce JavaScript a nen´ı proto potˇreba speci´aln´ı ana-lyz´ator. Vˇsechny prohl´ıˇzeˇce implicitnˇe analyzuj´ı JSON. Data jsou serializov´ana do tˇechto dvou forem:

Struktura v JSON (objekt)

Objekt je definov´an jako neuspoˇr´adan´a mnoˇzina dvojic´ı jm´eno a hodnota. Kaˇzd´y objekt zaˇc´ın´a levou sloˇzenou z´avorkou a konˇc´ı pravou sloˇzenou z´avorkou. Kaˇzd´e jm´eno objektu je oddˇeleno dvojteˇckou, za n´ıˇz je uvedena hodnota. Objekt je oddˇelen ˇc´arkami.

{ : }

,

object

string value

Obr´azek 2.7: Struktura v JSON (objekt)

Kolekce v JSON (pole)

Pole je definov´ano jako uspoˇr´adan´a kolekce hodnot. Pole zaˇc´ın´a levou hranatou z´avorkou a konˇc´ı pravou hranatou z´avorkou. Hodnoty jsou oddˇelen´e ˇc´arkou.

array

[ ]

, value

Hodnota v JSON m˚uˇze nab´yvat n´asleduj´ıc´ı typy: string, number, true, false, null, objekt

nebo pole.

2.4.4 OAuth

Modern´ı autorizaˇcn´ı protokol, kter´y se stal standardem pro zabezpeˇcen´ı RESTov´ych webo-v´ych sluˇzeb. OAuth je otevˇren´y protokol navrˇzen´y Blaine Cookem a Chrisem Messinou. Tento protokol vznikl v roce 2006 a umoˇzˇnuje klientsk´e aplikaci pˇr´ıstup k dat˚um libovoln´e sluˇzby, aniˇz by t´eto aplikaci byly zpˇr´ıstupnˇeny pˇrihlaˇsovac´ı ´udaje. D´ale umoˇzˇnuje vymezit pravomoci jednotliv´ych klientsk´ych aplikac´ı. Aktu´aln´ı verze OAuth 2.0 definuje ˇctyˇri druhy rol´ı [11]:

• uˇzivatel(resource owner) - vlastn´ık chr´anˇen´eho zdroje. Typicky se jedn´a o koncov´eho uˇzivatele, kter´y je schopn´y povolit nebo odepˇr´ıt pˇr´ıstup ke chr´anˇen´emu zdroji (dat˚um)

• sluˇzba (resource server) - poskytovatel a hostitel chr´anˇen´eho zdroje. Tato sluˇzba obsluhuje poˇzadavky (maj´ıc´ıaccess token) ke chr´anˇen´emu zdroji. Ve vˇetˇsinˇe pˇr´ıpad˚u se jedn´a o serverovou sluˇzbu vystavuj´ıc´ı API

• klient(client) - aplikace, kter´a pˇristupuje ke chr´anˇen´emu zdroji s patˇriˇcn´ymi opr´avnˇ e-n´ımi

• autorizaˇcn´ı server (authorization server) - server, kter´y klientovi pˇridˇeluje access token v pˇr´ıpadˇe jeho ´uspˇeˇsn´e autentizace od uˇzivatele. Typicky je autorizaˇcn´ı server souˇc´ast´ı sluˇzby

Princip autorizace aplikace v˚uˇci sluˇzbˇe, d´ale jen webov´e API je n´asleduj´ıc´ı:

Aplikace Webové API

Přesměrování uživatele na webové API 1 Uživatelse úspěšně přihlásí 2 Přesměrování uživatele zpět do aplikace 3 Odeslání access tokenu 5 Žádosto zaslání access token 4 Žádosto data 6

Obr´azek 2.9: Autorizace protokolu OAuth

2. Webov´e API potvrzuje validitu aplikace

3. Aplikace (uˇzivatel) je pˇresmˇerov´ana na pˇrihlaˇsovac´ı br´anu webov´eho API a v poˇzadavku pˇred´arequest token

4. Po pˇrihl´aˇsen´ı na stranˇe webov´eho API je uˇzivatel pˇresmˇerov´an zpˇet do aplikace. Pot´e aplikace zaˇz´ad´a oaccess token

5. Webov´e API vygenerujeaccess token a poˇsle ho zpˇet aplikaci 6. Aplikace poˇz´ad´a saccess tokenem o data

Specifikace OAuth detailnˇe popisuje v´ymˇenu pˇr´ıstupov´ych kl´ıˇc˚u (token˚u). Nen´ı zde pops´ana komunikace mezi klientem (sluˇzbou) a webov´ym API [7]. OAuth nen´ı spjat´y s konkr´etn´ım typem API (SOAP, REST, WCF atd.). Je pouze omezen na HTTPS pro-tokol.

Kapitola 3

Architektura syst´

emu

3.1

Sch´

ema a ´

uloha jednotliv´

ych element˚

u

Cel´y syst´em se skl´ad´a z pˇeti ˇc´ast´ı: datab´aze, webov´eho API, WNS a aplikace. Po spuˇstˇen´ı aplikace je uˇzivatel vyzv´an k zad´an´ı pˇr´ıstupov´eho kl´ıˇce. Uˇzivatel tedy pˇristoup´ı v prohl´ıˇzeˇci na jeden z endpoint˚u webov´eho API, kde si po pˇrihl´aˇsen´ı nech´a vygenerovat kl´ıˇc, kter´y vloˇz´ı do aplikace. Webov´e API naslouch´a/odpov´ıd´a na HTTPS poˇzadavky. Webov´e API je pˇr´ımo propojen´e s datab´az´ı, na kter´e se nach´az´ı chr´anˇen´e zdroje dat. K datab´azi tedy uˇzivatel nem´a pˇr´ıstup. Po ´uspˇeˇsn´e autorizaci uˇzivatele webov´e API kontaktuje sluˇzbu WNS, kter´a pˇrepoˇsle notifikaci z webov´eho API do aplikace. WNS je tak´e vyuˇz´ıv´ana pro informov´an´ı o aktualizaci dat. Webov´e API pˇri zmˇenˇe dat kontaktuje WNS, kter´e pˇrepoˇsle notifikaci do aplikace 3.2. Samotn´a data pro grafick´e komponenty jsou pˇren´aˇsena ve form´atu JSON. S´ıt’ov´e pˇripojen´ı aplikace k webov´emu API je r˚uzn´e v z´avislosti na dostupn´e technologii (GRPS, 3G, LTE, Wifi, LAN, . . . ).

Obr´azek 3.1: Sch´ema architektury

Webov´e API a datab´aze

V poˇzadavc´ıch firmy C´ıgler Software je pouze v´yvoj aplikace a n´asledn´e napojen´ı na jejich webov´e API. Po dohodˇe s vedouc´ım bakal´aˇrsk´e pr´ace jsem pro demonstraˇcn´ı ´uˇcely

imple-mentovat vlastn´ı webov´e API. Webov´e API naslouch´a na jednotliv´ych endpoints1 _{a podle}

poˇzadavk˚u odpov´ıd´a. Data jsou do aplikace generov´ana pˇr´ımo v k´odu a nejsou perzistentnˇe uloˇzena. Autorizaˇcn´ı ´udaje viz 3.2, stejnˇe jako stav aplikace jsou uloˇzen´e v datab´azi.

WNS

Sluˇzba Push Notification Services spoleˇcnosti Microsoft, kter´a zajist´ı doruˇcen´ı notifikace pˇr´ımo do dan´eho zaˇr´ızen´ı. Pro ´uspˇeˇsn´e doruˇcen´ı notifikace je nutn´e autorizovat vlastn´ı webov´e API oproti WNS. Autorizace prob´ıh´a pˇres protokol OAuth 2.0 viz 2.4.4.

3.2

Notifikace

Jednou z moˇznost´ı pˇred´an´ı informace uˇzivateli/aplikaci je stav, kdy se aplikace aktivnˇe dotazuje webov´eho API, zda nedoˇslo ke zmˇen´am. V´yhoda tohoto ˇreˇsen´ı je nez´avislost na sluˇzb´ach tˇret´ı strany. V praxi to vˇsak vede ke zbyteˇcn´emu zatˇeˇzov´an´ı s´ıtˇe a vyb´ıjen´ı baterie na koncov´em zaˇr´ızen´ı. Druh´a moˇznost je zasl´an´ıpush notifikace, kdy aplikace je v pasivn´ım reˇzimu a jen naslouch´a. Po konzultac´ıch s vedouc´ım bakal´aˇrsk´e pr´ace a z´astupcem z firmy C´ıgler Software byla zvolena druh´a moˇznost.

WNS neinformuje webov´e API o tom, zda byla notifikace doruˇcena do zaˇr´ızen´ı. Po-kud je aplikace offline, WNS uloˇz´ı maxim´alnˇe 5 posledn´ıch notifikac´ı. Doruˇcen´ı nastane, jakmile aplikace pˇrejde do stavu online. Microsoft negarantuje ´uspˇeˇsn´e odesl´an´ı notifikac´ı. V pˇr´ıpadˇe, ˇze se nepodaˇr´ı doruˇcit notifikaci do tˇr´ı dn˚u, sluˇzba WNS notifikace smaˇze.

Postup autorizace pro WNS

Pˇred zasl´an´ım notifikace je nutn´e autorizovat webov´e API oproti sluˇzbˇe WNS. Autorizace prob´ıh´a dle protokolu OAuth 2.0 2.4.4. Webov´e API nejprve poˇz´ad´a WNS o access token. Pro z´ısk´an´ıaccess tokenumus´ı webov´e API pˇredat identifikaˇcn´ı ´udaje aplikace. Identifikaˇcn´ı ´

udaje jsou vygenerov´any po zaregistrov´an´ı aplikace doWindows Store. Tento krok provede zodpovˇedn´a osoba, nejˇcastˇeji v´yvoj´aˇr aplikace. Identifikaˇcn´ı ´udaje se jiˇz nezmˇen´ı a skl´adaj´ı se ze dvou poloˇzek:Package Security Identifier aClient Secret. Z´ısk´an´ı tˇechto dvou poloˇzek je uvedeno v kapitole 5.1. Po z´ısk´an´ıaccess tokenuje spoleˇcnˇe s tokenem zasl´an inotification channel, coˇz je adresa, na kter´e aplikace naslouch´a. Pokud jeaccess token st´ale platn´y, WNS zaˇsle notifikaci pˇr´ımo do pˇr´ısluˇsn´eho zaˇr´ızen´ı. Access token m´a omezenou dobu platnosti a webov´e API je o tom informov´ano HTTP statusem 400. Po vyprˇsen´ı je potˇreba webov´e API znovu autorizovat. Microsoft neuv´ad´ı pˇresnou dobu platnosti. Stejnˇe tak m´a omezenou dobu platnosti i notification channel a webov´e API je o tom informov´ano HTTP statusem 410. Dle MSDN [9] je doba platnostinotification channel zhruba 30 dn´ı. Sch´ema a postup v jednotliv´ych bodech je uveden n´ıˇze:

Obr´azek 3.2: Workflow autorizace a zasl´an´ı notifikace

1. Aplikace Money Dashboard S5 poˇsle poˇzadavekNotification Client Platform, d´ale jen NCP onotification channel, d´ale jen NC

2. NCP zaˇz´ad´a WNS o vytvoˇren´ı NC. Tento NC je posl´an zpˇet do volaj´ıc´ıho zaˇr´ızen´ı formouUniform Resource Identifier, d´al jen URI

3. NCP vr´at´ı URI aplikaci Money Dashboard S5

4. Money Dashboard S5 poˇsle URI na webov´e API, kde se uloˇz´ı do datab´aze. Tento krok je cel´y pod kontrolou v´yvoj´aˇre aplikace

5. Nastane-li stav, kdy je nutn´e poslat notifikaci do aplikace, pak se webov´e API auto-rizuje oproti WNS a zaˇz´ad´a o zasl´an´ı notifikace

6. WNS obdrˇz´ı ˇz´adost o notifikaci a pˇrepoˇsle ji do NCP, kter´e doruˇc´ı notifikaci pˇr´ımo do aplikace

Kapitola 4

Komunikaˇ

cn´ı protokol

4.1

Z´

akladn´ı prvky komunikace

Komunikace mezi webov´ym API a klientskou aplikac´ı je zprostˇredkov´ana HTTPS dotazy. Velk´y d˚uraz je kladen na minim´aln´ı pˇrenos dat mezi tˇemito komunikaˇcn´ımi body. Aplikace vyuˇz´ıv´a architekturu klient-server. Aplikace jako klient, webov´e API jako server. Aplikace je nejprve autorizov´ana a pot´e jsou j´ı zasl´ana data. Data jsou serializov´ana na stranˇe webov´eho API do JSONu a pot´e deserializov´ana v aplikaci.

4.2

Autorizace

Po spuˇstˇen´ı aplikace je uˇzivatel poˇz´ad´an o zad´an´ı identifikaˇcn´ıho kl´ıˇce, d´ale jen consumer key. Consumer key generuje autoritativn´ı webov´e API. Uˇzivatel mus´ı b´yt nejprve zare-gistrov´an u firmy C´ıgler Software, kde z´ısk´a pˇrihlaˇsovac´ı ´udaje pro autorizaci na stranˇe webov´eho API. Grafick´e rozhran´ı pro registraci nebylo implementov´ano, pˇrihlaˇsovac´ı ´udaje jsou vkl´ad´any do datab´aze manu´alnˇe. Po pˇrihl´aˇsen´ı na port´alu webov´eho API je moˇzn´e si vygenerovat kl´ıˇc.Consumer keyje uloˇzen do datab´aze. Uˇzivatel si tento kl´ıˇc uloˇz´ı a pˇrejde do aplikace Dashoboard Money S5, kde kl´ıˇc vloˇz´ı. Po zad´an´ı kl´ıˇce aplikace kontaktuje webov´e API a spolu s kl´ıˇcem se u n´ı identifikuje. D´ıkyconsumer key je moˇzn´e po prvn´ım spuˇstˇen´ı rozpoznat uˇzivatele, kter´y kl´ıˇc zadal. Pokud uˇzivatel nepouˇzije kl´ıˇc do tˇr´ı dn˚u, je kl´ıˇc z da-tab´aze odstranˇen. Pˇri druh´em a dalˇs´ım spuˇstˇen´ı aplikace jiˇz nen´ı nutn´e zadat consumer key. Aplikace si pamatuje access token, kter´y byl vygenerovan´y po pˇrihl´aˇsen´ı uˇzivatele. Poˇsle access token, webov´e API v datab´azi vyhled´a uˇzivatele, kter´emu naposledy pˇridˇelilo tento kl´ıˇc a odpov´ı aplikaci s nov´ym access tokenem. Proces vygenerov´an´ıconsumer key

Obr´azek 4.1: Workflow vygenerov´an´ı consumer key

1. Uˇzivatel se pˇrihl´as´ı na port´alu webov´eho API a vygeneruje siconsumer key

2. Tento kl´ıˇc vloˇz´ı do aplikace

3. Aplikace kontaktuje webov´e API spolu s consumer key a pˇrejde do dalˇs´ıho stavu Pˇredchoz´ı odstavec se zab´yval prvn´ım pˇrihl´aˇsen´ım uˇzivatele. Nyn´ı bude pops´an proces autorizace, kdy uˇzivatel vloˇzil consumer key a stiskl potvrzen´ı. Komunikace se skl´ad´a ze ˇ

ctyˇr ´uˇcastn´ık˚u: Resource owner, Application,Resource server a WNS. Resource owner je uˇzivatel, kter´y se autorizuje uResource Server a d´av´a svolen´ı pˇr´ıstupuApplication k jeho dat˚um. Application, t´eˇz klient, je aplikace, kter´a ˇz´ad´a o pˇr´ıstup k uˇzivatelov´ym dat˚um.

Resource server (webov´e API) je autorita, kter´a zprostˇredkov´av´a aplikaci pˇr´ıstup k dat˚um. WNS je sluˇzba, kter´a poˇsle notifikaci aplikaci o tom, ˇze se uˇzivatel ´uspˇeˇsnˇe autorizoval. Cel´y proces je sch´ematicky nakreslen a pot´e pops´an na n´asleduj´ıc´ım obr´azku.

Popis jednotliv´ych krok˚u autorizace:

• A - request token

Aplikace poˇsle ˇz´adost o token. Souˇc´ast´ı tokenu je consumer key a adresa, na kter´e aplikace naslouch´a.

• B - send token

Webov´e API poˇsle odpovˇed’ s tokenem, se kter´ym bude uˇzivatel pˇresmˇerov´an na rozhran´ı webov´eho API pro pˇrihl´aˇsen´ı.

• C - redirection

Uˇzivatel je spoleˇcnˇe s tokenem pˇresmˇerov´an na rozhran´ı webov´eho API pro pˇrihlaˇsov´an´ı. Zde zad´a sv´e pˇrihlaˇsovac´ı ´udaje.

• D - request notif

Po ´uspˇeˇsn´em pˇrihl´aˇsen´ı poˇz´ad´a webov´e API sluˇzbu WNS o zasl´an´ıpush notifikace.

• E - send notif

WNS poˇsle push notifikaci do aplikace.

• F - redirection back

Aplikace obdrˇz´ı notifikaci a pˇresmˇeruje uˇzivatele na obrazovku vyz´yvaj´ıc´ı k vytvoˇren´ı pinu.

• G - req. access token

Aplikace poˇz´ad´a oaccess token. Tento token je vygenerov´an pˇri pˇrihl´aˇsen´ı uˇzivatele na rozhran´ı webov´eho API. Zpˇr´ıstupnˇen´ı dat pomoc´ıaccess tokenu je ˇcasov´e limitovan´e.

• H - grant access token

Webov´e API poˇsleaccess token, se kter´ym bude aplikace pˇristupovat dat˚um.

• I get data

Aplikace poˇsle poˇzadavek metodouGET, kde specifikuje data, kter´a j´ı maj´ı b´yt zasl´ana. Souˇc´ast´ı poˇzadavku je access token.

• I send data

Webov´e API ovˇeˇr´ıaccess token a metodou POST poˇsle zpˇet poˇzadovan´a data.

4.3

Metody webov´

eho API

Prvn´ı ˇc´ast podkapitoly obsahuje struˇcn´y popis metod, typ HTTPS dotazu, odpovˇedi a se-znam vˇsech parametr˚u.

Tabulka metod:

n´azev metody HTTP dotaz HTTP odpovˇed’ popis funkcionality

check credentials GET POST kontrola validity aplikace auth redirect GET, POST POST autorizace uˇzivatele get access token GET POST zpˇr´ıstupnˇen´ıaccess token

Seznam vˇsech parametr˚u metod:

n´azev parametru typ HTTP popis funkcionality

method GET n´azev metody, kter´a m´a b´yt zavol´ana app id GET ˇc´ıslo, kter´e identifikuje danou aplikaci version GET verze aplikace

consumer key GET ˇretˇezec identifikuj´ıc´ı uˇzivatele

request token GET pˇr´ıstupov´y kl´ıˇc pro autorizaci uˇzivatele

component GET n´azev komponenty (graf, dlaˇzdice, tabulka, . . . ) id GET unik´atn´ı ˇc´ıslo urˇcuj´ıc´ı danou komponentu access token GET pˇr´ıstupov´y kl´ıˇc k dat˚um

notif channel POST notifikaˇcn´ı adresa aplikace

uri POST adresa aplikace pro Windows Store cs POST pˇr´ıstupov´y kl´ıˇc aplikace

Detailnˇejˇs´ı popis metod:

1. check credentials

Prvn´ı metoda nejprve zkontroluje identifik´ator aplikace a verzi. Obˇe tyto poloˇzky jsou uloˇzen´e v datab´azi - tabulka Auth apps. D´ale zkontroluje consumer key, kter´y je uloˇzen v tabulceAuth UserCred.

GET parametry: method, app id, consumer id, version

Vyjma chyb ze strany poskytovatele sluˇzby vrac´ı metoda aplikaci jednu ze ˇctyˇr odpovˇed´ı:

HTTP status parametry odpovˇedi popis funkcionality

200 id=1&request token=<string> pˇr´ıstupov´y kl´ıˇc uˇzivatele 200 id=2&request token=<string> pˇr´ıstupov´y kl´ıˇc uˇzivatele,

&possible upgrade moˇzn´a aktualizace 200 id=3&must upgrade nutnost aktualizace

200 id=4&app not supported aplikace nen´ı podporov´ana Pˇr´ıklad dotazu:

https://www.example.com/dialog/auth.php/?method=check_credentials&app_id=1 &consumer_key=56ar20&version=1

2. check credentials

Druh´a metoda slouˇz´ı k autorizaci uˇzivatele. Tato metoda obsahuje parametry v GETˇc´asti i

POST1 ˇc´asti HTTP zpr´avy, viz 3.2.

GET parametry: method, request token

1

POST - channel, uri a client secret - tvoˇr´ı pˇr´ıliˇs dlouh´y ˇretˇezec, kter´y pˇresahuje d´elku bˇeˇznˇe pos´ılan´ych dat pomoc´ı metody GET

POST parametry:notif channel, uri, cs

Webov´e API nevrac´ı odpovˇed’, ale poˇz´ad´a WNS o zasl´an´ı notifikace do aplikace. Notifikace je posl´ana, jen pokud se uˇzivatel ´uspˇeˇsnˇe autorizuje. Obdrˇzen´a zpr´ava od WNS m´a tvar:

HTTP status parametry odpovˇedi popis funkcionality

200 type=1&OK autorizace probˇehla v poˇr´adku Pˇr´ıklad dotazu:

https://www.example.com/dialog/auth_redirect.php/?method=auth_redirect &request_token=49a73c27a30421c650dde7aca2ab005d

body: { notif_channel = https://msapp.com/42 uri = https://myapp.com/xyz42xyz

cs = 123789852 }

3. get access token

Tˇret´ı metoda vrac´ı aplikaci access token. Ten je vygenerov´an po pˇrihl´aˇsen´ı na stranˇe webov´eho API a m´a omezenou dobu platnosti.

GET parametry: method, request token

Vyjma chyb ze strany poskytovatele sluˇzby vrac´ı metoda aplikaci access token:

HTTP status parametry odpovˇedi popis funkcionality

200 id=1&access token=<string> pˇr´ıstupov´y kl´ıˇc k dat˚um Pˇr´ıklad dotazu:

https://www.example.com/dialog/auth.php/?method=get_access_token& &request_token=49a73c27a30421c650dde7aca2ab005d

4. get data

ˇ

Ctvrt´a metoda vrac´ı aplikaci data ve form´atu JSON. Konkr´etn´ı data aplikace rozpozn´a z hodnot parametr˚u uveden´ych vGETˇc´asti dotazu.

GET parametry: method, component, id, access token

Vyjma chyb ze strany poskytovatele sluˇzby vrac´ı metoda aplikaci jednu ze dvou odpovˇed´ı: Pˇr´ıklad dotazu:

HTTP status parametry odpovˇedi popis funkcionality

200 JSON data data pro jednu komponentu

410 access token expired vyprˇsen´ı pˇr´ıstupov´eho kl´ıˇce k dat˚um

4.4

Aktualizace dat

Pˇri zmˇenˇe dat zaˇz´ad´a webov´e API sluˇzbu WNS o zasl´an´ıpush notifikace. V tˇele notifikace je uveden identifik´ator notifikace, typ komponenty a identifikaˇcn´ı ˇc´ıslo komponenty. Pˇr´ıklad notifikace je uveden n´ıˇze:

type=2&component=table&id=3

Po pˇrijmut´ıpush notifikace aplikace poˇz´ad´a webov´e API pomoc´ı metodyget datao data. Jako parametry zvol´ı ´udaje, kter´e pˇriˇsly v tˇele notifikace (comphonent aid).

4.5

Struktura pˇ

renesen´

ych dat

Po zasl´an´ı dotazu aplikace na webov´e API jsou dle pˇr´ısluˇsn´eho endpointu a metody pˇrenesena data v serializaˇcn´ım jazyce JSON nebo v jazyce HTML. Kaˇzd´a grafick´a komponenta (graf, tabulka, dlaˇzdice, . . . ) je na stranˇe webov´eho API zastoupena tˇr´ıdou, kter´a obsahuje data. Data jsou uloˇzena do jednoho pole, kter´e je serializov´ano a pˇreposl´ano aplikaci. Poloˇzka pole obsahuje data napˇr´ıklad pro jeden ˇr´adek tabulky, jeden rok v grafu, atd.

Serializovan´e pole pro tabulkuProdukt˚u o dvou ˇr´adc´ıch by vypadala takto:

[{"nameCompany":"jm´eno spoleˇcnosti A","profit":"89980","veer":"52980", "year":2013},{"nameCompany":"jm´eno spoleˇcnosti A1","profit":"89981", "veer":"52981", "year":2013}]

A v´ysledn´a tabulka v aplikaci takto:

Obr´azek 4.3: Uk´azka tabulky produkt˚u

Mimo tabulky Produkt˚u a Speci´aln´ı dlaˇzdice jsou data pˇrenesena vˇzdy po kliknut´ı na grafickou komponentu v aplikaci. U tabulky Produkt˚u je moˇzn´e rozkliknout kaˇzd´y ˇr´adek tabulky a zobrazit detailnˇejˇs´ı informace. Detailnˇejˇs´ı informace jsou do aplikace pos´ıl´any pr´avˇe aˇz po rozkliknut´ı. U Speci´aln´ı dlaˇzdice jsou data pˇren´aˇsena ve form´atu HTML.

Kapitola 5

Implementace

5.1

Push notifikace

Notifikace m˚uˇzeme z hlediska implementace rozdˇelit do dvou ˇc´ast´ı. Prvn´ı ˇc´ast je implemen-tace na stranˇe webov´eho API v jazyce PHP a druh´a ˇc´ast je na stranˇe aplikace v jazyce C#_{. Fundament´aln´ım zdrojem informac´ı se stala demonstraˇcn´ı videa od sdruˇzen´ı TechEnd}

Austria 2014. Nejprve byla implementov´ana notifikace v aplikaci. Spr´avn´e fungov´an´ı bylo ovˇeˇreno testovac´ım serverem1. Tento server nen´ı uveden v ofici´aln´ıch dokumentac´ıch od Microsoftu, avˇsak mnoh´e n´avody se na nˇej odkazuj´ı.

Webov´e API

Pro kontaktov´an´ı WNS sluˇzby 3.2 potˇrebuje webov´e API identifikaˇcn´ı ´udaje aplikace a ad-resu, na kter´e naslouch´a. Identifikaˇcn´ı ´udaje jsou dostupn´e po zaregistrov´an´ı aplikace do

Windows Store. Jedn´a se o zaregistrov´an´ı, nikoliv zveˇrejnˇen´ı produktu. Pro zaregistrov´an´ı je nutn´e disponovat ´uˇctem od Microsoftu a m´ıt pro aplikaci n´azev, kter´y je jedineˇcn´y v r´amci cel´ehoWindows Store.

Spr´avu notifikac´ı m´a na starost tˇr´ıda WnsNotif. V konstruktoru t´eto tˇr´ıdy dojde k au-torizaci u sluˇzby WNS dle protokolu OAuth 2.4.4. Pˇred odesl´an´ım ˇz´adosti orequest token

je nezbytn´e z´ıskat identifikaˇcn´ı ´udaje o aplikaci z datab´aze, coˇz je realizov´ano metodou

SetCredentialsFromDB. Rozpozn´an´ı uˇzivatele probˇehne podle ID vytaˇzen´eho z datab´aze, kter´e je pˇred´ano v parametru konstruktoru. Po vytvoˇren´ı instance m´a webov´e API v da-tab´azi uloˇzenaccess token, kter´ym se bude pro zasl´an´ı notifikace autorizovat u WNS. K vy-tvoˇren´ı instance dojde po pˇrihl´aˇsen´ı uˇzivatele na port´alu webov´eho API. Pˇrihlaˇsovac´ı for-mul´aˇr spoleˇcnˇe se stavem po pˇrihl´aˇsen´ı je v pˇr´ıloze C.1.

Pro rychlou anal´yzu pˇr´ıpadn´ych probl´em˚u je kromˇe informace o ´uspˇeˇsn´em pˇrihl´aˇsen´ı uˇzivatele uveden tak´e v´ysledek autorizace webov´eho API oproti WNS. V´ysledek je HTTPS status, kter´y webov´e API obdrˇz´ı po zasl´an´ı ˇz´adosti o notifikaci. Metoda pro odesl´an´ı notifi-kace je nazv´anaSendRawNotifa v parametru jsou j´ı pˇred´ana data, kter´a maj´ı b´yt odesl´ana do aplikace. V hlaviˇcce HTTPS poˇzadavku je uveden typ obsahu, d´elka zpr´avy, typ no-tifikace a koneˇcnˇe access token. Inicializace, odesl´an´ı a uzavˇren´ı poˇzadavku na WNS je uskuteˇcnˇeno vestavˇen´ymi metodami PHPcurl init,curl setopt acurl close.

Aplikace

Prvn´ı krok pro ´uspˇeˇsn´e pˇrijet´ıpush notifikace je informovat NCP, o samotn´e aplikaci. Nej-prve je nutn´e vytvoˇrit projekt typu Windows Run Time Component. Projekt je v ˇreˇsen´ı aplikace nazv´an RawPushBGTask a obsahuje tˇr´ıdu PushBGTask. Instance t´eto tˇr´ıdy je vy-tvoˇrena ve tˇr´ıdˇeAuthorization, kter´a je um´ıstˇena v projektuDashboard.Windows. Postup aplikace pro pˇr´ıjem notifikac´ı je zn´azornˇen sekvenˇcn´ım diagramem s podrobnˇejˇs´ım popisem n´ıˇze:

PUSHBGTASK.CS

Initilialize() DeliverNotication() IsTaskRegistered()

EnableTask() Register()

DisableTask()

AUTHORIZATION.CS PUSHNOTIFICATION.CS

Obr´azek 5.1: Postup pro pˇr´ıjem notifikac´ı

Po pˇresmˇerov´an´ı na pˇrihlaˇsovac´ı formul´aˇr webov´eho API je ve tˇr´ıdˇe Authorization

zavol´ana metoda IsTaskRegistered, kter´a zjist´ı, zda bylo vl´akno pro pˇr´ıjem notifikac´ı jiˇz vytvoˇreno. Vl´akno p˚usob´ı mimo aplikaci a pˇri nestandardn´ım vypnut´ı, napˇr´ıklad p´adu apli-kace, se m˚uˇze st´at, ˇze se z vl´akna stane sirotek. Pˇri kaˇzd´em spuˇstˇen´ı aplikace je tedy ovˇeˇreno, zda takov´eto vl´akno jiˇz neexistuje. Rozpozn´an´ı vl´akna se uskuteˇcn´ı podle jm´ena, kter´e uvede v´yvoj´aˇr. Neexistuje-li vl´akno, pak je zavol´ana metoda Register. Zde je pojmenov´ano, re-gistrov´ano a n´aslednˇe vytvoˇreno asynchronn´ı vl´akno, kter´e je spravov´ano NCP. Pot´e je ve tˇr´ıdˇe Authorizationzavol´ana metodaEnableTask, kter´a spust´ı zaregistrovan´e vl´akno. Souˇcasnˇe se zavol´a metoda Initialize, kter´a vytvoˇr´ıchannel (uri identifik´ator aplikace). Koneˇcnˇe je zaregistrov´ana ud´alostsharedPushComponent deliverNotifpro pˇr´ıjem notifi-kac´ı. Je-li aplikace ukonˇcena, pak je zavol´ana metodaDisableTask, kter´a vl´akno pro pˇr´ıjem notifikac´ı zruˇs´ı.

in-strukc´ı slouˇz´ıc´ıch k pˇresmˇerov´an´ı uˇzivatele na obrazovku vyz´yvaj´ıc´ı k zad´an´ı pinu, na-stala v´yjimka. Pˇri spuˇstˇen´ı aplikace vznikne standardnˇe vl´akno pro vykreslov´an´ı a interakci s uˇzivatelem, d´ale jen UI vl´akno. Jakmile program´ator vytvoˇr´ı dalˇs´ı vl´akno a pokus´ı se pˇristoupit k promˇenn´ym, kter´e vlastn´ı UI vl´akno, tak program vygeneruje v´yˇse zm´ınˇenou v´yjimku. ˇReˇsen´ım je asynchronnˇe pˇristoupit k j´adru aplikace a poˇz´adat o zavol´an´ı UI vl´akna [4].

V souhrnupush notifikace znamenaj´ı vytvoˇren´ı a zaregistrov´an´ı asynchronn´ıho vl´akna, kter´e notifikaci doprav´ı do aplikace. Aplikace vyuˇz´ıv´a notifikace typu raw, kter´e umoˇzˇnuj´ı poslat jak´ykoliv obsah.

5.2

Autorizace

N´asleduj´ıc´ı diagram popisuje pr˚ubˇeh autorizace aplikace. Podrobn´y popis je uveden v textu pod diagramem.

Obr´azek 5.2: Diagram pr˚ubˇehu autorizace

Po spuˇstˇen´ı aplikace probˇehne autorizace v nˇekolika kroc´ıch. Prvn´ı krok autorizace je na ´urovni uˇzivatele, kdy uˇzivatel mus´ı zadat unik´atn´ı identifikaˇcn´ı ˇretˇezec vygenerovan´y

Check app credentials, ve kter´em jsou zkontrolov´any ´udaje o aplikaci. Ovˇeˇren´ı validity aplikace je implementov´ano v metodˇe Check app credentials, tˇr´ıdaOAuth. Dle odpovˇedi webov´eho API pˇrejde do dalˇs´ıho stavu. Je-li vˇse v poˇr´adku, zkontroluje se existence pinu. Metody pro pr´aci s pinem jsou pops´any n´ıˇze v t´eto kapitole. Existuje-li pin, pak je uˇzivateli zobrazena obrazovka s ˇz´adost´ı o zad´an´ı pinu. Zde m˚uˇze zadat pin z kl´avesnice nebo pouˇz´ıt virtu´aln´ı ˇc´ıseln´ık. Metody pro pr´aci s pinem jsou implementov´any ve tˇr´ıdˇeLockScreen. Pro zad´av´an´ı pinu je pouˇzita vestavˇen´a komponenta PasswordBox. Zp˚usob zad´av´an´ı pinu byl inspirov´an u operaˇcn´ıho syst´emu Windows. Jakmile uˇzivatel zad´a 4 ˇc´ıslice, je pin zkontro-lov´an.

Pokud pin neexistuje, je vytvoˇrena instance tˇr´ıdyAuthorizationa uˇzivatel je pˇresmˇerov´an na pˇrihlaˇsovac´ı port´al webov´eho API. Zde zad´a sv´e pˇrihlaˇsovac´ı ´udaje. Aplikace je nyn´ı v pasivn´ım m´odu. Pro zmˇenu stavu mus´ı obdrˇzet push notifikaci. Po obdrˇzen´ı notifikace je uˇzivateli zobrazena obrazovka s ˇz´adost´ı o vytvoˇren´ı pinu. Aplikace se nach´az´ı ve stavu

pin init.

Po zad´an´ı nebo vytvoˇren´ı pinu aplikace poˇz´ad´a oaccess token. Tato metoda je opˇet imple-mentov´ana ve tˇr´ıdˇe Oautha nese n´azev GetAccessToken. Pokud vˇse probˇehne v poˇr´adku, aplikace pˇrech´az´ı do stavuget data, ve kter´em se zavol´a metoda GetDataFromEndpoint. Implementace t´eto metody je uvedena v b´azov´e tˇr´ıdˇe DataModel, ze kter´e dˇed´ı kaˇzd´y gra-fick´y prvek zobrazen´y v dashboardu. Metodˇe je pˇred´an ˇretˇezec, ve kter´em je uvedena adresa na pˇr´ısluˇsn´yendpoint, od nˇehoˇz se oˇcek´avaj´ı data. Nepodaˇr´ı-li se obdrˇzet do 3 vteˇrinaccess token, aplikace pˇrech´az´ı do stavu check offline data. V tomto bodˇe se vytvoˇr´ı instance tˇr´ıdy OfflineData. Na z´akladˇe n´avratov´e hodnoty metody IsOfflineDataAvaiable do-jde/nedojde ke zobrazen´ı offline dat.

5.3

Security Vault

Pin zadan´y uˇzivatelem je lok´alnˇe uloˇzen tak, aby jej bylo moˇzn´e z´ıskat i po vypnut´ı a opˇetovn´em zapnut´ı aplikace. Pˇri uloˇzen´ı jsou hodnoty zaˇsifrov´any. ˇSifrov´an´ı a pˇr´ıstup je v pln´e moci operaˇcn´ıho syst´emu, kter´y vyuˇz´ıv´a stejn´ych sluˇzeb pˇri pˇrihl´aˇsen´ı uˇzivatele do Windows.

Pro uloˇzen´ı pinu byla vytvoˇrena tˇr´ıda SecurityVault. Tˇr´ıda vyuˇz´ıv´a rozhran´ı

Windows.Security.Credentials. Rozhran´ı je podporov´ano u operaˇcn´ıho syst´emu Win-dows a WinWin-dows Phone. Slouˇz´ı k uloˇzen´ı a spr´avˇe hesel. Tˇr´ıda disponuje metodou

AddIntoVault, kter´a vytvoˇr´ı instanci PasswordVault. Pro uloˇzen´ı hesla je nutn´e obecnˇe specifikovat n´azev aplikace, uˇzivatele a heslo. V naˇsem pˇr´ıpadˇe je za uˇzivatele dosazen ˇretˇezec ”pin”a heslo je uˇzivatel˚uv pin. ´Udaje jsou zaˇsifrov´any a vloˇzeny do bezpeˇcnostn´ıho trezoru. Hledat a mazat pin lze podle n´azvu aplikace a identifikaˇcn´ıho ˇretˇezce ”pin”. K to-muto ´uˇcelu slouˇz´ı metody GetValueFromVaulta DeleteValueFromVault.

5.4

Offline stav

Inicializace a detekce

Pˇri spuˇstˇen´ı aplikace je vytvoˇrena instance tˇr´ıdyCheckConnection, kter´a obsahuje metody pro identifikaci pˇripojen´ı k internetu. V konstruktoru je inicializov´an a spuˇstˇen ˇcasovaˇc

hlavn´ı vl´akno, kter´e v metodˇetimer Tickvykon´a poˇzadovan´e instrukce. Interval je v apli-kaci nastaven na 5 vteˇrin. Kaˇzd´ych 5 vteˇrin je tedy zkontrolov´ano, zda je aplikace pˇripojena k internetu. Tomuto ´uˇcelu slouˇz´ı metoda TryConnection.

Prvn´ı verze detekce pˇripojen´ı bylo zasl´an´ı HTTP dotazu na jeden z endpoint˚u webov´eho API a pokud nepˇriˇsla odpovˇed’ do deseti vteˇrin, pˇreˇsla aplikace do stavu offline. Tento zp˚usob zbyteˇcnˇe zatˇeˇzuje zaˇr´ızen´ı, a tak´e zvyˇsuje objem pˇrenesen´ych dat. Metoda byla optimalizov´ana a v koneˇcn´e verzi vyuˇz´ıv´a vestavˇen´ych metod NetworkInformation, kter´e kontroluj´ı, zda je zaˇr´ızen´ı pˇripojeno k nˇejak´emu profilu. Komunikace tedy prob´ıh´a v´yhradnˇe uvnitˇr zaˇr´ızen´ı mezi aplikac´ı a operaˇcn´ım syst´emem.

Upozornˇen´ı uˇzivatele

Pˇrejde-li aplikace do offline stavu, je o tom uˇzivatel informov´an nˇekolika zmˇenami. Prvn´ı rozd´ıl je z´amˇena ˇcerven´e liˇsty na ˇsedou. Souˇcasnˇe se v prav´em horn´ım rohu objev´ı pulzuj´ıc´ı ikona wifi s informativn´ım textem. Efekt pulzov´an´ı byl doc´ılen animac´ıDoubleAnimation, kter´a se po vytvoˇren´ı vloˇz´ı doStoryBoard. StoryBoardje kontejner, do kter´eho je moˇzn´e pˇridat v´ıce animac´ı a tyto animace pot´e jednoduˇse spustit metodou Begin. Animovan´a vlastnost objektu (ikony) je pr˚uhlednost. Pˇr´ıklad zmˇeny sch´ematu a objeven´ı ikony je uve-den n´ıˇze.

Obr´azek 5.3: Online a offline stav hlavn´ı liˇsty

Tato zmˇena se projev´ı v z´ahlav´ı aplikace a je stejn´a pro vˇsechny zobrazen´e str´anky. Po kliknut´ı napˇr´ıklad na dlaˇzdici je vpravo nad hlavn´ım obsahem uvedeno ˇcasov´e raz´ıtko posledn´ı aktualizace. Objev´ı se tak´e komponentaProgressBar, kter´a m´a u uˇzivatele vyvolat dojem, ˇze se aplikace snaˇz´ı o pˇripojen´ı.

Uloˇzen´ı do soubor˚u

Kaˇzd´a grafick´a komponenta (tabulka, dlaˇzdice, graf, . . . ) je uloˇzen do samostatn´eho sou-boru. Pokud aplikace obdrˇz´ı data z webov´eho API, tak jsou tato data zpracov´ana a uloˇzena v metodˇeSaveDataToFile. Metoda vyuˇz´ıv´a rozhran´ıWindows.Security.Cryptohgraphy, kter´e pˇrevede data do bin´arn´ıho tvaru a pomoc´ıWindows.Security.Storageuloˇz´ı do sou-boru. Vˇzdy, kdyˇz dojde k pˇrijet´ı dat z webov´eho API, je otevˇren soubor, kter´y sdruˇzuje posledn´ı aktualizace dan´e komponenty. V obsahu souboru je nalezena komponenta, kter´a byla pr´avˇe aktualizov´ana a jej´ı ˇcas aktualizace se pˇrep´ıˇse. N´aslednˇe dojde k uloˇzen´ı nov´eho obsahu do souboru. Aplikace se snaˇz´ı z´ıskataccess token, aby mohla zobrazit aktu´aln´ı data. O z´ısk´an´ı pˇr´ıstupov´eho kl´ıˇce se snaˇz´ı samostatn´e vl´akno (pokud je detekov´an reˇzim online), kter´e je vˇzdy na 5 vteˇrin usp´ano.

Kapitola 6

Rozˇ

s´ıˇ

ren´ı

6.1

Universal Apps

Souˇcasn´a aplikace Money Dashboard S5 je urˇcena pro osobn´ı poˇc´ıtaˇce a tablety, kter´e disponuj´ı operaˇcn´ım syst´emem Windows 8 a vyˇsˇs´ım. Po anal´yze moˇznost´ı v´yvoje aplikace pro prostˇred´ıWinRT bylo zjiˇstˇeno, ˇze existuje technologie Universal apps. Tato technologie byla pˇrid´ana do Visual studio v druh´e aktualizaci, kter´a probˇehla v kvˇetnu 2014.

Implementace aplikace je rozdˇelena do tˇrech projekt˚u: Windows, Windows Phone

a Shared. Zdrojov´y k´od v projektu Shared je sd´ılen mezi dva zb´yvaj´ıc´ı projekty. V praxi se sd´ıl´ı chov´an´ı aplikace. Vzhled je upraven pro kaˇzd´y operaˇcn´ı syst´em zvl´aˇst’. Nejedn´a se o razantn´ı zmˇeny a ve vˇetˇsinˇe pˇr´ıpad˚u staˇc´ı zmˇenit velikost a uspoˇr´ad´an´ı ovl´adac´ıch prvk˚u. Minoritn´ı ˇc´ast pˇr´ıpad˚u zastupuj´ı prvky, kter´e jsou rozd´ıln´e u obou skupin. Detailnˇejˇs´ı v´ypis skupin prvk˚u a jejich specifika jsou uvedena n´ıˇze:

• Bˇeˇzn´e: Tyto prvky lze pouˇz´ıt pro obˇe zaˇr´ızen´ı a jejich vzhled je identick´y (Button, CheckBox, Slider)

• Optimalizovan´e: Tyto prvky lze pouˇz´ıt pro obˇe zaˇr´ızen´ı, avˇsak jejich vzhled je modi-fikov´an pro kaˇzdou platformu (DatePicker, TimePicker)

• Jedineˇcn´e: Tyto prvky jsou pro kaˇzd´e zaˇr´ızen´ı odliˇsn´e a to hlavnˇe z d˚uvodu r˚uzn´eho ovl´ad´an´ı prvku (GridView, Pivot, Hub)

Chceme-li pˇreloˇzit urˇcitou ˇc´ast zdrojov´eho k´odu pro kaˇzd´y operaˇcn´ı syst´em zvl´aˇst’ v pro-jektu Shared, pak je nutn´e ˇr´ıdit pˇreklad speci´aln´ı direktivou:

#IF WP_8 #END IF

6.2

Ziv´

ˇ

e dlaˇ

zdice a interakce s uˇ

zivatelem

ˇ

Ziv´e dlaˇzdice

Podkapitola se zab´yv´a moˇznostmi zobrazen´ı ˇziv´e dlaˇzdice a n´aslednˇe jsou pops´any vˇsechna moˇzn´a upozornˇen´ı uˇzivatele.

”Dlaˇzdice v nov´em prezentaˇcn´ım rozhran´ı Windows 8.1 umoˇzˇnuje uˇzivateli spustit aplikaci nebo se pˇrepnout do jiˇz spuˇstˇen´e aplikace. Na rozd´ıl od jin´ych platforem to nejsou jen statick´e ikony, ale dok´aˇzou v souladu s ´uˇcelem pˇr´ısluˇsn´e aplikace, kterou na domovsk´e obrazovce zastupuj´ı, dynamicky zobrazovat rozmanit´y in-formaˇcn´ı, pˇr´ıpadnˇe ilustraˇcn´ı, obsah, a to i tehdy kdyˇz aplikace nen´ı spuˇstˇena“ [6]. Podm´ınka pro fungov´an´ı ˇziv´e dlaˇzdice je jej´ı pˇr´ıtomnost na ´uvodn´ı obrazovce prostˇred´ıModern UI. Zobrazovan´e obr´azky mohou m´ıt form´at JPEG nebo PNG a nesm´ı pˇres´ahnout 150 kB. Tvar dlaˇzdice je striktnˇe omezen na obd´eln´ıkov´y ˇci ˇctvercov´y. Nastaven´ı velikosti, tvaru a ob-sahu je moˇzn´e v aplikaˇcn´ım manifestu Package.appxmanifest. Obsah dlaˇzdice m˚uˇze b´yt i obr´azek, jehoˇz velikost je r˚uzn´a v z´avislosti na velikosti obrazovky. Jejich mˇeˇr´ıtko je vyj´adˇreno procentu´alnˇe, konkr´etnˇe 80, 100, 140 a 180 procent z´akladn´ıho rozmˇeru. Vˇsechny obr´azky urˇcen´e k tomuto ´uˇcelu jsou uloˇzen´e ve sloˇzeAssets. Z hlediska interakce uˇzivatele je dlaˇzdice zcela pasivn´ı. To znamen´a, ˇze obsah, kter´y zobrazuje, uvid´ı uˇzivatel jen v pˇr´ıpadˇe, pokud pˇrejde na ´uvodn´ı obrazovku.

Interakce s uˇzivatelem

V Modern UI prostˇred´ı m˚uˇze b´yt uˇzivatel upozornˇen na zmˇenu stavu programu notifikac´ı. Notifikace m˚uˇzeme rozdˇelit do dvou kategori´ı. Prvn´ı kategorie je zp˚usob doruˇcen´ı, druhou je zp˚usob zobrazen´ı. Zp˚usob doruˇcen´ı je rozdˇelen na: local, scheduled, periodic a push 5.1. Zp˚usob zobrazen´ı je rozdˇelen na: tile, badge, toast a raw. Obˇe kategorie jsou ´uzce spjaty. Jejich vz´ajemn´y vztah popisuje tabulka n´ıˇze:

Zp˚usob doruˇcen´ı Zp˚usob zobrazen´ı Popis

local tile, badge, toast aplikace mus´ı bˇeˇzet. Vhodn´e napˇr´ıklad pro upozornˇen´ı na novˇe pˇrehr´avanou p´ısniˇcku. scheduled tile, toast aplikace tak´e mus´ı bˇeˇzet, ale upozornˇen´ı je zobrazeno v urˇcit´y ˇcas. Vhodn´e pro aplikace pracuj´ıc´ı s ˇcasem (kalend´aˇre, bud´ıky).

periodic tile, badge aplikace mus´ı bˇeˇzet a dotazuje se serveru na zmˇeny. Vhodn´e napˇr´ıklad pro poˇcas´ı nebo denn´ı zpr´avy.

push tile, badge, toast, raw aplikace nemus´ı bˇeˇzet. Uˇzivatel je upo-zornˇen ze serveru, napˇr´ıklad emailov´y kli-ent.

Moˇznosti zobrazen´ı notifikace1

Obr´azek 6.1: Uk´azka moˇzn´ych zp˚usob˚u zobrazen´ı notifikac´ı

1

RAW umoˇzˇnuje zaslat jak´ykoli ˇretˇezec a uˇzivatel o n´ı nen´ı informov´an. Ostatn´ı zobrazen´ı vyˇzaduj´ı z´apis v XML.

Kapitola 7

Z´

avˇ

er

C´ılem t´eto pr´ace bylo navrhnout a implementovat Windows 8 aplikaci pro prezentaci dat z webov´eho API. Uˇzivatel´e mohou sledovat data z r˚uzn´ych, pˇredevˇs´ım finanˇcn´ıch, kategori´ı v re´aln´em ˇcase. Velk´y d˚uraz byl kladen na minimalizaci pˇrenesen´ych dat a bezpeˇcnost. Fin´aln´ı ˇreˇsen´ı se skl´ad´a ze tˇr´ı ˇc´ast: klientsk´e aplikace, webov´eho API a datab´aze. Aplikace zobrazuje citliv´a data, pˇriˇcemˇz jejich zdroj je pr´avˇe datab´aze. Produkt bude um´ıstˇen v dis-tribuˇcn´ı platformˇe Windows Store. Pracovat s n´ı budou osoby disponuj´ıc´ı ´uˇctem u firmy C´ıgler Software. Pro ´uˇcely bakal´aˇrsk´e pr´ace bylo vytvoˇreno webov´e API a pozdˇeji bude nahrazeno propriet´arn´ım. C´ılov´y produkt je urˇcen pro zaˇr´ızen´ı s operaˇcn´ım syst´emem Win-dows 8 a vyˇsˇs´ım. Dnes to mohou b´yt tablety a pˇrenosn´e/stoln´ı poˇc´ıtaˇce.

Autorizace je zaloˇzena na protokolu OAuth 2.0, data jsou zabezpeˇcena protokolem HTTPS. Za majoritn´ı ´uspˇech povaˇzuji implementaci notifikac´ı do aplikace. Aplikace je tak v´ypoˇcetnˇe m´enˇe n´aroˇcn´a, ˇc´ımˇz ˇsetˇr´ı v´ykon a baterii zaˇr´ızen´ı. Webov´e API moment´alnˇe nem˚uˇze b´yt oznaˇceno jako RESTfull, protoˇze neuv´ad´ı zda klient data m˚uˇze ukl´adat do mezipamˇeti a tak´e neuv´ad´ı, jak zpracovat serializovan´a data.

V d˚usledku nahrazen´ı webov´eho API bude pˇrizp˚usoben komunikaˇcn´ı protokol. Pro ovˇeˇren´ı spr´avn´eho zobrazen´ı byl vyuˇzit vestavˇen´y simul´ator Visual Studia. ˇCinnost a gra-fick´a podoba aplikace byla konzultov´ana se z´astupcem zadavatele. Komunikaˇcn´ı protokol byl navrhnut a implementov´an po konzultac´ıch s vedouc´ım bakal´aˇrsk´e pr´ace.

Do budoucna se pl´anuje rozˇs´ıˇren´ı aplikace pro Windows Phone. Produkt byl vyv´ıjen jako

Universal Apps, coˇz umoˇzˇnuje sd´ılet vˇetˇsinovou ˇc´ast k´odu mezi obˇe platformy (Windows 8 a Windows Phone).

Literatura

[1] ECMA-404 The JSON Data Interchange Standard. [online].

http://www.json.org/json-cz.html, 2015 [cit. 2015-01-17]. [2] Avram, A.: Design Details of the Windows Runtime [online].

http://www.infoq.com/news/2011/09/Design-Details-Windows-Runtime, 2011-09-21 [cit. 2015-18-01.

[3] Burget, R.: Struktury a kolekce, 2D reprezentace - vizualizace [online].

https://www.fit.vutbr.cz/study/courses/WAP/private/opory/IIS0502D.pdf, 2014-11-04 [cit. 2015-10-03].

[4] Freeman, A.:Metro Revealed: Building Windows 8 apps with XAML and C#. Apress, 2012, iSBN 978-1-4302-4491-2.

[5] Istv´an Nov´ak, Z. A. D. F., Gy¨orgy Bal´assy: Begining Windows 8 Application Development. John Wiley & Sons, Inc., 2012, iSBN 978-1-118-01268-0.

[6] L’uboslav Lacko: V´yvoj aplikac´ı pro Windows 8.1 a Windows Phone. COMPUTER PRESS, 2014, iSBN 978-80-251-3822-9.

[7] Mal´y, M.: OAuth ? nov´y protokol pro autentizaci k vaˇsemu API [online].

http://www.zdrojak.cz/clanky/oauth-novy-protokol-pro-autentizaci -k-vasemu-api, 2008-11-25 [cit. 2015-21-02].

[8] McVetta, J.: What is a RESTful API? [online].

http://advanced-python.readthedocs.org/en/latest/rest/what-is-rest.html, 2012 [cit. 2015-27-02].

[9] MSDN: Windows Push Notification Services (WNS) overview (Windows Runtime apps) [online].https://msdn.microsoft.com/cs-cz/library/hh913756.aspx, [cit. 2015-20-03].

[10] Olson, J.: Reimagining App Development with the Windows Runtime [online].

https://msdn.microsoft.com/en-us/magazine/jj651567.aspx, 2015 [cit. 2014-27-12].

[11] Parecki, A.: OAuth 2 Simplified [online].

https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified, 2012-06-29 [cit. 2015-20-02].

[12] Samaras, C.: Differences Between WPF And Windows Forms [online].

http://www.myengineeringworld.net/2014/08/wpf-and-windows-forms -differences.html, 2014-08-27 [cit. 2015-19-01].

Pˇ

r´ıloha A

Obsah CD

Adres´aˇrov´a struktura CD

• Source

– Dashboard - zdrojov´e k´ody pro aplikaci

– WebApi- zdrojov´e k´ody pro webov´e API

– DB - exportovan´a MySQL datab´aze

• OfflineData- soubory s offline daty

• Icons- logo a ikony pouˇzit´e v aplikaci

• Thesis- zdrojov´e soubory LA_TEXaMakefile

Pˇ

r´ıloha B

Screenshoty z aplikace

Obr´azek B.1: Hlavn´ı obrazovka aplikace

Obr´azek B.3: Tabulka neuhrazen´ych faktur

Pˇ

r´ıloha C

Manu´

al

Instalace aplikace

1. Aplikace podporuje pouze Windows 8 a vyˇsˇs´ı.

2. V adres´aˇri (viz A) Instalace je soubor Add-AppDevPackage.ps1. Tento soubor je nutn´e otevˇr´ıt a spustit. Nejl´epe kliknut´ım prav´eho tlaˇc´ıtka myˇsi d´atRun with Power-shell.

3. Otevˇre se dialogov´e okno, ve kter´em se spust´ı instalace.

Obr´azek C.1: Pˇrihlaˇsovac´ı formul´aˇr a formul´aˇr pro zad´an´ı pinu

4. Pro dokonˇcen´ı instalace staˇc´ı stisknout kl´avesuEnter. Pro spuˇstˇen´ı je nutn´e pˇrej´ıt do prostˇred´ıModern UI a aplikaci vyhledat.

Instalace webov´eho API a datab´aze

1. V adres´aˇri (viz A) Source/WebApi/restnaleznete zdrojov´e k´ody pro webov´e API. 2. Obsah adres´aˇrerest je nutn´e vystavit veˇrejnˇe/lok´alnˇe (webov´e API, kter´e bude

na-slouchat).

3. Adresu, na kter´e je webov´e API uloˇzeno mus´ı b´yt zmˇenˇeno v souboruEndpoint.txt

v adres´aˇriSource/Aplikace/Dashboard/Dashboard.Shared.

4. D´ale je nezbytn´e, aby se provedl import MySQL datab´aze. Zdrojov´e k´ody naleznete v adres´aˇriSource/DB.

5. Koneˇcnˇe v souboruconnect.phpje nutn´e zmˇenit adresu a pˇr´ıstupov´a pr´ava datab´aze. Soubor lze nal´ezt v adres´aˇri Source/WebAPI/rest/dialog.