Sem vložte zadání Vaší práce.

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Bakalářská práce Mobilní aplikace pro aukční portál Veronika Stojanová Vedoucí práce: Ing. Martin Klíma, Ph.D. 16. května 2013

Poděkování Tímto bych ráda poděkovala svému vedoucímu Ing. Martinu Klímovi, Ph.D. za vedení mé práce a rady k praktické i teoretické části. Dále bych ráda poděkovala Ing. Josefu Kufnerovi za rady ohledně porálu Nume.cz a v neposlední řadě bych chtěla poděkovat rodině a kolegům ze školy za jejich podporu a cenné rady při vypracovávání praktické části.

Prohlášení Prohlašuji, že jsem předloženou práci vypracovala samostatně a že jsem uvedla veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 16. května 2013.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Veronika Stojanová. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Stojanová, Veronika. Mobilní aplikace pro aukční portál. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract The bachelor thesis is about developing of mobile application for web portal www.nume.cz. Portal specializes in the auction of antique coins and legal tenders. Goal is extend it to the mobile devices running the Android operating system. Keywords mobile application, Android, auction portal, auction, client, server, REST Abstrakt Tato bakalářská práce se zabývá vývojem mobilní aplikace pro stávající webový portál www.nume.cz. Portál je zaměřen na dražbu starožitných mincí a platidel. Cílem práce je rozšířit jej na mobilní zařízení s operačním systémem Android. Klíčová slova server, REST mobilní aplikace, Android, aukční portál, dražba, klient, ix

Obsah Úvod 1 Cíl práce................................ 2 1 Analýza a návrh 3 1.1 Aukce.............................. 3 1.2 Mobilní platforma Android................... 6 1.3 Web services........................... 11 1.4 REST.............................. 13 1.5 Restful aplikace......................... 14 1.6 Hlavičky HTTP......................... 17 1.7 Autentizace........................... 18 1.8 Webový portál Nume...................... 19 1.9 Mobilní aplikace Nume..................... 22 1.10 Uživatelské role......................... 22 1.11 Případy užití.......................... 24 1.12 Analýza požadavků....................... 27 1.13 Funkční požadavky....................... 30 1.14 Nefunkční požadavky...................... 31 1.15 Návrh restového rozhraní.................... 31 2 Realizace serveru 35 2.1 Vývojové prostředí....................... 35 2.2 Framework Nette........................ 35 2.3 Persistence dat......................... 36 2.4 Aplikační logika......................... 36 3 Realizace Klienta - mobilní aplikace 39 xi

3.1 Vývojové prostředí....................... 39 3.2 Aplikační logika......................... 39 3.3 Knihovny třetích stran..................... 51 3.4 Grafické rozhraní........................ 53 4 Testování 55 4.1 Test uživatelského rozhranní.................. 55 Závěr 57 Budoucnost aplikace......................... 58 Literatura 59 A Seznam použitých zkratek 61 B Test uživatelského rozhranní 63 B.1 Vstupní dotazník........................ 63 B.2 Výstupní dotazník....................... 64 C Obsah přiloženého CD 65 xii

Seznam obrázků 1.1 Hlavní součásti operačního systému Android. [12]........ 9 1.2 Životní cyklus activities. [11].................... 12 1.3 Stavový model komunikace [15].................. 15 1.4 Bezestavový model komunikace [15]................ 16 1.5 Lišta pro sdílení na sociálních sítích [17]............. 19 1.6 autentizační schéma OAuth [17].................. 20 1.7 Úvodní stránka portálu Nume. a) Registrace, b) Přihlášení, c) Prodej, d) Nákup, e) Hlavní kategorie, f) Vyhledávání....... 23 1.8 Diagram případů užití....................... 25 3.1 Hlavní aktivita, vlevo uživatel není přihlášen, vpravo je uživatel přihlášen............................... 41 3.2 Potvrzovací dialog odhlášení.................... 41 3.3 Přihlašovací aktivita, vpravo registrace.............. 42 3.4 Osobní profil přihlášeného uživatele................ 43 3.5 Zleva: hlavní kategorie, druhá podkategorie, třetí podkategorie. 44 3.6 Položky z vybrané kategorie, vpravo vidíme načítací kolečko.. 45 3.7 Stavový diagram položky...................... 46 3.8 Vlevo detail aukce, vpravo detail obchodu............ 49 3.9 Stav ze kterého nelze nakupovat, uživatel není přihlášen.... 49 3.10 Zleva: potvrzovací dialog nákupu v obchodě, dialog Kup teď, dialog přihoď............................ 50 3.11 View zobrazovaný v případě, že není připojení.......... 50 3.12 Sherlock ActionBar (uživatel je přihlášen)............ 51 3.13 Zleva: logo www.nume.cz, logo mobilní aplikace......... 53 xiii

Seznam tabulek 1.1 Ukázka dražby s pravidly Vickreyho aukce............ 5 1.2 Případ užití - Přihlášení uživatele................. 26 1.3 Případ užití - Odhlášení uživatele................. 26 1.4 Případ užití - Zobrazení vlastního profilu............. 26 1.5 Případ užití - Nákup v obchodě.................. 27 1.6 Případ užití - Nákup pomocí Kup teď............. 28 1.7 Případ užití - Nákup pomocí příhozů............... 29 xv

Úvod Internetové aukce se stávají stále populárnější a počet internetových portálů nabízejících internetové dražby stoupá. Možnost získat dražený předmět za nižší, než skutečnou cenu se stává stále více atraktivní. Láká tak mnoho v tomto oboru zkušených i nezkušených spotřebitelů do oblasti virtuálního světa nákupů. Právě jeden z nově založených internetových portálů je jádrém mé bakalářské práce. Jedná se o aukci nabízející zboží pro specifický sběratelský koníček, kterým je numismatika. Mobilní telefony dnes již také neslouží pouze pro telefonování a posílání SMS zpráv. Od doby kdy spatřil světlo světa první mobilní telefon se vývoj posunul tak dopředu, že dnes již může zastoupit dříve nenahraditelné věci jako noviny, hudební přehrávače či fotoaparáty. Chytrý mobilní telefon, anglicky smartphone, může dnes snadno v mnoha případech zastoupit běžný počítač. Provozovatelé internetových obchodů a jiných internetových aplikací se snaží rozšířit své pole působnosti i mezi uživatele smartphonů, a proto jim nabízejí možnost stáhnout si jejich aplikaci do svého telefonu. V dnešní době je pro každou větší internetovou společnost provozující eshop nebo aukci jakousi povinností nabídnout jejich zákazníkovi mobilní verzi aplikace. Důvodem vzniku této bakalářské práce tedy bylo nabídnout zákazníkům portálu www.nume.cz aplikaci do jejich chytrého telefonu a rozšířit tak možnost nákupu mincí a platidel. V současné době vede mezi mobilními operačními systémy Android od společnosti Google, a proto je mobilní aplikace vyvíjena pro tuto platformu. 1

Úvod Cíl práce Cílem této práce je vytvořit mobilní aplikaci pro platformu Android, která nabídne základní funkcionalitu aukčního portálu, jako je procházení nabízených položek a jejich následné nakupování. Součástí práce je také implementace serveru, který by umožnil komunikaci mezi stávajícím webovým portálem www.nume.cz a vyvíjenou mobilní aplikací. V první kapitole provedu analýzu potřebnou pro následující návrh řešení a poté i samotný návrh řešení jak klientské aplikace, tak serveru. V druhé a třetí kapitole přiblížím realizaci serveru a klienta. Ve čtvrté kapitole poté popíši proběhlé testování. V závěru práce poté zhodnotím, zda bylo dosaženo požadovaných výsledků. 2

Kapitola 1 Analýza a návrh 1.1 Aukce Aukce je druh obchodu se specifickými pravidly. Většina typů aukcí je postavena na následujícím principu, přičemž detaily se mění druh od druhu. Princip spočívá v tom, že na počátku obchodu (aukce) není jisté, kolik vlastně zájemce za draženou věc zaplatí. Zprostředkovatel dražby před začátkem stanoví počáteční cenu a po začátku dražby se tato cena navyšuje podle toho kolik je zájemců. Ti se přehazují tím způsobem, že se střídají a zvedají cenu předmětu. Aukce je časově omezená a dražený předmět v závěru získá ten přihazující, který nabídne nejvyšší částku. Díky tomuto způsobu může nakupující získat předmět daleko levněji, než v obyčejném prodeji, ale na druhou stranu také může prodělat, a to v případě, že neuváženě zvedne cenu, která převýší standardní hodnotu předmětu. V našem případě se konkrétně budeme zabývat typem aukce s názvem Vickreyho aukce, jejíž princip je popsán níže. Historie aukcí se datuje již od dob před naším letopočtem, kdy ovšem nebyly aukce nijak běžné. V dnešní době však představují nemalou součást obchodu se zbožím. Dostupné je prakticky cokoliv od klíčenky, přes živé mazlíčky po celé domy. V současnoti existují jak aukce, na kterých můžete být přítomni, jako například známá britská Sotheby s specializující se na umění, tak internetové aukce využívající moderních technologií. Internetové aukce jsou dnes již standardním jevem a poskytují kupci možnost získat potřebnou věc jednoduše bez fyzické účasti na aukci. 3

