Mendelova univerzita v Brně Provozně ekonomická fakulta
Multiplatformní mobilní aplikace pro nákup kuponů Diplomová práce
Vedoucí práce: Ing. Ondřej Popelka, Ph.D.
Bc. Martin Ševčík
Brno 2014
Rád bych vyjádřil poděkování panu Ing. Ondřeji Popelkovi, Ph.D. za cenné připomínky, odborné rady a podněty k zamyšlení během vypracování diplomové práce.
Čestné prohlášení Prohlašuji, že jsem tuto práci: Multiplatformní mobilní aplikace pro nákup kuponů vypracoval/a samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 25. května 2014
_______________________________
Abstract Ševčík, M. This thesis describes design and implementation of cross-platform mobile application for coupon purchasing in the Vykupto company. First part analyzes the existing mobile Vykupto applications. New application‘s draft including visual application screens is created on basis of requested functional and non-functional requirements. The following part is about selecting appropriate technology to create cross-platform application. The last part covers implementation of a application prototype and user testing. Keywords Vykupto, coupon, multiplatform application, hybrid application, jQuery mobile, PhoneGap, CoffeeScript
Abstrakt Ševčík, M. Diplomová práce se zabývá návrhem a implementací multiplatformní mobilní aplikace pro nákup kuponů ve firmě Vykupto. V první části jsou analyzovány stávající mobilní aplikace Vykupto. Na základě vyžádaných funkčních a nefunkčních požadavků je vytvořen návrh nové aplikace včetně vizuálních návrhů obrazovek aplikace. V další části je vybrána vhodná technologie pro vytvoření multiplatformní aplikace. Po výběru technologií probíhá implementace prototypu aplikace a uživatelské testování. Klíčová slova Vykuto, kupón, multiplatformní aplikace, hybridní aplikace, jQuery mobile, PhoneGap, CoffeeScript
HTML5 Web Storage ....................................................................................................... 68
7.10 Implementace přihlášení do aplikace ....................................................................... 70 7.11 PhoneGap pluginy ............................................................................................................ 70 7.12 Změny provedené v API Vykupto ............................................................................... 71 7.13 Testovací server Vykupto .............................................................................................. 72 7.14 Kompilace aplikace .......................................................................................................... 72 7.14.1
Kompilace přes Phonegap Build ....................................................................... 72
7.14.2
Lokální kompilace .................................................................................................. 72
7.15 Certifikace aplikace .......................................................................................................... 73 7.16 Emulace Aplikace.............................................................................................................. 73 7.16.1
Ukázka dat pro detail slevy, které odesílá API Vykupto, formát JSON
89
B
Základní HTML struktura jQuery Mobile aplikace s jednou stránkou
91
C
Navigační schéma aplikace
92
D
Přiložené CD
93
12
Obsah
Seznam obrázků
13
Seznam obrázků Obr. 1
Náhled aktuální mobilní aplikace Vykupto (Android)
19
Obr. 2
Hlavní obrazovka aplikace
32
Obr. 3
Mockup – Slide panel aplikace
33
Obr. 4
Přihlašovací obrazovka aplikace
33
Obr. 5
Registrační obrazovka aplikace
34
Obr. 6
Hlavní seznam slev
35
Obr. 7
Mockup – základní informace o slevě
35
Obr. 8
Mockup – více detailů u slevy
36
Obr. 9
Mockup – fotogalerie slevy
36
Obr. 10
Mockup – proces nákupu
37
Obr. 11
Mockup – poděkování za objednávku
38
Obr. 12
Mockup - Nastavení účtu uživatele
38
Obr. 13
Mockup - nalezené slevy pomocí vyhledávání
39
Obr. 14
Mockup – moje kupóny
39
Obr. 15
Mockup - Detail voucheru (kupónu)
40
Obr. 16
Princip fungování wrapperu
42
Obr. 17
Sencha Touch Architect
48
Obr. 18
Hlavní okno ThemeRolleru
59
Obr. 19
Slide panel v jQuery Mobile aplikaci
67
Obr. 20
Vykupto aplikace spuštěná v Ripple Emulátoru
75
Obr. 21
Hlavní okno Weinre nástroje
77
Obr. 22
Nástroje vývojáře ve Weinre
78
14
Obr. 23
Seznam obrázků
Jak spustit ladění přes Phonegap Build
79
Úvod a cíl práce
15
1 Úvod a cíl práce 1.1
Úvod
Mnou vybrané téma jsem si zvolil po schůzce s panem Tomášem Bátrlou z firmy Vykupto s.r.o. (dále jen Vykupto), kde jsme společně vymysleli koncept nové mobilní aplikace pro nákup kuponů. Tomáš Bátrla se ve Vykupto stará o partnery projektu, marketing a obchod v Brně. Vykupto v tuto chvíli má aplikaci na iPhone i na Android, avšak obě nejsou delší dobu již udržovány, jelikož jejich původní programátoři odešli z firmy. Akutální mobilní aplikace neobsahují novinky, které jsou vidět na hlavním webu Vykupto. Některé funkce nefungují zcela korektně, některé dokonce způsobují pády aplikace. Vykupto se tedy rozhodlo pro vytvoření multiplatformní aplikace, díky čemuž bude jednodušší a levnější vývoj a údržba aplikace. Přes mobilní aplikace zpracovává Vykupto přibližně 15 % objednávek, proto jsou pro ně mobilní zařízení velice důležitá. Díky multiplatformnosti aplikace lze vytvořit jeden aplikační kód, díky kterému vznikne aplikace pro více platforem. I z hlediska udržování kódu je tento přístup efektivnější. Není nutno zaměstnávat programátory pro každou mobilní platformu zvlášť, stačí pouze jeden programátor, který vytvoří multiplatformní aplikaci. Toto je cesta, která Vykupto zajímá vzhledem k výhodám, které multiplatformní aplikace přináší.
1.2
Cíl práce
Cílem práce je vytvoření a otestování prototypu aplikace pro nákup kuponů (voucherů) pro firmu Vykupto.cz s.r.o., dále pouze Vykupto. Bude se jednat o aplikaci pro mobilní zařízení (smartphony, tablety) primárně na platformách Apple iOS a Google Android. Aplikace bude tedy multiplatformní. To znamená jeden aplikační kód, který jen s pár změnami bude fungovat na všech platformách, na které bude aplikace zkompilována. Od firmy Vykupto budou vyžádány funkční a nefunkční požadavky na aplikaci a bude analyzována stávající mobilní aplikace firmy Vykupto. Na základě analýzy požadavků se vytvoří návrh nové aplikace včetně tzv. mockupů, což jsou vizuální návrhy obrazovek aplikace. Následně budou vybrány vhodné technologie pro vytvoření dané aplikace, které umožní udělat aplikaci multiplatformní. Po výběru technologií proběhne implementace prototypu aplikace. Prototyp aplikace bude otestován několika uživateli, jejich návrhy a poznámky budou sepsány a brány v úvahu během pozdějšího dokončování ostré verze aplikace.
16
Stávající řešení
2 Stávající řešení V této kapitole bude probrána aktuální mobilní aplikace, kterou Vykupto má, dále problematika slev a API, které Vykupto poskytuje pro mobilní aplikace.
2.1
Princip fungování slev
Principem slevových portálů je nabízení slev (dealů) na zboží všeho druhu, které si na těchto portálech nechávají vystavit různé firmy za účelem prodeje. Jedná se například o služby, oblečení, zájezdy, různé vybavení do domácností a podobně. Při vstupu na slevový portál jsou uživateli zobrazeny nabídky pro aktuální den. Pokud se uživateli některá nabídka líbí, přečte si detailní informace o ní, podívá se případně na diskuzi a pokud je spokojený, může si ji zakoupit. Po zakoupení mu přijde na e-mail tzv. voucher, což je většinou PDF dokument, který je připraven k vytištění a obsahuje unikátní kód identifikující tento konkrétní voucher. Na mnoha místech navíc již není vůbec nutno tento voucher tisknout, stačí se jakkoliv prokázat s unikátním kódem. Voucher se tedy dá zobrazit například na displeji mobilního telefonu. Jak dále voucher využít už záleží na typu dané slevy. V případě např. gastronomické slevy je nutno se tímto voucherem prokázat na místě. U slevy do e-shopu se pak například opisuje unikátní identifikační kód do kolonky pro slevu, která se před dokončením objednávky aplikuje a cena se u objednávky sníží. Je to velice individuální a u každé slevy se může voucher aplikovat různě.
2.2
Proces nákupu slevy
V případě stávající mobilní aplikace Vykupto se celý proces nákupu slevy dělí na určitý počet kroků. Počet kroků je určen na základě údajů, které musí uživatel zadat během nákupu. Například sleva do gastronomického zařízení nebude vyžadovat žádné údaje kromě e-mailu (ten je evidován v uživatelském účtu, není potřeba jej vyžadovat od uživatele během nákupu). Ale sleva na zboží (různé oblečení aj.) již bude vyžadovat adresu pro doručení, takže se počet kroků změní. Maximální počet kroků během nákupu je 5 (u slev, které vyžadují nejvíce údajů), minimální pak 2 (u slev, které nevyžadují žádné údaje). Rozbor jednotlivých kroků nákupu: 1.
Výběr varianty slevy. Výběr varianty se zobrazuje v případě, že sleva má více variant, nezobrazuje se tedy vždy. Nejčastěji se jedná o oblečení (barvy, velikosti oblečení) nebo zájezdy (počet lidí v zájezdu, počet dní ubytování atd.)
2.
Počet voucherů k zakoupení. Tento krok je povinný, zobrazuje se vždy u všech slev. U každé slevy je navíc maximální počet zakoupených voucherů individuální a určuje ji zadavatel slevy. Například u oblečení bývá možnost zakoupit až
Stávající řešení
17
10 voucherů (tedy 10 kusů oblečení), u dovolených se často povoluje pouze jeden voucher na objednávku. 3.
Typ dodání slevy. Tento krok není vyžadován vždy. Pokud sleva vyžaduje vyplnění typu dodání, pak se uživateli zobrazí možnosti, které jsou u každé slevy individuální. Typy dodání specifikuje zadavatel slevy.
4.
Typ platby. Zde si uživatel vybere, jak chce slevu zaplatit. Má na výběr platbu předem na účet nebo platbu některou z možných platebních karet (Visa, Visa Electron, MasterCard, Maestro). Tento krok je povinný, zobrazuje se vždy. Zároveň tento krok slouží jako potvrzovací u většiny slev - odešle se objednávka. Pouze některé slevy pokračují na poslední, tedy pátý, krok a to v případě, že jsou potřeba dodací a fakturační adresy. Dodací a fakturační adresa. Tento krok se nezobrazuje vždy, ale pouze u některých slev, které vyžadují adresu. Fakturační adresa je povinná. Pokud je doručovací adresa jiná než fakturační, pak se vyplňuje i ta. Po vyplnění povinných údajů pak končí proces nákupu v tomto kroku potvrzením objednávky.
5.
Kroky 2 a 4 se uživateli zobrazí vždy (jsou povinné), ostatní kroky se zobrazují na základě dat konkrétní nakupované slevy. U kroku 4 a 5 během potvrzování objednávky je také nutno potvrdit souhlas s obchodními podmínkami. Bez potvrzení nelze objednávku dokončit.
2.3
Varianty a skupiny slev
Vykupto má komplexní systém variant a skupin slev, aby bylo schopno pokrýt maximální počet variant slev. Možná uložení variant u slevy: 1. Sleva obsahuje pouze jedinou variantu, není na výběr z dalších možností. Jedná se o nejjednodušší reprezentaci slevy. 2. Sleva obsahuje více než jednu variantu. Například zájezd, kde je na výběr plná či poloviční penze nebo počet dní trvání zájezdu. 3. Sleva obsahuje skupiny, přičemž každá skupina může obsahovat další varianty. U tohoto typu slevy navíc závisí také na tom, zda je u skupiny přítomen obrázek či nikoliv. I tento malý rozdíl rozhoduje o tom, jak se sleva uživateli v aplikaci zobrazí. Tyto rozdíly budou dále rozebrány v návrhu řešení (kapitola 4). U tohoto typu slevy se může jednat například o následující členění v případě zájezdu k moři: 3.1. Skupina Včetně dopravy autobusem Varianta Termín 13. 6. – 22. 6. 2014 (cena 20 000 Kč) Varianta Termín 20. 6. – 29. 6. 2014 (cena 21 000 Kč) 3.2. Skupina Vlastní doprava Varianta Termín 13. 6. – 22. 6. 2014 (cena 15 000 Kč) Varianta Termín 20. 6. – 29. 6.2014 (cena 16 000 Kč)
18
Stávající řešení
4.
Sleva, která obsahuje varianty vnořené ve skupinách, přičemž tyto skupiny jsou vnořeny do další skupiny. Jedná se tedy o tři úrovně. Může se jednat o následující členění slevy v případě dámských šatů: 4.1. Skupina Černé šaty 4.1.1. Skupina velikost S/M o Varianta osobní odběr (cena 350 Kč) o Varianta včetně poštovného (cena 400 Kč) 4.1.2. Skupina velikost L/XL o Varianta osobní odběr (cena 350 Kč) o Varianta včetně poštovného (cena 400 Kč) 4.2. Skupina Červené šaty 4.2.1. Skupina velikost S/M o Varianta osobní odběr (cena 350 Kč) o Varianta včetně poštovného (cena 400 Kč) 4.2.2. Skupina velikost L/XL o Varianta osobní odběr (cena 350 Kč) o Varianta včetně poštovného (cena 400 Kč)
2.4
Stávající aplikace Vykupto
Vykupto má nyní nativní aplikaci pro Android a iOS. Bohužel obě aplikace již nejsou déle jak rok a půl vyvíjeny. Web Vykupto během té doby však prochází různými změnami a žádné z nich nejsou zpětně reflektovány do mobilních aplikací. S aplikacemi je samozřejmě nadále možno nakupovat vouchery (i tato skutečnost se však může brzo změnit), ale o spousty novinek je uživatel ochuzen. Jedná se například o nový věrnostní program V-klub, logiku kategorií (ta se mění velice často), atd. Uživatel navíc ve stávající aplikaci vidí pouze názvy zakoupených voucherů, žádné další informace nevidí (důležité je možnost si zobrazit unikátní kód voucheru). Bez těchto informací musí uživatel vždy voucher tisknout. Velkou nevýhodou stávajících mobilních aplikací Vykupto je nutnost se přihlásit. Pokud se uživatel nepřihlásí, nemůže si nijak zobrazit žádný obsah. To je velice nestandardní způsob a navíc to ani není nutné. Přihlášení je totiž nutné až v případě, kdy chce uživatel nakupovat slevy nebo si zobrazovat vlastní zakoupené vouchery. Problémem je také samotné zobrazení obsahu slevy v mobilní aplikaci. Mobilní aplikace přijme z API data, ve kterých je popis slevy již ve vytvořené HTML struktuře navržené pro zobrazení na velkých displejích (klasické počítače a notebooky). HTML kód je nutno upravit v mobilní aplikaci tak, aby se zobrazoval správně i na mobilních zařízeních.
Stávající řešení
19
Stávající aplikace má problém se zobrazením Youtube videí v textu slevy. Pokud se Youtube video nachází v textu, aplikace se ukončí s chybou. Nelze tedy nakupovat slevy, které mají v textu Youtube video. V kapitole 2.2 byly probrány jednotlivé kroky nákupu voucheru. I v tomto případě mají nativní aplikace problém, obzvláště s prvním krokem, kdy v některých případech špatně interpretují data z API serveru a uživateli jsou zobrazeny nesmyslné údaje. Stávající aplikace nyní nezobrazují u slev jejich diskuzi a různé další údaje, jako například platnost voucheru. Celkově tak v aplikacích chybí hodně důležitých údajů, které by mohly uživatele pozitivně přesvědčit o nákupu. Stejně tak je hodně údajů špatně interpretováno aplikací.
Obr. 1
2.5
Náhled aktuální mobilní aplikace Vykupto (Android)
Api Vykupto
Vykupto poskytuje API pro mobilní aplikace, přes které je možno se dotazovat na všechna data, která jsou potřeba ke korektnímu běhu aplikace.
20
Stávající řešení
API je (zkratka pro Application Programming Interface) rozhraní pro komunikaci dvou a více různých aplikací. V tomto případě poskytuje server Vykupto API pro komunikaci s mobilní aplikací. [1] Vykupto vytvořilo API pro dotazování na všechna potřebná a důležitá data, která mohou mobilní aplikace potřebovat. Toto API využívá protokol HTTP, přičemž požadavky jsou zasílány dvěma různými metodami - POST a GET. POST metoda slouží pro zaslání dat na server Vykupto (např. přihlášení odesílá data o uživateli) a GET metoda slouží pro získání dat ze serveru na základě parametrů, které jsou v požadavku specifikovány. [2] Všechna data z API jsou vrácena jako JSON struktura. [3] Adresa pro API požadavky je vždy stejná, mění se pouze název funkce, která určuje, jaká data jsou požadována (GET), případně zasílána (POST). Adresa API je http://www.vykupto.cz/mobile/api/?function=nazev_funkce, kde nazev_funkce představuje funkci, se kterou se pracuje. API poskytuje následující funkce: 1. Seznam slev s možností filtrace Funkce deal_list Typ požadavku: GET Vstupem jsou 3 různé filtry, všechny jsou nepovinné. Filtrační štítek je filtr, který vybírá slevy na základě nějakých vlastností. o filter: Umoznuje filtrovan na zajmove slevy. Moznymi hodnotami filtru jsou: best_sellers: filtrovan na 10 nejprodavanejs ch slev newest: filtrovan na nejnovejs slevy. Funkce nac ta vsechny slevy z aktualn ho dne, popr pade vsechny ze dne, kdy se naposledy slevy spoustely. Dále může filter přijímat jakoukoli hodnotu, kterou získá pomocí API funkce sub_category_list pro aktuální kategorii v aplikaci. o category: Specifikuje vypis slev pro jednotlive kategorie. Moznymi hodnotami kategori jsou: local_services (lokaln sluzby), travels (zajezdy), goods: (zboží), fashion: (moda) o city: Specifikuje vypis slev na definovane mesto. Seznam dostupnych mest lze z skat z API funkce city_list. Funkce vrátí seznam slev, kde ke každé slevě jsou uloženy základní údaje identifikační kód slevy, nadpis, cena, cena před slevou, obrázek, město působnosti, datum vytvoření, krátký anotační text a stav (aktivní/neaktivní). V případě, že působnost slevy je celorepubliková, je uvedena hodnota “Celá ČR”. 2. Detail slevy Funkce deal_detail Typ požadavku: GET Vstup: Identifikační kód slevy (parametr deal_id)
Stávající řešení
21
Funkce vrátí všechny důležité údaje o slevě, které jsou potřeba pro její zobrazení a také nákup. Náhled dat ve formátu JSON, které funkce vrací, je v příloze A. 3. Seznam měst 4.
Zakoupené vouchery uživatele
5.
Funkce voucher_list Typ požadavku: GET Vstup není žádný Funkce vrátí seznam voucherů, které uživatel zakoupil. Vytvořené objednávky uživatele
6.
Funkce purchase_list Typ požadavku: GET Vstup není žádný Funkce vrátí seznam objednávek, které uživatel provedl. Jedna objednávka se může vztahovat k více voucherům. Uživatel totiž během nákupu slevy může zvolit, kolik voucherů chce. Ve většině případů si vybírá uživatel mezi 1 a 10 vouchery. V datech lze přehledně vidět, kolik voucherů již bylo využito, zrušeno nebo nevyužito. Detail vytvořené objednávky uživatele
7.
Funkce city_list Typ požadavku: GET Vstup není žádný Funkce vrátí seznam měst, pomocí kterých bude možno slevy filtrovat.
Funkce purchase_detail Typ požadavku: GET Vstup: Identifikační kód objednávky (parametr id) Funkce vrátí detailní popis objednávky. Oproti funkci purchase_list jsou v této funkci navíc některé údaje. Jedná se o výslednou cenu objednávky, cena za jeden voucher, cena využitého bonusu uživatele, odkaz na HTML verzi všech voucherů, které spadají pod danou objednávku a nakonec platební informace pro uživatele pro platbu předem. Pokud byla objednávka již zaplacena, tak v položce s informacemi k zaplacení objednávky se bude nacházet hodnota null. Přihlášení
Funkce login Typ požadavku: POST Vstup pro normální přihlášení: E-mail (username) a heslo (password). Heslo se zasílá nehashované. Hashuje se až na straně Vykupto serveru. Vstup pro Facebook přihlášení: Pokud probíhá přihlášení skrze Facebook, je nutno nastavit parametr facebook_login na nenulovou hodnotu. V
22
Stávající řešení
pr pade facebook prihlasen se ignoruj hodnoty username a password, jelikoz autentizace uzivatele prob ha na tret strane. Po uspesnem prihlasen vrat funkce odpove s hodnotou SESSION_ID prihlaseneho uzivatele a zakladn udaje o uzivateli. Jedna se o jmeno, pr jmen , pohlaví a identifikační kód uživatelova profilu. SessionID je hodnota, která identifikuje konkrétního uživatele přihlášeného na serveru Vykupto. [4] 8.
Odhlášení Funkce logout Vstup: SESSION_ID. Jedná se o identifikátor sezení (přihlášení uživatele). Funkce odhlásí uživatele na straně Vykupto. Uživatel poté nebude schopen využívat funkcí, které jsou dostupné jen pro přihlášené uživatele, např. zobrazit si vlastní nakoupené vouchery.
9.
Registrace nového uživatele Funkce registration Typ požadavku: POST Vstup: uzivatelsky nazev uctu v podobe emailu uzivatele (username), heslo uzivatele (password), jmeno uzivatele (firstname, nepovinne), pr jmen uzivatele (surname, nepovinné), pohlav uzivatele (sex, nepovinne, moznymi hodnotami jsou male, female ci unknown). V pr pade uspesne registrace na strane Vykupto serveru funkce automaticky provede prihlasen uzivatele. Navratove hodnoty jsou shodne s hodnotami funkce login. V pr pade neuspesne registrace dojde k vyvolan chyboveho stavu USER_REGISTRATION.
10.
Změna hesla uživatele
11.
Funkce new_password Typ požadavku: POST Vstup: E-mail uživatele (email) Funkce provad vygenerovan noveho hesla a jeho zaslan na email uzivatele. Na straně Vykupto se na základě povinného parametru email vyhleda uzivatelsky ucet a na nej se odešle nove vygenerovane heslo. Pro vets bezpecnost je krome hesla vygenerovan a zaslan aktivacn odkaz, kterym mus uzivatel prokazat svoji totoznost jeho navštívením. Z tohoto duvodu nen po vygenerovan noveho hesla umozneno prihlasen pres nové heslo, to je umožněno az po proveden aktivace hesla. Zakoupení slevy
Funkce buy Vstup: Data z nákupního procesu, nejsou vždy stejná. Mění se na základě slevy, která je nakupována. Povinné je id zakoupené varianty (variant_id), počet zakoupených voucherů (amount) a typ platby (payment_type).
Stávající řešení
23
Funkce deal_detail poskytuje informace o povinných položkách. Invoice_address_required stanovuje povinnost vyplnění fakturační adresy a delivery_address_required stanovuje povinnost vyplnění doručovací adresy. Pokud je některý typ adres vyžadován, musí být vložen do jmenného prostoru address a poté v závislosti na typu adresy dále vnořen do prostoru invoice nebo delivery. Prostory invoice a delivery očekávají adresy v definovaném formátu. Všechny následující položky jsou povinné. jméno uživatele (name) příjmení uživatele (surname) název ulice (street) číslo popisné a orientační (number) název města či obce (city) PSČ (zip) V případě, že některý údaj chybí, vrátí API v odpovědi chybový kód ERR_PARAM_NOT_FOUND a objednávka nebude vytvořena. V případě, že fakturační a doručovací adresy jsou stejné, není nutno je v požadavku vyplňovat dvakrát. Stačí nastavit parametr copy_invoice_address na TRUE a server Vykupto automaticky zpracuje fakturační údaje i jako doručovací. Pokud sleva vyžaduje vyplnění typu poštovného, musí být tato hodnota odeslaná v objednávkovém požadavku také pod parametrem shipping_id. Pokud je typ poštovného povinný a nebude v požadavku přítomen, vrátí API v odpovědi chybový kód ERR_PARAM_NOT_FOUND. Pokud je typ platby (payment_type) nastaven na hodnotu BANK_TRANSFER, pak bude platba provedena skrze bankovní převod. Po vytvoření objednávky se čeká na dokončení platby od uživatele. Uživatel si tuto objednávku může zobrazit, ale neuvidí ještě žádné vouchery, jelikož nejsou vytvořeny. V případě, že je typ platby nastaven na hodnotu CREDIT_CARD, tak se platba bude provádět kreditní kartou. Je nutno také v požadavku zaslat typ platební karty (parametr credit_card_brand) s možnou hodnotou VISA, VisaElectron, MasterCard nebo Maestro. Po vytvoření objednávky se z API Vykupto v odpovědi vrátí hodnota URL adresa (parametr payment_url), na kterou proběhne přesměrování. Jedná se o platební bránu, kde uživatel vyplní potřebné údaje a provede platbu. V případě úspěchu i neúspěchu platby dojde k přesměrování zpět do aplikace. Server Vykupto vytvoří uživateli novou objednávku v případě, že všechna data v požadavku byla v pořádku. Po přijetí finanční částky budou uživateli vygenerovány všechny vouchery (může si jich objednat najednou více) a zaslány na e-mail. 12. Seznam filtrů pro kategorii Funkce sub_category_list
24
Stávající řešení
Typ požadavku: GET Vstup: Název kategorie (category_name) Vrac seznam filtru, ktere lze v dane kategorii aplikovat. Seznam filtru je v podobe jednoducheho pole, kde index je technicky nazev filtru (odpov da SEO nazvu na webu Vykupto) a hodnota je text, ktery se bude vypisovat v aplikaci. 13. Parametry objednávkového formuláře
Funkce order_params Typ požadavku: GET Vstup: Identifikační kód slevy (deal_id) Kazda sleva pozaduje po uzivateli jina vstupn data pro proveden uspesneho nakupu. Mobiln aplikace ma za ulohu na zaklade prijatych dat dynamicky generovat objednavkove formulare. Popis atributů vrácených dat: o invoice_address_required - urcuje, zda je pozadovana fakturacn adresa. o delivery_address_required- urcuje, zda je pozadovana dorucovac adresa. o shippings - jedna se o seznam postovnych, ze kterych ma uzivatel na vyber. Pokud obsahuje null, tak pro budouc objednavku nen potreba zpracovavat postovne. 14.
Počet slev spuštěných v aktuálním dni
Funkce deal_count_today Typ požadavku: GET Vstup: žádný 15. Detail objednávky 16.
Funkce purchase_detail Typ požadavku: GET Vstup: Identifikační kód slevy (deal_id) Funkce vrátí detailní informace o objednávce, kterou uživatel zakoupil. Bonus uživatele
Funkce bonus_balance Typ požadavku: GET Vstup: Identifikační kód slevy (deal_id) Vrátí aktuální zůstatek bonusu uživatele.
Ve funkcích deal_list a deal_detail se také nachází stavy slev. Jedná se o následující stavy: SELLING o Sleva je aktuálně v prodeji, je aktivní. Nedošlo však k zakoupení minimálního množství voucherů.
Stávající řešení
25
SELLING_DEALON o Sleva je v prodeji a je aktivní. Oproti stavu SELLING, zde jiz doslo k zakoupen minimaln ho mnozstv voucheru. SOLDOUT: o Sleva (nebo jen varianta) je vyprodána. V tomto stavu lze slevu zobrazit, avšak ji již nelze zakoupit. Zobrazení slevy po zakoupení je důležité např. kvůli informacím, jak slevy využít, kontaktní informace, diskuze o slevě a další. TIMEOUT o Sleva je ukončená. Neměla by se dostat do výpisu aktivních slev. Její zobrazení je však povoleno. Tuto slevu již nelze zakoupit. Uživatelovy objednávky mohou nabývat několika různých stavů: NEW o Objednávka s tímto stavem je nově vytvořená, nebyla dosud uhrazena. Pro tuto objednávku zatím neexistují žádné vygenerované vouchery. Ty se vygenerují až po přijetí platby. PAID o Objednávka je zaplacena, následně je vygenerován voucher, který si uživatel může stáhnout. CANCELLED o Objednávku uživatel zaplatil, avšak ji poté stornoval. EXPIRED o Tato objednávka nebyla uhrazena a už být uhrazena nemůže, jelikož skončila platnost voucherů. Jedná se o zamezení, aby uživatel nemohl zaplatit objednávku, ve které by mu byly vygenerovány neplatné vouchery. PREPARED o Objednávka byla vytvořena a jako typ platby byla nastavena kreditní karta. Platba však nebyla úspěšně dokončena. API Vykupto vypisuje chybové stavy v případě, že není požadavek v pořádku nebo nastala chyba na straně Vykupto. Pokud nějaký chybový stav nastane, je jeho hodnota vložena do parametru err v API odpovědi od serveru Vykupto. Ke každému chybovému kódu je v API přítomna i zpráva, jedná se o krátké vysvětlení chyby. Například chybový kód FUNCTION_UNKNOWN bude obsahovat vysvětlení “Unknown function name `deal_create`”. Tato chybová zpráva například vznikla proto, že byla volána API funkce deal_create, která ovšem neexistuje. Typy chybovych kodu: FUNCTION_NOT_FOUND: o V požadavku na API nebyla specifikována funkce na zavolání. Jedná se o parametr function v URL adrese požadavku.
26
Stávající řešení
FUNCTION_UNKNOWN: o V požadavku byla funkce specifikována, avšak nebyla nalezena. Taková funkce pravděpodobně není v API implementována. DATA_NOT_FOUND: o Nebyla nalezena požadovaná sleva. Jedná se pravděpodobně o chybný identifikátor slevy v parametru odeslaného požadavku. CREDENTIALS_INVALID: o Nevalidní hodnoty pro přihlášení do Vykupto. Může se jednat o nevyplněné heslo či přihlašovací jméno v požadavku, neexistující přihlašovací jméno nebo špatné heslo k uživatelskému účtu. FB_USER_NOT_CREATED: o API se nepodařilo uživatele přihlásit přes Facebook API. USER_NOT_LOGGED_IN: o Uživatel není přihlášen do mobilní aplikace, ale volá funkci, která přihlášeného uživatele vyžaduje. Může se jednat například o zobrazení vlastních nakoupených voucherů. USER_REGISTRATION: o Chyba během registrace uživatele. Ta může nastat z více různých důvodů, například duplicitní e-mail, který již v databázi Vykupto je nebo nevalidní e-mail. PARAM_NOT_FOUND: o V požadavku na API nebyl u dané funkce nalezen povinný parametr. Například při požadavku na data konkrétní slevy je povinný parametr ID, který specifikuje slevu. Pokud tento parametr není zadán, vypíše se tato chybová zpráva. PARAM_BAD_USAGE: o Byl použit špatný typ HTTP požadavku. Požadavky se do API zasílají metodou POST nebo GET. Každá funkce požaduje konkrétní typ HTTP požadavku, jiný nesmí být použit. o POST slouží pro případy, kdy se data na server Vykupto posílají. Například vytvoření objednávky nebo přihlášení uživatele. GET metoda slouží pro získání dat, například data o slevě a podobně. ACCESS_DENIED: o Nepovolený přístup uživatele k datům. Může se jednat například o zobrazení nakoupených voucherů jiného uživatele. ORDER_NOT_CREATED: o Tato chyba vznikne, pokud se nepodaří na straně Vykupto vytvořit objednávku. UNKNOWN: o Neznamy chybovy stav.
Analýza požadavků
27
3 Analýza požadavků Analýza požadavků získává informace o potřebách a podmínkách, které jsou kladeny na právě vyvíjený nebo upravovaný produkt. Požadavky jsou funkční a nefunkční. Ty budou popsány v samostatných kapitolách. [5] Požadavky na aplikaci budou získány především od zaměstnanců firmy Vykupto. Programátoři a marketingoví zaměstnanci mají přehled o nejdůležitějších funkcích a novinkách, které se týkají slevové problematiky ve Vykupto. Nová aplikace by měla mít podobný uživatelský prožitek (User Experience – UX) jako stávající mobilní aplikace. [6] Jedná se například o nákupní proces s proměnlivou délkou kroků. Se zaměstnanci Vykupto budou navrženy nové funkce, které stávající mobilní aplikace nemá a bude analyzováno, které funkce nepracují správně nebo by mohly být vylepšeny.
3.1
Funkční požadavky
Jedná se o soupis požadavků na funkce aplikace z pohledu uživatele. Každý funkční požadavek se skládá ze tří celků. Jedná se o funkcionalitu – popis daného požadavku z pohledu uživatele, dále vstup, který definuje údaje, které jsou nutné pro správné fungování požadavku a provedení, což je detailní popis chování funkce. Pro správnou analýzu funkčních požadavků je nutno znát potřeby uživatelů v takové aplikaci a také podnikové procesy a pravidla. V případě Vykupto se jedná např. o princip fungování slev, typy slev apod. Dokument s funkčními požadavky by měl splňovat následující podmínky: Kompletní – všechny funkční požadavky by měly být přítomny. Konzistentní – funkční požadavky by si neměly vzájemně odporovat. Všechny požadavky by měly být stejně detailní. Všechny požadavky by měly být kontrolovatelné. [7] 3.1.1
Přihlášení uživatele do aplikace přes API Vykupto.cz
Funkcionalita: Uživatel bude schopen se v aplikaci přihlásit ke svému Vykupto účtu za účelem možnosti nakupovat slevy nebo si zobrazit seznam svých nakoupených slev. Další možností přihlášení do aplikace bude přihlášení skrze sociální síť Facebook. Vstup: E-mail uživatele a heslo uživatele. V případě Facebook přihlášení se jedná o nutnost, aby uživatel byl ve Facebooku přihlášen a mobilní aplikaci povolil přihlášení přes tuto sociální síť. Provedení: Pro přihlášení slouží API funkce login. Aplikace zpracuje údaje z přihlašovacího formuláře (email i heslo jsou povinné) a data odešle na server Vykupto. V případě úspěšného přihlášení na straně Vykupto budou do aplikace odeslány údaje o uživateli (jméno, příjmení, pohlaví aj.). V případě neúspěšného přihlášení bude v datech z API přítomen příslušný chybový kód.
28
Analýza požadavků
V případě přihlášení přes Facebook musí uživatel povolit přihlášení přes tuto sociální síť. Pokud přihlášení povolí, tak od Facebooku přijme aplikace data, která poté zašle pomocí API funkce login na server Vykupto, který tyto údaje zpracuje a v případě, že budou data v pořádku, vrátí Vykupto API do mobilní aplikace stejná data, jako při běžném přihlášení skrze e-mail a heslo. 3.1.2
Zobrazení přehledu slev
Funkcionalita: Aplikace bude schopna přehledně zobrazit seznam slev. U každé slevy by měl být vidět malý anotační obrázek, název slevy, místo působnosti, původní cena a cena po slevě. Tento seznam slev by se měl posouvat vertikálně, jak je u mobilních aplikací běžné. Uživateli bude umožněno filtrovat slevy pomocí prvků vložených do uživatelského prostředí. Jedná se o hlavní kategorii, filtrační štítek a město působnosti slevy. V přehledu slev bude uživateli umožněno slevy vyhledávat. Vstup: Vstupem této funkce jsou tři zmíněné filtry, které vyžaduje API funkce pro tento funkční požadavek. Provedení: Data poskytuje API funkce deal_list. Aplikace načte aktivní filtry, které si uživatel zvolí a odešle požadavek na API Vykupto. To na základě filtrů vygeneruje seznam slev a pošle je zpět do aplikace. Pokud jsou data v pořádku a bez chyby, slevy budou zobrazeny. Pokud se vyskytne chyba, API zašle v datech příslušný chybový kód a aplikace uživatele upozorní na chybu. 3.1.3
Zobrazení detailu slevy
Funkcionalita: Aplikace bude schopna zobrazit detail slevy, kterou uživatel požaduje. Cílem zobrazení detailu slevy je na první pohled co nejvíce upoutat uživatele, přinést mu co nejvíce informací za co nejméně času. První, co by měl uživatel především vidět je název slevy, cena před slevou, cena po slevě, velký obrázek a tzv. anotační text, který v jedné větě shrnuje vše důležité o této slevě. Anotační text je vytvářen na straně Vykupto, aplikace jej bude pouze zobrazovat, nebude jej generovat. Další informace o slevě, které by se měly u detailu objevit, jsou následující: Kolikrát byla sleva zakoupena Kolik času zbývá do konce slevy (do kdy lze nakupovat) Od kdy a do kdy platí nakoupený voucher Dlouhý detailní popis slevy Jak použít slevu a kde tuto slevu uplatnit Komentáře slevy. Ty by se měly pokud možno zobrazovat velice podobně jako komentáře na webu Vykupto. To znamená odsazování komentářů a podbarování textu podle typu komentáře. Typy komentářů jsou normální (uživatelé, zákazníci, žádné podbarvení), od Vykupto podpory (žluté podbarvení) a od dodavatele slevy (fialové podbarvení). Vstup: Identifikační kód slevy Provedení: Data poskytuje API funkce deal_detail. Aplikace odešle požadavek na API Vykupto. Pokud vrácená data z API jsou v pořádku a bez chyby, sleva budou
Analýza požadavků
29
zobrazena. Pokud se vyskytne chyba, aplikace uživatele upozorní na chybu a zobrazí mu zpět seznam slev, ve kterém se uživatel nacházel, aby mohl požadavek na zobrazení detailu slevy vykonat znovu. 3.1.4
Provedení nákupu slevy
Funkce: Nákup slevy je komplexní funkce, která se skládá z různých počtů kroků v závislosti na typu slevy. Tato problematika byla rozebrána v kapitole 2.2. Po úspěšném provedení nákupu slevy se uživateli zobrazí poděkování za provedení nákupu a možnost se vrátit na hlavní stranu aplikace s výpisem slev. Vstup: Identifikační kód slevy, identifikační kód varianty, kterou chce uživatel zakoupit. Provedení: Uživatel projde v aplikaci všemi nutnými kroky v nákupním procesu pro získání všech povinných údajů, které jsou nutné pro zakoupení slevy. Aplikace tyto údaje zpracuje, sestaví požadavek (API funkce buy) a odešle jej na server Vykupto. V případě úspěšného provedení nákupu bude uživateli zobrazena děkovná stránka. V případě chyby během provádění nákupu na straně Vykupto bude v odpovědi z API vrácen chybový kód oznamující typ problému. 3.1.5
Zobrazení vlastních nakoupených voucherů (i offline)
Funkcionalita: Aplikace zobrazí všechny vouchery, které si uživatel zakoupil a měla by být schopna tyto vouchery zobrazit i v případě, že internetové připojení není aktivní. Aby se mohly zobrazit vouchery i v offline režimu, je nutné, aby aplikace měla tyto vouchery uložené. Musí tedy proběhnout alespoň jedno úspěšné přihlášení do aplikace před použitím offline režimu. Vstup: Identifikační kód uživatele, údaje o uživateli, uložené vouchery v aplikaci. Provedení: Aplikace se dotáže API Vykupto na uživatelovy zakoupené vouchery. Pokud API úspěšně zašle aplikaci data, tato data budou zpracována, zobrazena a uložena. Pokud data nebudou v pořádku nebo v nich bude přítomen nějaký chybový kód, aplikace o tomto uživatele upozorní. V případě offline režimu zjistí aplikace, jestli má data o voucherech uložené. Pokud ano, musí navíc zjistit, zda jsou uloženy i uživatelovy přihlašovací údaje v aplikaci. Pokud by uživatelovy údaje nebyly uloženy, znamenalo by to, že se odhlásil nebo se mu nepodařilo úspěšně do aplikace přihlásit. V tom případě by data o zakoupených voucherech byla neplatná. Pokud jsou offline data i přihlašovací údaje v pořádku, zobrazí se uživateli offline vouchery.
3.2
Nefunkční požadavky
Nefunkční požadavky stanovují různé požadavky na aplikaci, které se přímo netýkají funkce aplikace. Jedná se o různé požadavky na uživatelské rozhraní, výkon aplikace a podobně. [7] Aplikace by měla dle moderních trendů a požadavků ze strany Vykupto obsahovat tzv. slide panel. [8] Jedná se o navigační panel, který je v aplikaci skrytý a zobrazí
30
Analýza požadavků
se správným provedením gesta přes displej. Zpravidla se jedná o rychlé táhnutí prstem po displeji z jednoho kraje směrem k prostředku displeje. Těmto gestům se říká swipe gesta. Panel se může zobrazit pomocí různých typů animací. Panelů může být v aplikaci i více, zpravidla se však používá pouze jeden. Dva panely jsou již velice ojedinělé. Aplikace by měla být přístupná, měli by ji být tedy schopni používat i lidé zrakově postižení. Zdrojový kód aplikace by měl být vhodně okomentován, aby aplikaci mohlo bez problému vyvíjet více vývojářů. Aplikace by měla fungovat i na pomalejších a starších mobilních zařízeních. Uživatelské rozhraní by mělo být přehledné a využívat co nejlépe velikost displeje. Písmo by mělo být čitelné na co nejvíce různých velikostech a rozlišeních displejů. Jako minimální rozlišení je stanoveno 320 × 240 obrazových bodů, jelikož je to nejmenší rozlišení, které v dnešní době stále některá nejlevnější zařízení používají. V případě Android platformy bude předpokládána verze minimální 2.0, iOS bude předpokládána minimální verze 4.2.1 a u Windows Phone minimální verzi 7.
Návrh řešení
31
4 Návrh řešení Návrh řešení je fáze, která se zaměřuje na návrh dané aplikace z technického hlediska. Řeší se různá vývojová prostředí, programovací jazyky a vše, co může ovlivnit vývoj aplikace. Návrh řešení se zakládá na výstupech z analýzy požadavků, popisů funkcí, uživatelského rozhraní a dalších. Výsledkem této fáze bude detailní plán pro vývoj a testování aplikace. V případě Vykupto aplikace bude nutné zvolit především programovací jazyk, pomocí kterého aplikace vznikne a následný framework (nástroj), díky kterému bude aplikace multiplatformní. Hardware se nebude řešit, jelikož bude aplikace multiplatformní a tak jeden z hlavních cílů je, aby aplikace běžela na co nejvíce různých přístrojích s různou hardwarovou výbavou. Bude se navrhovat uživatelské prostředí včetně uživatelských obrazovek. U formulářových prvků budou definovány datové typy, jejich omezení a pravidla pro vyplňování (například validita e-mailu). Na konci návrhu řešení by mělo být jasné vše, co je potřeba k zahájení implementace mobilní aplikace. Celý návrh řešení bude počítat s tím, že aplikaci bude používat pouze jeden typ uživatele a to budou zákazníci.
4.1
Mockup aplikace
Na základě komunikace se zaměstnanci Vykupto a Tomášem Bátrlou byl navržen tzv. Mockup aplikace v aplikaci Balsamiq Mockups. Mockup je vizuální návrh, jak by měla aplikace vypadat, jak budou přibližně rozložené prvky uživatelského rozhraní a jak se bude aplikace chovat na základě vyvolaných událostí. [9] Pro všechny následující popisy oken platí společné pravidlo. Pokud v některém z oken uživatele provede swipe gesto směrem doprava, tak se zobrazí slide panel s nabídkou možností uživateli. Pouze u přihlašovacího okna se slide panel nezobrazí, jelikož aplikace musí napřed zjistit, jestli chce uživatel prohlížet slevy jako přihlášený nebo nepřihlášený. V příloze C je kompletní navigační schéma aplikace.
32
4.1.1
Návrh řešení
Hlavní obrazovka aplikace
Předchozí okno: žádné Popis: Tato obrazovka uživateli zobrazuje základní možnosti aplikace po spuštění. K dispozici je odkaz pro klasické přihlášení skrze e-mail a heslo, potom přihlášení skrze Facebook nebo možnost se nepřihlašovat vůbec – je možno si rovnou prohlížet slevy bez přihlášení. Na konci stránky se nachází odkaz na registraci uživatele. Toto okno slouží uživateli pro přihlášení. Po přihlášení může uživatel provádět nákupy a prohlížet si své vlastní nakoupené vouchery. Přihlášení je možno provádět skrze klasickou metodu (e-mail a heslo) nebo přes sociální síť Facebook. Uživatel se však nemusí do aplikace přihlašovat, prohlížení nabídek je umožněno i bez přihlášení.
Obr. 2
Hlavní obrazovka aplikace
4.1.2
Slide panel
Předchozí okno: Všechny kromě hlavní obrazovky, přihlašovací a registrační obrazovky Popis: Když uživatel provede swipe gesto směrem doprava, tak se zobrazí slide panel, ve kterém bude uživateli zobrazena nabídka pro odhlášení, změnu aktuální kategorie slev nebo zobrazení vlastních voucherů.
Návrh řešení
Obr. 3
Mockup – Slide panel aplikace
4.1.3
Přihlašovací obrazovka
33
Předchozí okno: Hlavní obrazovka aplikace Popis: Přihlašovací okno umožňuje uživateli se přihlásit pomocí klasické přihlašovací metody použitím e-mailu a hesla. Vyplnění e-mailu a hesla je v přihlašovacím formuláři povinné.
Obr. 4
Přihlašovací obrazovka aplikace
34
4.1.4
Návrh řešení
Registrační obrazovka
Předchozí okno: Hlavní obrazovka aplikace Popis: Tato obrazovka umožňuje uživateli se registrovat do Vykupto. V přihlašovacím formuláři je povinné vyplnit e-mail uživatele a heslo. Jméno, příjmení a pohlaví nejsou povinné, není nutné je vyplňovat.
Obr. 5
Registrační obrazovka aplikace
4.1.5
Hlavní seznam slev
Předchozí okno: Hlavní obrazovka aplikace Popis: Na této obrazovce se uživateli přehledně zobrazí seznam aktuálních slev, které Vykupto nabízí. Slevy budou zobrazeny v okně s vertikálním scrollováním (posunem).
Návrh řešení
Obr. 6
Hlavní seznam slev
4.1.6
Základní informace o slevě
35
Předchozí okno: Seznam slev Popis: Uživateli jsou zobrazeny základní údaje o slevě. Jedná se o obrázek, umístění na mapě, krátký popis slevy, cena a další.
Obr. 7
Mockup – základní informace o slevě
4.1.7
Více detailů a informací o slevě
Předchozí okno: Detail slevy Popis: Oproti základnímu přehledu o slevě je v této stránce zobrazen především hlavní dlouhý text o slevě a také diskuze, která se k této slevě pojí.
36
Návrh řešení
Obr. 8
Mockup – více detailů u slevy
4.1.8
Fotogalerie slevy
Předchozí okno: Detail slevy Popis: Tato stránka zobrazí jednoduchou fotogalerii, ve které budou načteny všechny obrázky, které patří k dané slevě.
Obr. 9
Mockup – fotogalerie slevy
Návrh řešení
4.1.9
37
Nákup voucheru
Předchozí okno: Detail slevy Popis: V tomto případě se okno počítá jako celý proces nákupu slevy. Jak již bylo popsáno v kapitole 2.2, nákupní proces může mít 2 až 5 kroků. Uživatel musí všemi povinnými kroky projít a zvolit si možnosti, které si přeje.
Obr. 10
Mockup – proces nákupu
4.1.10
Poděkování za objednávku
Předchozí okno: Nákup voucheru Popis: Když uživatel všechny povinné kroky během nákupu voucheru projde, potvrdí vytvoření objednávky a zobrazí se mu děkující stránka, kde bude mít možnost se rychle vrátit na hlavní seznam slev.
38
Návrh řešení
Obr. 11
Mockup – poděkování za objednávku
4.1.11
Nastavení účtu uživatele
Předchozí okno: Jakékoliv, do této sekce se přistupuje přes slide panel Popis: V této sekci bude uživateli umožněno nastavit si některé základní údaje svého účtu, jako např. přijímání reklamních nabídek skrze e-maily.
Obr. 12
Mockup - Nastavení účtu uživatele
4.1.12
Vyhledané slevy
Předchozí okno: Seznam slev Popis: Tato stránka zobrazí uživateli seznam všech slev, které byly nalezeny na základě vyhledávacího hesla.
Návrh řešení
Obr. 13
Mockup - nalezené slevy pomocí vyhledávání
4.1.13
Mé kupóny
39
Předchozí okno: Jakékoliv, do této sekce se přistupuje přes slide panel Popis: Zobrazí uživateli seznam jeho zakoupených voucherů. Na každý voucher lze kliknout a zobrazit si jeho detail.
Obr. 14
Mockup – moje kupóny
4.1.14
Detail voucheru
Předchozí okno: Mé vouchery Popis: Detail voucheru zobrazí údaje týkající se daného voucheru. Jedná se o místo uplatnění, datum platnosti, unikátní kód voucheru a další.
40
Obr. 15
Návrh řešení
Mockup - Detail voucheru (kupónu)
Popis vhodných technologií
41
5 Popis vhodných technologií Před samotným výběrem vhodné technologie je nutné si stanovit kritéria, pomocí kterých se jednotlivé technologie budou hodnotit. Jedná s o následující: Licence Rychlost vývoje Rychlost aplikace Podpora zařízení/hardwaru Dokumentace Možnosti rozšíření Možnosti úpravy kódu (customizace) Jelikož každá mobilní platforma (Android, iOS, Windows Phone a další) obsahuje vlastní systémové API/SDK, nelze logicky vytvořit z kódu pro jednu platformu aplikaci pro jinou platformu. Např. Objective-C (iOS) kód nelze kompilovat do kódu Android platformy, ve které jsou aplikace vytvářeny v jazyce Java s jiným systémovým API. Jedná se o naprosto rozdílnou platformu. Je tedy nutno využít jiných metod, aby byla aplikace multiplatformní. [10]
5.1
Přístupy k tvorbě multiplatformních aplikací
Pro tvorbu multiplatformních aplikací se využívají CPT nástroje (Cross-Platform Tools). Pomocí těchto nástrojů lze vytvářet nativní, hybridní a webové aplikace pomocí různých technologií. Jedná se o JavaScriptové frameworky, wrappery pro webově-nativní aplikace, běhová prostředí a převodníky zdrojových kódů. Nejpoužívanější metodou jsou tzv. hybridní aplikace. Nejpopulárnějším nástrojem pro vývoj hybridních aplikací je framework Apache Cordova nebo Adobe Phonegap, což je distribuce Cordovy s různými nástroji navíc. Jedná se o wrapper pro webově-nativní aplikace. V této práci nebudou zvažovány čistě webové aplikace, jelikož cílem je vznik nativní instalovatelné aplikace do mobilního zařízení. Webová aplikace se nedá nainstalovat, spouští se pouze v prohlížeči daného zařízení. Uživatelé musí vždy navštívit přes webový prohlížeč konkrétní URL adresu. Webovou aplikaci nelze používat offline a nelze ji vytavit do obchodu s aplikacemi v jednotlivých mobilních platformách. Webová aplikace nemá přístup k API mobilní platformy. Porovnají se hybridní aplikace a nativní aplikace, které vznikají převodem jednoho zdrojového kódu do nativního kódu jednotlivých platforem. [10] 5.1.1
Hybridní aplikace
U tohoto přístupu je nejprve nutno vytvořit klasickou webovou mobilní aplikaci a poté použít nástroj (tzv. wrapper), který tento kód převezme a obalí jej do další aplikační vrstvy, která mobilní webové aplikaci umožní komunikovat se systémovým API dané mobilní platformy.
42
Popis vhodných technologií
Takovým aplikacím se říká hybridní. Hybridní proto, že se jedná o spojení webové aplikace a nativní aplikace do jedné. Uživatel však poté vidí pouze webovou část aplikace a nativní kód umožňuje komunikaci se systémovým API dané mobilní platformy. [11]
Obr. 16
Princip fungování wrapperu
Kompilací vznikne klasický instalační balíček pro danou mobilní platformu a je možno jej nainstalovat. Po spuštění takové aplikace se vnitřně spustí velice jednoduchá nativní aplikace, ve které je načtené webové okno prohlížeče přes celou plochu displeje a v tomto prohlížeči se načte mobilní webová aplikace. Uživatel tak vůbec nemusí poznat, že se nejedná o nativní aplikaci. Uživatelské prostředí však musí být vytvořeno tak, aby nevypadalo jako tradiční webová stránka. To je velice důležitá podmínka, především u firmy Apple, která velice dbá na to, aby všechny aplikace dodržovaly jejich vnitřní pravidla pro návrh uživatelských prostředí. Velice často se stává, že aplikace není schválena a nedostane se do App Store. Důvodů však může být více, nemusí se jednat jen o uživatelské prostředí, hodnotí se i rychlost odezvy takové aplikace a ta je u webových aplikací menší než u nativních aplikací. Z tohoto vychází jedno specifikum této skupiny aplikací - nemohou být příliš komplexní. [12][13]
Popis vhodných technologií
43
U této skupiny se tedy využívá wrapper a pro urychlení vývoje se používají mobilní webové frameworky, které se postarají o správné zobrazení aplikace na většině mobilních zařízení. Je nutno již dopředu počítat s tím, že mobilní webové aplikace nebudou nikdy tak výkonné jako nativní. Společného kódu v hybridních aplikacích je 60 % - 90 %. Zbytek kódu je individuální pro každou platformu zvlášť. [14] 5.1.2
Nativní aplikace s využitím systémových funkcí
U těchto nástrojů se podobně jako u nástrojů pro hybridní aplikace píše aplikační kód v jednom programovacím jazyce, ale tím veškerá podobnost s hybridními aplikacemi končí. Jsou to nástroje, kde se kód píše v programovacím jazyce Javascript, C# a různých dalších. Tento aplikační kód po spuštění aplikace volá nativní funkce mobilní platformy. Pokrytí funkcí z mobilních API je u těchto nástrojů v rozmezí 90 % - 100 %. Vždy se však dosáhne toho, že aplikace opravdu využívá nativní funkce mobilní platformy. Lze tak například pomocí jazyka JavaScript napsat kód, který do aplikace vytváří tlačítko. Daný nástroj na základě tohoto kódu zavolá nativní funkci z API systému, ve kterém se aplikace spustí a zobrazí nativní tlačítko. Díky jednomu kódu se tak v Android, iOS či dalších platformách zobrazí nativní prvky. To má pozitivní dopad na výkon a také uživatelský prožitek z aplikace. Bohužel v případě těchto nástrojů nemá programátor plně pod kontrolou, jak se nativní funkce systému volají a v některých případech to způsobuje problémy. Výhodou u těchto nástrojů oproti hybridním aplikacím je, že uživatelské prostředí aplikace využívá nativní prvky platformy. Uvnitř aplikace se nespouští žádné webové okno, jedná se o klasickou nativní aplikaci. Nevýhodou ovšem je, že díky použití nativních UI prvků je nutno upravovat kód pro každou platformu zvlášť. Udává se, že společného kódu, který je použit ve všech platformách pomocí této metody je 40 - 60 %. Ostatní kód je individuální pro každou platformu. A to bohužel znamená, že tyto nástroje vyžadují určitou znalost každé použité platformy na úrovni vývoje, do které se bude aplikace kompilovat. [14]
5.2
Hlavní zástupci
Hlavní zástupci pro vývoj mobilních multiplatformních aplikací: jQuery Mobile (hybridní aplikace) Sencha touch 2 (hybridní aplikace) Appcelerator Titanium (nativní s využitím systémových funkcí) Xamarin (nativní s využitím systémových funkcí) jQTouch (hybridní aplikace) Tento seznam byl sestaven na základě mnoha webových stránek a článků, které se věnuji multiplatfromním aplikacím a také na základě počtu dotazů na webu Stackoverflow. Stackoverflow je rozsáhlý celosvětový webový portál pro programátory, kteří si tam mohou radit a diskutovat nad různými problémy. Některé nástroje
44
Popis vhodných technologií
na webu Stackoverflow měly například jen do dvou set dotazů (Intel’s App Framework) a některé měly az o dva řády více. Například jQuery Mobile s 31000 dotazy, Appcelerator Titanium s 10000 dotazy nebo Sencha Touch se 7600 dotazy. [15][16][17][18][19] Zástupci pro vývoj hybridních aplikací potřebují wrapper, který danou mobilní webovou aplikaci zabalí do nativní aplikace. V dnešní době existuje jeden dominantní nástroj, který toto umožňuje - Adobe PhoneGap (Apache Cordova). Tento nástroj je popsán v kapitole 5.3.6. Existují i další, avšak méně známé projekty, např. Ionic Zepto.js Embarcardero RAD Corona Labs SDK Kendo UI Complete Intel’s App Framework (dříve jqMobi) RhoMobile Adobe AIR Qt Marmelade MoSync
5.3
Popis jednotlivých technologií
V následujících kapitolách budou popsány jednotlivé frameworky pro tvorbu multiplatformních mobilních aplikací. 5.3.1
jQuery Mobile
jQuery Mobile je zdarma a open source framework pro vytváření webových mobilních aplikací. Jeho snahou je přivést jednotné uživatelské prostředí do všech aplikací na všech platformách. Samozřejmě s tím však sleduje i moderní UI/UX trendy a tak v nových verzích doznává UI malých změn. [20] jQuery Mobile je postaveno na známé knihovně jQuery a jQuery UI. jQuery je JavaScriptová knihovna vydaná v roce 2006. Slouží pro práci s DOM, událostmi, AJAXem a další. [21][63] jQuery je velice známá a oblíbená knihovna pro práci s DOM. Existuje mnoho dalších knihoven pro práci s DOM, ale jQuery komunita patří mezi největší. Pro srovnání - počty vláken (zaokrouhleno) na webu Stackoverflow: jQuery - 457 000 vláken Dojo - 18 000 vláken Mootools - 6 600 vláken Prototype - 1 800 vláken Zepto.js - 1 100 vláken Ext.js - 380 vláken
Popis vhodných technologií
45
Jedná se o robustní řešení reagující na stále rostoucí podíl mobilních zařízení v internetu. jQuery Mobile neupřednostňuje žádnou platformu, snaží se být maximálně univerzální. To může být však i problém - v dnešní době existují stovky mobilních telefonů s různými prohlížeči, systémy a rozlišeními. Nelze tedy perfektně optimalizovat všechny existující zařízení. V lednu 2014 vývojáři jQuery mobile upravili rozhraní do moderního minimalistického designu. [22] Výhodou jQuery Mobile je jeho jednoduchost, dá se velice rychle naučit. Nemá žádnou speciální syntaxi, využívá standardní přístup k vytváření webových aplikací, to je jeho velká a nesporná výhoda oproti ostatním nástrojům. Pro jednoduché weby stačí základní znalost HTML5 (jQuery Mobile využívá ve velké míře data atributy uvedené právě v HTML5). [23] Ani CSS a JavaScript nejsou nutnou podmínkou pro vytvoření jednoduchého webu. jQuery Mobile se samo postará o vytvoření správné struktury webové aplikace a správně nastaví CSS styly v závislosti na typu zařízení. jQuery Mobile vyžaduje standardizované zápisy HTML5 a CSS z důvodu zachování vysoké kompatibility a použitelnosti na co nejvíce mobilních zařízení. Dokumentace je psaná taktéž v jQuery Mobile, takže si v ní každý může hned zkusit, jak vypadá právě na jeho mobilním telefonu. jQuery Mobile má přehledný a velice účinný systém HTML zápisu nejen samotných stránek, ale i ovládacích prvků ve stránkách. Využívá vlastností CSS3 pro vytváření různých efektů, jako jsou stíny, kulaté rohy nebo gradientní přechody. Vývojáři navíc mohou použít předpřipravené grafické ikony nebo celé grafické šablony. Jelikož je jQuery Mobile postavené na jQuery a jQuery UI, obsahuje v sobě také mnoho animací a efektů. Lze tak vytvářet různé plynulé přechody mezi stránkami, kterých je na výběr velká spousta. jQuery Mobile podporuje funkci WAI-ARIA, která umožňuje používat různé asistenční služby, které například umožňují čtení obsahu z obrazovky mobilního zařízení. Na platformě iOS slouží k tomuto například aplikace VoiceOver. [24] 5.3.2
JQTouch
JQTouch je plugin pro knihovny Zepto.js nebo jQuery, je zdarma a open source. Implementuje animace, navigační logiku, témata a další. Podporuje hlavně prohlížeče založené na jádru WebKit, které obsahují především zařízení s operačními systémy iOS, Android, BlackBerry a WebOS. [25] Výhodou JQTouch je možnost použít knihovnu Zepto.js namísto jQuery. Zepto.js je knihovna, která podporuje majoritní část funkcí v jQuery API. Je tedy možno téměř jakoukoliv aplikaci napsanou v jQuery spustit s knihovnou Zepto.js a aplikace bude fungovat. Velikost Zepto.js je 30 kB oproti 80 kB u knihovny jQuery. Jde o velkou úsporu, která se v aplikaci pozitivně projeví na výkonu. Zepto.js je optimalizované pro prohlížeče s jádrem WebKit, mezi které patří Android i iOS zařízení.
46
Popis vhodných technologií
Navíc tato knihovna přináší podporu pro dotyková gesta, která se provádí na mobilních zařízeních. Stylování JQTouch je založeno na CSS preprocesoru SASS, díky kterému je možno jednoduše měnit vzhled celé aplikace změnou jen některých hodnot. Je také možno stáhnout mnoho různých již vytvořených nastylovaných šablon, které stačí pouze načíst. JQTouch podporuje velkou řadu animací pro přechody mezi stránkami včetně 3D animací pomocí CCS3. V zařízeních, která CSS3 nepodporují, budou spuštěny 2D animace. Historii procházení stránek v aplikaci řeší JQTouch také. [26] Velikost komunity okolo JQTouch je o mnoho menší než například u Sencha Touch nebo jQuery Mobile. To stejné platí o počtu různých návodů a tutoriálů na internetu. JQTouch se bohužel zaměřuje pouze na prohlížeče s jádrem WebKit. V dnešní době však na mobilních zařízeních existují prohlížeče i s jinými jádry. Například mobilní Mozilla Firefox s jádrem Gecko nebo mobilní Opera s jádrem Presto. JQTouch je primárně vytvořeno pro mobilní telefony. Vývojáři JQTouch se na tablety nezaměřují, i když říkají, že by s nimi problém být neměl. Pokud by se však nějaký objevil, pravděpodobně nelze čekat nápravu problému. [27] 5.3.3
Sencha Touch 2
Sencha Touch 2 (dále jen Sencha) od firmy Sencha Inc. má podobnou filozofii jako jQuery Mobile. Je to Framework zdarma pro vývoj multiplatformních mobilních aplikací. V Sencha se však vytváří aplikace odlišným způsobem. Má velice netradiční syntaxi pro vývoj, je nutno se naučit kompletní syntaxi frameworku od začátku a to zabere hodně času. Sencha je postavena na knihovně Ext JS, která je taktéž vyvíjena firmou Sencha Inc. [28] Ext JS zjednodušuje práci s DOM a AJAXem. Přináší mnoho různých GUI komponent. Výhodou je optimalizace pro všechny moderní majoritně používané webové prohlížeče. [29] Sencha je postavena na MVC paradigmatu, obsahuje vlastní šablonovací systém a má předpřipravené styly pro Android, iOS, Windows Phone 8 a BlackBerry, pro stylování se používá CSS preprocesor SASS. [30] Sencha dokumentace je na velice dobré úrovni, je detailní a přehledná. Nevýhodou Sencha je, že není Open Source. V případě ukončení vývoje se tak mohou dostat do problému i aplikace na tomto frameworku postavené. Sencha obsahuje integrované animace pro přechody mezi stránkami. Stejně jako jQuery Mobile, i Sencha je optimalizovaná pro mnoho rozlišení mobilních zařízení v dnešní době. Obsahuje podporu pro velké množství dotykových gest. [32] Samotná aplikace napsaná v Sencha Touch nemůže být na mobilním zařízení nainstalována. Vyžaduje wrapper, stejně jako jQuery Mobile, který tuto aplikaci převede do nativní, aby mohla být instalována a umístěna do obchodů s aplikacemi. Sencha poskytuje vlastní wrapper, kterým lze převod udělat, ale lze také používat jakékoli jiné existující konkurenční wrappery. Programování aplikace v Sencha Touch je odlišné od ostatních frameworků. Programátor během vývoje nemusí vůbec přijít do styku s HTML kódem. Velká
Popis vhodných technologií
47
většina kódu je v JavaScriptu a aplikace se tvoří voláním metod z API Sencha Touch. To je důvod, proč může být výuka Sencha frameworku delší, než u jiných frameworků. [31] Sencha poskytuje pro vývoj aplikace nástroj Sencha Architect, ve kterém lze vizuálně vytvářet mobilní aplikace. Architect obsahuje velkou řadu již připravených UI prvků, které lze ihned použít pří vývoji pouhým přetažením ze seznamu do okna s aplikací. To velice urychluje a zjednodušuje vývoj aplikace. Architect nabízí funkci témat pro rychlé přestylování celé aplikace. Skrze uživatelská rozšíření lze do aplikace instalovat komplexní funkce. Dostupné jsou na adrese https://market.sencha.com/. Stáhnout se tak dá například přehrávač audio souborů, kalendář, slide panel, komponenta pro zobrazení grafů a další. V Architectu je také mnoho již předpřipravených jednoduchých aplikačních šablon. Může se jednat o jednoduchou aplikaci zobrazující Google mapy, aplikaci se seznamem prvků nebo aplikace zpracovávající a zobrazující grafy. Architect lze považovat za WYSIWYG editor (What you see is what you get). To znamená, že uživatel by ve spuštěné aplikaci na svém mobilním zařízení měl vidět to stejné, co programátor navrhuje v Architectu. Architect však neslouží jen pro návrh UI aplikace, jedná se také o klasický editor aplikačního kódu, který podporuje doplňování kódu, obarvování kódu, kontrolu chyb v kódu a další. Sencha Architect bohužel není dostupný zdarma. Je nutno jej zakoupit. Licence pro jednoho uživatele stojí $399.00, v přepočtu téměř 8000 Kč. [33]
48
Popis vhodných technologií
Obr. 17
Sencha Touch Architect
5.3.4
Appcelerator Titanium
Framework Titanium je zdarma a open source. Aplikace se ve frameworku Titanium píší v jazyce JavaScript. Titanium však nepřevádí aplikační kód přímo do nativního kódu platformy, ale jednotlivým JavaScriptovým příkazům přiřazuje volání metod z Titanium API (které je napsané pro každou platformu zvlášť v jejím nativním kódu) a ty teprve volají nativní metody platformy. Vnitřně tedy ve spuštěné Titanium aplikací běží JavaScriptový interpret (engine), který volá přes Titanium nativní funkce. Titanium SDK se dá považovat jako spojovací most mezi JavaSciptovým kódem a nativním API mobilní platformy. Spouští se integrovaný JavaScript engine, který je v daném systému přítomen. Nespouští se však žádné webové okno, spouští se jen samotný engine. V prvních verzích Titanium (1.0alpha) se vnitřně v aplikaci webové okno spouštělo, ale už v ostré verzi 1.0 se od webového okna upustilo, jelikož spotřebovávalo zbytečně moc systémových prostředků. Aktuální verze Titania v dubnu 2014 je 3.2.0. [34] Výhodou Titanium aplikací je větší výkon a programátor nemusí vůbec manipulovat s HTML kódem jako v případě hybridních frameworků. Nevýhodou Titania je, že programátor nemá přímou kontrolu nad kódem, který Titanium vykonává. V mnoha případech jeden aplikační kód běží bez problému na všech platformách, které Titanium podporuje. Může se však stát, že je potřeba použít v aplikaci například nějaký systém navigace v aplikaci a tuto problematiku implementuje iOS a Android různě. Takové rozdíly nemohou být abstrahovány, proto se může stát, že
Popis vhodných technologií
49
bude muset programátor napsat nějaké části kódu aplikace v jazyce pro každou platformu zvlášť. Tedy Java pro Android a Objective-C pro iOS. [35][17] Titanium aplikace vykresluje nativní prvky uživatelského prostředí z jednotlivých mobilních platforem, což velice pomůže schvalovacímu procesu aplikace a ocení to také uživatelé díky rychlejší odezvě aplikace. Společného kódu pro všechny platformy je přibližně 50 - 70 %. [14] Na základě mnoha článků, fór a diskuzí na internetu bylo zjištěno, že nástroj Appcelerator Titanium není zcela vhodný pro větší a náročnější aplikace. Uživatelé si často stěžují, že Titanium neumí hospodařit s pamětí a u větších aplikací stávalo, že aplikace padala a někdy se zasekl i celý systém mobilní platformy. Problém je, že programátor nemá svůj kód zcela pod kontrolou, když se jím napsaný Javascript kód převádí na nativní kód dané platformy. Titanium aplikace jsou tak pomalejší než nativní, jelikož kód zpracovává JavaScript engine a nejedná se tedy o nativní kód. [38] Titanium podporuje kompilaci aplikací do platforem iOS, Android, BlackBerry, Windows Phone a Windows Phone 8 a poskytuje přístup k přibližně 90 % všech nativních funkcí dané mobilní platformy. [36] Aplikace v Titaniu se složitě ladí. Když nastane problém, tak se vypíše např. u Androidu výjimka Javového kódu, nikoliv však chyba v JavaScript kódu. Programátor musí tedy na základě chyby v Javovém kódu složitě zjišťovat, který příkaz ji vyvolal v JavaScriptu a to může být velice náročné. Často k takové výjimce nedostane programátor žádná vodítka, kde problém hledat. Vyžaduje to dobrou znalost jak dané mobilní platformy včetně programovacího jazyka, tak dobrou znalost programovacího jazyka JavaScript. Problémem u Titania dle komunity je problém s opravováním chyb. Uživatelé se zmiňují, že Appcelerator téměř všechny požadavky od uživatelů bez placeného účtu neřeší. Jedná se o závažné problémy nebo i malé detaily, většina z nich je bohužel ignorována. 5.3.4.1 Alloy Alloy je aplikační MVC framework postavený na Titaniu. Podporuje MVC, uživatelská prostředí se navrhují v jazyce XML a stylování aplikací probíhá pomocí speciálního stylovacího jazyka TSS. Aplikační kód se stejně jako v Titaniu píše v jazyce JavaScript. Hlavním důvodem existence Alloy je právě architektura MVC, kdy je aplikační kód a uživatelské prostředí separované do zvláštních souborů. Alloy umožňuje implementovat znovupoužitelné widgety. V Alloy je implementovaná podpora pro známé JavaScriptové knihovny Backbone.js a Underscore.js. Alloy není (v době psaní této práce, březen 2014) příliš rozšířené. Není pro něj mnoho různých návodů. [36][39]
50
5.3.5
Popis vhodných technologií
Xamarin
Projekt Xamarin je zdarma, ale není open source. V mnoha ohledech je velice podobný nástroji Appcelerator Titanium. Největší rozdíl mezi těmito nástroji je v jazyce, ve kterém se dané aplikace píšou. V Xamarinu se aplikace píší v jazyce C# ve frameworku .NET. [40] Xamarin se dělí na dvě části - Xamarin.iOS (dříve MonoTouch) a Xamarin.Android (dříve MonoDroid). Smyslem Xamarinu je mít napsanou aplikační logiku aplikace v jednom programovacím jazyce, avšak uživatelské prostředí aplikace je navrženo skrze tradiční přístup u každé platformy zvlášť. V případě Xamarinu je tedy 40 - 60 % kódu společného, multiplatformního. Zbytek je platformě závislý, což také znamená nutnost znalosti obou platforem, tedy Androidu i iOS. Platformě závislý kód je především uživatelské prostředí aplikace. [17] Velkou výhodou Xamarinu je jeho plná podpora kompletních systémových API podporovaných platforem. Mezi podporované platformy patří Android a iOS. Díky kompletní podpoře systémových API se mohou Xamarin aplikace chovat stejně jako nativní aplikace. Mohou pracovat v pozadí, mohou přistupovat k externímu hardwaru a podobně. [38] Dle různých názorů na internetu je však vývoj Xamarin aplikací velice náročný. Mnoho firem zjistilo, že vývoj multiplatformních aplikací v Xamarinu byl dražší než vývoj jednotlivých aplikací nativně. [14] 5.3.6
Adobe Phonegap
PhoneGap není regulérní framework pro vývoj mobilních aplikací. Účel Phonegapu je umožnit zkompilovat HTML webové stránky do nativních aplikací pro mobilní platformy, takovému nástroji se říká wrapper. HTML webová stránka může poté skrze Phonegap API využívat nativní funkce systému mobilní platformy. Mobilním webovým aplikacím totiž nejsou zpřístupněny nativní funkce systému jako například přístup ke kameře, telefonním kontaktům, různým sensorům (GPS apod.) a dalším. To je primární účel PhoneGapu - umožnit přístup k systémovým API. [41] Zkompilované Phonegap aplikace lze do mobilní platformy klasicky nainstalovat jako ostatní nativní aplikace, lze je také umístit do obchodu s aplikacemi. Pro vytvoření Phonegap aplikace musí programátor vytvořit mobilní webovou aplikaci postavenou na HTML, CSS a JavaScriptu. Tyto zdrojové kódy poté převezme PhoneGap kompilátor a vytvoří z nich nativní instalovatelnou aplikaci. Stylování webové mobilní aplikace (CSS) se píše responzivně, aby na všech mobilních zařízeních různých rozlišení a úhlopříček vypadala aplikace co nejlépe. K tomuto dopomáhají různé frameworky, které uživatelské prostředí řeší z velké části za programátora (JQTouch, jQuery Mobile, Sencha Touch 2). Když se spouští Phonegap aplikace, načítá se webové okno, ve kterém je zobrazena webová aplikace. [42] Pokud Phonegap nějakou funkci mobilní platformy nepodporuje, je možno si ji napsat. K tomu je však už nutno znát programovací jazyk dané platformy (Java pro
Popis vhodných technologií
51
Android, Objective-C pro iOS atd.). V dnešní době obsahuje PhoneGap pluginy na drtivou většinu běžných funkcí. [43] Podporované platformy jsou: FireOS od Amazonu Android BlackBerry 10 iOS (iPhone) Ubuntu Windows Phone 7 Windows Phone 8 Windows 8 Samsung Tizen PhoneGap umožňuje přístup k systémovým API mobilních platforem, avšak neumožňuje zobrazovat nativní prvky uživatelského rozhraní z dané platformy. Celá aplikace tedy musí být webová. Phonegap je modulární a umožňuje tak využívat již vytvořené pluginy od jiných autorů. [64] [17]
5.4
Zhodnocení technologií
V předchozích kapitolách bylo popsáno 5 různých technologií pro implementaci. V této kapitole se zhodnotí pozitivní a negativní aspekty jednotlivých technologií. jQuery Mobile o Výhoda: Jednoduchá syntaxe o Výhoda: Využívá HTML5 atributů o Výhoda: Největší uživatelská komunita o Výhoda: Open source o Nevýhoda: Pomalejší běh o Nevýhoda: V základu nepodporuje MVC Sencha Touch 2 o Výhoda: MVC architektura o Výhoda: Sencha Architect (placený) o Výhoda: Dobrá dokumentace o Nevýhoda: Syntaxe o Nevýhoda: Uzavřenost jQTouch o Výhoda: Jednoduchá syntaxe o Výhoda: SASS stylování o Výhoda: Podpora Zepto.js o Nevýhoda: Zaměřeno pouze na WebKit o Nevýhoda: Malá uživatelská komunita o Nevýhoda: Horší dokumentace Appcelerator Titanium
52
Popis vhodných technologií
o o o o o Xamarin o o o o
Výhoda: Výkon aplikace Výhoda: Nativní uživatelské prostředí Výhoda: MVC framework Alloy Nevýhoda: Nutná dobrá znalost jednotlivých platforem Nevýhoda: Problémy s pamětí u větších aplikací Výhoda: Výkon aplikace Výhoda: Nativní uživatelské prostředí Nevýhoda: Nutná dobrá znalost jednotlivých platforem Nevýhoda: Velice složitý
Výběr technologií
53
6 Výběr technologií V této kapitole bude vybrána hlavní technologie (Framework) pro vývoj mobilní aplikace, tyto technologie budou popsány a budou vybrány další knihovny, které budou při implementaci potřeba.
6.1
Vybrané technologie
Na základě zhodnocení technologií v kapitole 5.4 nelze jednoznačně určit nejlepší technologii. Každá nabízí různé výhody a nevýhody. Žádná z technologií není špatná, žádná z nich však také není výrazně technologicky dále než ostatní. Jedná se o rovnocenné konkurenční technologie. Výběr konkrétní technologie může záležet na velice specifických požadavcích na aplikaci. V případě Vykupto aplikace žádné takové specifické požadavky nebyly definovány. Mohlo by se jednat např. o konkrétní požadavky na uživatelské rozhraní, programovací jazyk, aj. Zde je však výběr bez jakéhokoliv omezení. Pro implementaci Vykupto aplikace bylo vybráno jQuery Mobile v aktuální verzi 1.3 (s wrapperem PhoneGap) na základě předchozích zkušeností a znalostí, potom také díky obrovské komunitě, spoustě pluginů a syntaxi, která využívá HTML5 atributů. Jedná se o velice jednoduchou a účinnou syntaxi, která je běžná v oblasti vývoje webových aplikací. Není nutno se učit jinou syntaxi (např. Sencha Touch) nebo úplně nový jazyk (např. Xamarin), který navíc vyžaduje hlubší znalosti jednotlivých mobilních platforem, jelikož aplikační kód není společný pro všechny platformy. Výhodou jQuery Mobile je také znovupoužitelnost kódu, která je mnohem vyšší, než např. u nástrojů Titanium a Xamarin. jQuery Mobile se velice aktivně vyvíjí, jeho zdrojový kód je dostupný na GitHubu a není tak problém si do detailu nastudovat, jak celé jQuery Mobile včetně samotné knihovny jQuery funguje. Použití jQuery Mobile je také výhodné pro Vykupto. Nemusí najímat do budoucna nové zaměstnance na vývoj aplikace. V případě Xamarinu nebo nativních aplikací by byl potřeba další zaměstnanec, kterého by však nemohli zaměstnávat na hlavní pracovní poměr, jelikož úpravy mobilních aplikací ve Vykupto nejsou kontinuální, ale spíše nárazové vzhledem k novinkám, které jsou uváděny na webu Vykupto. Díky jQuery Mobile si mohou stávající zaměstnanci Vykupto upravovat mobilní aplikaci, jelikož bude postavena na stejných webových technologiích, které důvěrně znají z vývoje webu Vykupto.
6.2
Další použité technologie a knihovny
K vývoji mobilní multiplatformní aplikace byly zvoleny navíc doplňující knihovny. Ty slouží například pro zpětnou kompatibilitu některých funkcí v JavaScriptu nebo pro přehlednější psaní HTML šablon aplikace.
54
6.2.1
Výběr technologií
CoffeeScript
CoffeeScript je programovací jazyk, který je kompilován do JavaScriptu. Takovým jazykům se říká transpilery, kompilují zdrojový kód do jiného zdrojového kódu. [45] CoffeeScript se snaží vyzdvihnout dobré části JavaScriptu a udělat ho jednodušší. Přidává tzv. syntax sugar (zjednodušení syntaxe) s cílem zkrátit kód a udělat ho čitelnějším. Syntaxe jazyka je inspirovaná jazyky Ruby, Python a Haskell. Coffeescript nepoužívá středníky, složené závorky a není nutno deklarovat proměnné. [44] Hlavní výhody CoffeeScriptu jsou: Kratší kód než JavaScriptový kód Jednoduchá definice funkce Bezpečnost proměnných o CoffeeScript automaticky sám deklaruje každou použitou proměnnou v daném scope. Nemůže se tak stát, že by uživatel omylem použil proměnnou v jiném scope a změnil tak její hodnotu. To není problém v JavaScriptu provést. Scope lze popsat jako rámec působnosti proměnné. Je to prostor, ve kterém je proměnná viditelná. Jednoduché a bezpečné cykly využívající hasOwnProperty pro procházení objektů Interpolace textových řetězců o "My name is #{name} and your?" o Name je proměnná, která pomocí hashe a složené závorky bude do řetězce vložena. Není tak nutno psát složité “My name is “ + name + “ and your?” Rozsahy o Zápis [2..10]je převeden na [2, 3, 4, 5, 6, 7, 8, 9, 10]; o Díky této konstrukci lze vytvářet různá pole nebo také získávat jen části polí touto konstrukcí: array[2..5]. Převedený kód vypadá následovně: array.slice(2, 6); o Díky konstrukci rozsahů nemusí programátor pamatovat na to, že do funkce slice musí psát jiné indexy, než doopravdy chce. Existenční operátor o if x? then use(x) o Zavolá funkci use(x) jen v případě, že hodnota x není rovna undefined nebo null. o are?.you?.there? o Tato konstrukce zjistí, zda je nastaven objekt are, poté v něm vyhledá objekt you a nakonec objekt there. Pokud všechny atributy byly nalezeny, vrátí tato konstrukce true, v opačném případě false. Function binding
Výběr technologií
Třídy
55
o bar: => this.foo() o Napevno nastaví funkci bar scope na ten, ve kterém je definována bez ohledu na to, odkud je volána. To se velice hodí například u callbacků, které mění scope funkce. o V Coffeescriptu nemusí programátor řesit složitou JavaScriptovou prototypovou dědičnost. To vše za programátora řeší CoffeeScript. Stačí používat klíčové slovo Class (včetně extends), které CoffeeScript přidává a o vše bude postaráno automaticky. Budou vytvořeny JavaScriptové prototypy, které zajistí požadované chování
Kompletní seznam všech syntaktických konstrukcí CoffeeScriptu je dostupný na adrese http://coffeescript.org/. CoffeeScript od verze 1.6.1 podporuje vytváření tzv. Source map. Source mapa je soubor, který definuje vztah CoffeeScript kódu a JavaScript kódu. Tento soubor používají prohlížeče a hodí se při ladění kódu. Když se během zpracování JavaScript kódu vyskytne chyba, bez source mapy by prohlížeč označil daný chybový řádek v kódu JavaScriptu. Programátor by pak musel zjistit, kde se v CoffeeScript kódu nachází konstrukce, která tento JavaScript kód vytvořila. Díky source mapě toto programátor nemusí dělat. Prohlížeč uživateli přímo zobrazí kód z CoffeeScriptu a problém tak může být vyřešen i řádově rychleji. [44] 6.2.2
Handlebars
Handlebars je jednoduchý šablonovací systém. Umožňuje v HTML kódu definovat šablonu s funkčními bloky a helpery, jako je procházení polí, podmínkové bloky nebo definice vlastních funkčních bloků. [46] Důvod použití Handlebars je, že jQuery Mobile žádný vlastní šablonovací systém nemá. jQuery Mobile pouze načte HTML kód a ten upraví tak, jak potřebuje, aby se webová aplikace správně zobrazila v mobilním zařízení. Tomuto přístupu se říká progressive enhancement. HTML kód je však nutno napřed vytvořit, než se předá jQuery Mobile. Například seznam slev - nejprve se musí vytvořit HTML seznam - jedná se o dlouhý a komplexní UL (Unordered list, nečíslovaný seznam) seznam. Ten se předá jQuery Mobile a seznam se poté může zobrazit správně v mobilním zařízení. jQuery Mobile na seznamu provede nutné úpravy (přidá různé třídy, atributy, změní strukturu kódu apod.) Postup zpracování kódu je tedy následující: 1. Načtení HTML šablony. 2.
Načtení všech důležitých proměnných, se kterými se pracuje v šabloně.
3.
Předání proměnných a šablony Handlebars.
4. 5.
Handlebars šablonu zpracují a vrátí ji. Vygenerovaný HTML kód se za pomoci jQuery Mobile vloží do DOM.
56
Výběr technologií
6.
jQuery Mobile vložený kód zpracuje a upraví do výsledné podoby (progressive enhancement).
7.
Stránka je připravena se zobrazit v mobilním zařízení.
HTML kód se může vytvářet i za pomoci jQuery nebo zcela bez použití jakéhokoliv frameworku či knihovny - jednoduchou prací se stringy (řetězci znaků). Tento přístup je ovšem velice nepřehledný, vytváří spoustu kódu navíc. Navíc není vhodné v jednom souboru psát aplikační logiku s uživatelským prostředím. Výrazně jednodušší je mít vytvořené HTML soubory (šablony), které se načtou v Handlebars a vytvořenou HTML strukturu předají ke zpracování jQuery Mobile, jak bylo popsáno výše. Handlebars je v základu (po stažení) velice minimalistická a podporuje pouze několik helperů. Helper je funkce, která pomáhá upravit nebo přeformátovat data do výsledné podoby. Knihovna Handlebars vznikla z knihovny Mustache. 6.2.2.1 Základní funkce Handlebars {{prom}} o Výpis proměnné {{{prom}}} o Výpis proměnné bez escapování {! komentar }} o Klasický komentář kódu. Ve výsledném vygenerovaném HTML kódu tento komentář nebude. {{#each prom}} {{/each}} o Cyklus pro procházení pole. Uvnitř pole je v každé iteraci nastaven ukazatel this na právě procházenou položku pole. {{#with prom}} o Nastaví kontext na proměnnou prom. Poté je jednodušší přistupovat k atributům objektu. Bez použití #with by bylo nutné psát např. author.name, author.surname, author.email, ale díky {{#with author}} lze poté psát pouze name, surname a email. {{#if prom}} o Podmínka - pokud je hodnota prom rovna true, provede se blok těla proměnné. V opačném případě se blok těla proměnné přeskočí. Je možno použít větev else. {{#unless prom}} o Jedná se o opak funkce if. Tělo bloku unless se provede pouze v případě, že hodnota prom je rovna false. Další helpery si může programátor vytvořit sám za pomoci funkce Handlebars.registerHelper(). Již hotové helpery se dají stáhnout zde: https://github.com/assemble/handlebars-helpers. Ke dni 23. břez-
Výběr technologií
57
na 2014 obsahuje tento repozitář celkem 123 připravených helperů, které lze ihned po stažení použít. Jedná se o helpery pro práci např. s datem, čísly, měnami, řetězci znaků, porovnávání a další. 6.2.2.2 Příklad jednoduché šablony Šablona se uzavírá do <script> značky, její název určuje parametr id a jelikož se nejedná o JavaScript kód, je to nutno přes parametr type prohlížeči oznámit hodnotou text/x-handlebars-template. Dále se již v šabloně nachází klasický HTML kód, ve kterém se jsou použité Handlebars konstrukce. V následující šabloně je pro ukázku implementován výpis proměnné headline bez escapování, to zajišťují tři složené závorky. Dále je vidět použití helperu createOptions se dvěma parametry. První parametr je číslo 10, druhý pak proměnná amount z objektu dealElement. Jako poslední Handlebars konstrukce v šabloně je vidět použití podmínkového bloku if. Tělo bloku se vykoná pouze, když bude hodnota proměnné shipping rovna TRUE. <script id="_dealBuyAmountTemplate" type="text/xhandlebars-template">
<select name="amount" class="vouchersAmount"> {{{createOptions 10 dealElement.amount}}} {{#if shipping}} Cena za dopravu: {{shipping.price_raw}} Kč {{/if}}
{{{slidePanel}}} 6.2.2.3 Příklad jednoduchého helperu Příklad helperu je psán v CoffeeScriptu: Handlebars.registerHelper "createCommentMargin", (depth) ->
58
Výběr technologií
margin = depth * 10 "margin-left: #{margin}px;" Helper vytvořený pomocí funkce Handlebars.registerHelper přijímá jako první parametr název helperu createCommentMargin a jako druhý parametr anonymní funkci, která je tělem helperu. Tato anonymní funkce přijímá parametr udávající zanoření komentáře v diskuzi slevy jako celočíselnou hodnotu. Helper na základě hodnoty zanoření vytvoří příslušné CSS odsazení pomocí hodnoty margin-left a tento kód vypíše do šablony. Tento helper se bude v šabloně volat způsobem: {{createCommentMargin value}}, kde hodnota value představuje celočíselnou hodnotu zanoření. 6.2.3
Underscore.js
Underscore.js je JavaScriptová knihovna, která přináší přibližně 80 různých funkcí. Underscore neupravuje prototypy žádných vestavěných objektů v JavaScriptu. Některé jsou obecně funkcionální (forEach, map, reduce, filter, every, some, indexOf), jiné specializovanější (function binding, šablony, apod.). Underscore také obsahuje funkce pro práce s kolekcemi (pole a objekty). [47] I když ECMAScript 5 již obsahuje mnoho funkcí pro funkcionální programování, Underscore.js je i přesto implementuje. Důvodem jsou starší prohlížeče, které jsou stále velice používané a tyto funkce neimplementují. Pokud Underscore.js zjistí, že některá funkce je v prohlížeči implementována nativně, pak zavolá nativní funkci. [48] Například funkce Array.prototype.map není implementovaná v Internet Exploreru starším než verze 9. [65] Všechny funkce Underscore.js jsou dostupné přes globální identifikátor podtržítko. Např. funkce map se volá následovně: _.map([1, 2, 3], function(num){ return num * 3; }); 6.2.4
ThemeRoller for jQuery Mobile
Theme Roller je webová aplikace pro rychlý návrh stylování jQuery Mobile aplikací. Je vhodná na prototypování aplikací. Umožňuje si rychle a jednoduše nastavit barvy aplikace, různé stylování textu, formulářových prvků a dalších. Výsledný vzhled je možno exportovat do CSS souboru. ThemeRoller také umožňuje importovat již vytvořený CSS soubor a nadále jej upravovat. [49]
Výběr technologií
Obr. 18
59
Hlavní okno ThemeRolleru
Obrázek znázorňuje hlavní okno ThemeRolleru. Ve vrchní části stránky je vidět paleta barev, které lze přetahovat na místa, která se uživateli líbí. Lze je přetahovat přímo do ukázky uživatelského rozhraní, ale také do levého sloupce. Levý sloupec navíc slouží k nastavení dalších různých hodnot, jako je stín písma, různá ohraničení a podobně.
60
Implementace
7 Implementace V této kapitole bude popsán postup implementace aplikace. Budou probrány všechny důležité aspekty vývoje a různé problémy, které bylo nutno během vývoje řešit.
7.1
Jak funguje jQuery Mobile
Jak již bylo zmíněno výše, základním principem jQuery Mobile je metoda progressive enhancement. To znamená, že jQuery Mobile zpracuje základní HTML kód stránky a upraví jej tak, aby se na daném mobilním zařízení zobrazoval správně. Z jednoduché struktury s typickými značkami jako je div, span, p, a, table vytvoří složitější strukturu. Velká většina vlastností jQuery Mobile aplikace se nastavuje v atributech jednotlivých HTML prvků pomocí data atributů. Lze tak velice jednoduše změnit vzhled nebo dokonce chování celé aplikace. [50] Pro vývoj aplikace je nutno vytvořit základní strukturu kódu. Do té patří kód pro stránku, která se zobrazí uživateli. Nepovinně pak může stránka obsahovat kód pro záhlaví a zápatí. Základní kód aplikaci s jednou stránkou je k nahlédnutí v příloze B. Stránek může být v jednom HTML souboru více. Nejjednodušší přepínání mezi nimi zajistí HTML odkaz, jehož atribut href se bude odkazovat na identifikátor (id) stránky. Po kliknutí na takový odkaz provede jQuery Mobile samo přechod na další stránku. HTML kód může být rozdělen i do více různých souborů. V tom případě stačí, aby href odkaz vedl na daný HTML soubor a jQuery Mobile se opět o vše postará. To znamená, že načte pomocí AJAXu požadovanou stránku, provede progressive enhancement a stránku uživateli zobrazí. [50] Díky progressive enhancement nemusí programátor řešit, jak budou různé HTML prvky v mnoha různých mobilních zařízeních vypadat. Jednoduše pouze HTML prvek použije a o vše ostatní se postará jQuery Mobile. Všechny viditelné prvky jsou na displejích dostatečně velké, využívají co nejlépe rozměry malých displejů mobilních telefonů a tabletů. [51]
7.2
Vytvoření tříd v CoffeeScriptu
jQuery Mobile nenařizuje programátorovi používat nějakou konkrétní strukturu kódu. Je čistě na programátorovi, jak takovou aplikaci začne psát. Pro srovnání, například Sencha Touch se zakládá na architektuře MVC, kterou by měl programátor dodržovat. Pro implementaci jQuery Mobile aplikace lze využít i libovolný aplikační framework. Například framework Backbone.js je častá varianta k psaní aplikací společně s jQuery Mobile pomocí MVC architektury. Použití Backbone.js však vyžaduje alespoň základní znalosti a zkušenosti s frameworkem, jinak může být jeho použití spíše kontraproduktivní.
Implementace
61
Aplikační kód aplikace je vytvořen podle MVC paradigmatu, nebyl však využit žádný framework k jQuery Mobile, jako je Backbone.js. V kódu existuje jedna hlavní třída (Base), od které dědí všechny ostatní třídy. Jak již bylo zmíněno v popisu CoffeeScriptu, nejedná se o pravou třídu, ale JavaScriptový prototyp. Třídami se nazývají v CoffeeScriptu díky jejich maximálnímu zjednodušení a přiblížení ke klasickým programovacím jazykům s objektově orientovaným programováním. MVC (Model-view-controller) je softwarová architektura, která kód aplikace rozděluje na tři nezávislé komponenty. Jedná se o datový model, který především obstarává práci s daty, dále controller, což je řídící logika aplikace a nakonec uživatelské rozhraní. Modifikace jedné ze tří komponent by měla mít jen minimální vliv na ostatní komponenty. [52] Aplikace tedy obsahuje tři hlavní typy souborů - controllery, modely a šablony. Rozdělení tříd je následující: BuyController o Třída, která zajišťuje kompletní průchod nakupovacím procesem aplikace. Nakupovací proces může mít dva až pět kroků (zmíněno v kapitole 2.2). FacebookController o Tato třída se stará o přihlášení uživatele skrze sociální síť Facebook v případě, že se uživatel chce přes tuto sociální síť přihlásit. LoginController o Třída se stará o přihlašování uživatele do aplikace. OfflineController o Třída starající se o chování aplikace v případě, že je offline (není možný přístup k internetu). PhonegapController o Třída implementující funkce z PhoneGap API. RegisterController o Třída zajišťující registraci uživatele do Vykupto. VouchersController o Tato třída umožňuje uživateli si zobrazit přehled jeho zakoupených voucherů včetně zobrazení detailu jednotlivých voucherů. VykuptoController o Hlavní třída zobrazující aktuální seznam slev, detail zvolené slevy a stará se vytváření HTML struktury pro slide panel. Storage o Tato třída se stará o ukládání všech dat, která mohou být v aplikaci potřeba. Jedná se o tyto údaje: Údaje z nakupovacího procesu (jakou variantu si uživatel vybral, počet voucherů apod.) Aktuální filtry Kód pro slide panel Uložená města
62
Implementace
API
Načtené detaily slev Načtený seznam slev Údaje o uživateli, který je v aplikaci přihlášený Uživatelovy zakoupené vouchery o Tato třída je implementována jako model z architektury MVC, jelikož implementuje pouze funkce pracující s daty. o Tato třída implementuje funkce, které byly popsány v kapitole 2.5. Všechny AJAXové požadavky jsou vytvořeny pomocí vzoru (patternu) Promise/A (popsáno v kapitole 7.4). o API implementováno jako model z architektury MVC, jelikož umožňuje pouze přistupovat k datům z Vykupto API, žádné jiné funkce nepodporuje.
Všechny třídy obsahující v názvu Controller mají dvě závislosti, bez kterých nemohou fungovat. Tyto závislosti jsou API a Storage, které jsou přítomny v každé instanci Controller tříd v aplikaci.
7.3
Struktura HTML kódu
Tato kapitola obsahuje popis šablon pro zobrazení uživatelského rozhraní aplikace. Jelikož bude aplikace obsahovat více různých stránek, nebylo by vhodné používat pouze jeden HTML soubor, ve kterém bude uložena veškerá HTML struktura. HTML kód je rozdělen do více souborů následovně: Vhodná je následující struktura HTML souborů: IndexRun.html o Kód pro stránky zobrazující hlavní seznam slev, detail slevy, stránky pro kompletní proces nákupu a nakonec kód pro vygenerování slide panelu. Login.html o Stránka zajišťující přihlášení uživatele klasicky (e-mail a heslo) nebo skrze sociální síť Facebook. Register.html o Kód pro stránky, které se zabývají registrací uživatele. Bude obsahovat definici formuláře pro registraci. termsOfUse.html o Před registrací by měl mít uživatel možnost si přečíst podmínky používání Vykupto služeb. Jelikož se jedná o dlouhý a rozsáhlý text, bude uložen v samostatném HTML souboru. Settings.html o Tato šablona obsahuje kód pro zobrazení sekce nastavení. vouchers.html o Kód pro stránky, které zobrazují uživatelovy nakoupené vouchery a detaily těchto voucherů.
Implementace
7.4
63
Promise/A
Promise/A je vzor (pattern) pro práci s AJAXem. Existuje více typů Promise - A, B, KISS, C a D. jQuery implementuje typ A, proto se používá označení Promise/A. Umožňuje definovat, v jakém pořadí budou volány obslužné callbacky a definovat podmínky, na základě kterých se callbacky budou volat. Callbacky jsou funkce, které se zavolají automaticky podle nějaké události. V případě AJAXu může být callback pro úspěšné provedení AJAX požadavku, pro neúspěšné provedení požadavku a callback, který se zavolá vždy bez ohledu na úspěch požadavku. [53][54] Následující ukázka kódu psaná v CoffeeScript jazyce prezentuje použití Promise/A v jQuery Mobile. Za mřížkou v kódu se vždy nachází komentář, k čemu daný blok kódu slouží. Tato ukázka implementuje stav done (úspěšné provedení AJAXu), fail (neúspěšné provedení AJAXu) a always (volá se vždy bez ohledu na výsledek AJAX požadavku). [55] jQxhr = $.ajax( type: "GET" dataType: "json" contentType: "application/json" url: "http://www.vykupto.cz/mobile/api?function=deal_list" ).done((data) => #Kód v tomto bloku se zavolá v případě úspěšného AJAX požadavku ).fail((data) -> #Kód v tomto bloku se zavolá v případě neúspěšného AJAX požadavku ).always((data) -> #Kód v tomto bloku se zavolá vždy )
7.5
Spuštění aplikace
Hlavním souborem aplikace je Bootstrap.coffee, který celou aplikaci spouští. Musí zachytit dvě důležité události. Po zachycení těchto událostí je možno změnit nastavení jQuery Mobile a všech jeho funkcí. Dále se inicializují objekty a aktivuje se router. Hlavním úkolem routeru je definice všech URL adres a funkcí, které se mají zavolat. Nakonec router zavolá příslušnou funkci pro zobrazení hlavní strany aplikace. Router je popsán v následující kapitole 7.5. Bootstrap také kontroluje, zda je aplikace online nebo offline po spuštění. První důležitá událost je deviceready a tu vyvolává PhoneGap. Vyvolává se, když je PhoneGap kompletně načten a připraven. Druhá důležitá událost je mobileinit, tu vyvolává jQuery Mobile ve chvíli, kdy jsou všechny soubory a závislosti načteny, ale ještě se nespustil progressive enhancement.
64
Implementace
7.6
Router aplikace
Router je funkcionalita, která na základě změny URL adresy umí zavolat příslušnou funkci pro zobrazení nové obrazovky. Například když chce uživatel zobrazit detail slevy, po stisku tlačítka pro zobrazení detailu slevy se v URL objeví hash #dealdetail55874. Hash #dealdetail routeru signalizuje, že se jedná o adresu pro zobrazení detailu slevy. Číslo pak udává konkrétní identifikátor slevy. Router zavolá příslušnou funkci pro zobrazení detailu slevy a uživateli se zobrazí na displeji. jQuery Mobile neobsahuje žádný vestavěný router, který by bylo možno ihned použít a vytvářet na něm aplikaci. Na internetu se nachází spousta návodů, jak takové routování vytvořit, avšak často taková řešení obsahovala nějaké chyby. Proto byl využit k routování plugin jQueryMobile-Router. [56] Jedná se o velice komplexní plugin. Podporuje routování na základě událostí (eventů) v jQuery Mobile, které se spouštějí během změny stránky. Jedná se o události pagebeforecreate, pagecreate, pagebeforeshow, pageshow, pagebeforehide, pagehide a pageremove. Klasický router sleduje pouze URL adresu a na základě ní spustí příslušné funkce. jQuery Mobile však se změnou URL adresy vyvolává i události. Jeden routovací záznam se tedy píše jako kombinace URL adresy a události. Toto je pro jQuery Mobile unikátní vlastnost. 7.6.1
Popis jednotlivých událostí
pagebeforeshow o Tato událost je vyvolána před spuštěním animace přechodu z jedné stránky na druhou. pageshow o Tato událost je vyvolána, když se dokončí animace přechodu stránky. pagebeforehide o Tato událost je vyvolána před započetím animace u stránky, která má být skryta. pagehide o Tato událost je vyvolána po dokončení animace u stránky, která má být skryta. o Společně s události pagebeforehide může být tato událost využita k tomu, že aplikace smaže nepotřebnou část DOM, smaže již nepotřebný aplikační kód, apod. pagebeforechange o Tato událost se vyvolá ve chvíli, kdy jQuery Mobile přijme data o stránce, kterou bude muset zobrazit. Při zpracování této události je možné pozastavit přechod na novou stránku, provést různé změny, výpočty a po dokončení těchto změn je možno povolit animaci, aby proběhla a stránku zobrazila.
Implementace
65
Události pro aplikace využívající AJAX: pagebeforecreate o Tato událost je vyvolána u konkrétní stránky předtím, než jQuery Mobile provede progressive enhancement na stránce. pagecreate o Událost se vyvolá, když jQuery mobile vytvoří kompletní HTML strukturu stránky a vloží ji do DOM. pageinit o Událost je vyvolána, když jQuery Mobile dokončí progressive enhancement HTML kódu vloženého DOM. pageremove o Tato událost je vyvolána automaticky, když jQuery Mobile smaže z DOM nepotřebnou stránku, aby snížilo paměťové nároky a zvýšilo výkon aplikace. Mazány jsou však pouze stránky, které byly načteny do DOM pomocí AJAXu. Automatické mazání stránek z DOM lze zakázat v nastavení jQuery Mobile. V této aplikaci je nejdůležitější a nejpoužívanější událost pagebeforeshow. Router vždy přijme tuto událost u každé stránky, kterou má zobrazit. Nejprve pozastaví přechod na novou stránku a pomocí Handlebars se vytvoří HTML struktura, ta se vloží do stránky a poté se pokračuje dál v zobrazení stránky. Router například přijme URL, ve které je hash #dealdetail55874. Router pozastaví přechod, aplikace z API stáhne všechny údaje o slevě, pomocí Handlebars sestaví HTML strukturu a tu vloží do DOM. jQuery Mobile provede na stránce progressive enhancement a stránku uživateli zobrazí. 7.6.2
Příklad použití routeru
Ukázka je psaná v CoffeeScriptu: router = new $.mobile.Router([ { "#certainPage": handler: "foo" events: "s" } { "#certainPage": handler: "bar" events: "h" } ], foo: (param) -> #Tělo funkce foo
66
Implementace
bar: (param) -> #Tělo funkce bar , options) V tomto kódu je do konstruktoru $.mobile.router dosazen jako první parametr pole a jako druhý parametr objekt. V prvním parametru jsou definice adres, které je potřeba zachytávat (#certainPage). Obě adresy jsou stejné, jelikož se liší v události, které se k dané routě pojí. V prvním případě je to událost s, což znamená pageShow, u které se zavolá funkce foo. Ve druhém případě je to událost h, to znamená pagehide, zde se zavolá funkce bar. Druhý parametr konstruktoru obsahuje definice obou zmíněných funkcí, které zpracují odkaz, tedy foo a bar. Třetí parametr je objekt s nastavením routeru.
7.7
Slide panel
Slide panel je pro celou aplikaci stejný. V každé stránce se při vykonání swipe gesta směrem doprava zobrazí stejný panel. V jQuery Mobile ve verzi 1.3 je však bohužel nutno vkládat HTML kód slide panelu do každé stránky, která se bude uživateli zobrazovat. To není optimální řešení, jelikož slide panel může mít komplexní DOM a bude tím pádem náročný na zpracování, což má negativní dopad na výkon aplikace. V době psaní této práce byla dostupná na internetu testovací verze jQuery Mobile ve verzi 1.4, ve které již není nutno vkládat slide panel do každé stránky zvlášť. Tato verze však neměla hotovou dokumentaci. Do budoucnosti se však jedná o vhodnou úpravu aplikace, jelikož se aplikační kód značně zjednoduší. [57] Následující kód ukazuje, jak má být slide panel vygenerován do každé stránky v jQuery Mobile:
Zde se nachází HTML struktura slide panelu
Obsah hlavičky stránky
Obsah stránky
Obsah zápatí stránky
Slide panel je definován v div značce s hodnotou panel v atributu data-role. Tento div může obsahovat libovolný kód, který bude poté zobrazen ve slide panelu.
Implementace
Obr. 19
7.8
67
Slide panel v jQuery Mobile aplikaci
Facebook integrace
Facebook se používá v aplikaci pro přihlašování. Pro úspěšnou implementaci pluginu pro Facebook je nutno v prvním kroku nainstalovat do aplikace příslušný plugin. Do souboru config.xml v sekci <widget> je nutno vložit následující kód: <param name="APP_ID" value="Vykupto" /> <param name="APP_NAME" value="135792468" /> APP_ID Představuje název aplikace na Facebooku, skrze kterou bude probíhat přihlašování a APP_ID je unikátní kód aplikace (v ukázce nejsou reálné hodnoty). Poté je nutné vložit do HTML kódu následující dvě značky odkazující se na JavaScript soubory, díky kterým bude možno se přes Facebook přihlašovat.
68
Implementace
<script src="cdv-plugin-fb-connect.js"> <script src="facebook-js-sdk.js"> Samotné soubory není nutné mít uložené v projektu, vkládá je tam automaticky PhoneGap během kompilace. Aby Facebook přihlašování fungovalo, je nutné, aby aplikace měla certifikát. Jak certifikovat aplikaci se popisuje v kapitole 7.15. Dále je nutné nastavit správně údaje o aplikaci také ve Facebooku na adrese http://developers.facebook.com. Na této adrese je nutno vytvořit novou aplikaci (v případě Vykupto již aplikace existuje) a nastavit u ní možnost přihlašování se do aplikace skrze mobilní zařízení. Platformy se vybírají jednotlivě. V případě Androidu se vyplňuje název aplikace a název třídy v aplikačním kódu, který bude využívat přihlášení přes Facebook. Jako poslední krok je nutno vložit do položky Key Hashes vytvořený hash klíč z certifikátu aplikace, jeho vytvoření je popsáno v kapitole 7.15. Hash se vytáří příkazem keytool -exportcert alias vykupto -keystore vykupto.keystore | openssl sha1 binary | openssl base64, kde vykupto.keystore představuje název souboru již existujícího certifikátu a –alias vykupto značí tzv. alias (pojmenování) již existujícího certifikátu. V aplikačním kódu je poté možno využívat nového objektu FB (plugin FacebookConnect). Jeho implementace je v souboru FacebookController.coffe. K přihlášení stačí implementovat dvě metody. Inicializační metodu init, která nastaví hodnoty objektu FB a funkci login, ve které je pomocí Promise/A volán požadavek na Facebook o přihlášení.
7.9
HTML5 Web Storage
Web Storage je technologie, pomocí které lze jednoduše ukládat data do prohlížeče za pomoci JavaScriptového API. Jedná se o velice jednoduchou a rozšířenou technologii. [58] Specifikace Web Storage definuje dva typy lokálních úložišť, které jsou až na jeden detail identické. Jedná se o perzistenci dat. V úložišti typu Local Storage jsou data perzistentní, tedy stálá a nejsou tedy smazána po zavření záložky s webovou stránkou nebo po vypnutí prohlížeče. Úložiště typu Session Storage oproti Local Storage ukládá data jen po dobu sezení (session). Data se tedy ztratí po zavření záložky s webovou stránkou nebo po vypnutí celého prohlížeče. Důležité je, že data ve Web Storage jsou spojena s doménou stránky. Pokud si tedy uživatel otevře jednu webovou stránku ve více záložkách prohlížeče, všechny záložky budou mít k dispozici stejná data. Záleží poté již na programátorovi, jak tuto situaci vyřešit na základě typu webové aplikace. Ve Vykupto mobilní aplikaci je použito Local Storage pro ukládání přihlašovacích údajů uživatele a jeho zakoupených voucherů. Všechny moderní webové prohlížeče v mobilních platformách podporují Web Storage, lze jej bez problému použít. [66]
Implementace
69
Úložiště pracují jako velice jednoduchá key-value (klíč-hodnota) databáze. Jedná se o strukturu stejnou jako u asociativního pole dat. V něm jsou položky indexovány volitelným klíčem, nejčastěji se jedná o řetězec znaků. Kapacita úložiště dat je rozdílná u mnoha webových prohlížečů. Neexistuje žádná specifikovaná minimální nebo maximální kapacita tohoto úložiště. Je doporučeno ukládat do úložiště maximálně 5 MB dat pro jednu doménu. API WebStorage definuje následující metody, které slouží pro práci s ukládanými položkami: setItem(key, value) o Tato metoda umožňuje uložit do úložiště databáze hodnotu value pod klíčem key. Pokud položka s klíčem key již existuje, bude přepsána, jinak bude vytvořena nová. Pokud by nastal problém a nemohla být nová hodnota do úložiště vložena (například nedostatek volné kapacity), vyvolá tato metoda výjimku QUOTA_EXCEEDED_ERR. getItem(key) o Tato metoda vrátí uloženou položku na základě požadovaného klíče. Pokud daná položka v úložišti neexistuje, vrátí metoda hodnotu null. removeItem(klíč) o Tato metoda smaže položku z úložiště na základě zadaného klíče. clear() o Smaže z úložiště všechna uložená data. key(index) o Tato metoda vrátí název klíče z úložiště na základě zadaného indexu. V úložišti jsou všechny položky číslovány od hodnoty 0 a jejich celkový počet lze zjistit pomocí vlastnosti length. Díky této metodě a vlastnosti length je možno iterativně procházet celé úložiště bez znalosti klíčů. Web Storage vyvolává událost storage v případě, že proběhne jakákoliv změna s daty. V datech této události jsou přítomny následující údaje: key o Klíč položky, u které proběhla změna oldValue o V tomto atributu se nachází původní hodnota dané položky. Pokud byla vytvořena nová položka, bude zobrazena hodnota null. newValue o Nová hodnota položky vložená do úložiště. url o URL webové stránky, která vyvolala tuto událost storageArea
70
Implementace
o Udává, ve kterém typu datového úložiště došlo ke změně. Může to být Local Storage nebo Session Storage. K oběma úložištím (Local Storage a Session Storage) se v JavaScriptu přistupuje skrze globální objekt window. Local Storage je přístupný pod položkou window.localStorage a Session Storage je přístupný pod položkou window.sessionStorage. Přistupovat k nim lze však i bez uvedení objektu window, například následovně: localStorage.setItem(„user‟, „test‟). K Web Storage úložištím lze přistupovat i jako k polím. V tom případě jsou metody setItem a getItem volány automaticky na pozadí. Lze tedy přistupovat k položce user i tímto způsobem: localStorage[„user‟]. [59] Local Storage ve Vykupto aplikaci ukládá přihlašovací údaje uživatele, údaje o uživateli, přihlašovací metodu, kterou uživatel použil a seznam voucherů, které uživatel zakoupil.
7.10 Implementace přihlášení do aplikace Pro přihlášení do aplikace musí uživatel využít klasické metody skrze e-mail a heslo nebo může využít přihlášení skrze Facebook. Po stisknutí tlačítka přihlásit se na Vykupto API pošle požadavek na přihlášení. Po úspěšném přihlášení se vrátí data o uživateli ze serveru Vykupto. V datech je navíc přítomna položka sessionid. Položka sessionid je také přítomna v HTTP hlavičce Set-cookie. Díky této hlavičce si prohlížeč uloží do COOKIES identifikátor Session ID (identifikátor sezení). Session ID hodnotu je nutné zasílat v každém požadavku na API Vykupto, kdy je vyžadována operace pouze pro přihlášeného uživatele. Problémem aplikací postavených na PhoneGapu je, že všechny COOKIES jsou po vypnutí aplikace ztraceny, neuchovávají se. Nejedná se však o chybu, PhoneGap byl tímto způsobem vytvořen. Po vypnutí aplikace a jejím zpětném zapnutí bude tedy uživatel odhlášen. Aby se uživatel nemusel po každém spuštění znovu přihlašovat, tedy vyplňovat přihlašovací jméno a heslo, je nutno tento problém vyřešit. Vhodný způsob, jak to vyřešit je uložení přihlašovacích údajů uživatele (po úspěšném přihlášení) do HTML5 Local Storage. Po spuštění aplikace se potom automaticky zavolá přihlašovací požadavek do Vykupto API a uživatel bude v aplikaci přihlášen. Pokud se uživatel v aplikaci odhlásí, musí se také automaticky smazat přihlašovací údaje z Local Storage, aby po příštím spuštění aplikace neproběhlo opětovné přihlášení. [60]
7.11 PhoneGap pluginy PhoneGap je modulární framework. Po stažení z internetu obsahuje jen nejnutnější funkce, aby bylo možno aplikaci zkompilovat a nainstalovat do zařízení. Pokud programátor chce přistupovat k nativním funkcím systému, musí si nejprve stáh-
Implementace
71
nout plugin na URL http://plugins.cordova.io/. Na této stránce je možno si zobrazit všechny pluginy, které jsou pro PhoneGap dostupné. K březnu 2014 jich bylo na této stránce dostupných 208. Každý plugin obsahuje vlastní dokumentaci, jak jej použít. Například plugin org.apache.cordova.network-information zjišťuje stav internetového připojení. Tyto informace jsou dostupné v globálním objektu navigator.connection, které může nabývat různých hodnot podle typu připojení. Instalace takového pluginu se provádí přes příkazovou řádku, ve které je jako aktuální adresář nastavena požadovaná PhoneGap aplikace. Příkaz phonegap local plugin add https://git-wipus.apache.org/repos/asf/cordova-plugin-networkinformation.git nainstaluje plugin a je ihned připraven k použití. Mezi nejpoužívanější pluginy patří následující: Plugin zobrazující informace o mobilním zařízení Plugin pro práci se soubory Plugin pro zobrazování nativních dialogů Plugin pro práci s fotoaparátem Plugin pro práci s geolokací Plugin pro přístup k vibracím zařížení Plugin pro přístup ke kontaktům uživatele Informace o baterii, orientaci zařízení a další.
7.12 Změny provedené v API Vykupto Během implementace aplikace byly objeveny nedostatky ve funkcích v API Vykupto. Tyto nedostatky nebyly dříve identifikovány, jelikož stávající Vykupto mobilní aplikace zobrazuje ve všech sekcích pouze velice obecné údaje. Například u voucherů, které uživatel zakoupil je vidět pouze název a údaj, zda byl kupón využit nebo ne. Tyto nedostatky byly po identifikaci řádně sepsány a odeslány zaměstnancům Vykupto, kteří v API provedli požadované změny a funkce upravili. Seznam změn je následující: Byla přidána nová funkce comment_list, která na základě identifikátoru slevy vrátí všechny komentáře v diskuzi slevy. Nová funkce pro vyhledávání slev dealSearch. Upravena funkce purchase_list, která nově v datech vrací číslo objednávky, identifikační kód slevy, unikátní kód voucheru a platnost voucheru. Upravena funkce pro detail slevy (deal_detail). U skupin a podskupin slev nebyly uváděny původní ceny před slevou, což znemožňovalo zobrazovat údaj o slevě u záznamů, které obsahovaly skupiny nebo podskupiny. Nyní je původní cena uvedena korektně u všech skupin a podskupin. V detailech slevy je nově uveden údaj o maximálním počtu voucherů, které uživatel může zakoupit. Například různé dovolené a zájezdy bývají limitovány
72
Implementace
na 1 nebo 2 kupóny, ovšem oblečení mívá možnost zakoupit až 10 voucherů najednou.
7.13 Testovací server Vykupto Vykupto poskytuje pro vývojové a testovací účely speciální testovací server. Díky testovacímu serveru je možno vytvářet libovolné objednávky v aplikaci, které nebude nutné zaplatit. Stejně tak lze testovat například registrace uživatele. Databáze testovacího serveru Vykupto je každou noc smazána a jsou do ní nahrány upravené údaje z produkční databáze. Upraveny jsou zejména citlivé informace, jako například údaje o zákaznících, údaje ve fakturách a podobně.
7.14 Kompilace aplikace V následujících kapitolách budou popsány dvě možnosti, jak mobilní aplikaci kompilovat. Lze to lokálně i přes cloudové služby, díky kterým není nutno mít v počítači nainstalovány nástroje pro kompilaci aplikace. 7.14.1
Kompilace přes Phonegap Build
PhoneGap Build je cloudová služba pro kompilaci a komprimaci aplikací napsaných pro PhoneGap. Dostupná je na adrese https://build.phonegap.com/ Stačí si vytvořit účet a vytvořit projekt, do kterého se poté budou zasílat zdrojové soubory ke kompilaci v jednom zip archivu. Po úspěšné kompilaci si může uživatel stáhnout instalační balíčky pro jednotlivé platformy. Může se stát, že některé platformy se nezkompilují úspěšně a kompilace skončí s nějakou chybou. Tuto chybu PhoneGap uživateli vypíše. Přes Phonegap Build je možno kompilovat do následujících platforem: Android BlackBerry, verze starší než 10 iOS Windows Phone 7 WebOS Symbian 7.14.2
Lokální kompilace
PhoneGap aplikaci je možno také kompilovat lokálně pomocí příkazové řádky. Pro kompilaci do dané platformy je nutné mít stažené její kompletní SDK. Lokálně lze ve PhoneGapu kompilovat do více platforem než přes Phonegap Build. Android BlackBerry, verze starší než 10 BlackBerry verze 10 iOS
Implementace
73
Windows Phone 7 Windows Phone 8 Windows 8 Tizen
Lokálně nelze kompilovat pouze pro WebOS a Symbian. Kompilace se provádí skrze příkazovou řádku. Pro kompilaci aplikace je nutné mít nastaven aktuální adresář na root (kořenový) adresář aplikace. Po zadání příkazu phonegap build android se provede kompilace. Aplikace je poté uložena v adresáři aplikace v adresáři platforms/android. Během kompilace jsou do příkazové řádky vypisovány vysokoúrovňové informace. Pro výpis i nízkoúrovňových informací slouží přepínač -V (verbose, upovídaný).
7.15 Certifikace aplikace Aby bylo možno vystavit zkompilovanou aplikaci do obchodu s aplikacemi, je nutno, aby měla certifikát. Certifikovat aplikace umí PhoneGap Build, je však nutno provést kompilaci skrze webové rozhraní. Certifikát je potřeba napřed vytvořit. Jako příklad bude uvedeno zavedení certifikátu pro platformu Android. V případě iOS jsou kroky podobné a pro obě platformy se nacházejí podrobné návody v dokumentaci PhoneGapu. Certifikát se vytvoří nástrojem keytool pomocí příkazu keytool -genkey -v -keystore vykupto.keystore -alias vykupto -keyalg RSA -keysize 2048 -validity 10000. Keytool si vyžádá od uživatele několik různých údajů identifikující společnost, hesla a po jejich zadání vytvoří soubor s názvem vykupto.keystore. Následně je nutno v nastavení uživatelského profilu na stránce PhoneGap Build přidat tento certifikát do sekce Signing Keys pro platformu Android. Posledním krokem je v sekci kompilace u platformy Android vybrat z nabídky certifikát, odemknout ho stejným heslem, kterým se certifikát vytvořil a zmáčknout tlačítko pro zkompilování aplikace. Výsledný APK soubor je korektně podepsaný certifikátem a tento soubor s aplikací je možno vystavit v obchodě s aplikacemi. [67]
7.16 Emulace Aplikace V následujících kapitolách bude popsáno, jaké jsou možnosti spuštění aplikace. Není nutno aplikaci vždy instalovat do mobilního zařízení. Lze využít také emulátoru dané mobilní platformy nebo speciálního emulátoru do desktopového webového prohlížeče Chrome s názvem Ripple. 7.16.1
Emulátor platformy
Pro spuštění emulátoru platformy je nutné mít nainstalován SDK s emulátorem, ve kterém se bude aplikace spouštět. Pro emulaci Apple iOS zařízení je nutno vlastnit
74
Implementace
počítač Apple s operačním systémem Mac OS X. Emulátor se spouští ve PhoneGapu v příkazové řádce. V ní je třeba mít aktuální adresář nastaven na root (kořenový) adresář aplikace. Po zadání příkazu phonegap run android --emulator se spustí emulátor platformy. Příkaz lze spustit i bez přepínače --emulator, avšak pokud bude připojeno k počítači nějaké mobilní zařízení, PhoneGap se pokusí nejprve spustit aplikaci v zařízení. Přepínačem --emulator se tedy explicitně nastavuje spouštění v emulátoru. 7.16.2
Spuštění na zařízení
Aplikaci lze spustit přímo v mobilním zařízení skrze příkazovou řádku. Je nutné, aby bylo mobilní zařízení připojeno k počítači skrze USB rozhraní. V příkazové řádce by měl být aktuální adresář nastaven na root (kořenový) adresář aplikace. Poté již stačí zadat příkaz phonegap install android --device,který nainstaluje aplikaci do Android zařízení. V případě, že nebyla aplikace předem zkompilována, tak nebude možno ji nainstalovat. Pro kompilaci a instalaci aplikace slouží příkaz run. Přepínač --device potlačuje spuštění emulátoru v případě, že by nebylo nalezeno fyzické zařízení připojené do USB nebo se z nějakého důvodu nepovedlo aplikaci do zařízení nainstalovat. Bez --device přepínače by se PhoneGap pokoušel spouštět emulátor zařízení. 7.16.3
Emulace v prohlížeči (Apache Ripple)
Aplikaci vytvořenou ve PhoneGapu je možno také emulovat v nástroji Apache Ripple. Ripple je prostředí pro emulaci multiplatformních webových aplikací. Byl vytvořen především pro emulaci Phonegap aplikací. Lze v něm však emulovat i aplikace napsané ve frameworku WebWorks nebo mobilní aplikace bez frameworku. Ripple je open source projekt a jeho zdrojové kódy jsou dostupné na GitHubu na adrese https://github.com/apache/incubator-ripple. [61] Ripple je možno nainstalovat jako rozšíření do prohlížeče Chrome nebo jej nainstalovat přímo do operačního systému. K instalaci v operačním systému je vyžadován (v době psaní) GNU/Linux nebo Mac OS X, Windows není podporován. Dále je potřeba mít nainstalován node.js s balíčkovacím systémem npm. Pokud je Ripple nainstalován v operačním systému, tak by dle dokumentace měl být schopen běžet v jakémkoli moderním internetovém prohlížeči. [62] Na první pohled se může zdát, že takový emulátor je zbytečný, avšak pro PhoneGap aplikace je to jediná možnost, jak ji spustit, aniž by se musel načítat emulátor mobilní platformy (Android, iOS) nebo se musela aplikace přímo spouštět v mobilním zařízení. PhoneGap aplikace spuštěná v prohlížeči nebude bez Ripple fungovat, protože PhoneGap nemá kam zasílat své požadavky na systémové API. Žádné API totiž není v prohlížeči dostupné. Tento problém řeší Ripple tím, že abstrahuje systém mobilní platformy. Je poté možno vytvářet odpovědi na požadavky, které vytváří PhoneGap mobilní aplikace.
Implementace
75
Díky tomu, že PhoneGap aplikace v Ripple funguje, je možno využít všech různých možností a nástrojů prohlížeče pro ladění aplikace, nahlížení do DOM, analyzovat rychlost JavaScriptu apod. Na obrázku je vidět spuštěný Ripple emulátor v prohlížeči. V levém sloupci se nacházejí nástroje pro změnu rozlišení emulovaného zařízení, orientaci, verzi Phonegapu a nastavení akcelerometru. Na pravé straně je panel s různými nastaveními emulátoru. Jedná se například o geolokaci, typ internetového připojení aplikace a další. Ripple má těchto nastavení více, než je vidět na obrázku 20.
Obr. 20
Vykupto aplikace spuštěná v Ripple Emulátoru
7.17 Ladění aplikace V následujících kapitolách budou popsány způsoby ladění aplikace pomocí Ripple nebo speciálního nástroje Weinre.
76
7.17.1
Implementace
Ladění přes Ripple
Ripple umožňuje používat nástroje vývojáře ve webovém prohlížeči stejně jako u klasických webových stránek. Avšak u DOM inspektoru je potřeba počítat s tím, že samotná mobilní aplikace je vložena do iframe, takže i během ladění JavaScriptového kódu je potřeba přistupovat k objektům mobilní aplikace přes iframe. U zobrazení AJAXových požadavků je také potřeba dát pozor, jelikož všechny požadavky jsou zasílány přes proxy server Ripple. Hlavičky požadavků mohou být tedy rozdílné, než programátor očekává. 7.17.2
Ladění přes Adobe Phonegap Build
Na adrese http://debug.build.phonegap.com/ se nachází aplikace pro vzdálené ladění mobilní aplikace. Je postavena na technologii Weinre (web inspector remote). Slouží pro ladění aplikace, která běží spuštěná v mobilním zařízení. Umožňuje přístup k běžným nástrojům pro vývojáře v prohlížečích. Jedná se o kompletní zobrazení DOM včetně možnosti upravovat kód, JavaScriptovou konzoli, síťové informace, časovou osu a správu zdrojů. Weinre je možno si nainstalovat i lokálně v systému a nepoužívat tak vůbec debug.build.phonegap.com. Pro ladění Vykupto aplikace byla zvolena možnost ladění přes zmíněnou adresu. Nastavení ladění je velice jednoduché. Mobilní aplikace musí kdekoli v HTML kódu obsahovat následující script značku: <script src="http://debug.build.phonegap.com/target/target-scriptmin.js#unique_code"> Důležitá je část #unique_code, kterou je potřeba nahradit jiným unikátním řetězcem. Může se jednat například o takový unikátní kód: 0d84c4b2-0b7f11e3-86e5-22000a98b3d6. Po vložení této script značky stačí již aplikaci spustit v zařízení či v emulátoru (v Ripple tato možnost nemá význam, jelikož lze využít nástroje prohlížeče). Stejný unikátní kód se poté použije u URL adresy, která spustí ladící nástroj Weinre - debug.build.phonegap.com/client/#0d84c4b20b7f-11e3-86e5-22000a98b3d6. Pokud bude aplikace spuštěna v mobilním zařízení nebo v emulátoru, objeví se možnost ladění ve weinre aplikaci, jak značí obrázek.
Implementace
Obr. 21
77
Hlavní okno Weinre nástroje
V obrázku 21 je vidět hlavní okno ladícího nástroje Weinre. Pod nadpisem Targets je vidět aktivní zařízení na IP adrese 10.46.233.101, ve kterém je spuštěná mobilní aplikace. Po kliknutí na toto zařízení je možno se přepínat do všech záložek v záhlaví stránky a analyzovat tak celou aplikaci.
78
Obr. 22
Implementace
Nástroje vývojáře ve Weinre
Spustit nástroj Weinre lze i jiným způsobem. Stačí nahrát přes Phonegap Build do aplikace nové zdrojové kódy a zatrhnout možnost Enable debugging. Po úspěšném zkompilování a spuštění aplikace je možno stisknout tlačítko Debug pro spuštění nástroje Weinre.
Implementace
Obr. 23
79
Jak spustit ladění přes Phonegap Build
7.18 Testování aplikace Zhotovený prototyp aplikace byl otestován několika uživateli, aby se zjistilo, zda prototyp uživatelského prostředí jim vyhovuje a nemají problém v něm najít, co potřebují. Lze předpokládat, že se může testováním aplikace uživateli zjistit mnoho různých poznatků, které mohou být však protichůdné nebo zcela měnící filozofii aplikace. Je potřeba dobře zvážit všechny poznatky a rozhodnout se, které jsou stěžejní a které ne během finálního dokončování aplikace. Bylo zjištěno, že aplikace by měla po spuštění uživateli oznamít, že je přítomen slide panel a jak si jej zobrazit. Zobrazení slide panelu by bylo vhodné naznačit obrázkem, který bude ukazovat provedení gesta. Uživatelé jsou již v dnešní době zvyklí na slide panely, avšak musí vědět, že se v aplikaci nachází. Vhodné by bylo uživatele upozornit pouze jednou a až tuto zprávu skryje potvrzením, nikdy se již znovu neobjeví. Po skrytí zprávy již uživatel ví, že se slide panel v aplikaci nachází. Po implementaci zobrazení této zprávy bude možno odstranit tlačítko otevírající slide panel z hlavní obrazovky aplikace. Další připomínka se týkala odhlášení. Po odhlášení by se měla uživateli ukázat zprávu oznamující, že odhlášení proběhlo úspěšně. Jelikož se jedná o jednoduchou úpravu, byla do aplikace zapracována ihned. Během testování někteří uživatelé upozorňovali na nepřehlednou strukturu kategorií a subkategorií. Toto je však připomínka, kterou musí řešit Vykupto. Tento problém byl s nimi probírán již dříve, avšak zatím žádná změna neproběhla.
80
Implementace
Tento problém se týká i samotného webu Vykupto, který je pro některé uživatele zmatený. Někdy se v subkategoriích objevují názvy hlavních kategorií. Například kategorie Domácnost obsahuje subkategorii Oblečení a móda a ta uživatele přesměruje do kategorie Oblečení. To je velice nepřehledné. V prototypu aplikace není implementována možnost vkládat komentáře u slevy, dle testování uživatelů se však jedná o žádanou funkci, ve finální verzi aplikace bude tedy zahrnuta. Malá úprava byla provedena v registračním formuláři. Výchozí hodnota souhlasu s podmínkami užití by měla být nastavena na hodnotu Ne, přičemž nyní byla výchozí hodnota Ano. Tato změna byla zapracována v aplikaci ihned po zjištění. Malou úpravou také projde slide panel. Ten má nyní nastavenou pozici jako absolutní. To znamená, že během vertikálního posunu se posunuje na displeji i slide panel. Slide panel by však měl mít pozici fixní, aby byl vždy vidět na displeji celý bez ohledu na vertikální posun stránky. Uživatelé však neměli žádný problém projít celým objednávkovým procesem, všechny kroky jim připadaly logické a přehledné. Slide panel se uživatelům taktéž líbil. Jsou v něm nejdůležitější položky, ke kterým se dostanou ve kterékoli stránce v aplikaci.
Závěr
81
8 Závěr Na základě návrhu řešení byl implementován prototyp mobilní multiplatformní aplikace. Aplikaci lze do mobilního zařízení po zkompilování nainstalovat, bez problému spustit a používat. Stále se však nejedná o aplikaci schopnou produkčního nasazení. Během implementace se objevily některé problémy, které je nutno vyřešit. Aplikace není jednoduchá a potřebuje hodně pracovat s DOM a vytvářet různé stránky. To má bohužel negativní dopad na výkon aplikace. Je pravděpodobné, že právě kvůli komplexnosti DOM se někdy stává, že během animací přechodu stránek „problikávají“ do animace jiné vygenerované stránky v DOM. To bohužel nevypadá dobře a kazí to uživatelům dobrý dojem z aplikace. Jedná se tedy o problém, který je nutno před produkčním nasazením vyřešit. Tento problém může pravděpodobně řešit nová verze jQuery Mobile 1.4, která vyšla během dokončování prototypu aplikace. U této verze vývojáři slibují velké navýšení výkonu díky značnému omezení práce s DOM. Tato verze bude tedy vyzkoušena v mobilní aplikaci, jak se bude chovat. Bohužel před dokončením prototypu tato, na první pohled rychlá, změna nešla provést, jelikož se v nové verzi 1.4 nachází velký počet zpětně nekompatibilních změn. I to ale značí, že se jQuery Mobile hodně změnilo od verze 1.3 a to může velice pozitivně ovlivnit výkon aplikace včetně problematických animací. Výkon také mohlo negativně ovlivnit použití knihovny Handlebars. Několika výkonovými testy však bylo zjištěno, že Handlebars výkon aplikace neovlivňují. U jedné konkrétní testované slevy bylo zjištěno, že kompletní načtení a zobrazení slevy trvá 960 ms. Jedná se o čas měřený od kliknutí na název slevy v seznamu do úplného zobrazení detailu slevy. Z naměřených 960 ms generovalo Handlebars HTML kód pro zobrazení slevy 60 ms. Progressive enhancement prováděný jQuery Mobile trval 250 ms, což je již nezanedbatelná hodnota. V případě složitějších HTML struktur některých slev zabral progressive enhancement až 500 ms. Zbytek měřeného času je přechodová animace a načítání dat z API. Na základě těchto měření bude možno během implementace jQuery Mobile 1.4 exaktně určit zlepšení ve výkonu aplikace. Další problém, který bude ještě nutno vyřešit je s PhoneGapem. Ten má po inicializaci vyvolat událost, která značí, že je vše připraveno a aplikace se může spustit. Avšak během testování se několikrát stalo, že PhonegGap tuto událost nevyvolal, aplikace se tedy nespustila a na displeji zůstala pouze bílá obrazovka. Tento problém je taktéž možno zkusit vyřešit pouhým nahráním nové verze. Může se však stát, že problém bude přetrvávat a poté bude nutné analyzovat samotný kód PhoneGapu a zjistit, proč se událost nevyvolává. Aplikaci je tedy nutno věnovat ještě nějaký čas, než se dostane do produkčního stavu a budou ji moci začít využívat všichni uživatelé.
82
Zdroje
9 Zdroje 1.
BEAL, Vangie, Forrest STROUD a Paul SHREAD. API - application program interface. Webopedia [online]. 2013 [cit. 2014-05-04]. Dostupné z: http://www.webopedia.com/TERM/A/API.html
COWART, Jim. When to Go Native, Mobile Web or Cross-Platform/Hybrid. [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://tech.pro/blog/1355/when-to-go-native-mobile-webor-cross-platformhybrid
11.
APPBUILDER. What is a Hybrid Mobile App?. [online]. 2012 [cit. 2014-05-05]. Dostupné z: http://blogs.telerik.com/appbuilder/posts/1206-14/what-is-a-hybrid-mobile-app-
SONMEZ, John. Which Cross Platform Mobile Development Platform Should You Choose. [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://simpleprogrammer.com/2013/07/01/cross-platformmobile-development/
16.
DILLARD, Sophina. Top Cross-Platform Mobile App Development Tools and Frameworks. [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://mobileappstuff.blogspot.cz/2013/11/top-crossplatform-mobile-app.html
17.
COWART, Jim. Pros and Cons of the Top 5 Cross-Platform Tools. [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://www.developereconomics.com/pros-cons-top-5cross-platform-tools/
18.
SYNODINOS, Dio. What are the Most Important and Mature Cross Platform Mobile Tools?. [online]. 2012 [cit. 2014-05-05]. Dostupné z: http://www.infoq.com/research/cross-platform-mobiletools
19.
FALK, Markus a Sascha BÄDE. Mobile Frameworks Comparison Chart. [online]. [cit. 2014-05-05]. Dostupné z: http://mobile-frameworkscomparison-chart.com/
20.
ROCHELEAU, Jake. Web Design: 20 Hottest Trends To Watch Out For In 2014. [online]. 2014 [cit. 2014-05-05]. Dostupné z: http://www.hongkiat.com/blog/web-design-trends-2014/
KANEDA, David. JQT (formerly jQTouch) Zepto/jQuery plugin for mobile web development [online]. [cit. 2014-05-05]. Dostupné z: http://jqtjs.com/
84
Zdroje
26.
GAIĆ, Dragan. Switching from jQuery Mobile to AppFramework. [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://www.gajotres.net/switchingfrom-a-jquery-mobile-to-appframework/
27.
PERKINS, Rimian. Difference between jQTouch and jQuery mobile. [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://stackoverflow.com/questions/3624660/differencebetween-jqtouch-and-jquery-mobile
28.
SENCHA INC. Sencha Touch. [online]. [cit. 2014-05-05]. Dostupné z: http://www.sencha.com/products/touch/
29.
JUHOS, Miroslav. Ext JS – javascriptový framework pro tvorbu RIA. [online]. 2009 [cit. 2014-05-05]. Dostupné z: http://www.zdrojak.cz/clanky/ext-js-javascriptovyframework-pro-tvorbu-ria/
30.
CATLIN, Hampton, Nathan WEIZENBAUM a Chris EPPSTEIN. Sass: CSS with superpowers [online]. [cit. 2014-05-05]. Dostupné z: http://sasslang.com/
31.
BOONSTRA, Lee. Getting Started with Sencha Touch 2: Build a Weather Utility App (Part 3). [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://www.sencha.com/blog/getting-started-with-senchatouch-2-build-a-weather-utility-app-part-3/
32.
HUJER, Martin. Cordova a Sencha Touch aneb mobilní aplikace pomocí webových technologií. [online]. 2014 [cit. 2014-05-05]. Dostupné z: http://www.zdrojak.cz/clanky/cordova-sencha-touchmobilni-aplikace/
33.
SENCHA INC. Sencha Architect: Build for Mobile and Desktop. [online]. [cit. 2014-05-05]. Dostupné z: http://www.sencha.com/products/architect/
34.
APPCELERATOR. Titanium Mobile Development Environment. [online]. [cit. 2014-05-05]. Dostupné z: http://www.appcelerator.com/titanium/
35.
DALLERA, Andrea. Why you should stay away from Appcelerator’s Titanium. [online]. roč. 2011 [cit. 2014-05-05]. Dostupné z: http://usingimho.wordpress.com/2011/06/14/why-youshould-stay-away-from-appcelerators-titanium/
36.
POWELL, Jason. What Titanium Appcelerator REALLY is and How it Works!. [online]. roč. 2012 [cit. 2014-05-05]. Dostupné z: http://forumone.com/blogs/post/what-titaniumappcelerator-really-and-how-it-works
37.
TRAEG, Peter. Four Ways To Build A Mobile Application, Part 4: Appcelerator Titanium. [online]. 2014 [cit. 2014-05-05]. Dostupné z: http://mobile.smashingmagazine.com/2014/03/10/4-waysbuild-mobile-application-part4-appcelerator-titanium/
Zdroje
85
38.
SAGGESE, Luigi. Xamarin 2.0 vs Appcelerator Titanium vs PhoneGap. [online]. roč. 2013 [cit. 2014-05-05]. Dostupné z: http://stackoverflow.com/questions/17249500/xamarin-20-vs-appcelerator-titanium-vs-phonegap
XAMARIN INC. Xamarin: Create Native iOS, Android, Mac and Windows apps in C# [online]. [cit. 2014-05-05]. Dostupné z: https://xamarin.com/
41.
ADOBE SYSTEMS INC. PhoneGap: Easily create apps using the web technologies you know and love: HTML, CSS, and JavaScript [online]. [cit. 2014-05-05]. Dostupné z: http://phonegap.com/
BULAT, Alex. Designer’s Choice: Chrome Extensions to Give a Run for Your Browser. [online]. 2013 [cit. 2014-05-05]. Dostupné z: http://blog.templatemonster.com/2012/10/24/chromeextensions-web-design/
63.
LE HÉGARET, Philippe. Document Object Model (DOM). [online]. 2005 [cit. 2014-05-05]. Dostupné z: http://www.w3.org/DOM/Overview
Ukázka dat pro detail slevy, které odesílá API Vykupto, formát JSON
89
A Ukázka dat pro detail slevy, které odesílá API Vykupto, formát JSON { "data" : { "variants" : [ { "price_original" : "6 050 Kč", "active" : true, "id" : 247701, "price" : "3 933 Kč", "price_raw" : 3933, "price_original_raw" : 6050, "purchased" : 0, "max_amount" : "5", "vclub_credit" : 642, "name" : "Pobyt pro dvě osoby na 3 noci" } ], "status" : "SELLING", "price_original" : "6 050 Kč", "url" : "http://www.vykupto.cz/dovolena/31611-jiznicechy-apartman-u-rybnika-na-4-dny", "overview" : "Krátký popis slevy v HTML", "image" : "http://img.vykupto.cz/cw/31611/vykupto_ratmirak_hlavni.jpg ", "discount" : 35, "shippings" : null, "valid_to" : 1406671200, "price_discount" : "2 117 Kč", "id" : 31611, "voucher_use" : "HTML text popisující použití voucheru", "purchased" : "0", "end" : "2014-03-27 23:59:00", "invoice_address_required" : false, "price_raw" : 3933, "text" : "Penzion Ratmírák s bazénem a snídaní až na pokoj! Jižní Čechy a Českou Kanadu projedete na kole, půjčení šlapadla a privátní sauna v ceně", "valid_from" : 1395356400, "price" : "3 933 Kč",
90
Ukázka dat pro detail slevy, které odesílá API Vykupto, formát JSON
"headline" : "Jižní Čechy – apartmán u rybníka na 4 dny", "how_to_use" : "Text popisující jak použít slevu v HTML", "delivery_address_required" : false, "description" : "HTML text popisující slevu" }, "err" : 0 }
Základní HTML struktura jQuery Mobile aplikace s jednou stránkou
91
B Základní HTML struktura jQuery Mobile aplikace s jednou stránkou Vzorová aplikace <meta name="viewport" content="width=device-width, initialscale=1"> <script src="http://code.jquery.com/jquery1.3.0.min.js"> <script src="http://code.jquery.com/mobile/[version]/jquery.mobile1.3.0.min.js">
Záhlaví stránky
Obsah stránky
Zápatí stránky
92
C Navigační schéma aplikace
Navigační schéma aplikace
Přiložené CD
D Přiložené CD Přiložené CD obsahuje: Zdrojové kódy aplikace o CoffeeScript o Transpilovaný JavaScript o HTML o Soubory kaskádových stylů CSS o Soubory PhoneGapu nutné ke kompilaci Navigační schéma ve velkém rozlišení Zkompilovaná aplikace s certifikátem
