WINDOWS 8 APLIKACE PRO PREZENTACI DAT Z WEBOVÉHO API

ˇ ´ UCEN ´I TECHNICKE ´ V BRNE ˇ VYSOKE BRNO UNIVERSITY OF TECHNOLOGY

ˇ ´ICH TECHNOLOGI´I FAKULTA INFORMACN ˇ ´ICH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

WINDOWS 8 APLIKACE PRO PREZENTACI DAT Z ´ WEBOVEHO API

´ RSK ˇ ´ PRACE ´ BAKALA A BACHELOR’S THESIS

´ AUTOR PRACE AUTHOR

BRNO 2015

ˇ ´I KALUS JIR

ˇ ´I TECHNICKE ´ V BRNE ˇ VYSOKE´ UCEN BRNO UNIVERSITY OF TECHNOLOGY

ˇ ´ICH TECHNOLOGI´I FAKULTA INFORMACN ˇ ´ICH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

WINDOWS 8 APLIKACE PRO PREZENTACI DAT Z ´ WEBOVEHO API PRESENTATION OF WEB API DATA IN WINDOWS 8 APPLICATION

´ RSK ˇ ´ PRACE ´ BAKALA A BACHELOR’S THESIS

´ AUTOR PRACE

ˇ ´I KALUS JIR

AUTHOR

´ VEDOUC´I PRACE SUPERVISOR

BRNO 2015

ˇ Ing. MARTIN MILICKA

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 autorizaci 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 literatury 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 informaˇcn´ıch technologi´ı. Pr´ ace je chr´ anˇena autorsk´ym z´ akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´ avnˇen´ı autorem je nez´ akonn´e, s v´yjimkou z´ akonem definovan´ych pˇr´ıpad˚ u.

Obsah ´ 1 Uvod

2

2 Zp˚ usoby reprezentace dat a vybran´ e technologie 2.1 Dashboard . . . . . . . . . . . . . . . . . . . . . . . 2.2 Komponenty pro reprezentaci dat . . . . . . . . . . 2.3 V´ yvojov´e prostˇred´ı a jazyk . . . . . . . . . . . . . 2.4 S´ıt’ov´ a komunikace . . . . . . . . . . . . . . . . . . 2.4.1 HTTPS . . . . . . . . . . . . . . . . . . . . 2.4.2 Architektura REST . . . . . . . . . . . . . 2.4.3 JSON . . . . . . . . . . . . . . . . . . . . . 2.4.4 OAuth . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

3 3 4 6 8 8 8 10 11

3 Architektura syst´ emu 3.1 Sch´ema a u ´loha jednotliv´ ych element˚ u . . . . . . . . . . . . . . . . . . . . . 3.2 Notifikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 13 14

4 Komunikaˇ cn´ı protokol 4.1 Z´ akladn´ı prvky komunikace 4.2 Autorizace . . . . . . . . . . 4.3 Metody webov´eho API . . . 4.4 Aktualizace dat . . . . . . . 4.5 Struktura pˇrenesen´ ych dat .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

16 16 16 18 21 21

5 Implementace 5.1 Push notifikace 5.2 Autorizace . . . 5.3 Security Vault . 5.4 Offline stav . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

22 22 24 25 25

6 Rozˇ s´ıˇ ren´ı 6.1 Universal Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ e dlaˇzdice a interakce s uˇzivatelem . . . . . . . . . . . . . . . . . . . . . 6.2 Ziv´

27 27 28

7 Z´ avˇ er

30

A Obsah CD

32

B Screenshoty z aplikace

33

C Manu´ al

35

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

Kapitola 1