1. Analýza a návrh 1.1.1 Vickreyho aukce Právě tento typ aukce je použit na aukčním portálu Nume.cz, a tak považuji za podstatné popsat zde pravidla tohoto typu aukce. Své jméno získala podle Williama Vickreyho, který jako první roku 1961 tento způsob dražení popsal. Setkat se ale můžeme také s názvem Aukce druhé ceny, anglicky Second-price sealed-bid auction, který vychází ze způsobu dražby. Jak druhý název vypovídá, jedná se o aukci, kde vyhrává přihazující s nejvyšší nabídkou, ale nezaplatí svoji nabízenou cenu, nýbrž druhou nejvyšší nabídnutou. Aby byl tento způsob možný, probíhá aukce skrytě, a tudíž není vidět aktuální nejvyšší nabídka. [1] Tento druh aukce je výhodný v tom, že nabádá nakupující ke spravedlivé ceně a dražené zboží tak je možné získat za jeho skutečnou hodnotu. K těmto pravidlům portál Nume.cz ještě přidal další omezující podmínku, kterou si určuje zakladatel aukce - prodávající. Touto podmínkou je tzv. Rezervní cena. Rezervní cena určuje minimální cenu, za kterou je prodávající ochoten dražený předmět prodat a tato cena není veřejně známá. Pokud dražba nedosáhne hodnoty rezervní ceny, není předmět vydražen nikomu. [2] Pro lepší znázornění jsem připravila tabulku 1.1 demonstrující dražbu předmětu s počáteční cenou 5 Kč, rezervní cenou 1000 Kč a časem do konce 10min. 1.1.2 Aukro.cz Jedná se o neznámější aukční portál na českém trhu. Založen byl roku 2003 a později roku 2011 se stává členem skupiny Allegro Group, která se realizuje ve světě obchodování na internetu, realit, cestovního ruchu, apod. [3] [4] Aukro.cz nabízí svým uživatelům nepřeberné množství zboží v mnoha kategoriích. Cena zboží se zde pohybuje v řádu korun až tisíců, s možností nákupu zboží nového i použitého. Mezi hlavní funkce tohoto portálu patří možnost Kup teď, která umožňuje zájemci koupit zboží ihned za předem známou cenu (která je vyšší než počáteční cena aukce) a vyhnout se tak možnosti prohry při přihazování. V současné době Aukro.cz poskytuje i svoji mobilní verzi pro nejpoužívanější platformy Android, Symbian, Apple ios a Windows Phone. [5] Kromě standardního prohlížení a nakupování poskytuje aplikace widget, který spravuje Váš účet a zobrazuje hlídané aukce. Nevýhodou aplikace je, že neposkytuje možnost vytvářet nové aukce - jedná se pouze o nakupovací aplikaci. 4

1.1. Aukce Přihazující A Tabulka 1.1: Ukázka dražby s pravidly Vickreyho aukce Přihazující B Cena Vítěz Čas (min) Poznámka 5-10 Počáteční cena je stanovena na 5. Vítězem není nikdo, protože zatím nikdo nepřihazuje 10-5 A 9 A přihodil 10, je tedy vítěz tohoto kola. Cena je druhá nejvyšší - 100 11 B 7 B přehodil A s částkou 100, je tedy vítěz tohoto kola. Cena je o 1 vyšší než druhá nejvyšší částka (10) 90-91 B 6 A nevidí cenu nabídnutou od B a tak nabízí málo. Cena = 90 + 1 95-96 B 5 A stále nabízí málo. Cena = 95 + 1 150-101 A 3 A nabídl víc než B, je tedy vítěz. Cena je o 1 vyšší než druhá nejvyšší čátka (100) - 1500 1000 B 3 B se rozhodl přihodit 1500, je tedy vítěz. Cena překročila rezervní cenu, a tak je druhá nejvyšší částka 1000 (rezervní cena) 1200-1201 B 2 B je stále vítěz. Cena = 1200 + 1 2000-1501 A 0 A přehodil B a je vítěz, protože čas vypršel. Konečná cena, kterou A zaplatí je 1501,- 5

1. Analýza a návrh 1.1.3 ebay ebay je největší obchodní portál na světě založený americkou společností ebay Inc. se vznikem roku 1995. [6] Jeho dostupnost je celosvětová ve všech různých jazycích, a to i v češtině (www.ebay.cz). Bohužel se ale jedná pouze o zjednodušenou verzi ebay.com v českém jazyce, která nenabízí možnost prodávání předmětů. Pokud by tedy měl někdo zájem prodávat na ebay musí navštívit americkou verzi a souhlasit s prodejem po celém USA a Evropě. Co se týče nákupu jsou možnosti podobné jako u českého výše zmíněného Aukro.cz. Zákazník má možnost nakupovat pomocí příhozů, případně pomocí Kup teď. ebay sází na službu PayPal!, což je jeho nepochybnou výhodou v tom, že pokud má zákazník službu PayPal! zařízenou je nákup velice rychlý a jednoduchý. Stejně tak jako Aukro.cz nabízí i ebay svoji mobilní verzi pro platformy Android, Apple ios, Windows Phone a navíc také pro BlackBerry. Nenabízí verzi pro Symbian, ale je dostupný v mobilní verzi. [7] Neposkytuje možnost výběru verze pro Českou republiku. Oproti mobilní verzi českého Aukra je dostupná možnost vytvoření nové aukce. 1.2 Mobilní platforma Android Hlavní důvod pro výběr platformy Android byl ten, že sama vlastním mobilní telefon s touto platformou. Proto je mi Android velice blízký a sympatický. Android je open-sourcová platforma od společnosti Google založená na Linuxovém jádru a jedná se o nejrozšířenější platformu jak na českém, tak i celosvětovém trhu. Na svých stránkách Android uvádí, že každý den je aktivováno více než 1 milion nových zařízení s jejich platformou. [8] Nemalý podíl na takovém úspěchu je fakt, že si Android zvolili za svůj operační systém takoví velikáni jako HTC a Samsung, kteří nabízejí s tímto OS nejen mobilní telefony, ale i tablety. Značnou výhodou je také to, že Android poskytl svůj systém opensourcově a na svých stránkách nemale podporuje vývojáře a nabízí jim rady při vyvíjení vlastních aplikací. Díky tomu, se dá mnoho věcí najít na internetu a vývojář nemusí zbytečně ztrácet čas dohledáváním informací. Díky tomuto a také díky silné společnosti stojící za tímto operačním systémem se dá předpokládat, že rozšířenost a oblíbenost Androidu bude nadále stoupat. 6

1.2. Mobilní platforma Android 1.2.1 Historie Android Ačkoliv se na první pohled zdá, že platformu Android vyvinula společnost Google, není to zcela tak jednoznačné. Počátky Androidu se začínají psát roku 2003 kdy je založena společnost Android Inc. jejímž zakladatelem je Andy Rubin (který byl do tohoto roku (2013) vedoucím vývoje Android u Google). Již v tu dobu bylo v plánu vyvinout chytřejší mobilní zařízení. Až v druhé polovině roku 2005 začíná svoji roli hrát i společnost Google, která Android Inc. kupuje. V tu dobu začíná být jisté, že Google má v plánu konkurovat operačním systémům jako je Symbian a o vývoj se začínají zajímat velké firmy jako HTC, LG, Samsung a T-Mobile. Ti poté společně zakládají Open Handset Alliance - konsorcium výrobců mobilních telefonů, telefoních operátorů a technologických firem, které má za úkol vyvíjet operační systém Android. [9] 1.2.2 Verze Android Android již měl mnoho verzí, zde jsou vypsané ty s nejdůležitějšími inovacemi: [8] Verze 0.9 beta a 1.0, srpen 2008 a září 2008 Podpora služeb Google Verze 1.1, únor 2009 Podpora ovládání hlasem Podpora pro ukládání příloh MMS Verze 1.5 (Cupcake), duben 2009 Rychlejší start kamery, získávání GPS polohy, GMail Widgety (hodiny, kalendář, hudební přehrávač, vyhledávání) Nahrávání a přehrávání videa Verze 2.1 (Eclair), říjen 2009 Rychlý přístup ke kontaktům Vyhledávání uložených SMS a MMS Kamera (digitální zoom, makro, vyvážení bílé) Multi-touch klávesnice 7

1. Analýza a návrh Podpora HTML5 Verze 2.2 (FroYo), květen 2010 Hotspot Wifi Vícejazyčná klávesnice Bluetooth (hlasové vytáční, sdílení kontaktů, připojení k automobilu) instalace na externí úložiště Verze 3.0 (Honeycomb), únor 2011 Podpora pro tablety Verze 4.0 (IceCreamSandwitch), říjen 2011 Akce na zamčené obrazovce Screenshot Face Unlock - odemykání telefonu pomocí tváře Verze 4.2 (Jelly Bean), červen 2012 Podpora více uživatelů pro tablety Posílání souborů dotykem 1.2.3 Vývoj aplikací na platformě Android Android na svých stránkách poskytuje podporu pro vývojáře a zdarma nabízí plugin pro Eclipse s názvem The Android Developer Tools (ADT), který je dostupný pro Windows, Mac OS i Linux. Android je vlastně takový framework psaný v jazyce Java a ADT je balíček usnadňující vývoj nových aplikací. Jedná se o plnohodnotné Java IDE 1 s kompletními funkcemi, které pomůžou s tvorbou, testováním a debugem nové Android alikace. 1.2.4 Architektura Android Android jakožto softwarový balíček pro mobilní zařízení zahrnuje operační systém, middleware a aplikace s následující architekturou (obr. 1.1): Applications - základní aplikace jako e-mail, SMS, kalendář, mapy, prohlížeč 1 Integrated Development Environment - vývojové prostředí 8

1.2. Mobilní platforma Android Obrázek 1.1: Hlavní součásti operačního systému Android. [12] Application framework - zjednodušuje opakované použití součástí systému Libraries - obsahuje set knihoven C/C++, které využívají různé součásti systému Android Android Runtime - každá aplikace běží jako samostatný proces se svojí vlastní instancí na virtuálním stroji s názvem Dalvik (architektura založená na Linuxovém jádru s ohledem na úsporu energie) Linux Kernel - Android je postaven na Linuxovém jádru 2.6 kvůli službám, jako jsou správa paměti a řízení procesů 1.2.5 Aplikační součásti Android Aplikační součásti jsou základní stavební kameny systému Android. Každá součást má svoji jedinečnou funkci a předem specifikovaný životní cyklus, čímž vytváří konečné chování aplikace. 9

1. Analýza a návrh Ještě před startem aplikačních součástí se musí systém ujistit, že všechny komponenty existují. To provede tím, že přečte soubor AndroidManifest.xml, který je umístěn v kořenovém adresáři a jsou v něm definovány všechny podstatné položky. Pokud je vše v pořádku může začít pracovat s následujícími součástmi: [10] 10 Activities Aktivita poskytuje uživateli obrazovku se kterou může provádět interakci (např. používat e-mailového klienta). Každá aktivita je vedená jako samostatná obrazovka, a proto můžeme v e-mailovém klientu např. zapnout fotoaparát pro pořízení fotografie. Activities obsahují většinu aplikační logiky a musí dodržovat životní cyklus. Aktivita posunutá do pozadí se ukládá do zásobníku, aby mohla být při zpětném volání zavolána. Pokud ale nová aktivita např. potřebuje mnoho paměti, může být stará aktivita zničena. Activities se mohou nacházet v těchto stavech (obr. 1.2): Activity launched - aktivita se incializuje Activity running - aktivita běží, uživatel může obrazovku používat Activity shut down - aktivita skončila, nebo byla zničena systémem App process killed - systém ukončil neviditelnou aktivitu, např. z důvodu nedostatku paměti pro aktuálně používanou aktivitu Services Služba je součást, která běží na pozadí a slouží například k tomu, aby uživatel mohl přehrávat hudbu zatímco píše SMS nebo ovládá jinou aplikaci. Neposkytuje uživatelské rozhraní, to mají za úkol Activities, které většinou Services ovládají. Content providers Poskytovatel obsahu spravuje sadu aplikačních dat. Má za úkol sdílet data mezi aplikacemi a mezi aktivitami, které se mohou jeho prostřednictvím na data dotazovat, nebo je měnit. Např. při vytváření události v kalendáři s odkazem na konkrétní kontakt. Data mohou být ukládána do souborů, databáze, na webu nebo na jiné úložiště. Broadcast reciever

1.3. Web services Broadcast reciever naslouchá a reaguje na systémová volání, které mohou pocházet ze systému (oznámení o vybité baterii) nebo přímo od aplikace (data byla stažena). Broadcast může na taková volání reagovat výpisem do stavové řádky, nebo zavoláním jiné komponenty (neposkytuje uživatelské rozhraní). Komunikace mezi součástmi probíhá pomocí prostředku Intent. Ten se stará o to, abychom v případě, že chceme prostřednictvím jedné aplikace využít nějakou jinou, nemuseli tuto aplikaci náročně hledat. Pokud například chceme v kalendáři vytvořit událost, ke které chceme připojit kontakt a zvolíme možnost přiřadit kontakt, Intent vyhledá všechny možnosti splňující naše kritéria - tzn. dá nám na výběr, zda chceme kontakt vyhledat pomocí aplikace Kontakty, nebo například pomocí nějakého správce souborů, případně pomocí jiného programu spravujícího kontakty. 1.3 Web services Web services, neboli česky webové služby umožňují komunikaci dvou aplikací po síti pomocí strojově zpracovatelného formatu, čímž je XML 2. Služby ve Web services jsou definovány pomocí jazyku WSDL a komunikace probíhá s pomocí protokolu SOAP. Další součástí je standard UDDI, který slouží pro nalezení webových služeb. [13] Jak jsem tedy již napsala, web services jsou tvořeny třemi základními částmi: SOAP - protokol pro vzdálené volání procedur WSDL - jazyk pro popis webových služeb UDDI - standard pro nalezení webové služby 1.3.1 SOAP SOAP neboli Simple Object Access Protokol je protokol pro výměnu zpráv vyvinutý firmou Microsoft v roce 1998. Pro svoji činnost využívá HTTP 3, kde s metodou POST posílá data ve formátu XML. S předávanými parametry poté zasílá i informaci, která funkce se bude volat. Nezanedbatelnou roli hraje WSDL, s jehož pomocí je definována struktura SOAP. 2 extensible Markup Language - obecný značkovací jazyk 3 HyperText Transfer Protocol 11

1. Analýza a návrh Obrázek 1.2: Životní cyklus activities. [11] 1.3.2 WSDL Web Services Description Language je jazyk popisující webové služby, tedy například to, jaké funkce se dají volat. Je založen na XML, jehož pomocí je možné zapsat libovolně složitě strukturovaná data v platformově nezávislém formátu. Jednotnosti potřebné pro nezávislost se dá dosáhnout například pomocí využití XML Schémat, která typově omezují data a XML jmenných prostorů, která zabraňují kolizím, například předchází stejnému pojmenování proměnných. 12

1.4. REST 1.3.3 UDDI Poslední součástí webové služby je Universal Description, Discovery and Integration, standard pro nalezení webové služby. V praxi se jedná o registr sloužící pro veřejné či neveřejné ukládání a vyhledávání webových služeb. Cílem je tedy reprezentace dat a metadat o webových službách s využitím možností třídění a řazení webových služeb. 1.4 REST V této kapitole se seznámíme s pojmem REST, který je součástí zadání práce. Zkratka REST znamená Representational State Transfer a jedná se o architekturu rozhraní pro vytváření síťových aplikací. Jeho představitelem je Roy Fielding, který tuto architekturu prezentoval ve své disertační práci v roce 2000. Vzhledem k tomu, že Roy Fielding je spoluautorem protokolu HTTP, není divu, že se architektura REST opírá právě o protokol HTTP. Mezi nepopiratelné výhody patří, že je REST platformově nezávislý, takže je jedno zda server běží na Unixu a klient používá Windows či Mac, jazykově nezávislý a ačkoliv sám není standardizován, je založen na standardu HTTP. Jako potvrzení, že se REST opírá o HTTP je fakt, že RESTové aplikace používají čtyři základní operace s daty, tzv. CRUD metody (Create, Read, Update, Delete), které jsou implementovány pomocí metod HTTP protokolu. REST vlastně určuje, jak se přistupuje k datům a je používaný pro snadný a jednotný přístup ke zdrojům pomocí jejich unikátního identifikátoru URI 4. Co se týče reprezentace zdrojů, mohou mít různou podobu, např. JSON 5, XML nebo RSS 6. [14] GET (Read) HTTP metoda GET slouží jako základní metoda pro přístup ke zdrojům. Konkrétně se jedná například o požadavek na stránku odeslaný pomocí HTTP GET metody s použitím identifikátoru URI. Pokud bychom potřebovali získaná data nějak konkretizovat, nebo filtrovat je to možné. Jedná se o metodu která je idempotentní - lze ji volat opakovaně se stále stejným výsledkem. POST (Create) 4 Universal Resource Identifier 5 JavaScript Object Notation 6 Really Simple Syndication 13

1. Analýza a návrh Tato metoda slouží k vytvoření nového zdroje a jedná se o jedinou metodu, která není idempotentní, tedy s každým požadavkem se stav zdroje mění. Metoda POST se používá například v HTML 7 formulářích. V případě, že vytvoření proběhlo vrací server návratový kód 201 - Created, v opačném případě vrací server chybový kód, například 401 - Unauthorized, 403 - Forbidden. PUT (Update) Metoda PUT je velice podobná metodě POST s tím rozdílem, že u metody PUT je předem známý URI identifikátor zdroje, který chceme změnit. U vytvářeného zdroje metodou POST není možné aby bylo známé jeho URI, protože zdroj ještě není vytvořen. Jedná se o idempotentní metodu. DELETE Metoda DELETE je velice podobná metodě GET. Místo abychom zdroj získali, tak ho přímo smažeme. Jedná se o idempotentní metodu. 1.5 Restful aplikace Abychom mohli aplikaci označit za Restful, musí splňovat základní principy REST designu [15]. Mezi základní principy patří: Jednotné rozhraní Bezestavová komunikace Adresovatelnost Reprezentace zdrojů 1.5.1 Jednotné rozhraní Tato podmínka jednoznačně určuje, že je potřeba držet se HTTP protokolu a výše zmíněných CRUD metod (Create, Read, Update, Delete), tzn.: POST pokud chceme na serveru vytvořit nový zdroj GET pokud chceme získat zdroj PUT pro pozměnění zdroje 7 HyperText Markup Language 14