´ Uvod N´apln´ı t´eto pr´ ace je navrhnout a realizovat Windows 8 aplikaci pro prezentaci dat z webov´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´akazn´ı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 Motion Dashboard, kter´ a se nach´ az´ı na App 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 Software. ´ celem produktu je vhodn´ Uˇ 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 komponent, 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 optimalizov´ 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 minimalizov´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. ´ celem n´ Uˇ asleduj´ıc´ıho textu je poskytnout ˇcten´aˇri informace o v´ yvoji Windows 8 aplikac´ı, moˇznostech reprezentace dat a prostˇredc´ıch pro rychlou a bezpeˇcnou komunikaci na s´ıti. V u ´vodu 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 autorizace s moˇznost´ı naˇcten´ı offline dat je obsaˇzena v kapitole Architektura syst´emu. V kapitole 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.

2

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 technologi´ı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 ´ celem dashboardu je nˇekolik typ˚ u komponent, kter´e jsou pops´any n´ıˇze v t´eto kapitole. Uˇ 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 u ´daj˚ u jim z˚ ustane zobrazena pouze 3

u ´vodn´ı 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´ı naleznete 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 produkty 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ˇzn ˇuje 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. Vizualizuje kolekci struktur. Profity tabulkov´eho zobrazen´ı je moˇzn´a filtrace dat pro danou kolekci a jej´ı moˇznost pˇrehlednˇe zobrazit podrobnˇejˇs´ı informace k poloˇzce v tabulce. 4

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 zobrazen´ı 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 obsah, 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´ı agregovan´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.4: Dlaˇzdice pouˇzit´e v aplikaci

5