1.5. Restful aplikace Obrázek 1.3: Stavový model komunikace [15] DELETE pro odstranění zdroje Neměli bychom se dopouštět omylů, jako například přidávání zdroje pomocí metody GET: GET /adduser?name=robert HTTP/1.1 Správně má přidání zdroje vypadat například takto: POST /users HTTP/1.1 Host: myserver Content-Type: application/xml <?xml version="1.0"? <user> <name>robert</name> </user> 1.5.2 Bezestavová komunikace V případě bezestavové komunikace nejsou data spravována serverem, ale pouze klientskou aplikací. Server je tedy zodpovědný pouze za generování odpovědi a poskytování rozhraní, které umožňuje klientovi udržet vlastní stav aplikace. Takový přístup je méně komplikovaný a výkonější. Na obrázku 1.3 můžeme vidět stavovou komunikaci - aplikace si neudržuje svůj stav, proto se může dotazovat všeobecně na NextPage. Zatímco na obrázku 1.4 se jedná o bezestavovou komunikaci, a proto při požadavku na další stranu aplikace informuje, že se aktuálně nacházíme na straně 2. 15

1. Analýza a návrh Obrázek 1.4: Bezestavový model komunikace [15] 1.5.3 Adresovatelnost REST pracuje s tzv. zdroji, které jsou identifikovány pomocí URI (Uniform Resource Identifier), neboli pomocí jednotného identifikátoru zdroje. Všeobecně platí, že by URI mělo být jednoznačné, předvídatelné a snadno odvoditelné. Abychom toho dosáhli, je vhodné definovat si adresářovou strukturu, která je hierarchická a má vlastní kořen. Ukázkou takového URI může být například následující adresa: http://www.myservice.org/discussion/topics/{topic}, přičemž: http:// je protokol, www.myservice.org je doménové jméno, discussion je kořen, který má pod sebou uzel topics pod uzlem topics existuje řada názvů různých diskuzních témat. Další pravidla, která bychom měli dodržovat aby bylo URI plně funkční jsou: 16 používat pouze malá písmena namísto mezer používat podtržítko nebo pomlčku nepoužívat znaky používané pro dotazy (jako například otazník) a v neposlední řadě platí, že URI by měla být statická, což umožní funkčnost odkazu i v případě změny zdroje

1.6. Hlavičky HTTP 1.5.4 Reprezentace zdrojů Reprezentace zdrojů, tzn. formát dat o které jsme právě požádali může být v různých formátech, nejčastěji se setkáváme s XML, JSON nebo RSS. 1.6 Hlavičky HTTP REST aplikace využívají HTTP protokol a tím pádem i HTTP hlavičky. Co to tedy vlastně HTTP hlavičky jsou? HTTP hlavičky jsou součástí protokolu a mají za úkol konkretizovat parametry probíhající komunikace. Dalo by se říci, že se v nich definuje jak bude probíhat komunikace, jak probíhá a jaký je její výsledek. Hlavičky bychom mohli rozdělit do čtyř typů: [16] Obecné hlavičky, které poskytují univerzální informace o zprávě, např.: Date - informují o datu vytvoření zprávy: Sun, 06 Nov 1994 08:49:37 GMT Connection - definují podmínky připojení: Connection: close Hlavičky dotazu, které konkretizují dotaz, např.: Host - informuje o jméně serveru, případně portu pro požadavek: Host: info.pvt.net:8087 Accept-Charset - definuje, která znaková sada se má použít v odpovědi: Accept-Charset: iso-8859-2, iso-8859-1;q=0.8 Hlavičky odpovědi, které konkretizují odpověď, např.: Location - používá se v případě přesměrování stránky - uvádí se v ní kam byla stránka přesunuta: HTTP/1.1 301 Moved Permanently Location: http://www.abc.cz/text.html Hlavičky těla, popisující tělo, např.: Content-Type - určuje formát zobrazovaných dat: Content-Type: text/html;charset=iso-8859-1 17

1. Analýza a návrh 1.7 Autentizace Pokud se běžný uživatel internetu chce například přihlásit na webové stránky, musí zadávat své uživatelské jméno a heslo. V takovém případě server spolupracuje s databází, kde hledá zadaného uživatele a kontroluje, zda je v databázi zaveden a zda odpovídá jak jméno, tak heslo. Protože ale není možné, aby uživatelská data byla posílána nechráněná, je potřeba tato data nějakým způsobem zabezpečit. U HTTP protokolu, který využívá REST se setkáváme se třemi nejčastějšími možnostmi: [18] 1.7.1 Basic Authentication V tomto případě klient posílá jméno a heslo v hlavičce Authorization (kapitola 1.6). Například: GET /soukrome/text.html HTTP/1.1 Authorization: Basic QWxhZGRpbjGVuIH== Jak můžeme vidět na příkladu, jméno a heslo je kódováno. U metody HTTP Basic se kóduje algoritmem base64. Již na první pohled je vidět, že ochrana není zcela dostačující. Schéma neposkytuje zabezpečení proti odposlechu a pokud se někomu podaří odchytit autorizační řetězec, není problém ho rozluštit, například v PHP pouhým jedním řádkem: $decoded = base64_decode($stringtodecode); 1.7.2 Digest Access Authentication S příchodem protokolu HTTP 1.1 přichází i rozšíření v podobě Digest Access Authentication. Digest řeší problém se zasíláním skoro nechráněného jména a hesla u Basic Authentication tak, že již nezasílá přímo jméno a heslo, ale pouze kontrolní součet jména, hesla a řetězce, šifrovaného algoritmem MD5. Díky tomu odpadá možnost odposlechu a rozluštění jména a hesla, a proto je Digest Access Authentication o poznání bezpečnější. 1.7.3 OAuth Cílem metody OAuth je možnost používat webové aplikace, aniž bychom museli poskytovat údaje třetím stranám. Nejlepší vysvětlení je na příkladu - v dnešní době sociálních sítí jako Facebook, Twitter a Google+ se stále 18

1.8. Webový portál Nume Obrázek 1.5: Lišta pro sdílení na sociálních sítích [17] častěji setkáváme s tím, že můžeme například článek ze stránky, která nemá s danou sociální sítí nic společného, publikovat na svém profilu (viz. obrázek 1.5). Právě OAuth toto umožňuje aniž bychom museli například stránce root.cz sdělovat své přihlašovací údaje na sociální síť, např. na facebook. Jak tedy takový proces probíhá popisuje obrázek 1.6, slovně asi takto: Pokud chceme např. nějaký článek ze serveru root.cz sdílet na našem facebookovém profilu, musí nejdřív root.cz zažádat facebook o neautorizovaný Token. Facebook token poskytne a uživatel je přesměrován (i s neautorizovaným tokenem) na facebookové stránky a vyzván k přihlášení. Po přihlášení je uživatel přesměrován zpět na root.cz a root.cz může požádat o klíč k tokenu ve kterém jsou přihlašovací údaje. Facebook mu klíč předá a root nyní může přistupovat k našemu facebookovému profilu. [17] 1.8 Webový portál Nume Jedná se o aukční portál zabývající se dražbou položek ze sběratelských oborů numismatika (věda zabývající se platebními prostředky, jako jsou mince a bankovky), faleristika (věda zabývající se historií řádů a vyznamenání) a podobných. V současné době je implementace řešena ve frameworku Nette. Za naprosto nezbytné považuji zmínit, že aukční portál Nume.cz je založen na pravidlech Vickreyho aukce, která je popsaná výše v kapitole Vickreyho aukce 1.1.1. Co do funkčnosti nabízí portál Nume.cz širokou nabídku funkcí, které nyní představím. 1.8.1 Registrace Registraci může provést fyzická nebo právnická osoba tím, že vyplní své osobní informace. (obr. 1.7, a)) 1.8.2 Přihlášení/Odhlášení Po registraci je možné se přihlašovat a odhlašovat. (obr. 1.7, b)) 19

1. Analýza a návrh Obrázek 1.6: autentizační schéma OAuth [17] 20

1.8. Webový portál Nume 1.8.3 Aktivace účtu Aby mohl registrovaný uživatel plně využívat všech funkcí Nume.cz, například nákup a prodej, musí provést aktivaci účtu zasláním požadavku o aktivaci. Po zaslání požadavku je uživateli na příslušnou adresu zaslán aktivační kód, který zadá do aktivační sekce na svém profilu, a tím aktivuje svůj účet. Následující funkce jsou popsány s předpokladem, že uživatel má plně aktivovaný účet. 1.8.4 Prodej V případě, že chce uživatel nabídnout své zboží k prodeji, může tak učinit vyplněním formuláře informacemi o prodávaném předmětu. Za určitých podmínek (upřesněných ve Všeobecných podmínkách Nume [2]) je uživateli zpřístupněn hromadný upload, tzn. nahrání více položek najednou. Další možnosti prodeje upřesním níže. (obr. 1.7, c)) 1.8.5 Nákup Za předpokladu, že si nakupující uživatel vybral ze zveřejněné nabídky zboží o které má zájem, může využít následujících prostředků, uvedených v kapitole 1.8.6 pro jeho koupi. (obr. 1.7, d)) 1.8.6 Možnosti nákupu a prodeje To, jaké jsou možnosti nákupu závisí na tom, jaké podmínky určil majitel (prodávající) žádaného zboží. Pro prodávajícího a tedy i pro nakupujícího jsou dostupné tyto možnosti, s tím, že první dvě možnosti (Příhoz a Kup teď) jsou součástí aukce a jsou časově omezené (omezení určí prodávající) a třetí možnost (obchod) není časově omezena: Příhoz - nakupující uživatelé se přehazují a vyhrává nejvyšší nabídka. Kup teď - uživatel nakoupí položku za předem známou cenu určenou prodávajícím. Obchod - zboží je nabídnuto za pevnou cenu a není možné zakoupit položku pomocí příhozů. 21

1. Analýza a návrh 1.8.7 Procházení kategorií Jedná se o jednu z funkcí, kterou může využít i nepřihlášený uživatel. Zboží je vystavováno ve třech základních kategoriích, které jsou dále děleny do dvou podkategorií. Základní kategorie jsou: (obr. 1.7, e)) Mince a medaile Papírová platidla Řády a vyznamenání 1.8.8 Vyhledávání V případě, že nakupující uživatel má alespoň přibližnou představu co hledá, může využít funkci vyhledávání. (obr. 1.7, f)) 1.8.9 Další funkce Sledování aukce - Pokud má uživatel o dražený předmět zájem, ale ještě není rozhodnut zda ho koupit, může si aukci přidat do sledovaných a sledovat vývoj ceny draženého předmětu. Komentář - Ke každému prodávajícímu může být napsán komentář. Hodnocení uživatele - Prodávající uživatel je hodnocen předchozími nakupujícími podle jejich zkušenosti. 1.9 Mobilní aplikace Nume V následujících kapitolách je provedena analýza požadavků na funkce a funkčnost budoucí mobilní aplikace pro portál Nume. 1.10 Uživatelské role 1.10.1 Uživatel aplikace Uživatel aplikace je libovolný člověk, který může aplikaci nějakým způsobem využívat. V našem případě se pravděpodobně bude jednat o zájemce o aukce a starožitná platidla a vyznamenání. 22

1.10. Uživatelské role Obrázek 1.7: Úvodní stránka portálu Nume. a) Registrace, b) Přihlášení, c) Prodej, d) Nákup, e) Hlavní kategorie, f) Vyhledávání 23

1. Analýza a návrh 1.10.2 Nepřihlášený uživatel Jedná se o uživatele u kterého nebyla provedena autentizace, ale aplikaci již zapnul a využívá možností pro neautorizované uživatele, které jsou popsané v částech výše (mobilní aplikace bude dodržovat stejná pravidla přístupů jako webový portál). 1.10.3 Přihlášený uživatel Přihlášený uživatel je ten uživatel, který přes webové stránky provedl registraci a poté se úspěšně pomocí mobilní aplikace autorizoval. 1.10.4 Přihlášený uživatel s plně aktivním účtem Tato role je získána tak, že přihlášený uživatel zadá aktivační kód, který obdržel po zažádání do své poštovní schránky, na svém profilu a může poté využívat všechny dostupné možnosti aukčního portálu Nume. 1.11 Případy užití Na obrázku 1.8 můžeme vidět případy užití s výše zmíněnými uživatelskými rolemi. V následujících podkapitolách podrobněji vysvětlím některé z hlavních případů užití. 1.11.1 Přihlášení uživatele Popis případu užití pro přihlášení uživatele se nalézá v tabulce 1.2. 1.11.2 Odhlášení uživatele Popis případu užití pro odhlášení uživatele se nalézá v tabulce 1.3. 1.11.3 Zobrazení vlastního profilu Popis případu užití pro zobrazení vlastního profilu přihlášeného uživatele se nalézá v tabulce 1.4. 1.11.4 Nákup v obchodě Popis případu užití pro nákup v obchodě se nalézá v tabulce 1.5. 24

1.11. Případy užití Přihlášený uživatel s aktivovaným účtem Kup teď Přihodit Přihlásit se Procházet kategorie Procházet položky Zobrazit detail položky Zobrazit profil Odhlásit se Nakoupit v obchodě System Nepřihlášený uživatel Přihlášený uživatel Obrázek 1.8: Diagram případů užití 25

1. Analýza a návrh Cíl Aktér Vstupní podmínky Výstupní podmínky Základní scénář Alternativní scénáře Tabulka 1.2: Případ užití - Přihlášení uživatele Autorizace aktéra Nepřihlášený uživatel Aktér se chce přihlásit Aktér je identifikován a proběhla autorizace - Je zobrazen přihlašovací formulář - Aktér vyplní své přihlašovací údaje (jméno a heslo) - Aplikace se spojí se serverem a identifikuje aktéra - Aplikace se nemohla spojit se serverem, je potřeba obnovit spojení - Aktér vyplnil nesprávně přihlašovací údaje, je vyzván k opakování Cíl Aktér Vstupní podmínky Výstupní podmínky Základní scénář Alternativní scénáře Tabulka 1.3: Případ užití - Odhlášení uživatele Odhlášení aktéra Přihlášený uživatel Aktér se chce odhlásit Aktér je odhlášen - Je zobrazen potvrzovací dialog - Aktér potvrdí odhlášní - Aplikace odhlásí aktéra - Aktér nepotvrdil odhlášení a je stále přihlášen Tabulka 1.4: Případ užití - Zobrazení vlastního profilu Cíl Aktér Vstupní podmínky Výstupní podmínky Základní scénář Alternativní scénáře Zobrazení vlastního profilu aktéra Přihlášený uživatel Aktér chce zobrazit vlastní profil Aktér vidí vlastní profil - Aktér je přihlášen a vidí tlačítko Zobrazit profil - Aktér stiskne tlačítko Zobrazit profil - Aktérovi je zobrazen vlastní profil - Aktér není přihlášen a tedy nevidí tlačítko Zobrazit profil - Aktér je přihlášen, ale nestiskl tlačítko Zobrazit profil 26

1.12. Analýza požadavků Cíl Aktér Vstupní podmínky Výstupní podmínky Základní scénář Alternativní scénáře Tabulka 1.5: Případ užití - Nákup v obchodě Zakoupit předmět nabízený v obchodě Přihlášený uživatel s plně aktivním účtem Aktér chce zakoupit předmět z obchodu Aktér úspěště zakoupil předmět z obchodu - Systém zkontroluje zda je aktér přihlášen - Aktér zvolí možnost Nakup v obchodě - Aktér je vyzván k pozvrzení výběru - Aktér nevidí možnost nakup v obchodě, protože u daného předmětu (aukce) není možná - Aktér nemá možnost nákupu, je potřeba přihlásit se - Aktér nemá možnost nákupu - jeho účet není aktivní - Aktér nepotvrdí výběr a obchod neproběhne - Není možné zakoupit položku, protože se nachází v jiném stavu než v aktivním - Aplikace se nemohla spojit se serverem, je potřeba obnovit spojení 1.11.5 Nákup pomocí Kup teď Popis případu užití pro nákup pomocí Kup teď se nalézá v tabulce 1.6. 1.11.6 Nákup pomocí příhozů Popis případu užití pro nákup pomocí příhozů se nalézá v tabulce 1.7. 1.12 Analýza požadavků 1.12.1 Start aplikace Uživatel zapne aplikaci a ta mu nabídne možnost přihlásit se a zobrazit základní kategorie nabízené na tomto portálu. Jako další možnosti se tedy uživateli nabízí: Procházení kategorií Uživatel může procházet kategorie a podkategorie. Prohlížení sekcí 27

1. Analýza a návrh Tabulka 1.6: Případ užití - Nákup pomocí Kup teď Cíl Aktér Vstupní podmínky Výstupní podmínky Základní scénář Alternativní scénáře Zakoupit dražený předmět Přihlášený uživatel s plně aktivním účtem Aktér chce zakoupit předmět Aktér úspěště zakoupil předmět - Systém zkontroluje zda je aktér přihlášen - Aktér zvolí Kup teď u vybraného předmětu - Aktér je vyzván k pozvrzení výběru - Aktér nevidí možnost Kup teď, protože u daného předmětu není možná - Aktér nemá možnost nákupu, je potřeba přihlásit se - Aktér nemá možnost nákupu - jeho účet není aktivní - Aktér nepotvrdí výběr a obchod neproběhne - Není možné koupit za Kup teď, příhozy přesáhly cenu Kup teď - Není možné zakoupit položku, protože se nachází v jiném stavu než v aktivním - Aplikace se nemohla spojit se serverem, je potřeba obnovit spojení Uživatel může procházet nabízené zboží s možností dělení na aukční položky, položky v obchodu, nebo položky obchodu i aukce dohromady. Zobrazení detailu Aukce/Obchodu Po zvolení požadovaného zboží ze sekce, se uživateli zobrazí detail položky (aukce/obchod), který obsahuje podrobnosti o zboží a po přihlášení je možné na položku přihazovat nebo nakupovat. Přihlášení Uživatel je vyzván k autentizaci vyplněním svého přihlašovacího jména a hesla. 1.12.2 Uživatel je přihlášen Pokud uživatel již provedl autentizaci a je nyní přihlášen, může se odhlásit, a to v případě, že již nechce využívat výhody přihlášení. Po odhlášení může uživatel užívat aplikaci stejně tak, jako tomu bylo po startu aplikace. Důležité je zmínit, že aby uživatel mohl nakupovat zboží, musí být přihlášen a musí mít plně aktivovaný účet. V případě, že uživatel nemá plně 28