V aplikaci je tak´e dlaˇzdice, kter´a informuje uˇzivatele o zpr´av´ach. Dlaˇzdice disponuje dvˇema odr´aˇzkami, u kter´ ych se periodicky 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 Obr´ azek 2.5: Dlaˇzdice v aplikaci 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´ yvoj Universal Apps je nutn´e m´ıt Visual Studio 2013 Update 2 a vyˇsˇs´ı. • Windows RunTime Operaˇcn´ı syst´em mus´ı obsahovat architekturu Windows RuntTime, d´ale jen WinRT, 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´ı v sandboxu. 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 volat syst´emov´e funkce, kter´e nejsou implicitnˇe povolen´e, napˇr. vypnut´ı nebo restartov´ an´ı zaˇr´ızen´ı. Pro tvorbu WinRT [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´ı.

6

Obr´ azek 2.6: Architektura aplikac´ı Windows 8 [2] Presentation Foundation a XAML Technologie Windows 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´ı vektorovˇ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) ve Windows Forms je nahrazeno a pro vykreslov´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 (desktopov´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

Device Independent Pixel

7

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 zabraˇ 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´ı infrastruktury 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 Metody HEAD a GET jsou 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´ı. Metody POST, PUT a DELETE jsou urˇceny pro akce, kter´e mohou zmˇenit stav serveru. Metody PUT a DELETE jsou 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´ yu ´ˇ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

8

Z´ akladn´ı principy pro jednotn´e rozhran´ı: • Zdroje dat - jsou koncepˇcnˇe oddˇelen´e od reprezentac´ı, kter´e jsou vr´aceny klientovi. 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 koncov´ ym serverem. Architektura na stranˇe serveru tak m˚ uˇze l´epe rozloˇzit z´atˇeˇz nebo zvyˇsovat u ´roveˇ 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 2 RESTfull . Vˇsechny zdroje maj´ı vlastn´ı identifik´ator URI, kde REST definuje ˇctyˇri z´akladn´ı operace (CRUD) pro manipulaci se zdroji: Create, Read, Update a Delete. Tyto operace jsou namapov´ any na HTTP operace POST, GET, PUT a DELETE. Zdroje mohou m´ıt r˚ uzn´e reprezentace (JSON, XML, SVG, PDF). REST architektura umoˇzn ˇuje 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 procedur´alnˇe (RPC 3 ). Moˇ znosti autorizace Vˇetˇsina sluˇzeb typicky vyˇzaduje autorizaci pˇred pˇr´ıstupem ke zdroji dat. Vyuˇz´ıvat sessions 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 u ´daje (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 3

REST je architektonick´e paradigma. Restfull popisuje sluˇzby, kter´e se t´ımto paradigmatem ˇr´ıd´ı RPC je vzd´ alen´e vol´ an´ı procedur

9

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´ y token. 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 autorizaci znovu.

2.4.3

JSON

JavaScript Object Notation je form´at pro v´ ymˇenu dat. Je zaloˇzen na podmnoˇzinˇe programovac´ı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´ı analyz´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. obj ec t s t r i ng

{

:

val ue

}

,

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. ar r ay [

val ue

]

,

Obr´ azek 2.8: Kolekce v JSON (pole) 4

definov´ ano v druh´e sekci (Section 2: Characters) RFC ( )

10

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 webov´ 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ˇzn ˇuje 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´ı u ´daje. D´ale umoˇzn ˇuje 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ˇen´ımi • autorizaˇ cn´ı server (authorization server ) - server, kter´ y klientovi pˇridˇeluje access token v pˇr´ıpadˇe jeho u ´spˇ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´ı: Apl i kac e 1

WebovéAPI 2

Př es měr ování už i vat el ena webovéAPI

Už i vat el s e ús pěš něpř i hl ás í

3 Př es měr ování už i vat el ez pět doapl i kac e 4 Žádos toz as l ání ac c es st oken 5 Odes l ání ac c es st okenu 6 Žádos todat a

Obr´ azek 2.9: Autorizace protokolu OAuth 1. Aplikace poˇz´ ad´ a webov´e API o jednor´azov´ y request token 11

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´ a request 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 o access token 5. Webov´e API vygeneruje access token a poˇsle ho zpˇet aplikaci 6. Aplikace poˇz´ ad´ a s access 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 protokol.

12

Kapitola 3

Architektura syst´ emu 3.1

Sch´ ema a u ´ loha 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 u ´spˇ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-

13

mentovat vlastn´ı webov´e API. Webov´e API naslouch´a na jednotliv´ ych endpoints 1 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´ı u ´daje 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 u ´spˇ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´ı. Pokud 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 u ´spˇ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 tokenu mus´ı webov´e API pˇredat identifikaˇcn´ı u ´daje aplikace. Identifikaˇcn´ı u ´daje jsou vygenerov´ any po zaregistrov´an´ı aplikace do Windows Store. Tento krok provede zodpovˇedn´ a osoba, nejˇcastˇeji v´ yvoj´aˇr aplikace. Identifikaˇcn´ı u ´daje se jiˇz nezmˇen´ı a skl´adaj´ı se ze dvou poloˇzek: Package Security Identifier a Client Secret. Z´ısk´an´ı tˇechto dvou poloˇzek je uvedeno v kapitole 5.1. Po z´ısk´ an´ı access tokenu je spoleˇcnˇe s tokenem zasl´an i notification channel, coˇz je adresa, na kter´e aplikace naslouch´a. Pokud je access 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 platnosti notification channel zhruba 30 dn´ı. Sch´ema a postup v jednotliv´ ych bodech je uveden n´ıˇze:

1

endpoint - vstupn´ı br´ ana, na kter´e sluˇzba naslouch´ a

14

Obr´ azek 3.2: Workflow autorizace a zasl´an´ı notifikace 1. Aplikace Money Dashboard S5 poˇsle poˇzadavek Notification Client Platform, d´ale jen NCP o notification 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´ı formou Uniform 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 autorizuje 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

15

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 zaregistrov´ an u firmy C´ıgler Software, kde z´ısk´a pˇrihlaˇsovac´ı u ´daje pro autorizaci na stranˇe webov´eho API. Grafick´e rozhran´ı pro registraci nebylo implementov´ano, pˇrihlaˇsovac´ı u ´daje 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 key je 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´ıky consumer 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 datab´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 spolu s kr´ atk´ ym popisem je zobrazen n´ıˇze.

16

Obr´ azek 4.1: Workflow vygenerov´an´ı consumer key 1. Uˇzivatel se pˇrihl´ as´ı na port´ alu webov´eho API a vygeneruje si consumer 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 u Resource Server a d´av´a svolen´ı pˇr´ıstupu Application 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 u ´spˇeˇsnˇe autorizoval. Cel´ y proces je sch´ematicky nakreslen a pot´e pops´an na n´asleduj´ıc´ım obr´azku.

Obr´ azek 4.2: Handshake komunikaˇcn´ıho protokolu

17

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´ı u ´daje. • D - request notif Po u ´spˇ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 o access 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ˇsle access token, se kter´ ym bude aplikace pˇristupovat dat˚ um. • I get data Aplikace poˇsle poˇzadavek metodou GET, 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 seznam vˇsech parametr˚ u. Tabulka metod: n´ azev metody check credentials auth redirect get access token get data

HTTP dotaz GET GET, POST GET GET

HTTP odpovˇ ed’ POST POST POST POST

18

popis funkcionality kontrola validity aplikace autorizace uˇzivatele zpˇr´ıstupnˇen´ı access token zpˇr´ıstupnˇen´ı dat

Seznam vˇ sech parametr˚ u metod: n´ azev parametru method app id version consumer key request token component id access token notif channel uri cs

typ HTTP GET GET GET GET GET GET GET GET POST POST POST

popis funkcionality n´azev metody, kter´a m´a b´ yt zavol´ana ˇc´ıslo, kter´e identifikuje danou aplikaci verze aplikace ˇretˇezec identifikuj´ıc´ı uˇzivatele pˇr´ıstupov´ y kl´ıˇc pro autorizaci uˇzivatele n´azev komponenty (graf, dlaˇzdice, tabulka, . . . ) unik´atn´ı ˇc´ıslo urˇcuj´ıc´ı danou komponentu pˇr´ıstupov´ y kl´ıˇc k dat˚ um notifikaˇcn´ı adresa aplikace adresa aplikace pro Windows Store 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 tabulce Auth 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 200 200 200 200

parametry odpovˇ edi id=1&request token=<string> id=2&request token=<string> &possible upgrade id=3&must upgrade id=4&app not supported

popis funkcionality pˇr´ıstupov´ y kl´ıˇc uˇzivatele pˇr´ıstupov´ y kl´ıˇc uˇzivatele, moˇzn´a aktualizace nutnost aktualizace 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

19

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 u ´spˇeˇsnˇe autorizuje. Obdrˇzen´a zpr´ava od WNS m´a tvar: HTTP status 200

parametry odpovˇ edi type=1&OK

popis funkcionality 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 200

parametry odpovˇ edi id=1&access token=<string>

popis funkcionality 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 v GET ˇ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: https://www.example.cz/data/get\_data.php/?method=get_data&component=tile &id=2&access_token=8730d5cee5cfedd4a470e40b493eb0d2 20

HTTP status 200 410

4.4

parametry odpovˇ edi JSON data access token expired

popis funkcionality data pro jednu komponentu vyprˇsen´ı pˇr´ıstupov´eho kl´ıˇce k dat˚ um

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´ı metody get data o data. Jako parametry zvol´ı u ´daje, kter´e pˇriˇsly v tˇele notifikace (comphonent a id ).

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 tabulku Produkt˚ 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.

21

Kapitola 5

Implementace 5.1

Push notifikace

Notifikace m˚ uˇzeme z hlediska implementace rozdˇelit do dvou ˇc´ast´ı. Prvn´ı ˇc´ast je implementace 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´ı u ´daje aplikace a adresu, na kter´e naslouch´ a. Identifikaˇcn´ı u ´daje 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´eho Windows Store. Spr´ avu notifikac´ı m´ a na starost tˇr´ıda WnsNotif. V konstruktoru t´eto tˇr´ıdy dojde k autorizaci u sluˇzby WNS dle protokolu OAuth 2.4.4. Pˇred odesl´an´ım ˇz´adosti o request token je nezbytn´e z´ıskat identifikaˇcn´ı u ´daje 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 datab´azi uloˇzen access token, kter´ ym se bude pro zasl´an´ı notifikace autorizovat u WNS. K vytvoˇren´ı instance dojde po pˇrihl´ aˇsen´ı uˇzivatele na port´alu webov´eho API. Pˇrihlaˇsovac´ı formul´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 u ´spˇ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´ı notifikace je nazv´ ana SendRawNotif a 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 notifikace a koneˇcnˇe access token. Inicializace, odesl´an´ı a uzavˇren´ı poˇzadavku na WNS je uskuteˇcnˇeno vestavˇen´ ymi metodami PHP curl init, curl setopt a curl close.

1

http://pushtestserver.azurewebsites.net/wns/

22

Aplikace Prvn´ı krok pro u ´spˇeˇsn´e pˇrijet´ı push notifikace je informovat NCP, o samotn´e aplikaci. Nejprve 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 vytvoˇrena ve tˇr´ıdˇe Authorization, kter´a je um´ıstˇena v projektu Dashboard.Windows. Postup aplikace pro pˇr´ıjem notifikac´ı je zn´azornˇen sekvenˇcn´ım diagramem s podrobnˇejˇs´ım popisem n´ıˇze:

PUSHBGT ASK. CS

AUTHORI ZATI ON. CS

PUSHNOTI FI CATI ON. CS

I s T a s k Regi s t er ed( ) Regi s t er ( )

E na bl e T a s k ( ) I ni t i l i a l i z e( ) Del i v er Not ic a t i on( )

Di s a bl e T a s k ( )

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 aplikace, 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, registrov´ ano a n´ aslednˇe vytvoˇreno asynchronn´ı vl´akno, kter´e je spravov´ano NCP. Pot´e je ve tˇr´ıdˇe Authorization zavol´ ana metoda EnableTask, 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´ alost sharedPushComponent deliverNotif pro pˇr´ıjem notifikac´ı. Je-li aplikace ukonˇcena, pak je zavol´ana metoda DisableTask, kter´a vl´akno pro pˇr´ıjem notifikac´ı zruˇs´ı. Bˇehem implementace se objevil probl´em, kdy notifikace dorazila do aplikace a u in23

strukc´ı slouˇz´ıc´ıch k pˇresmˇerov´ an´ı uˇzivatele na obrazovku vyz´ yvaj´ıc´ı k zad´an´ı pinu, nastala 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 souhrnu push 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ˇzn ˇuj´ı 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 u ´rovni uˇzivatele, kdy uˇzivatel mus´ı zadat unik´atn´ı identifikaˇcn´ı ˇretˇezec vygenerovan´ y u autoritativn´ıho webov´eho API. Aplikace ovˇeˇr´ı identifikaˇcn´ı k´od a pˇrejde do stavu 24

Check app credentials, ve kter´em jsou zkontrolov´any u ´daje o aplikaci. Ovˇeˇren´ı validity aplikace je implementov´ ano v metodˇe Check app credentials, tˇr´ıda OAuth. 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ˇe LockScreen. 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 zkontrolov´an. Pokud pin neexistuje, je vytvoˇrena instance tˇr´ıdy Authorization a uˇzivatel je pˇresmˇerov´ an na pˇrihlaˇsovac´ı port´ al webov´eho API. Zde zad´a sv´e pˇrihlaˇsovac´ı u ´daje. 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 o access token. Tato metoda je opˇet implementov´ ana ve tˇr´ıdˇe Oauth a nese n´azev GetAccessToken. Pokud vˇse probˇehne v poˇr´adku, aplikace pˇrech´ az´ı do stavu get 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 grafick´ 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´ y endpoint, od nˇehoˇz se oˇcek´avaj´ı data. Nepodaˇr´ı-li se obdrˇzet do 3 vteˇrin access 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 dojde/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 Windows a Windows 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 tomuto u ´ˇcelu slouˇz´ı metody GetValueFromVault a DeleteValueFromVault.

5.4

Offline stav

Inicializace a detekce Pˇri spuˇstˇen´ı aplikace je vytvoˇrena instance tˇr´ıdy CheckConnection, kter´a obsahuje metody pro identifikaci pˇripojen´ı k internetu. V konstruktoru je inicializov´an a spuˇstˇen ˇcasovaˇc DispatcherTimer. Instance ˇcasovaˇce vytvoˇr´ı vl´akno, jenˇz v urˇcit´ ych intervalech kontaktuje

25

hlavn´ı vl´ akno, kter´e v metodˇe timer Tick vykon´a poˇzadovan´e instrukce. Interval je v aplikaci 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´ı do StoryBoard. StoryBoard je 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 uveden 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 komponenta ProgressBar, 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 souboru. Pokud aplikace obdrˇz´ı data z webov´eho API, tak jsou tato data zpracov´ana a uloˇzena v metodˇe SaveDataToFile. Metoda vyuˇz´ıv´a rozhran´ı Windows.Security.Cryptohgraphy, kter´e pˇrevede data do bin´ arn´ıho tvaru a pomoc´ı Windows.Security.Storage uloˇz´ı do souboru. 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´ıskat access 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.

26

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 modifikov´ 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 projektu Shared, pak je nutn´e ˇr´ıdit pˇreklad speci´aln´ı direktivou: #IF WP_8 #END IF

27

6.2

ˇ e dlaˇ Ziv´ zdice a interakce s uˇ zivatelem

ˇ e dlaˇ Ziv´ 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ˇzn ˇuje 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 informaˇ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 u ´vodn´ı 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 obsahu 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ˇze Assets. 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 u ´vodn´ı 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 u ´zce spjaty. Jejich vz´ ajemn´ y vztah popisuje tabulka n´ıˇze: Zp˚ usob doruˇ cen´ı Zp˚ usob zobrazen´ı

Popis

local

tile, badge, toast

scheduled

tile, toast

aplikace mus´ı bˇeˇzet. Vhodn´e napˇr´ıklad pro upozornˇen´ı na novˇe pˇrehr´avanou p´ısniˇcku. 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 upozornˇen ze serveru, napˇr´ıklad emailov´ y klient.

28

Moˇznosti zobrazen´ı notifikace1

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

1

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

29

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 distribuˇ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 Windows 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´ı u ´spˇ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 grafick´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ˇzn ˇuje sd´ılet vˇetˇsinovou ˇc´ast k´odu mezi obˇe platformy (Windows 8 a Windows Phone).

30

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].

31

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 LATEXa Makefile • Manual - PDF s n´ avodem na instalaci a spuˇstˇen´ım aplikace

32

Pˇ r´ıloha B

Screenshoty z aplikace

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

Obr´ azek B.2: Aplikace byla spuˇstˇena bez pˇripojen´ı k internetu

33

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

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

34

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´at Run with Powershell. 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´avesu Enter. Pro spuˇstˇen´ı je nutn´e pˇrej´ıt do prostˇred´ı Modern UI a aplikaci vyhledat. 35

Instalace webov´ eho API a datab´ aze 1. V adres´ aˇri (viz A) Source/WebApi/rest naleznete zdrojov´e k´ody pro webov´e API. 2. Obsah adres´ aˇre rest je nutn´e vystavit veˇrejnˇe/lok´alnˇe (webov´e API, kter´e bude naslouchat). 3. Adresu, na kter´e je webov´e API uloˇzeno mus´ı b´ yt zmˇenˇeno v souboru Endpoint.txt v adres´ aˇri Source/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ˇri Source/DB. 5. Koneˇcnˇe v souboru connect.php je 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.

36