1.12. Analýza požadavků Tabulka 1.7: Případ užití - Nákup pomocí příhozů Cíl Aktér Vstupní podmínky Výstupní podmínky Základní scénář Alternativní scénáře Zakoupit dražený předmět pomocí příhozů Přihlášený uživatel s plně aktivním účtem Aktér chce zakoupit předmět prostřednictvím příhozů Aktér úspěště vydražil předmět - Systém zkontroluje zda je aktér přihlášen - Aktér zvolí maximální cenu - Systém navýší hodnotu předmětu - Aktér nevidí možnost příhozů, protože u daného předmětu (obchod) není možná - Aktér nemá možnost nákupu, je potřeba přihlásit se - Aktér nemá možnost nákupu - jeho účet není aktivní - Aktér nepotvrdí příhoz a transakce neproběhne - Aktér přihodil nižší cenu, než je současná cena, příhoz nebyl přijat - Příhoz byl přijat, ale byl přehozen předchozím příhozem - Není možné zakoupit položku, protože se nachází v jiném stavu než v aktivním - Aplikace se nemohla spojit se serverem, je potřeba obnovit spojení aktivovaný učet, nemůže nakupovat zboží a nad možnosti nepřihlášeného uživatele může využít pouze možnosti zobrazit svůj profil. Pokud je uživatel přihlášen a má plně aktivní účet, může využít všech dostupných možností, včetně nákupu zboží. 1.12.3 Nákup zboží V případě, že uživatel v sekci nalezl zboží o které má zájem,e může si zobrazit detail položky, kde se nacházejí informace o jejím aktuálním stavu, informace o položce a v případě aukce zde může nalézt historii příhozů. Samozřejmě může na dražený předmět přihodit (v případě aukce) a tím projevit zájem o koupi nebo pokud je to u dané aukce možné, koupit zboží ihned za předem známou cenu funkcí Kup teď. U obchodu může uživatel zboží pouze nakoupit, a to za předem známou cenu. 29

1. Analýza a návrh 1.12.4 Zobrazit profil V sekci Zobrazit profil může přihlášený uživatel vidět své osobní informace, jako je jméno, adresa, telefon a další. Také zde vidí, zda je jeho účet aktivní nebo není. 1.13 Funkční požadavky Přihlášení Vyžadovaná role - Nepřihlášený uživatel (1.10.2) Odhlášení Vyžadovaná role - Přihlášený uživatel (1.10.3) Zobrazení nabídek Vyžadovaná role - Nepřihlášený uživatel (1.10.2) Zobrazení detailu položky Vyžadovaná role - Nepřihlášený uživatel (1.10.2) Zobrazení vlastního profilu Vyžadovaná role - Přihlášený uživatel (1.10.3) Nákup v obchodě Vyžadovaná role - Přihlášený uživatel s plně aktivním účtem (1.10.4) Příhoz na aukci Vyžadovaná role - Přihlášený uživatel s plně aktivním účtem (1.10.4) Možnost Kup teď u aukce Vyžadovaná role - Přihlášený uživatel s plně aktivním účtem (1.10.4) 30

1.14. Nefunkční požadavky 1.14 Nefunkční požadavky Funkční na platformě Android Minimální verze 2.2 Uživatelsky přívětivé - snadná orientace 1.15 Návrh restového rozhraní Vzhledem k tomu, že pro funkčnost mobilní aplikace je nezbytně nutné mít serverovou stranu, bylo potřeba abych takový server naimplementovala. Ráda bych ale zdůraznila, že serverová část není hlavním předmětem mé bakalářské práce a proto jsem se při implementaci zaměřila především na funkčnost, nezbytně nutnou pro chod mé mobilní aplikace. Po předchozí analýze jsem se rozhodla využít architekturu REST. Pro snazší implementaci jsem připravila návrh restového rozhraní: 1.15.1 Přihlášení uživatele Cíl: Metoda: URL: Hlavička: Formát odpovědi: Odpověď: Uživatel se chce přihlásit GET /rest/login.json Authorization: Basic [username:password v Base64] JSON Osobní údaje uživatele (pokud jsou přihlašovací údaje správné) 1.15.2 Odhlášení uživatele Cíl: Uživatel se chce odhlásit Metoda: GET URL: /rest/logout.json Hlavička: Authorization: Basic [username:password v Base64] Formát odpovědi: JSON Odpověď: ok 31

1. Analýza a návrh 1.15.3 Zobrazení hlavních kategorií Cíl: Uživatel chce zobrazit hlavní kategorie Metoda: GET URL: /rest/category.json Hlavička: - Formát odpovědi: JSON Odpověď: informace o třech hlavních kategoriích (název, id) 1.15.4 Zobrazení podkategorií Cíl: Uživatel chce zobrazit podkategorie Metoda: GET URL: /rest/category/[id nadřazené kategorie].json Hlavička: - Formát odpovědi: JSON Odpověď: informace o podkategoriích (název, id) 1.15.5 Zobrazení položek auction může mít hodnoty 0 - pouze obchod, 1 - pouze aukce, 2 - aukce i obchody Cíl: Uživatel chce zobrazit položky - aukce a obchody Metoda: GET URL: /rest/section/[id kategorie].json?auction=[0 1 2]&page=[číslo stránky] Hlavička: - Formát odpovědi: JSON Odpověď: informace o položkách z vybrané kategorie 1.15.6 Zobrazení detailu položky Cíl: Uživatel chce zobrazit detail položky Metoda: GET URL: /rest/auction/[id položky].json Hlavička: - Formát odpovědi: JSON Odpověď: detailní informace o vybrané položce 32

1.15. Návrh restového rozhraní 1.15.7 Příhoz Cíl: Metoda: URL: Hlavička: Formát odpovědi: Odpověď: Uživatel chce přihodit na aukci POST /rest/bid/[id aukce].json Authorization: Basic [username:password v Base64] Price: [přihozená částka] JSON odpověď serveru (true, Házíte pod cenou) 1.15.8 Nákup v obchodu nebo Kup teď Cíl: Uživatel chce koupit položku z aukce nebo obchodu Metoda: POST URL: /rest/buy/[id aukce].json Hlavička: Authorization: Basic [username:password v Base64] Formát odpovědi: JSON Odpověď: odpověď serveru (true, chyba) 33

Kapitola 2 Realizace serveru Protože mobilní aplikace - klient není funkční bez serveru, popíši v první části realizaci serveru. Jak jsem již zmínila na předchozích stránkách, server není předmětem mé bakalářské práce, a proto byl vypracován tak, aby v první řadě sloužil mé mobilní aplikaci. 2.1 Vývojové prostředí Jako vývojové prostředí jsem si zvolila program NetBeans IDE 7.2.1 8, který podporuje jazyk PHP 9, ve kterém je server napsán. Abych byla konkrétnější, server je napsán v jazyku PHP s využitím frameworku Nette, který je popsán v následující kapitole (2.2 Framework Nette). 2.2 Framework Nette Nette framework jsem si zvolila z prostého důvodu, že již hotová webová aplikace Nume byla napsána s využitím tohoto frameworku. Výhoda Nette frameworku je ta, že celá dokumentace je v češtině a rozšiřuje tak skupinu zájemců i o ty, kteří angličtinu zcela neovládají. Já jsem bohužel nemohla, z důvodu nutnosti práce na klientovi, dostatečně nahlédnout do světa Nette. Nevýhoda ovšem byla v tom, že Nette samo nepodporuje Restový server. Proto jsem na restové routování použila kód od Adama Štipáka RestRoute 10, který mapuje CRUD operace do presenteru a je dostupný přes úložiště Github. 8 www.netbeans.org 9 Hypertext Preprocessor 10 https://github.com/newpope/nette-restroute 35

2. Realizace serveru 2.3 Persistence dat Data se kterými jsem pracovala bohužel nemohu poskytnout, neboť jsou majetkem firmy NUME ONE s.r.o. a jsou licencovaná. Pouze tedy vypíši strukturu databáze, a to tabulky, které jsem ve své práci využívala. bid - Tabulka, ve které se uchovávají informace o příhozech, jako id aukce, id uživatele, výše příhozu a čas příhozu. buynow - Tabulka, ve které se uchovávají informace o nákupu Kup teď a nákupu přes obchod. category - Tabulka se záznamy o kategoriích a podkategoriích. itemimages - Tabulka se záznamy o obrázcích k položkám, jako je id aukce a id obrázku. images - Jedná se o tabulku na kterou se odkazuje tabulka itemimages, nachází se v ní například cesta k obrázku a jeho název. saleitem - Obsahuje veškeré informace o položkách, jako je název, id majitele, cena, čas do konce a další. user - Tabulka se záznamy o uživatelích, například jméno, příjmení, email, telefon a další. address - Tabulka s adresou uživatele. 2.4 Aplikační logika Aplikační logika Nette je založená na architektuře MVP, tedy Model-View- Presenter. Kdy každá část má svoji vlastní úlohu. Model je datová a funkční vrstva aplikace, View se stará o vykreslení výsledku a Presenter spojuje obě vrstvy dohromady, kdy na základě požadavku uživatele vyvolá příslušnou aplikační logiku. V mé práci se setkáváme s presentery, které popisuji v následujících odstavcích. 2.4.1 BasePresenter Základní presenter, který podle zadaného URL volá příslušné presentery. Mimo této funkce také pracuje s hlavičkami a z výsledků presenterů tvoří JSON, který odesílá jako odpověď. Mimo jiných v něm najdeme funkce: public function actionread(){} 36

2.4. Aplikační logika public function actioncreate(){} pro GET a POST operace. 2.4.2 SectionPresenter Třída zajištující načítání položek ze zadané kategorie. Protože se může stát, že chceme zobrazit položky z kategorie, která není poslední, musíme použít rekurzi. V tomto případě se jedná o funkci private function gettree($parent, $where) {} které předáváme id nadřazené kategorie a která rekurzivně prochází tabulku saleitem (2.3) a hledá v ní položky z příslušné kategorie. Proměnná $where určuje zda se budou hledat aukce, obchody nebo obojí. 2.4.3 CategoryPresenter Presenter, který vrací kategorie. V případě, že předem známe nadřazenou kategorii, vypisuje podkategorie podle id nadřazené kategorie, zadané v url. V případě, že neznáme nadřazenou kategorii vypíše tři hlavní kategorie. 1.8.7 2.4.4 AuctionPresenter Presenter, který vrací všechny informace z tabulky saleitem - tedy podrobnosti o obchodu nebo aukci. Mimo to vrací i historii příhozů a adresu a název obrázku. 2.4.5 LoginPresenter Podle přijatého jména a hesla (dešifrovaného z hlavičky v BasePresenteru) vyhledá v databázi záznam o uživateli. Pokud uživatel existuje, vrací jeho osobní informace a adresu. Pokud v databázi uživatel neexistuje, případně se neshoduje jméno a heslo, vrací prázdné pole. 2.4.6 ImagePresenter Presenter, který podle přijatého id položky vrací předem neznámou množinu cest a názvů obrázků. 37

2. Realizace serveru 2.4.7 LogoutPresenter Odhlásí uživatele a vrací true. 2.4.8 BidPresenter Presenter zajišťující příhoz na aukci identifikované podle id v url. Přihazovaná cena se zjistí z hlavičky v BasePresenteru. Spolupracuje s již hotovou logikou Nume a v případě úspěchu vrací true. V případě neúspěchu vrací chybovou hlášku. 2.4.9 BuyPresenter Zajišťuje nákup v obchodě nebo pomocí Kup teď. Stejně jako BidPresenter spolupracuje s již hotovou logikou Nume a v případě úspěchu vrací true, v případě neúspěchu vrací chybovou hlášku. 38

Kapitola 3 Realizace Klienta - mobilní aplikace 3.1 Vývojové prostředí Svoji mobilní aplikaci jsem vyvíjela v prosředí Eclipse SDK verze 4.2.2 11, které se dá stáhnout jako součást balíčku ADT 12. ADT je oficiální plugin, česky zásuvný modul, pro vývoj Androidu a obsahuje všechny knihovny a nástroje potřebné pro vznik nové Android aplikace. Mimo jiné je součástí balíčku i emulátor AVD 13, který jsem při své práci často využívala a z něhož pochází následující obrázky. Ještě bych ráda připomněla, že aplikace je psaná v jazyku Java. 3.2 Aplikační logika Většina aplikační logiky se skrývá v aktivitách (popsaných v kapitole 1.2.5). Každou aktivitu můžeme prezentovat jako samostatnou obrazovku. Ve své práci jsem navrhla několik aktivit, které popisuji v následujícíh kapitolách. 3.2.1 Hlavní aktivita Jedná se o aktivitu, kterou uživatel vidí jako první po startu aplikace. Můžeme jí také říkat domovská aktivita, protože se na ní odkazujeme z action baru, při stisknutí domovského tlačítka 3.12 (obrázek vlevo na actionbaru). 11 www.eclipse.org 12 Android DeveloperTools 13 Android Virtual Device 39

3. Realizace Klienta - mobilní aplikace Při startu aplikace se na obrazovce nacházejí pouze dvě tlačítka (viz. obrázek 3.1 vlevo), a to: Kategorie Přihlásit se Při kliknutí na tlačítko Kategorie se přesměrujeme na aktivitu 3.2.4 - Aktivita Kategorie. Při kliku na tlačítko Přihlásit se, se přesměrujeme na aktivitu 3.2.2 - Přihlašovací aktivita. V případě, že uživatel je přihlášen a vrátí se zpět na tuto aktivitu jsou vidět jiná tlačítka (viz. obrázek 3.1 vpravo), a to: Kategorie Zobrazit profil Odhlásit se Při kliku na tlačítko Zobrazit profil se přesměrujeme na aktivitu 3.2.3 - Aktivita Profilu. Při kliknutí na tlačítko Odhlásit se se pouze zobrazí potvrzovací dialog (viz. obrázek 3.2). Také se jedná o jedinou aktivitu, která není závislá na internetu, tzn. můžeme ji vidět i v případě, kdy nemáme připojení na internet. 3.2.2 Přihlašovací aktivita Jak již název vypovídá, jedná se o kategorii, kde se může uživatel přihlásit. Při stisknutí tlačítka Přihlásit se na hlavní obrazovce (případně na actionbaru) se zobrazí tato aktivita obsahující dvě textová vyplňovací pole a odesílací tlačítko Přihlásit se. V každém vyplňovacím poli je nápověda Jméno a Heslo aby uživatel věděl, kam má své údaje zapsat (obrázek 3.3). Po vyplnění údajů, přičemž u hesla se zobrazují pouze tečky, uživatel stiskne tlačítko Přihlásit se a mohou nastat následující situace: 40 Přihlášení bylo úspěšné V případě, že v databázi existuje záznam se zadaným jménem a heslem, je uživatel přihlášen a přesměrován na domovskou aktivitu 3.2.1. Přihlášení proběhlo neúspěšně V případě, že v databázi nebyl nalezen uživatel se zadaným jménem a heslem, je zobrazena varovná hláška (viz obrázek 3.3 uprostřed) a je ponecháno vyplněné jméno a odstraněno heslo. Stejná situace nastává i v případě, že uživatel nevyplnil jedno nebo obě textová pole.

3.2. Aplikační logika Obrázek 3.1: Hlavní aktivita, vlevo uživatel není přihlášen, vpravo je uživatel přihlášen Obrázek 3.2: Potvrzovací dialog odhlášení 41

3. Realizace Klienta - mobilní aplikace Obrázek 3.3: Přihlašovací aktivita, vpravo registrace Není připojení Pokud aktuálně není připojení k internetu, nemůžeme zjistit, zda je uživatelské jméno a heslo platné, proto se zobrazí View 3.2.7. V případě, že uživatel ještě není registrován, může využít odkaz Registrace, který přesměruje na webové stránky www.nume.cz/registrace (3.3, vpravo). 3.2.3 Aktivita Profilu Aktivita zobrazující osobní profil přihlášeného uživatele. Jedná se o jednu z aktivit, kdy není potřeba připojení. Připojení není potřeba, neboť všechny potřebné údaje byly přijaté spolu s odesláním přihlašovacích údajů jako odpověď na požadavek o přihlášení. Proto když po přihlášení dojde k přerušení internetového spojení, mohou být údaje zobrazeny. V této aktivitě se také na actionbaru zobrazí tlačítko Odhlásit se, které funguje stejně jako na domovské aktivitě (obrázek 3.2). Ukázka profilu je na obrázku 3.4 3.2.4 Aktivita Kategorie Aktivita kategorií je aktivita vytvořená s pomocí prvku ListView, což znamená, že se jedná o seznam položek, přičemž předem nevíme o kolik položek se bude jednat. Ač v hlavní kategorii víme, že se bude jednat o 3 položky, nemůžeme vědět, zda se tento počet v budoucnu nezvýší a nebude přidána další hlavní kategorie. 42

3.2. Aplikační logika Obrázek 3.4: Osobní profil přihlášeného uživatele Protože jsem chtěla, aby se mezi jednotlivými kategoriemi a podkategoriemi dalo přesouvat i pomocí systémového tlačítka Zpět, každou z úrovní jsem vytvořila jako samostatnou aktivitu. Aby kód nemusel být několikrát duplikovaný, vytvořila jsem hlavní třídu GeneralCat ze které každá kategorie aktivita (KategorieActivity, SecondCat, ThirdCat) dědí. Předávání id mezi jednotlivými kategoriemi probíhá pomocí Intentu (viz. kapitola 1.2.5), stejně tak předávání názvu nadřazené kategorie: Intent act = new Intent(v.getContext(), MainSherlock.class); act.putextra("oldid", ida); act.putextra("oldname", labela); startactivity(act); V našem případě mají kategorie tři stupně. Poté co máme zobrazen poslední stupeň kategorie a nějakou z nich vybereme, přesměrujeme se na aktivitu 3.2.5 - Aktivita Sekce a ta zobrazí položky z vybrané kategorie. Může se ale stát, že nejsme zcela rozhodnuti jakou přesně kategorii požadujeme, a proto je zde možnost zvolit např. celou hlavní kategorii Mince a medaile. Docílit toho můžeme stisknutím Zobrazit vše u příslušné kategorie (viz. obrázek 3.5). Stisknutí tohoto tlačítka nás přesměruje na aktivitu 43

3. Realizace Klienta - mobilní aplikace Obrázek 3.5: Zleva: hlavní kategorie, druhá podkategorie, třetí podkategorie 3.2.5 (stejně jako v případě zvolení poslední kategorie), ovšem zobrazí se nám položky ze všech jejích podkategorií. Pokud nastane situace, kdy mobilní zařízení nemá připojení na internet (nebo se internet přeruší ještě před vytvořením aktivity), nezobrazí se požadovaná aktivita, ale nastaví se View 3.2.7 - Není připojení. 3.2.5 Aktivita Sekce Jedná se o aktivitu s největší a nejsložitější funkčností. Po zvolené kategorii nám tato aktivita zobrazí položky aukce nebo obchodu. Základem aktivity je třída MainSherlock která dědí z třídy SherlockFragmentActivity importované z rozšíření Sherlock ActionBar (popsané v kapitole 3.3.1). Jednou z hlavních funkcí aktivity je přepínání mezi takzvanými Taby, neboli záložkami (viz. obrázek 3.6), které umožňují vybírat položky podle jejich typu, tedy: Aukce - aukční položky na které lze přihazovat, nebo využít funkci Kup teď Obchod - položky obchodu, které lze nakoupit za pevnou cenu a nejsou časově omezené Vše - aukční položky i položky obchodu dohromady Mezi další funkci této aktivity patří stránkování. Protože jsou veškeré údaje načítané z internetu je doba zobrazení závislá na rychlosti připojení, a proto 44

3.2. Aplikační logika Obrázek 3.6: Položky z vybrané kategorie, vpravo vidíme načítací kolečko také není možné zobrazit všechny položky najednou, protože jich mohou být stovky. Proto je ve spolupráci se serverem navrženo stránkování, konkrétně 7 položek na stránku, nastavených na straně serveru. Při prvním načtení této aktivity se zobrazí prvních 7 položek. Pokud chce uživatel vidět další položky, odroluje na konec stránky, kde se zobrazí načítací kolečko, které signalizuje načítání dalších 7 položek (obrázek 3.6 vpravo). Tímto způsobem lze postupně zobrazit všechny dostupné položky. V případě, že uživatele nějaká položka zaujme, zvolí ji a přesměruje se na aktivitu 3.2.6 - Aktivita Detail Položky. V této aktivitě byla také poprvé použita knihovna ImageLoader (3.3.2), zajišťující načítání obrázků a knihovna JodaTime (3.3.3), zajišťující přepočet času zbývajícího do konce aukce. 3.2.6 Aktivita Detail Položky Jednou z posledních aktivit je Detail položky. Jedná se o detailní náhled námi zvolené položky. V této aktivitě také můžeme provést příhoz nebo nákup. Podstatné je také říci že vzhled aktivity se liší podle toho, zda se jedná o obchod nebo o aukci. Rozdíl je patrný na obrázku 3.8. Rozdílů mezi detailem obchodu a aukce je více: u obchodu se nemůžeme setkat s historií 45

3. Realizace Klienta - mobilní aplikace 46 Obrázek 3.7: Stavový diagram položky

3.2. Aplikační logika příhozů. Dále, jak bylo uvedeno výše, je položka obchodu časově neomezená, proto u ní není uveden čas konce. Kromě rozdílů mezi obchodem a aukcí jsou zde rozdíly také podle toho, do jaké kategorie položka spadá. Například u detailu položky z kategorie Mince a medaile jsou informace jako Mincovna a Mincmistr, zatímco u kategorie Řády a vyznamenání jsou to Název řádu a Medailiér. Položky se řídí stavovým automatem 3.7, definovaném již při vzniku webové verze portálu Nume.cz. Z tohoto automatu vyplývá, že jsou pro nás důležité všechny stavy, kromě stavů 4 - Skryté, 7 - Čeká na vystavení a 2 - Smazáno, kdy běžný uživatel nemůže tuto aukci vidět ani si zobrazit její detail a nejsou tedy zobrazeny v mobilní aplikaci. Dle logiky tohoto automatu, může uživatel zakoupit položku pouze pokud se nachází ve stavu 5 - Vystaveno. Může se ale stát, že v okamžiku kdy uživatel aktualizuje detail, je položka již prodána, tzn. nachází se ve stavu 6 - Prodáno. Proto se v této aktivitě vyskytuje několik stavů, kdy uživatel nemůže nakupovat. Tyto stavy jsou následující a jsou výrazně vyznačeny 3.9: Pokud chcete nakupovat, přihlašte se - Uživatel není přihlášen a musí se přihlásit Pokud chcete nakupovat, aktivujte si účet - Uživatel nemá aktivní účet, aktivaci musí provést přes webové stránky www.nume.cz Nemůžete koupit vlastní položku Položka je navržena na zrušení - stav 10 Položka byla zrušena portálem - stav 9 Úspěšně ukončeno - stav 8 Prodej byl zrušen prodávajícím - stav 1 Položka se neprodala - stav 3 Položka byla prodána - stav 6 Neaktivní - jiný, neočekávaný stav V případě, že se nenacházíme v žádném z těchto stavů, můžeme položku získat třemi způsoby: 47

3. Realizace Klienta - mobilní aplikace Nákup v obchodě Jde o jednorázový nákup za pevně stanovenou cenu, který může být realizován pouze u položek z obchodu. Pokud je uživatel přihlášen a položka se nachází ve stavu 5, může uživatel stisknout tlačítko Nakup v obchodě a potvrdit potvrzovací dialog (obrázek 3.10 vlevo). Pokud nenastane problém, je mu zobrazen text Gratuluji, nakoupil jste a položka změní svůj stav na stav Položka byla prodána. Kup teď Možnost, která je dostupná pouze u aukčních položek, ale pouze pokud ji prodávající uživatel povolil. V případě, že cena navýšená příhozy přesáhla cenu Kup teď, není už tato možnost dále dostupná. Pokud ale možnost Kup teď dostupná je, může uživatel stisknout tlačítko Kup teď a potvrdit potvrzovací dialog (obrázek 3.10 uprostřed). Pokud nenastane problém, je mu zobrazen text Gratuluji, nakoupil jste a položka změní svůj stav na stav Položka byla prodána. Příhoz Způsob, kdy uživatel u aukčních položek nabídne určitou cenu a snaží se díky ní zvítězit. Přihazování v mé aplikaci se říd modifikovanými pravidly Vickreyho aukce (kapitola 1.1.1). Uživatel do čistě numerického políčka zapíše svoji nabízenou cenu a stiskne tlačítko Odeslat a potvrdí potvrzovací dialog (obrázek 3.10 vpravo). Následně je mu zobrazen text, který definuje současný stav: Gratulujeme, nyní jste vítěz - Uživatel nabídl nejvyšší nabídku a nyní v dražbě vede. Přihodil jste cenu nižší než vlastní příhoz - Uživatel již jednou přihodil a při druhém příhozu nabídl nižší částku než při prvním Byl jste přehozen - Příhoz byl platný, bohužel před uživatelem přihodil někdo vyšší částku. Přihazujete pod cenou - Příhoz nebyl přijat, protože byla nabídnuta částka stejná nebo nižší než aktuální cena. Stejně jako u aktivity sekce, je zde využita knihovna ImageLoader a JodaTime. 48

3.2. Aplikační logika Obrázek 3.8: Vlevo detail aukce, vpravo detail obchodu Obrázek 3.9: Stav ze kterého nelze nakupovat, uživatel není přihlášen 49

3. Realizace Klienta - mobilní aplikace Obrázek 3.10: Zleva: potvrzovací dialog nákupu v obchodě, dialog Kup teď, dialog přihoď Obrázek 3.11: View zobrazovaný v případě, že není připojení 3.2.7 Není připojení Nejedná se o aktivitu, ale považuji to za důležitou součást práce. Jedná se o View, který je nastaven vždy při přechodu na novou aktivitu pokud není připojení. Je zde jednoduchý obrázek a text a spolu s tímto View je zobrazován i Toast Není připojení. Pokud uživatel připojení obnoví, musí se pomocí tlačítka Zpět vrátit o aktivitu zpět a znovu kliknout na požadovanou položku. Obrázek 3.11. 50