MASARYKOVA UNIVERZITA Fakulta informatiky
DIPLOMOVÁ PRÁCE Vývoj multiplatformních mobilních aplikací pro prodej zboží
Brno, 2014
Miroslav Kaděra
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Miroslav Kaděra
Poděkování Na tomto místě bych rád poděkoval vedoucímu mé diplomové práce doc. RNDr. Vlastislavu Dohnalovi Ph.D. za to, že svým vstřícným přístupem, cennými radami a připomínkami významně přispěl k dokončení této práce.
Abstrakt Předmětem diplomové práce je analýza a zhodnocení možností pro vývoj mobilních aplikací určených pro prodej zboží především s ohledem na autentizační mechanismus a možnosti realizovat on-line platby. Práce se věnuje
požadavkům
a
charakteristikám
mobilních
aplikací,
analýze
dostupných vývojových rámců a především platformě PhoneGap. Jsou popsány základní principy a na praktické aplikaci je demonstrováno, jak lze pomocí této platformy implementovat požadovanou funkcionalitu.
Abstract The goal of the submitted thesis is to analyze and assess possibilities of developing
mobile
applications
for
selling
goods,
accentuating
authentication mechanism and on-line payments realization. The thesis concentrates on requirements and characteristics of mobile applications, analysis of available development frameworks. The main part discusses the PhoneGap platform and its basic principles. A real implemented application then demonstrates how this platform could be used for implementing required functionality.
Klíčová slova Mobilní aplikace, multiplatformní aplikace, vývoj aplikací, on-line platby, mobilní platby, PhoneGap, Cordova
Keywords Mobile application, multiplatform application, application development, online payments, mobile payments, PhoneGap, Cordova
Obsah 1
Úvod...................................................................................................................... 9
2
Smartphony a jiná chytrá zařízení .................................................................. 11
3
4
5
2.1
Chytré zařízení ........................................................................................... 11
2.2
Mobilní platforma ...................................................................................... 12
2.3
Nejrozšířenější platformy .......................................................................... 13
2.3.1
Platforma Android .............................................................................. 14
2.3.2
Platforma iOS ....................................................................................... 15
2.3.3
Platforma Windows Phone ................................................................ 17
Základní požadavky a charakteristiky aplikací pro chytrá zařízení ......... 19 3.1
Požadavky na uživatelské rozhraní aplikace ......................................... 19
3.2
Další požadavky na aplikaci ..................................................................... 20
3.3
Charakteristiky s ohledem na náklady ................................................... 21
3.4
Základní typy aplikací ............................................................................... 23
3.4.1
Graficky náročné aplikace ................................................................. 23
3.4.2
Aplikace náročné na konektivitu ...................................................... 23
3.4.3
Aplikace náročné na výpočetní výkon............................................. 25
3.4.4
Aplikace náročné na úložný prostor ................................................ 26
3.4.5
Aplikace využívající pokročilé senzory ........................................... 27
3.4.6
Aplikace s vysokou mírou integrace s operačním systémem ...... 28
Komerční aplikace pro prodej zboží a služeb ............................................... 31 4.1
Specifika ....................................................................................................... 31
4.2
Požadovaná funkcionalita ......................................................................... 32
4.2.1
Notifikační funkce ............................................................................... 33
4.2.2
Autentizace .......................................................................................... 33
4.2.3
Zpracování platby ............................................................................... 34
Možnosti implementace mobilních aplikací ................................................. 35 5.1
Nativní aplikace .......................................................................................... 35
5.2
Webová aplikace otevíraná v prohlížeči ................................................. 36
5.3
Multiplatformní nativní aplikace ............................................................. 39
5.3.1
Multiplatformní běhové prostředí (runtime) .................................. 39
5.3.2
Překladače zdrojového kódu ............................................................. 40
5.3.3
Nástroje obalující standardizovaný kód .......................................... 40
5.4
Shrnutí.......................................................................................................... 41
6
Volba způsobu vývoje a vývojového rámce ................................................. 43
7
Platforma Adobe PhoneGap............................................................................ 44 7.1
PhoneGap Build .......................................................................................... 44
8
Specifikace ukázkové aplikace ........................................................................ 46
9
Implementace ukázkové aplikace .................................................................. 47 9.1
Prerekvizity ................................................................................................. 47
9.2
Principy platformy PhoneGap a základní struktura projektu ............. 48
9.3
Založení projektu ....................................................................................... 49
9.4
Přístup k lokálnímu úložišti ..................................................................... 50
9.5
Implementace autentizačního mechanismu ........................................... 51
9.6
Implementace notifikací ............................................................................ 53
9.7
Použití geolokačních služeb...................................................................... 53
9.8
Implementace on-line plateb .................................................................... 54
9.9
Kompilace, ladění a testování................................................................... 55
9.10
Ukázková aplikace.................................................................................. 57
9.11
Výhody a nevýhody platformy PhoneGap ......................................... 61
10 Závěr ................................................................................................................... 62 11 Seznam použitých zkratek............................................................................... 64 11.1
Označení firem ........................................................................................ 64
11.2
Použité zkratky a zkrácená označení ................................................... 64
12 Seznam použitých zdrojů ................................................................................ 67
1 Úvod Tématem diplomové práce je vývoj multiplatformních mobilních aplikací pro prodej zboží. Prodej prostřednictvím internetu nabyl v průběhu let natolik na významu, že se stal celosvětově hlavním motorem rozvoje a inovace v oblasti prodeje. Jeho podíl na objemu trhu je obrovský a neustále narůstá. Vzhledem k postupujícímu rozšiřování pokrytí světa internetem a vzhledem pokroku v oblasti technologií lze s jistotou prognózovat další zvyšování významu. Prodej prostřednictvím internetu představuje nejen rozsáhlý, ale i velmi dynamický obor. V průběhu vývoje elektronického obchodování byly vytvořeny
milióny
webových
obchodních
systémů.
S rozvojem
a zdokonalováním používané výpočetní techniky a především s rozvojem komunikačních možností se výrazně měnily i způsoby obchodování a vyvíjely se nové prodejní metody. V posledních letech se znatelně projevuje nárůst v oblasti využití mobilních zařízení jako mobilních telefonů, tabletů apod. Právě mobilní zařízení přinášejí oběma stranám obchodu zcela nové, dříve netušené možnosti a výhody – stírají omezení v místě a čase obchodování,
přinášejí
informace
z podrobné
identifikace
zákazníka,
s možnostmi detailního sledování zájmů, zvyků a potřeb zákazníků atd. Diplomová práce se věnuje možnostem tvorby aplikací sloužících k podpoře prodeje zboží či služeb pomocí mobilních zařízení. Tato oblast se vyznačuje velmi rychlým vývojem. To má za následek existenci mnoha vývojových nástrojů a platforem a především značný nedostatek literatury. Překotný vývoj vede také k velmi rychlému zastarávání veškerých dostupných materiálů. Odborná literatura či články staré byť i jeden rok mohou být při tomto tempu vývoje zcela nepoužitelné. Cílem práce je především
provést analýzu dostupných vývojových rámců,
9
zhodnotit tyto vývojové rámce z pohledu tvorby aplikace pro různé mobilní platformy,
zhodnotit možnosti realizace jednotného autentizačního systému a online plateb,
implementovat jednoduchou aplikaci demonstrující výše uvedenou funkcionalitu.
Následující kapitola popisuje základní charakteristiky tzv. chytrých mobilních zařízení a nejčastější platformy, se kterými se setkáváme a kterým se v této práci
budeme
věnovat.
V další
části
jsou
analyzovány
požadavky
a charakteristiky různých typů aplikací pro mobilní zařízení a specifika komerčních aplikací určených k prodeji zboží či služeb. Další části poté zkoumají možnosti implementace mobilních aplikací. Jednotlivé přístupy jsou zhodnoceny z hlediska jejich vhodnosti pro aplikace diskutované v této práci. Kapitola 7 poté popisuje charakteristiky vybrané platformy PhoneGap a služby PhoneGap Build. Kapitola 9 se již věnuje konkrétní implementaci funkcionality požadované zadáním této práce pomocí platformy PhoneGap. Jsou popsány nástroje, se kterými je potřeba pracovat, způsoby vývoje a postupy implementace základních funkcí potřebných pro aplikaci určenou pro prodej zboží. V závěrečných částech práce jsou zhodnoceny výhody a nevýhody zvolené platformy.
10
2 Smartphony a jiná chytrá zařízení V této kapitole se pokusíme definovat některé základní pojmy a stručně popsat zařízení a aplikace, které jsou předmětem této práce. V krátkosti charakterizujeme tzv. chytré telefony či chytrá zařízení a popíšeme nejrozšířenější platformy, se kterými se v této oblasti setkáváme.
2.1 Chytré zařízení Tato práce se zabývá vývojem mobilních aplikací. Ty jsou provozovány na tzv. „chytrých zařízeních“. Do této kategorie spadají především tzv. chytré telefony (často nazývány anglickým termínem smartphone). Definici chytrého telefonu můžeme nalézt např. v literatuře [3]: „Smartphone (v českém překladu chytrý telefon) je mobilní telefon, který využívá pokročilý operační systém a aplikační rozhraní, jež umožní instalaci nebo úpravy programů. Takovými operačními systémy jsou například: iOS, Android, Windows Phone, Firefox OS, Symbian OS, BlackBerry OS, PalmOS anebo Tizen.“, zdroj [3] V dnešní době se uvedené operační systémy rozšiřují i mimo oblast mobilních telefonů. Setkáváme se s nimi především u tabletů, ale také u chytrých televizí (Smart-TV), chytrých hodinek (s určitou omezenou funkčností), brýlí a další elektroniky. Pro účely této práce můžeme taková zařízení souhrnně označovat termínem „chytrá zařízení“, přičemž přívlastek „chytré“ zde bude značit, že zařízení je vybaveno operačním systémem umožňujícím instalaci aplikací. Existuje
pouze
několik
rozšířených
platforem
(operačních
systémů
a základního hardware), pro které jednotliví výrobci vyrábějí svá zařízení, která se v podstatných technických detailech příliš neliší Lze předpokládat, že chytrá zařízení se budou dále rozšiřovat a jejich rozvoj bude probíhat velmi rychlým tempem. I proto jsou pokusy o členění těchto zařízení do předem jasně definovaných kategorií velmi obtížné a většinou nepřinášejí příliš užitku. Jako příklad zde poslouží nejasně definovaná 11
hranice mezi telefonem a tabletem. Nelze jednoznačně říci, zda tablet vybavený modulem pro telefonování je už telefonem apod. V rámci této práce se věnujeme především chytrým telefonům. Vzhledem k tomu, že v současné době je trendem sjednocovat operační systémy, které na chytrých zařízeních běží, mohou být závěry této práce stejně dobře platné i pro tablety či jakákoliv jiná podobná zařízení.
2.2 Mobilní platforma Rysem charakterizujícím chytré zařízení je vždy jeho operační systém. Tyto operační systémy jsou značně specifické a úzce spjaté s hardwarem. Je zavedenou praxí výrobců, že jedno zařízení je prodáváno výhradně s jedním typem operačního systému. Můžeme tedy chytrá zařízení dle operačních systémů dělit na takřka disjunktní množiny. Mimo hardware a operační systém jsou z hlediska této práce důležité i některé další atributy:
vývojové prostředí a nástroje pro vývoj, ladění a testování aplikací,
prostředí pro nákup a instalaci aplikací,
podpora integrace s dalšími systémy (e-mailové, kancelářské, ...),
uživatelská a vývojářská komunita.
Kombinaci operačního systému, hardwaru, který jej podporuje a všech výše uvedených atributů budeme pro účely této práce považovat za „platformu“ (ačkoli přesná definice tohoto termínu by se z čistě technického hlediska mohla poněkud lišit, pro naši práci to nemá zásadního významu). Protože vývoj a podpora těchto mobilních platforem je finančně a kapacitně velmi náročná, masově se jich na trhu rozšířilo jen několik a ostatní zůstaly silně minoritními produkty. V následující kapitole si popíšeme několik platforem, které jsou suverénně nejrozšířenější. Vycházet budeme z průzkumů podílu těchto platforem na trhu mobilních zařízení.
12
2.3 Nejrozšířenější platformy Jak již bylo zmíněno v předchozích kapitolách, na trhu je masově rozšířeno jen několik málo mobilních platforem. To můžeme ilustrovat i následujícím obrázkem, který znázorňuje statistiku rozšířenosti mobilních operačních systémů za poslední tři měsíce1:
Obr. 1: Tržní podíl jednotlivých mobilních platforem Zdroj: [9] Výběr platforem, kterými jsme se v práci zabývali, jsme provedli především podle míry rozšíření (z uvedené statistiky). Zajímají nás jen platformy, které jsou dále rozvíjené a které splňují naši definici „chytrého zařízení“ resp. operačního systému pro mobilní zařízení. To z výše uvedené statistiky vyřazuje položky „Series 40“, „Symbian OS“ a „Samsung“. Tím docházíme k závěru, že suverénně nejrozšířenější jsou platformy Android a iOS, s velkým náskokem před operačním systémem BlackBerry OS a Windows Phone. Drtivá většina zařízení s BlackBerry OS však využívá operační systém
Je použita statistika StatCounter GlobalStats. Ta dle zdroje [10] vychází z počtu stránek zobrazených v prohlížečích jednotlivých mobilních platforem. Více informací je možné nalézt také ve zdroji [11]. 1
13
verze 7. Jeho vývoj byl ukončen a společnost BlackBerry nyní prodává a vyvíjí nový, kompletně přepracovaný systém BlackBerry 10. Ten má kompletně přepracovanou architekturu, bez zpětné kompatibility. V současné době je však v porovnání s předchozími, nyní již nevyvíjenými, verzemi rozšířen jen zanedbatelně. Dle zdroje [12] systém BlackBerry 10 umožňuje spouštění Android aplikací, proto se tomuto systému samostatně v této práci nebudeme věnovat. V této kapitole se tedy pokusíme stručně popsat tři nejrozšířenější platformy chytrých mobilních zařízení, které budeme pro zjednodušení označovat jménem operačního systému:
iOS (zařízení iPhone a iPad),
Android,
Windows Phone.
Pro každou z nich stručně popíšeme principy a historii platformy, možnosti vývoje aplikací a možnosti publikace aplikací do oficiálních distribučních sítí. 2.3.1 Platforma Android 2.3.1.1 Obecně o platformě Operační systém Android, v současné době zastřešován společností Google, je postaven na linuxovém jádře. Je určen pro různé typy zařízení – počínaje chytrými hodinkami, přes množství mobilních telefonů a tabletů až po netbooky či specializované notebooky. Můžeme jej nalézt i v některých exotických specializovaných zařízeních, jako např. brýlích, fotoaparátech apod. Jedná se o otevřenou platformu distribuovanou pod licencí Apache/MIT. Zdrojové kódy byly dány k dispozici, a to od nízkoúrovňových linuxových modulů, přes nativní knihovny až po vysokoúrovňové aplikační rámce. Tato otevřenost umožňuje výrobcům mobilních zařízení si systém do značné míry upravit (a je třeba poznamenat, že této možnosti výrobci v hojné míře využívají).
14
Operační systém Android je licencován bezplatně a nejsou aplikovány žádné oficiální požadavky na hardware, se kterým je distribuován. Pro výrobce je to velká komerční výhoda, což je také jedním z důvodů, proč se tato platforma stává v posledních letech velmi populární. 2.3.1.2 Historie Za vývojem tohoto operačního systému stála od roku 2003 společnost Android Inc. V roce 2005 byla tato společnost převzata společností Google, která se o vývoj Androidu stará dodnes. První verze byla uveřejněna v roce 2008. 2.3.1.3 Vývoj aplikací Primárním jazykem pro vývoj aplikací pro Android je Java. Vývojáři mají k dispozici Android SDK, které poskytuje prakticky veškeré prostředky potřebné pro vývoj. Jmenovitě se jedná především o
knihovny a skripty,
emulátor,
ladící nástroje,
dokumentaci,
vzorové zdrojové kódy a návody.
2.3.1.4 Publikace aplikací K distribuci aplikací slouží oficiální prodejní místo – Google Play, které je integrováno přímo do operačního systému. Pro publikaci aplikací na Google Play je zapotřebí placený vývojářský účet. Je však třeba poznamenat, že v zařízení s operačním systémem Android je většinou možné povolit i instalaci nepodepsaných aplikací a instalovat aplikace prostým stažením aplikačního souboru. 2.3.2 Platforma iOS 2.3.2.1 Obecně o platformě Operační systém iOS je proprietárním systémem vyvíjeným a distribuovaným společností Apple. Systém byl původně určen pro iPhone a iPod Touch, později byl použit i v zařízeních iPad a Apple TV. Jedná se o unixový 15
operační systém. Na rozdíl od většiny jiných systémů není licencován pro zařízení jiných výrobců. 2.3.2.2 Historie První verze operačního systému iOS byla uvedena na trh v roce 2007. Původně neumožňovala běh aplikací třetích stran. To se však na nátlak uživatelů v další verzi vydané v roce 2008 změnilo. V současné době je k dispozici sedmá verze. 2.3.2.3 Vývoj aplikací Primárním jazykem pro vývoj aplikací pro iOS je Objective-C. Preferovaným vývojovým prostředím je Xcode, přičemž pro běh emulátoru je zapotřebí počítač s operačním systémem OS X. Operační systém iOS je založen na unixovém jádře a skládá se ze čtyř hlavních vrstev:
Jádro
operačního
systému
–
obsahuje
nízkoúrovňové
funkce,
pro vývojáře je nepřístupné.
Vrstva služeb poskytovaných jádrem – zpřístupňuje základní systémové služby (např. úložiště iCloud, podporu XML, databázi SQLite, lokalizační služby apod.).
Vrstva podpory médií – poskytuje přístup k technologiím pro práci s grafikou, zvukem a videem (vykreslování vektorové grafiky, animace, vykreslování písma, ...).
Vrstva
Cocoa
Touch
–
obsahuje
vysokoúrovňové
nástroje
pro uživatelské aplikace (funkce pro notifikace, multitasking, ...). 2.3.2.4 Publikace aplikací K distribuci aplikací slouží výhradně oficiální Apple App Store. V současné době obsahuje řádově stovky tisíc aplikací. Pro publikaci aplikace do App Store je zapotřebí placený vývojářský účet a certifikát k podpisu aplikace. Ta musí před zpřístupněním projít několikadenním schvalovacím procesem.
16
2.3.3 Platforma Windows Phone 2.3.3.1 Obecně o platformě Windows Phone je proprietární operační systém, za jehož vývojem stojí společnost Microsoft. Je licencován pro zařízení různých výrobců, přičemž v současné době je většina zařízení s Windows Phone prodávána společností Nokia. Windows Phone definuje striktní hardwarové požadavky, které musí zařízení splnit, aby bylo pro tento operační systém použitelné (jmenujme např: kapacitní dotykový displej, minimálně dvoujádrový procesor, alespoň 512MB RAM, některé povinné senzory, unifikovaná hardwarová tlačítka, ...). Oproti např. Androidu se jedná o uzavřený systém, přičemž integrace aplikací je možná jen prostřednictvím oficiální poskytovaného API. V současné době je zřetelná snaha sjednotit systém Windows Phone s desktopovým systémem Windows, aktuálně také ve verzi 8. 2.3.3.2 Historie Windows Phone, jehož první verze nesla označení Windows Phone 7, byl původně založen, stejně jako jeho předchůdce (kterým byl systém Windows Mobile), na jádru Windows CE. První uvedení na trh proběhlo v roce 2010. Ve verzi 8 byl kompletně přepracován tak, že nyní využívá jádro systému Windows NT. 2.3.3.3 Vývoj aplikací Možnosti vývoje aplikací pro Windows Phone vycházejí z architektury sestávající ze tří základních vývojových bloků:
.NET
API
umožňující
vývoj
prostřednictvím
platformy
.NET
Framework,
Windows Phone Runtime napsané v jazyce C++ s kompletní portací do .NET jazyků,
nativní kód pro specializované funkce (Direct3D, Xaudio2, ...).
Preferovaným vývojovým prostředím je Microsoft Visual Studio, přičemž je k dispozici Windows Phone SDK obsahující mimo jiné i emulátor založený na virtualizační technologii Windows Hyper-V. 17
2.3.3.4 Publikace aplikací Aplikace jsou distribuovány prostřednictvím Windows Store. Pro uveřejnění aplikace je zde vyžadován placený vývojářský účet, přičemž každá publikovaná aplikace musí projít několikadenním schvalovacím procesem, při němž se kontroluje mimo jiné i striktní dodržování oficiálních pravidel pro vzhled uživatelského rozhraní (UI Guidelines).
18
3 Základní požadavky a charakteristiky aplikací pro chytrá zařízení V závislosti na účelu použití se můžeme setkat s rozličnými typy aplikací. Liší se především v požadavcích na systémové zdroje a speciální funkce zařízení. V této kapitole se pokusíme stručně popsat některé z hlavních charakteristik, ve kterých se aplikace odlišují.
3.1 Požadavky na uživatelské rozhraní aplikace Běh aplikace v mobilním zařízení má oproti klasické desktopové aplikaci spouštěné v počítači několik specifik. Většina z nich vychází z toho, jak dané zařízení vypadá a jak se používá. Základním požadavkem na každou aplikaci je, aby byla snadným způsobem ovladatelná. Zatímco běžné stolní počítače či notebooky se ovládají typicky pomocí klávesnice a myši, dnešní chytré telefony jsou ovládány prakticky výlučně dotykovým displejem s úhlopříčkou v řádech jednotek palců. Drtivá většina těchto mobilních zařízení se přitom ovládá prstem – dříve oblíbený stylus je dnes spíše okrajovou záležitostí. To klade nároky na uživatelské rozhraní – ovládací prvky musí být dostatečně velké, aby je bylo možné ovládat prsty na malém displeji, a musí být vhodně umístěny, aby byly v dosahu prstů. Některé platformy (nejvíce asi Windows Phone) toto řeší oficiálním manuálem, který popisuje vzhled základních prvků uživatelského rozhraní a definuje způsob, jakým má být tvořena koncepce ovládání aplikace. Dodržování takto určených pravidel je pak nutnou podmínkou ke schválení aplikace k prodeji oficiálními distribučními kanály. Důležitým požadavkem je, aby celé uživatelské rozhraní aplikace bylo konzistentní a aby maximálně využívalo komponenty poskytované systémem (typicky se jedná například o dotykovou klávesnici, základní grafiku nabídek, sadu ikon apod.). Uživatelé jsou na tyto komponenty zvyklí, snadno se jim
19
používají a především je pro ně používání zařízení mnohem snadnější, pokud jsou základní komponenty napříč jednotlivými aplikacemi stejné. Dalším z důležitých aspektů mobilních zařízení je fakt, že uživatel při jejich používání nemusí být plně soustředěný. Zatímco u běžných počítačů je pravděpodobné, že člověk věnuje práci většinu své pozornosti, například u mobilních telefonů tomu tak nemusí být. Lidé tato zařízení běžně využívají při chůzi, při řízení auta či při jiné práci.
3.2 Další požadavky na aplikaci Aby byla práce s telefonem pro uživatele pohodlná, je potřeba, aby všechny aplikace běžely pokud možno co nejplynuleji. Na osobních počítačích jsou uživatelé na nezanedbatelné doby odezvy jednotlivých aplikací již poměrně zvyklí (především z historických důvodů), na mobilních zařízeních však většina uživatelů očekává rychlost a stabilitu. Aplikace se musí vyvarovat prodlev v reakcích na uživatelovy pokyny a zároveň, a to především, nesmí svým chodem nikterak ohrožovat ostatní funkce zařízení. Nesmí se tudíž například stávat, aby spuštěná aplikace díky své nestabilitě či výkonovým nárokům neumožnila uživateli přijmout příchozí hovor na telefonu apod. Mobilní zařízení jsou většinou napájena bateriemi, jejichž kapacity jsou značně omezeny. Výdrž baterie a frekvence nabíjení jsou faktory, které komfort používání zařízení ovlivňují zcela zásadním způsobem. Veškeré aplikace, které jsou na zařízení spouštěny, by tak měly dbát o co nejmenší podíl na spotřebě baterie. Pro tvůrce aplikace to pak znamená snažit se využívat systémové zdroje jen v situacích, kdy je to opravdu potřeba, neprovádět zbytečné výpočty a operace, neudržovat otevřená síťová spojení déle, než je nutné apod. V souvislosti s baterií (ale nejen s ní) je třeba zmínit i další požadavek, který musí kvalitně napsaná aplikace splňovat – musí s minimálními škodami přežít vybití baterie, vypnutí telefonu, násilné ukončení aplikace apod. Bylo by velmi nevhodné, aby při náhlém vypnutí telefonu (např. z důvodu vybité baterie) uživatelé přišli o svá data, případně aby jim byla znemožněna práce po pozdějším spuštění zařízení. 20
Nenadálých situací se u mobilního zařízení vyskytuje samozřejmě mnohem více, nejedná se pouze o problémy s napájením. Aplikace se musí vyrovnat s nestabilním
připojením
k internetu,
s potenciálně
chybnými
daty
přicházejícími ze senzorů (přesnost a spolehlivost akcelerometrů, GPS jednotek i dotykových senzorů je principiálně omezená) apod.
3.3 Charakteristiky s ohledem na náklady Vývojář aplikace musí vést v patrnosti také ekonomickou stránku své činnosti. I zde mají aplikace pro mobilní zařízení určité charakteristiky, které činí vývoj pro mobilní zařízení odlišným oproti vývoji webových či desktopových aplikací. Pozitivním faktorem je, že u některých platforem, které omezují způsoby distribuce aplikací (např. iPhone či Windows Phone, kde je možné standardním
způsobem
aplikaci
nainstalovat
pouze
z oficiálního
distribučního systému výrobce systému), je mnohem obtížnější pořizovat nelegální kopie aplikací. Na druhou stranu, zatímco na běžném stolním počítači je zcela běžné platit za aplikace řádově tisíce korun, v případě mobilních aplikací se běžná cena pohybuje maximálně v řádech desítek korun. To samozřejmě vytváří na vývoj a prodej aplikací značný tlak, neboť bez velkého množství prodaných kopií je jen velmi obtížné zaplatit náklady s tvorbou aplikace spojené. Následující obrázek ukazuje průměrné ceny jednotlivých typů aplikací na nejpopulárnějším Apple App Store. Zdroj [4] uvádí průměrnou cenu aplikace v tomto obchodě přibližně 2,25 dolarů.
21
Obr. 2: Průměrné prodejní ceny aplikací v Apple App Store Zdroj: [4] Mobilní aplikace také do značné míry mění představy uživatelů o způsobu financování softwaru – zatímco na stolních počítačích ještě stále převládá model jednorázového nákupu aplikace, na mobilních zařízeních jsou aplikace velmi levné nebo dokonce zcela bezplatné a jejich financování je často rešeno jiným způsobem (typicky nákupy doplňkových položek až v rámci aplikace či pravidelné předplatné na jiné služby, které jsou s používáním aplikace spjaté). Tento trend potvrzuje i následující graf, ze kterého je patrné, že na obou dvou nejvýznamnějších prodejních místech (App Store a Google Play) je takřka 80% aplikací zdarma nebo v ceně do jednoho dolaru.
Obr. 3: Rozložení cen aplikací v App Store a Google Play Zdroj: [5] 22
Z tohoto pohledu je pravděpodobně ve velké většině případů výhodné vyrábět aplikaci jako multiplatformní, neboť rozšířením na více platforem se značným způsobem zvýší počet prodaných kopií, což alespoň částečně kompenzuje velmi nízké ceny aplikací.
3.4 Základní typy aplikací 3.4.1 Graficky náročné aplikace Dnešní mobilní zařízení mají již poměrně velký výpočetní výkon. To umožňuje mimo jiné i bezproblémový běh knihoven pro práci s 3D grafikou (jako např. OpenGL). Na mobilních zařízeních se tak běžně setkáváme s 3D hrami, s aplikacemi přehrávajícími video ve vysokém rozlišení apod. Charakteristické pro tyto typy aplikací je mimo vysoké nároky na výkon také časté zapojení dalších pokročilejších senzorů – graficky náročné aplikace (zpravidla hry) velmi často využívají akcelerometr, gyroskop apod. Graficky náročné aplikace jsou typicky implementovány jako nativní aplikace s co nejmenším zapojením vyšších vrstev. 3.4.2 Aplikace náročné na konektivitu Mnoho aplikací je závislých na připojení k internetu. Mobilní zařízení mají v tomto případě oproti stolním počítačům několik specifik. Mobilní aplikace musí být připravena na několik problémů:
Pomalé připojení – stahování a odesílání většího objemu dat trvá příliš dlouho. Aplikace s tímto musí počítat, nesmí blokovat uživatelské rozhraní a nesmí načítat zbytečná data.
Příliš dlouhé odezvy – některé technologie používané v oblasti mobilního internetu se vyznačují sice uspokojivými rychlostmi přenosu, nicméně doba odezvy při připojování dosahuje nepříjemných hodnot. Aplikace, které otevírají mnoho spojení trvajících relativně krátkou dobu (mnoho požadavků, krátké odpovědi), tak mohou běžet pomalu, ačkoliv nepřenášejí velký objem dat. Vývojář aplikace s tímto
23
může
počítat,
některá
data
předpřipravit
na
straně
serveru
a do mobilního zařízení je poté posílat po větších dávkách.
Nestabilní připojení – i přesto, že připojení k internetu má požadované parametry, u mobilního zařízení je vždy přítomné riziko ztráty konektivity. Uživatel se může s mobilním telefonem nacházet v oblasti špatného signálu, cestovat ve vlaku, v tunelu, v budovách apod. Aplikace i s tímto musí počítat a v případě výpadku zobrazit uživateli přívětivou hlášku a neblokovat uživatelské rozhraní.
Na všechny tyto problémy musí tvůrce aplikace při jejím návrhu myslet a patřičným způsobem reagovat. Výhodou je, že operační systém zařízení většinou poskytuje API, pomocí kterého může aplikace zjistit, na jakém typu připojení se momentálně zařízení nachází (typicky zda se jedná o GPRS, 3G, WiFi, LAN apod.). To jí umožní načasovat některé operace (např. synchronizace větších objemů dat, zálohování a další) tak, aby byly prováděny ve vhodnou dobu. Aby tak aplikace závislé na přenosech dat po internetu byly pro uživatele použitelné, musí vývojář (na rozdíl od vývojáře běžných aplikací pro stolní počítače) zvážit několik hledisek:
Asynchronní
operace
–
drtivou
většinu
operací
vyžadujících
komunikaci po síti je nutné provádět asynchronně. Procesní vlákno aplikace tak nesmí být blokováno, zařízení musí být stále ovladatelné a dlouhotrvající úkony musí provádět na pozadí.
Vhodné využívání mezipaměti – není-li požadováno, aby data byla 100% aktuální, je možné využít vyrovnávací paměti (angl. cache) v úložném prostoru zařízení.
Načítat či odesílat data po blocích vhodné velikosti – načítá-li aplikace velké objemy dat, je vhodné je rozdělit do menších bloků tak, aby v případě výpadku nebylo nutné stahovat velké objemy dat znovu. Je však třeba dát pozor, abychom nepřekročili únosnou mez a aby aplikace nevytvářela zbytečně mnoho požadavků, které by naopak na připojení s dlouhými dobami odezvy mohly způsobovat zpoždění.
24
Ošetřit výpadky vhodným způsobem v uživatelském rozhraní – není možné, aby bylo uživatelské rozhraní blokováno či aby byly zobrazeny pro uživatele neznámé a nepřehledné chybové hlášky. Detekuje-li aplikace problém s konektivitou, je nutné o tom uživatele informovat způsobem, který je pro něj důvěryhodný a kterému rozumí.
Reagovat na různé druhy konektivity – rozdělit datové přenosy podle toho, které z nich musí být provedeny okamžitě a které z nich snesou zpoždění. Typickým příkladem může být synchronizace souborů či zálohování – tyto operace je možné odložit až o několik hodin či dnů a zařízení je tak může provádět až ve chvíli, kdy je připojeno k WiFi či alespoň k vysokorychlostnímu mobilnímu internetu.
V současné době musí vývojář zvážit také fakt, že za data přenesená v mobilní síti může být uživateli účtován poplatek, případně může být vůči němu aplikována politika FUP. Platí tedy obecná zásada, že s datovými přenosy by aplikace měla šetřit. 3.4.3 Aplikace náročné na výpočetní výkon Výpočetní výkon procesorů současných mobilních zařízení roste velmi rychlým tempem. To umožňuje aplikacím provádět i náročné výpočty v reálném čase. Ačkoliv se myšlenka výpočetně náročných aplikací může jevit jako zcestná (vzhledem k tomu, že pro tento typ aplikací zde máme stolní počítače, notebooky, servery apod.), není tomu tak. S přibývajícím počtem mobilních zařízení a s klesajícími prodeji stolních počítačů a notebooků se velká část aplikací, včetně těch, které jsou náročné na procesorový výkon, přesouvá na tablety, chytré telefony a jiné mobilní platformy. Většina v současné době prodávaných mobilních zařízení je vybavena vícejádrovými procesory. U mobilních telefonů se často setkáváme s faktem, že jedno jádro je vyhrazeno pro nejdůležitější funkce telefonu (přihlašování k síti, realizace hovorů, ...) a druhé je vyhrazeno pro využití operačním systémem a aplikacemi. I přes dostatek výkonu jednotlivých zařízení zde však zůstává jeden zásadní problém – spotřeba energie. Ačkoli jsou zařízení z hlediska výpočetního 25
výkonu většinou velmi dobře vybavená, kapacita baterií tomu neodpovídá. Vývojář mobilní aplikace by tak vždy měl mít na paměti, že oblíbenosti jeho aplikace neprospěje, bude-li spotřebovávat energii výrazně více než ostatní aplikace. Vzhledem k tomu, že většina zařízení je prakticky neustále připojená k internetu,
můžeme
problém
spotřeby
procesorového
výkonu
řešit
prováděním náročných operací na straně serveru a odesíláním výsledků po internetové síti. Zde je však potřeba velmi opatrně vybalancovat náročnost na datové toky (která s sebou mimo jiné nese i spotřebu energie) a náročnost na výpočetní výkon. Tato rovnováha představuje pro tvůrce aplikací dlouhodobě vážné problémy, neboť kapacita baterií v posledních letech neroste ani zdaleka takovým tempem, jako výpočetní výkon procesorů v zařízeních. 3.4.4 Aplikace náročné na úložný prostor Mobilní zařízení primárně nejsou určena k práci s velkými objemy dat. S narůstajícím počtem tabletů, chytrých telefonů a s klesajícím podílem stolních počítačů a notebooků je však pravděpodobné, že budou uživatelé svá zařízení využívat i k jiným účelům, než tomu bylo doposud. Nezanedbatelná část aplikací bude pracovat s videem ve velkém rozlišení, hudbou, s rozsáhlými fotogaleriemi apod. To vše klade vysoké nároky na úložný prostor. Současná mobilní zařízení (spadající do kategorie chytrých telefonů či tabletů) většinou pracují s úložištěm o velikosti řádově desítek gigabajtů. Některé z nich jsou vybaveny sloty na paměťové karty, které tento prostor rozšiřují. Stále se však pohybujeme v řádech desítek či maximálně stovek gigabajtů. Problém nedostatečných kapacit datového úložiště je pro tvůrce aplikací velmi obtížný, neboť k jeho řešení může vést jen několik málo cest:
Používat ve větší míře zdroje na internetu. Tvůrce aplikace vždy stojí před rozhodnutím, která data bude uchovávat v zařízení (kde má omezenou kapacitu úložiště) a která bude uchovávat na serveru 26
a přistupovat k nim přes internet (kde má teoreticky neomezenou kapacitu, ale zvyšuje náročnost aplikace na internetové připojení).
Používat data nižší kvality – ne vždy je nutné uchovávat všechny obrázky ve vysokém rozlišení, ne vždy je nutné dekorovat aplikaci grafickými efekty či pracovat s videem s nízkou kompresí. Zde jdou však úspory proti uživatelskému zážitku. Rozlišení displejů, kvalita obrazu či zvukového výstupu se rok od roku zvyšují a uživatelé neradi vidí, když jsou jejich investice do novějších a kvalitnějších zařízení znehodnoceny aplikací, která těchto kvalit nevyužívá.
Nahrazovat datovou náročnost výpočetním výkonem – v některých případech je možné ukládat data v komprimované podobě a při přístupu k nim je v reálném čase rozbalovat. Dochází však ke zvýšení nároků na výpočetní výkon. Negativní efekty s tím spojené jsou popsány v předchozí kapitole.
Jak vidíme, problém nedostatečné kapacity je pro vývojáře oříškem. Všechny doposud známé způsoby jeho řešení s sebou totiž přinášejí nezanedbatelné negativní vedlejší efekty. 3.4.5 Aplikace využívající pokročilé senzory Současná zařízení jsou vybavena celou škálou senzorů, které může vývojář aplikace použít, aby zlepšil možnosti ovládání či přidal další funkcionalitu. Pro příklad jmenujme ty nejčastější:
Fotoaparát, videokamera – většina chytrých zařízení disponuje fotoaparátem s relativně vysokým rozlišením (některé současné chytré telefony jsou vybaveny fotoaparátem s rozlišením až 40 megapixelů). Některé z nich mají fotoaparáty dokonce dva – jeden na přední straně (typicky pro možnost videohovorů), druhý na zadní straně (většinou s vyšší kvalitou obrazu, určený pro pořizování fotografií a natáčení videa).
GPS anténa – typicky přístupná ve všech chytrých telefonech, tabletech a dnes již i v některých noteboocích. S jejím používáním je však spojena relativně vysoká spotřeba energie, proto některé současné mobilní operační systémy poskytují tzv. Geolokační API, které 27
umožňuje zjišťovat polohu zařízení v různých režimech – v případě, že aplikaci stačí přibližná poloha, poslouží dostatečně i informace získaná z mobilní GSM sítě, případně poslední známé polohy, a není nutné zapojovat energeticky náročnou GPS anténu.
Akcelerometr – senzor měřící zrychlení, najde uplatnění například ve hrách.
Gyroskop, pomocí kterého může být zařízení schopné rozpoznat pohyb resp. rotaci podle všech tří os;
Čtečky otisků prstů;
Teplotní čidla.
Operační systémy typicky poskytují API, pomocí kterého může aplikace zjistit, které senzory jsou k dispozici, a podle toho přizpůsobit svou funkcionalitu. 3.4.6 Aplikace s vysokou mírou integrace s operačním systémem Výrobci mobilních platforem se snaží používání jejich zařízení pro uživatele maximálně zjednodušit. Nabízejí proto tvůrcům aplikací mnoho komponent, které jsou pro celé zařízení společné tak, aby způsob, jakým uživatelé se zařízením pracují, byl pokud možno jednotný a konzistentní napříč všemi aplikacemi. Zároveň dává každý výrobce zařízení či operačního systému v rámci své konkurenční výhody k dispozici funkce, které jsou pro jeho zařízení specifické (hovoříme o tzv. platformně specifické funkcionalitě). Může se jednat o napojení na externí služby stejného dodavatele (jako příklad můžeme uvést
mapové
služby,
integraci
s firemními
systémy,
kancelářskými
aplikacemi apod.). Rozhodne-li se tvůrce aplikace využívat komponenty operačního systému či platformně specifické funkce, přináší mu to mnoho důsledků, z nichž některé jsou negativní a jiné pozitivní. Z těch negativních se jedná zejména o následující:
28
Nutnost pracovat s různými platformami – využívá-li aplikace platformně specifické funkce, musí být její implementace připravena na míru jedné konkrétní platformě. Vytváříme-li tedy multiplatformní aplikaci, neobejdeme se v některých případech bez více oddělených vývojových větví.
Zvyšování závislosti na výrobci platformy – pro komerční činnost je jakákoliv závislost na externí firmě vždy přidaným rizikem. Výrobce aplikace, která je do značné míry integrovaná s operačním systémem, musí počítat s tím, že v budoucnosti nemusí být zajištěna zpětná kompatibilita, že se některé části operačního systému mohou v dalších verzích měnit apod.
Nutnost přizpůsobovat uživatelské rozhraní konvencím operačního systému. Využíváme-li mnoho komponent poskytovaným systémem, musíme vzít v potaz, že míra přizpůsobitelnosti vzhledu těchto komponent může být omezená. Chceme-li i poté mít konzistentní uživatelské rozhraní v celé aplikaci, musíme počítat s tím, že bude nutné zbylou část aplikace vzhledově přizpůsobit.
Integrace komponent poskytovaných operačním systémem či obecně využívání platformně specifických funkcí s sebou však nese i pozitivní efekty. Uveďme například následující:
Konzistentní způsoby používání – uživatelé jsou na ovládání operačního systému zvyklí a nabídneme-li jim podobné ovládání i v naší aplikaci, budou se cítit jistěji a práce s aplikací pro ně bude příjemnější.
Odladěnost systémových komponent – lze předpokládat, že výrobce platformy (či operačního systému) věnoval velké úsilí odstranění chyb z komponent, které nabízí třetím stranám. Využitím těchto komponent tak můžeme snížit chybovost naší aplikace.
Ušetření práce – jakákoliv funkční komponenta, která do naší aplikace zapadne bez větší námahy, znamená pro programátora úsporu práce a pro tvůrce aplikace úsporu nákladů.
Pozitivní obraz v očích potenciálních kupců – lze předpokládat, že uživatel si zařízení vybral na základě svých preferencí. Můžeme se 29
tedy domnívat, že má k dané platformě kladný vztah. Využívání platformně
specifických
funkcí
tak
může
přinášet
i pozitivní
marketingový efekt. Nelze opomenout, že i pro výrobce operačního systému je žádoucí, aby aplikace na něm běžící byly do něj maximálním způsobem integrovány – prohlubuje to vazby mezi tvůrci aplikace a dodavatelem operačního systému.
30
4 Komerční aplikace pro prodej zboží a služeb Tato práce je zaměřena na tvorbu komerčních aplikací určených primárně pro prodej zboží či služeb. V této kapitole se pokusíme stručně popsat společné rysy takových aplikací.
4.1 Specifika Velmi důležitým specifikem těchto aplikací je fakt, že velmi často firma, pro kterou tato aplikace slouží, nemá prodej pomocí mobilních zařízení (či dokonce on-line prodej) jako svůj hlavní byznys. Webové aplikace, a jejich mobilní verze obzvlášť, velmi často (byť samozřejmě ne vždy) slouží jen jako doplňkový prodejní kanál. To se projevuje především v nižší ochotě firem platit náklady na vývoj těchto aplikací. Velmi často se také setkáváme se situací, kdy vedení firmy (které pro vývojáře aplikace vystupuje v roli zákazníka či odběratele) není dostatečně technicky vzdělané, nemá dostatečné znalosti a má často nereálné požadavky či nesmyslná kritéria hodnocení. Vývoj tohoto typu aplikací je rovněž poznamenán tím, že produkt se musí zpravidla přizpůsobit existujícím procesům ve firmě (často nazývaným „byznys procesy“). Velmi často se stává, že v internetovém prostředí jsou zavedeny poněkud odlišné postupy, než v existujících firmách, pro které je on-line prodej jen doplňkem k jejich hlavnímu předmětu podnikání. Pokud tento problém není při vývoji aplikace dostatečně vyřešen, vznikají aplikace, které jsou pro uživatele špatně použitelné, či aplikace, které uživatelé raději nahrazují konkurenčními produkty, neboť nejsou s jejich používáním spokojeni, a to i přesto, že tyto aplikace zcela splňují původní požadavky zákazníka, který si jejich vývoj objednal. U prodejních aplikací je potřeba rozlišovat, jaký druh zboží či služeb má aplikace prodávat. To je důležité zejména kvůli různým licenčním podmínkám jednotlivých platforem. Rozeznáváme zejména:
31
Digitální obsah o Obsah konzumovaný v rámci aplikace (typickým příkladem mohou být bonusové úrovně ve hrách či pokročilé doplňkové nástroje využívané v různých aplikacích, ...) o Obsah konzumovaný pro jeho informační hodnotu (např. možnost mobilního přístupu k placenému zpravodajství, hudbě či videu) o Obsah konzumovaný na jiném zařízení (kdy například mobilem zaplatíme za možnost sledovat placené video na televizi)
Reálné zboží mimo „digitální svět“ - Typickým příkladem budiž internetové obchody, ve kterých si uživatel nakupuje prakticky libovolné zboží z reálného světa
Reálné služby – zde jako příklad uveďme například mobilní platbu za služby kadeřníka apod.
Základním měřítkem úspěšnosti prodejní aplikace je tzv. konverzní poměr, zpravidla definovaný jako poměr počtu realizovaných nákupů a počtu příchozích uživatelů. V případě mobilních aplikací můžeme pro výpočet použít počet spuštění aplikace, počet instalací aplikace či počet unikátních uživatelů, kteří webovou aplikaci aktivně používají. Snahou je samozřejmě dosáhnout co největšího konverzního poměru. Zkušenosti ukazují, že konverzní poměr je do značné míry ovlivněn složitostí používání aplikace. U aplikací pro prodej zboží či služeb je tedy velmi důležité maximálně zjednodušit nákupní proces. Každý krok navíc, každé klepnutí, které je po uživateli zbytečně požadováno, bude v důsledku znamenat úbytek realizovaných prodejů. Zkušení provozovatelé internetových obchodů tento fakt dobře vědí a snaží se své aplikace pro uživatele neustále zjednodušovat.
4.2 Požadovaná funkcionalita U aplikace zaměřené na prodej zboží je velmi pravděpodobné, že bude využívat jen některé funkce telefonu, případně že poskytované funkce bude využívat jen povrchně. Nebudeme předpokládat, že by tyto aplikace kladly vysoké nároky na kvalitu fotoaparátu či jiných senzorů, že by byly výpočetně náročné či že by využívaly některé platformně specifické funkce zařízení. 32
V této podkapitole se pokusíme stručně popsat základní funkce, které budou pro většinu prodejních aplikací společné. 4.2.1 Notifikační funkce Velmi
častým
požadavkem
zákazníků
je,
aby
aplikace
dokázala
prostřednictvím notifikačních mechanismů, které jsou většinou zabudované v mobilním operačním systému, zobrazovat uživateli notifikace (upozornění, zprávy apod.) informující o novinkách v sortimentu, cenových akcích či sdělující důležité informace o nákupu. Rozeznáváme zde dva druhy notifikací, odlišující se především zdrojem, který je vyvolává:
běžné notifikace,
„push“ notifikace.
Zatímco push notifikace umožňují vyvolat notifikace signálem zvenčí (např. z centrálního serveru), běžné notifikace jsou vyvolány vždy aplikací běžící přímo na zařízení. Jako příklad push notifikací můžeme uvést např. oznámení reklamního charakteru či oznámení o vydání nové verze aplikace (výzva k aktualizaci). Jako příklad běžných notifikací uveďme varování o nízkém stavu baterie či jiná běžná hlášení. 4.2.2 Autentizace Zdaleka ne všechny mobilní aplikace vyžadují autentizaci. Je však pravdou, že
autentizace
uživatelů
je
z pohledu
prodejce
velmi
důležitá.
Neautentizovaný uživatel je anonymním zákazníkem. Jakmile se však přihlásí, obchodník (provozovatel aplikace) získává mnoho možností, jak jeho neanonymity komerčně využít. Z nich jmenujme například:
možnost přizpůsobovat nabídku produktů preferencím zákazníka;
možnost nabízet zákazníkům individuální ceny či slevy;
možnost sledovat chování zákazníků, např. o zjišťovat, jak často se k nákupu vracejí, v jakou dobu nejvíce nakupují, 33
o vysledovat, které kombinace zboží zákazníci nejčastěji nakupují.
Možnost zjednodušit nákupní proces tím, že uživatel nemusí zadávat údaje, které již jednou (při předchozím nákupu) zadal. To je pro mobilní aplikace obzvlášť přínosné, neboť zadávání dlouhých textů (adres, ...) je na mobilním zařízení zdlouhavé a nepohodlné.
Je také potřeba říci, že pro některé typy služeb je autentizace z principiálních a bezpečnostních důvodů nevyhnutelná. 4.2.3 Zpracování platby Nezbytnou součástí aplikací určených k prodeji zboží je i realizace plateb. Ačkoliv je tato funkcionalita z technického hlediska již dlouhou dobu vyřešená a existuje mnoho způsobů, jak ji technicky a bezpečnostně zajistit, zůstávají online platby stále zatíženy častou nedůvěrou ze strany uživatelů. I zde tedy platí jednoznačný požadavek, aby proces platby byl co nejjednodušší a nejtransparentnější. Existuje několik způsobů, jak platební systém implementovat, lišící se v několika podstatných principech:
integrace s oficiálním platebním systémem výrobce platformy (typicky Google, Microsoft, Apple, ...),
možnosti využití různých platebních způsobů (kreditní karta, platba pomocí SMS, PayPal, ...),
způsob implementace (v rámci aplikace či v rámci webové stránky, na kterou musí být uživatel přesměrován).
Jednotlivé přístupy budou z technického hlediska popsány v dalších kapitolách.
34
5 Možnosti implementace mobilních aplikací Při vývoji aplikací, které mají být využívány na mobilních zařízeních, se můžeme vydat několika směry, ze kterých se pak odvíjí způsob, jakým aplikace vzniká, nástroje, které máme při vývoji k dispozici i možnosti, které poté samotná aplikace na zařízení má. V následujících podkapitolách se pokusíme tyto různé přístupy stručně popsat.
5.1 Nativní aplikace Výchozím způsobem je vždy nativní aplikace psaná na míru pro jednu konkrétní platformu. Pro každou z platforem je k dispozici primární programovací jazyk (resp. sada takových jazyků), přičemž pro usnadnění vývoje je většinou poskytováno tzv. SDK, poskytující nástroje pro tvorbu aplikace, testování, kompilování, emulaci zařízení apod. Nativní aplikace
má
zpravidla
přístup
ke
všem
funkcím
zařízení
prostřednictvím API operačního systému. Může tak využívat pokročilé funkce zařízení, přistupovat k datům z různých senzorů či využívat společné komponenty systému. Zásadní výhodou nativní aplikace je tak možnost využít všech funkcí zařízení, které jsou vývojářům k dispozici. Nemůže se tak stát, že konkurenční aplikace má k dispozici něco více. Některé platformy umožňují nativním aplikacím spouštět přímo assembler vytvořený specificky pro danou čipovou sadu. Toho některé aplikace využívají především z výkonových důvodů. Zásadní nevýhodou nativních aplikací je fakt, že jsou vždy funkční jen na jedné konkrétní platformě. Nativní aplikaci kompilovanou pro iPhone není možné použít pro Android apod. To značným způsobem omezuje množinu potenciálních zákazníků. Výhodu naopak tvoří fakt, že aplikace má větší potenciál být pro uživatele příjemná na používání, jelikož výkonnostně ji kromě chyb programátora nic principiálního nebrzdí. 35
Hlavním problémem tohoto přístupu je však nutnost znát konkrétní vývojová prostředí pro jednotlivé platformy. Pro každou platformu totiž pracujeme se zcela odlišným programovacím jazykem, vývojovým prostředím, emulátory apod. Chceme-li tak zpřístupnit naši aplikaci uživatelům více platforem, musíme mít více kvalifikovaných programátorů a softwarového vybavení. Lze také poznamenat, že v dnešní době překotného tempa vývoje techniky je vývoj nativních aplikací pro mobilní telefony tímto způsobem neperspektivní, neboť aplikace spolu s platformami (a v neposlední řadě i s kvalifikací programátorů) nezanedbatelně rychle zastarávají. Tvorba nativních aplikací pro jednotlivé platformy většinou nevychází z žádného globálně uznávaného standardu, což ji činí méně perspektivní.
5.2 Webová aplikace otevíraná v prohlížeči Pro mnoho situací je zbytečné programovat nativní aplikaci a plně postačí jiné řešení – webová aplikace s uživatelským rozhraním v HTML, které si uživatel na zařízení spouští ve webovém prohlížeči. Toto řešení má několik nesporných výhod. Aplikace existuje v jediné instalaci, spravované na jednom místě. To značným způsobem usnadňuje instalace, aktualizace, konfiguraci apod. Je vždy zajištěno, že všichni uživatelé používají nejnovější verzi aplikace. Webová aplikace běží na serveru a má tak do značné míry zjednodušen přístup k serverovým zdrojům, databázím apod. Pro samotné vytvoření HTML uživatelského rozhraní je také možné využít libovolnou platformu, bez ohledu na to, které platformy jsou podporovány na zařízení. Všechna mobilní zařízení disponují webovým prohlížečem. Programátor webové aplikace má tak možnost zpřístupnit tuto aplikaci všem uživatelům, bez ohledu na typ jejich zařízení. Významnou výhodou je fakt, že část aplikace, která bude spouštěna v zařízení (tj. HTML kód doplněný o CSS styly či např. JavaScriptovou funkcionalitu) je možné vytvořit kompletně pomocí standardizovaných technologií, čímž můžeme dosáhnout velmi solidní dopředné kompatibility. 36
Problémem tohoto přístupu je závislost na prohlížeči v daném zařízení. Uživatelské rozhraní je v prohlížeči kompletně renderováno a jakékoliv chyby při tomto renderování tak ovlivní vzhled či funkčnost aplikace. Existuje více různých prohlížečů pro různé mobilní operační systémy a programátor aplikace nemá žádnou možnost ovlivnit, který z nich uživatel použije. Může se tak stát, že aplikace vykazuje vzhledové či funkční nedostatky, aniž by byl na vině její tvůrce. Zcela zásadním nedostatkem tohoto přístupu je fakt, že zařízení musí mít po celou dobu používání aplikace přístup k internetu. To může být pro mnoho aplikací kritické, neboť mobilní zařízení se často pohybují v oblastech se špatným signálem. Aplikace tak může být nestabilní, případně může být její používání pro uživatele nepohodlné. Problémem webových aplikací je, že masivně využívají JavaScript, jehož interpretace je z principiálních důvodů relativně pomalá (minimálně v porovnání s kompilovaným nativním kódem). Tématu výkonu JavaScriptu na mobilních platformách se podrobně věnuje například článek [7]. Pozitivním faktem je, že výkonnost interpretace JavaScriptu se v současné době rapidním způsobem zvyšuje. Pro ilustraci uvádíme graf znázorňující čas potřebný k vykreslení 10tis. křivek vektorové grafiky ve formátu SVG v různých verzích mobilních zařízení:
37
Obr. 4: Srovnání času potřebného k vykreslení vzorku vektorové grafiky u vybraných mobilních operačních systémů Zdroj [7] Vzhledem
k tomu,
jak
zásadním
zlepšením
výkonnost
JavaScriptu
v posledních letech prochází, lze bezpochyby tvrdit, že pro mnoho aplikací již výkonové omezení tohoto interpretovaného jazyka nebude problémem. Je třeba poznamenat, že pro mobilní zařízení zde existuje několik JavaScriptových vývojových rámců, které vývoj mobilních aplikací pomocí HTML značně usnadňují tím, že poskytují sady JavaScriptových funkcí a knihoven, které sjednocují rozhraní různých mobilních prohlížečů. Programátor tak může pracovat s jednotným JavaScriptovým rozhraním, bez ohledu na to, na které platformě je aplikace spouštěna. Podrobněji se těmto nástrojům věnují například zdroje [15] a [16]. „JavaScriptové rámce jsou sady knihoven určené na zrychlení komplexních úkonů při vývoji aplikací, jako je řízení interakce dotykového displeje, vývoj uživatelských rozhraní pro více prohlížečů současně nebo při řízení herních grafických elementů“, zdroj [15], vlastní překlad Zdroj [15] zde jako příklady těchto nástrojů uvádí:
jQuery Mobile, 38
Sencha Touch,
Cocos2D,
DHTMLX Touch,
ZeptoJS,
Impact.js,
iUI,
Wink.
5.3 Multiplatformní nativní aplikace Další z možností je vyvíjet aplikaci jakožto nativní, avšak se zapojením multiplatformních prostředků tak, aby co možná nejvíce vývojářské práce mohlo být odvedeno jen jednou, a co možná nejméně částí se muselo implementovat pro každou platformu zvlášť. Můžeme se setkat s několika základními přístupy, jak multiplatformní nativní aplikaci vytvořit. V následujících kapitolách jednotlivé přístupy stručně popíšeme. 5.3.1 Multiplatformní běhové prostředí (runtime) Existují sady nativních knihoven založené na některém z obvyklých jazyků (např. C++ jazyky z rodiny .NET), které existuje ve variantách pro různé platformy, ale jejich vnější rozhraní je vždy stejné (nebo alespoň co nejpodobnější). Zdroj [16] definuje takové prostředí následovně: „Běhové prostředí je exekuční prostředí a multiplatformní vrstva. Jeho hlavní funkcí je odstínit aplikace od rozdílů jednotlivých platforem, na kterých jsou tyto aplikace postavené. Jednotlivá běhová prostředí se liší svou komplexností, velikostí a metodami vykonávání kódu na zařízení. Může jít o virtualizaci, interpretaci, just-in-time kompilaci nebo ahead-oftime kompilaci“, zdroj [16], vlastní překlad Příklady takových běhových prostředí můžeme nalézt např. v literatuře [15]:
Corona,
Adobe Flex, 39
Antix,
Unity,
Titanium.
5.3.2 Překladače zdrojového kódu Poněkud odlišným způsobem fungují překladače zdrojového kódu. „Překladače zdrojového kódu překládají zdrojový kód do mezikódu, nativního jazyka (například C++, Objective-C, JavaScript), nebo přímo do nízkoúrovňového strojového kódu.Tyto nástroje jsou často kombinovány s prvky runtime nástrojů“, zdroj [15], vlastní překlad Jako příklady překladačů zdrojového kódu uvádí zdroj [15] následující:
MoSync,
Marmelade,
Mono (Xamarin).
Častým principem překladačů, obzvlášť v kombinaci s běhovými prostředími je, že funkční část aplikace (sdílené knihovny aplikační logiky) je naimplementována
jednou
v některém
z obecně
rozšířených
jazyků
(v případě nástrojů Xamarin se jedná např. o C#), a pro každou platformu zvlášť je pak vytvořeno uživatelské rozhraní. Tento přístup je pro vývojáře často výhodný, neboť uživatelská rozhraní se u jednotlivých operačních systémů do značné míry liší (typicky jsou vydávány oficiální manuály popisující základní principy a vzhled jednotlivých komponent aplikací pro danou platformu), zatímco aplikační logika je pro všechny platformy stejná. 5.3.3 Nástroje obalující standardizovaný kód Třetí možný přístup k vytvoření nativní aplikace multiplatformně představují tzv. obalovače (více známé též pod pojmem wrappery). Tyto nástroje fungují na principu webového prohlížeče, který je však obsažen v nativní aplikaci (využívá se komponenty často nazývané WebView). Vývojář v tomto případě vytváří aplikaci většinou ve standardizovaném HTML za použití JavaScriptu (i když samozřejmě principiálně mohou 40
existovat obalovače i pro jiné jazyky). Tím vzniká webová aplikace. Aby však bylo možné tuto spouštět na zařízení bez nutnosti použití prohlížeče, je vytvořena
nativní
zkompilovaná
aplikace,
která
jednoduše
spustí
komponentu webového prohlížeče a v ní zobrazí danou aplikaci. Obalovače jsou vytvořeny pro každou platformu zvlášť (resp. existují ve variantách pro více platforem), ale aplikaci je možné psát jenom jednou, bez nutnosti znalosti specifik jednotlivých platforem. Nespornou
výhodou
tohoto
přístupu
je
možnost
využití
plně
standardizovaných technologií (v dnešní době zejména HTML5 a CSS3). Velká část vývojářů tyto technologie velmi dobře zná, nehledě na fakt, že tyto znalosti uplatní i při vývoji jiných aplikací. Pomocí HTML5, CSS3 a JavaScriptu se dnes běžně programují aplikace nejen pro mobilní telefony, ale samozřejmě také běžné webové prohlížeče či dokonce i běžné desktopové aplikace. To vše může značným způsobem snížit náklady potřebné na vývoj aplikace. Nevýhodou může být obtížný přístup k vestavěným funkcím zařízení, k platformně specifickým funkcím či k hardwarovému vybavení zařízení. Tuto nevýhodu však poměrně účinně odstraňuje použití JavaScriptových vývojových rámců popsaných v předchozí kapitole.
5.4 Shrnutí V této
kapitole
byly
popsány
různé
přístupy
k vytvoření
aplikací
použitelných na různých mobilních platformách. Byl ve zkratce popsán vývoj aplikace jakožto nativní pro každou platformu zvlášť, vyznačující se nákladným vývojem, ale velkými možnostmi optimalizace a teoreticky neomezenou kvalitou výsledného produktu. Zmínili jsme možnost vyvíjet aplikaci jako čistě webovou, otevíranou skrze webový prohlížeč, kdy je jednoznačnou výhodou rychlý a snadný vývoj, ale značnou nevýhodou jsou omezené možnosti, které aplikace má na koncovém zařízení. A v neposlední řadě byl popsán hybridní přístup, který ve své podstatě více či méně kombinuje výhody a nevýhody předchozích dvou možností. U tohoto
41
hybridního přístupu jsme zmínili tři různé možnosti, jak tímto způsobem vyvíjet multiplatformní aplikace. Každý z diskutovaných přístupů má nezanedbatelné výhody i nevýhody. Volba vhodného přístupu je pro vývoj aplikace zcela zásadní rozhodnutí, neboť významným způsobem ovlivňuje úsilí, které bude potřeba vynaložit při implementaci. To, který z přístupů je pro vývoj aplikace optimální, závisí na druhu vyvíjené aplikace, na jejích požadavcích, na cílové skupině uživatelů a v neposlední řadě také na perspektivách jejího dalšího rozvoje. Nezanedbatelnou roli vždy hrají také vývojáři, kteří se na tvorbě aplikace podílejí – především jejich zkušenosti a kvalifikace.
42
6 Volba způsobu vývoje a vývojového rámce Tato práce se zabývá aplikací určenou pro prodej zboží. U takové aplikace můžeme předpokládat především následující funkcionalitu:
poskytování informací zákazníkovi (typicky informace o aktuálním sortimentu, cenách apod.),
zobrazování notifikací (např. o nových cenových akcích nebo o stavu zadané objednávky),
realizace
platby
co
možná
nejjednodušším
a
pro
zákazníka
nejdůvěryhodnějším způsobem. Aplikace tohoto typu nevyžaduje žádné zapojení pokročilých senzorů či platformně specifických funkcí. Zcela zásadním požadavkem je co nejširší uživatelská základna. Je tedy více než vhodné, aby aplikace byla použitelná na různých mobilních platformách. Vzhledem
k těmto
multiplatformního
požadavkům obalovacího
se
jako
rámce
a
nejvhodnější vývoje
volí
aplikace
použití
v HTML5
a JavaScriptu. Tento přístup nám umožní získat nativní aplikaci pro různé platformy a přesto se při vývoji stále držet standardizovaných technologií – HTML5, CSS3 a JavaScriptu. Tyto platformy jsou mezi programátory velmi dobře známé. Vzhledem k tomu, že aplikace mimo platby a notifikace nebude využívat prakticky žádné platformně specifické funkce, nemusíme se ani obávat obtížné integrace s operačním systémem. Pro tyto účely je možné vybírat z různých konkurenčních nástrojů. Principiálně jsou všechny podobné, pro účely této práce příliš nezáleží na tom, který z nich zvolíme. Podrobnému porovnání jednotlivých variant se věnují například zdroje [15] či [16]. Jako nejvhodnější varianta se jeví platforma PhoneGap. Jedná se o opensource platformu založenou na projektu Apache Cordova. V následující kapitole tuto vývojovou platformu podrobněji popíšeme. 43
7 Platforma Adobe PhoneGap Principem PhoneGapu je zapouzdření webového kódu psaného v HTML, CSS a JavaScriptu spolu s knihovnami funkcí do nativních aplikací pro jednotlivé platformy. Počátky projektu se datují do roku 2008, kdy vznikl pod záštitou společnosti Nitobi. Ta byla v roce 2011 odkoupena společností Adobe (zdroj: [15]), která následně projekt věnovala Apache Software Foundation, kde byl zpřístupněn jako open-source projekt Cordova pod licencí Apache 2.0. „Obchodní název PhoneGap však zůstal zachován a v současnosti je možné na něj nahlížet jako na vývojový rámec založený právě na projektu Apache Cordova.“ [16], vlastní překlad
7.1 PhoneGap Build Společnost Adobe poskytuje ke svému jinak bezplatnému projektu PhoneGap službu PhoneGap Build, jejíž myšlenkou je kompilace aplikací pro různé platformy v cloudu. Princip je velmi jednoduchý – programátor vytvoří aplikaci v HTML, CSS a JavaScriptu, poté ji spolu se základní konfigurací nahraje na server PhoneGap Build, kde je aplikace během několika minut automaticky zkompilována pro všechny dostupné platformy.
Momentálně jsou
podporovány platformy:
iOS,
Windows Phone,
Android,
BlackBerry 5, 6, 7,
WebOS,
Symbian WRT.
Výhodou je, že vývojář nemusí udržovat ve svém počítači aktuální verze SDK knihoven pro všechny platformy. Může se tak plně soustředit jen na vývoj 44
samotné aplikace a kompilování v prostředí cloudu tak výrazným způsobem urychluje vývojový cyklus aplikace. Dalším usnadněním je možnost napojení na verzovací systémy (např. GitHub). Vývojáři tak mohou mít zkompilované verze svých aplikací prakticky neustále dostupné, aniž by se museli starat o potřebné softwarové vybavení. Používání služby PhoneGap Build je velmi jednoduché. Skrze webové rozhraní stačí nastavit základní konfiguraci, případně pro některé platformy nahrát vývojářský certifikát. Poté je potřeba při každé změně nahrát zdrojové soubory aplikace zabalené do ZIP balíčku a počkat několik desítek vteřin či minut, než se verze pro jednotlivé platformy zkompilují. Jakmile je proces dokončený,
je
možné aplikaci okamžitě
nahrát
do
zařízení,
např.
oskenováním QR kódu.
Obr. 5: Snímek obrazovky uživatelského rozhraní aplikace PhoneGap Build Zdroj: [22] Služba PhoneGap Build je pro vývojáře open source aplikací, případně pro vývojáře publikující maximálně jednu proprietární aplikaci, zcela zdarma. Pro vývoj více aplikací nabízí společnost Adobe různé placené licenční plány, přičemž ceny v tuto chvíli začínají na přibližně deseti dolarech za měsíc.
45
8 Specifikace ukázkové aplikace Jedním z cílů této práce je vytvoření aplikace, která bude demonstrovat funkcionalitu popisovanou v kapitole 4. Není záměrem vytvořit přímo využitelnou komerční aplikaci, ale na praktickém příkladě demonstrovat, jakým způsobem lze pomocí vhodně zvolených vývojových nástrojů a knihoven vytvořit multiplatformní aplikaci poskytující následující funkce:
autentizaci uživatele způsobem „Single Sign-On“, konkrétně pomocí Facebook účtu nakonfigurovaného přímo v uživatelském profilu operačního systému zařízení,
zobrazování
notifikačních
zpráv
způsobem
konzistentním
s uživatelským rozhraním operačního systému,
možnost realizace on-line plateb za reálné zboží či služby (nikoliv tedy za digitální obsah).
Aplikace bude vytvořena pomocí standardizovaných jazyků HTML5, CSS3 a JavaScriptu, za pomoci knihoven Adobe PhoneGap založených na open source platformě Apache Cordova. Aplikace bude přístupná jako nativní aplikace pro Android, iOS a Windows Phone. Pro vytvoření nativní aplikace použitelné na těchto platformách bude využit produkt PhoneGap Build.
46
9 Implementace ukázkové aplikace 9.1 Prerekvizity Pro vývoj používáme platformu PhoneGap, která je implementací opensource projektu Cordova. V dalším textu budeme používat oba tyto názvy, v závislosti na tom, který z nich bude v daném kontextu relevantnější. Kdekoli je to možné, využíváme nejnovější verze vývojových rámců i všech ostatních komponent. Pro samotnou tvorbu a ladění aplikací je potřeba nainstalovat následující nástroje:
Node.js (softwarová platforma pro tvorbu škálovatelných serverových aplikací v jazyce JavaScript [18]),
Apache Cordova, resp. Adobe PhoneGap,
Apache Ant (sada nástrojů pro kompilaci, sestavování, testování a běh aplikací v jazyce Java [20]) ,
Git (sada nástrojů pro distribuovaný vývoj aplikací a správu zdrojových kódů [21]).
V závislosti na platformách, pro které chceme vyvíjet, je potřeba nainstalovat i vývojové sady (SDK) jednotlivých platforem, konkrétně tedy:
Android SDK,
Windows Phone SDK,
iOS SDK.
Lze přidat také další podporované platformy (např. BlackBerry 10, FireFox OS, Tizen, HP WebOS, ...). Pro ladění při vývoji je vhodné použít softwarový emulátor. Ten bývá většinou součástí jednotlivých sad SDK. Při vývoji této aplikace se ukázalo, že emulátor Windows Phone je použitelný bezproblémově, operační systém na něm běží relativně plynule a vše se velmi podobá reálnému zařízení. Naproti tomu emulátor, který je součástí Android SDK, měl při použití na Windows vysoké nároky na hardware a běh operačního systému byl velmi 47
pomalý. Pro otestování reakcí aplikace se ukázal jako nepoužitelný. Jako použitelnější alternativa se ukázal emulátor Genymotion, který není přímo součástí SDK, pro svůj běh využívá virtualizační platformu VirtualBox a pro osobní použití je k dispozici zdarma. Nevýhodou může být obtížná provázatelnost s vývojovým prostředím.
9.2 Principy platformy PhoneGap a základní struktura projektu V této kapitole popíšeme základní strukturu projektu na platformě PhoneGap/Cordova verze 3.0 a vyšších. Každý projekt obsahuje několik adresářů, pro účely této práce jsou podstatné zejména následující:
platforms,
plugins,
www.
Vývojář edituje webové stránky spolu JavaScriptovým kódem v adresáři www. O všechna ostatní umístění se již nemusí starat, veškeré zdrojové kódy jsou umístěny na tomto jednom místě. Mimo zdrojové kódy zde nalezneme také konfigurační XML soubory, pomocí kterých můžeme nastavovat parametry aplikace (názvy, doménové identifikátory, požadovaná oprávnění, minimální hardwarové požadavky, ...). Jádro Cordova při každé kompilaci vytvoří ze souborů v adresáři www projekty pro každou z instalovaných platforem, a ty umístí do adresáře platforms. Po zkompilování zde tedy nalezneme podadresáře pro jednotlivé platformy (např. wp8, android, ...), z nichž každý obsahuje kompletní projekt aplikace pro danou platformu. Například v případě Windows Phone je to soubor .sln (Visual Studio Solution) spolu s kódy v jazycích C#, XAML apod. Pro Android jsou to soubory projektu v jazyce JAVA. Tyto projekty obsahují infrastrukturu samotného obalovače (wrapperu), tedy nativní aplikaci, která inicializuje okno webového prohlížeče a zobrazí v něm naprogramovanou webovou aplikaci. Celkem obsahují jen velmi málo kódu. V případě Microsoft Visual studia se tak jedná jen o 50 řádků C# kódu pro hlavní obrazovku a přibližně 150 řádků C# kódu pro základní infrastrukturu aplikace (reakce na události životního cyklu aplikace, inicializace hlavního okna, ...). Tento kód je 48
velmi dobře čitelný, odpovídá standardním strukturám těchto projektů (projekt Visual Studio, Android Eclipse, ...) a je přehledně komentován. Adresář plugins obsahuje zdrojové kódy všech nainstalovaných zásuvných modulů, a to pro každou platformu zvlášť. Pozdějším přidáním další platformy poté vždy dojde ke stažení zdrojových kódů pluginů i pro tuto novou platformu (jsou-li pro tuto platformu dostupné).
9.3 Založení projektu Založení projektu (a tedy vytvoření příslušné souborové struktury) se provádí pomocí příkazové řádky, konkrétně příkazem cordova create. Nástroje příkazové řádky jsou základním způsobem ovládání jádra Cordova i pro další operace. Po založení projektu je vhodné specifikovat cílové platformy, pro které bude aplikace vyvíjena. V případě této ukázkové aplikace budeme používat platformy Android a Windows Phone 8. Vzhledem k tomu, že vývoj byl prováděn v operačním systému Windows, nelze cílit operační systém iOS. Pro vývoj pro prostředí iOS je potřeba mít k dispozici prostředí Mac OS. Funkčně by se ale nic jiného neměnilo – všechny ostatní činnosti probíhají na prostředích Windows i Mac zcela shodně. PhoneGap/Cordova pracuje s konceptem zásuvných modulů (v dalším textu budeme používat běžnější termín „plugin“). Pluginy poskytují funkcionalitu (především JavaScriptové API) pro přístup k systémovým prostředkům či pro pokročilejší funkce. V případě oficiálních základních pluginů, které jsou součástí projektu Cordova, se jedná zejména o
přístup k systémovým informacím,
přístup k údajům ze senzorů (GPS, akcelerometr, kompas, ...),
přístup k fotoaparátu,
možnost využití notifikačních systémů,
přístup k seznamu kontaktů,
funkci vnořeného internetového prohlížeče (InAppBrowser),
apod. 49
Kompletní seznam dostupných modulů je k dispozici na stránkách s dokumentací projektu PhoneGap/Cordova. Po založení projektu je tedy vhodné přidat alespoň základní moduly, se kterými budeme dále pracovat. V případě naší aplikace se jedná o tyto:
Device API (org.apache.cordova.device) – přístup k informacím o zařízení (název zařízení, kódové označení, operační systém a jeho verze, ...);
Network
Information
information)
–
ten
(org.apache.cordova.network-
v aplikaci
využíváme
ke
zjištění
typu
internetového připojení, které je v danou chvíli k dispozici;
Geolocation (org.apache.cordova.geolocation) – využíván pro získání přístupu k senzoru GPS;
Dialogs
(org.apache.cordova.dialogs)
–
pro
přístup
k notifikačním systémům operačního systému zařízení;
InnAppBrowser zobrazení
(org.apache.cordova.inappbrowser)
vnořeného
webového
prohlížeče,
který
–
pro
v aplikaci
využíváme pro přístup k platební bráně. Oficiálních pluginů je k dispozici velké množství. Lze v nich vyhledávat pomocí příkazu cordova plugin search. V naší aplikaci žádný z dalších pluginů použit není. Mimo oficiální pluginy existuje i velké množství pluginů vyvíjených třetími stranami případně komunitou vývojářů. Jejich instalace je možná při použití systému Git.
9.4 Přístup k lokálnímu úložišti PhoneGap/Cordova umožňuje aplikacím přistupovat do lokálního úložiště zařízení. Data zde uložená jsou přístupná i při dalších spuštěních aplikace. Implementace tohoto úložiště se na jednotlivých platformách může lišit, PhoneGap/Cordova však zajišťuje jednotný přístup bez ohledu na aktuální platformu.
50
V kódu aplikace je možné k lokálnímu úložišti přistupovat pomocí funkcí window.localStorage.getItem() a window.localStorage.setItem().
9.5 Implementace autentizačního mechanismu Pro jednotný autentizační mechanismus (Single Sign On) lze použít různé poskytovatele identit. Pro naši aplikaci jsme zvolili jeden z nejpoužívanějších, kterým je sociální síť Facebook. Platformně specifické aplikace zpravidla mají možnost připojení na API poskytované oficiální aplikací Facebook. PhoneGap/Cordova v aktuální verzi nic takového nenabízí. K dispozici je však velké množství neoficiálních pluginů, nejčastěji pro platformu Android, případně iOS. Jejich implementace je však nepříjemně závislá na verzi Cordova projektu a jsou často nekompatibilní s novějšími verzemi. Jelikož se ale jedná o silně platformně závislé implementace, v kontextu této práce se jimi nebudeme podrobněji zabývat. Abychom docílili co největší platformní nezávislosti, použijeme implementaci založenou na vnořeném prohlížeči. Vycházet budeme z veřejně přístupného projektu phonegap.facebook.inappbrowser2. Principem tohoto řešení je využití mobilní verze přihlašovací stránky Facebooku a OpenGraph protokolu3. Naše aplikace pomocí InAppBrowser otevře vnořené okno prohlížeče, přičemž je možné do tohoto okna registrovat tzv. callbacky, pomocí kterých můžeme zachytit a nějakým způsobem zpracovat události probíhající v tomto vnořeném prohlížeči. Můžeme tak zachytit následující situace:
Loadstart – tato událost je vyvolána při každém načtení stránky;
Loadstop – událost vyvolaná po dokončení načítání stránky;
Ten take používá ukázková aplikace. Je dostupný na GitHub repositáři https://github.com/caiovaccaro/phonegap.facebook.inappbrowser 3 OpenGraph je protokol založený na grafových objektech reprezentujících sociální síť, sloužící k integraci webových aplikací do sociálních sítí (zdroj: [23]). Více informací lze nalézt ve zdroji [24]. 2
51
Loaderror – událost zachycená v případě, že prohlížeč přijme jiný HTTP výsledek než HTTP 200 OK (například tedy v situaci, kdy požadovaná stránka není nalezena apod.);
Exit – událost vyvolaná při uzavření vnořeného prohlížeče.
Vnořený prohlížeč je možné z naší aplikace (tj. z vnějšku) uzavřít pomocí funkce close(). Mimo to je možné jej uzavřít ze stránky v něm zobrazené JavaScriptovým kódem (window.close()). Některé platformy (např. Windows Phone) poskytují možnost uzavřít tento prohlížeč ručně pomocí zavíracího tlačítka. Pro přihlášení uživatele tedy v naší aplikaci musíme provést následující kroky:
Zobrazit přihlašovací stránku Facebooku v InAppBrowseru (je nutné zaslat ID aplikace, které vývojář aplikace obdrží po její registraci na Facebooku).
Předat námi zvolené URL, na které má být uživatel přesměrován po úspěšném přihlášení. Na základě tohoto URL poté testujeme úspěšnost přihlášení.
V aplikaci zachytit pomocí události Loadstart přesměrování na toto URL, které Facebook automaticky doplní o autentizační token.
Tento token je potřeba z adresy extrahovat a uložit jej do lokálního úložiště aplikace.
Takto získaný autentizační token můžeme dále využít i pro další požadavky zasílané pomocí OpenGraph protokolu do Facebooku (například pro získání osobních údajů uživatele apod.). Zde je vhodné poznamenat, že vývojář aplikace musí při její registraci na Facebooku mimo jiné zadat i oprávnění, která tato aplikace požaduje (např. zda vyžaduje přístup k seznamu uživatelových přátel, přístup na uživatelovu Facebook Wall, přístup k fotografiím, možnost měnit Facebook Status apod.). Tato požadovaná oprávnění jsou uživateli na přihlašovací stránce vypsána. Kterékoliv další OpenGraph požadavky jsou poté na základě těchto oprávnění autorizovány.
52
Pro odhlášení je nutné zaslat HTTP požadavek obsahující přihlašovací token. Tím se tento token stane neplatným a my jej můžeme z lokálního úložiště odstranit. Tím docílíme požadovaného maximálního zjednodušení autentizačního procesu. Uživatel pro přihlášení musí zadat jméno a heslo pouze poprvé. Do okamžiku, než se explicitně odhlásí, je autentizační token uložen v úložišti zařízení a uživatel poté při dalším přihlášení přihlašovací stránku vůbec nevidí a je automaticky přesměrován zpět do aplikace. Nevýhodou tohoto principu je fakt, že zařízení musí být po celou dobu přihlašovacího procesu připojeno k internetu. Další nevýhodou je, že vzhled přihlašovací aplikace je plně v režimu Facebooku a naše aplikace nemá možnost jej ovlivnit. Další nevýhodou je závislost na aplikaci třetí strany – dojde-li ke změně Facebook OpenGraph API bez zpětné kompatibility, aplikace se může stát nefunkční. Je však pravdou, že tento způsob je celosvětově využíván velkým množstvím webových aplikací a proto zpětně nekompatibilní změny ze strany Facebooku nejsou pravděpodobné. Zajímavou alternativou by bylo využít přímo vestavěných účtů systému (tedy např. Google accounts v případě Android zařízení, Microsoft Live ID v případě Windows Phone zařízení či Apple ID v případě systému iOS). Problémem je, že aplikace by přestala být multiplatformní a především, PhoneGap bohužel v současné době takovou možnost vůbec nenabízí.
9.6 Implementace notifikací Každá platforma má k dispozici určitou sadu notifikačních dialogů. V naší aplikaci využíváme pouze základní notifikační okno, které zobrazí zprávu a uživatel jej může odklepnout. K tomu slouží funkce navigator.notification.alert().
9.7 Použití geolokačních služeb Existuje plugin Geolocation, který umožňuje zjištění aktuální pozice pomocí funkce getCurrentPosition(). Údaje jsou vráceny pomocí callbacku. 53
K dispozici jsou informace o
zeměpisné délce,
zeměpisné šířce,
nadmořské výšce,
přesnosti zeměpisné délky a šířky,
přesnosti nadmořské výšky,
směru pohybu,
rychlosti,
aktuálnímu času.
Při volání funkce můžeme volitelně zadat parametry určující, zda má být použit vestavěný GPS přijímač, nebo stačí polohu získat pomocí prostředků GSM sítě (což je rychlejší a méně náročné na baterii, ale výrazně méně přesné). Požadavek na použití GPS přijímače se provádí nastavením parametru enableHighAccuracy na hodnotu True. Pokud chceme sledovat polohu kontinuálně, je potřeba použít funkci watchPosition(), který sleduje hodnoty GPS přijímače a vyvolává zpětné volání pokaždé, když dojde ke změně souřadnic.
9.8 Implementace on-line plateb K implementaci plateb je možné využít tzv. platby z aplikací (in-app purchases). V PhoneGap/Cordova je k tomu možné využít např. oficiálně podporovaného pluginu com.smartmobilesoftware.inappbilling. Problémem je, že licenční podmínky jednotlivých výrobců platbu za reálné zboží a služby neumožňují. In-App payments je možné využít jen a pouze pro prodej digitálního obsahu či obsahu konzumovaného přímo v mobilní aplikaci (tedy například bonusové úrovně mobilních her apod.). Pro prodej reálného zboží či služeb tuto funkcionalitu použít nelze. Pro umožnění online plateb v rámci aplikace je tedy nutné využít opět funkce vnořeného prohlížeče. Princip je velmi podobný tomu, co bylo využito pro přihlašování pomocí Facebooku. Uživateli je platební brána zobrazována 54
ve vnořeném prohlížeči. Celý platební proces je realizován tímto způsobem a je tedy plně v režii vzdáleného platebního serveru. Tím je zajištěno, že v aplikaci není nutno přechovávat ani zpracovávat citlivé údaje (jako například čísla platebních karet). Samotný přenos výsledku platební transakce (aby nemohl být podvržen například změnou URL) bývá většinou zabezpečen šifrovaným klíčem, případně hashováním. Vzhledem k tomu, že provoz platební brány je nákladnou záležitostí, bývají online platby v drtivé většině případů realizovány pomocí existujících systémů třetích stran. Poskytovatel platební brány většinou umožňuje přizpůsobit si vzhled všech stránek platebního procesu pomocí systému šablon, čímž můžeme docílit plné vzhledové integrace se zbytkem aplikace. Ukázková aplikace jako simulovanou platební bránu používá jednoduchou serverovou aplikaci implementovanou na platformě ASP.NET. Ta umožňuje dvěma tlačítky nasimulovat přesměrování na adresu odpovídající úspěšné či neúspěšné transakci a zpětné přenesení náhodně vytvořeného řetězce (simulující přenášení např. ID transakce či hashovaného výsledku). Zdrojové kódy této serverové aplikace jsou součástí elektronické přílohy této diplomové práce.
9.9 Kompilace, ladění a testování Vnitřní JavaScriptový kód, který se sám o sobě nekompiluje, můžeme vyvíjet v libovolném vývojovém prostředí (např. Microsoft Visual Studio, Eclipse, NetBeans, ...). Pro některá vývojová prostředí existují již předpřipravené šablony a sady nástrojů pro PhoneGap/Cordova projekty. V těchto vývojových prostředích pak většinou bývá vestavěna podpora pro syntaktickou a sémantickou kontrolu kódu během psaní, a to na úrovni výpisu varování či zvýrazňování chyb v editoru. Kompilaci celého PhoneGap projektu můžeme poté provádět lokálně pomocí příkazové řádky příkazem cordova build (přičemž vždy specifikujeme platformu, pro kterou chceme kompilovat), nebo máme možnost využít cloudové služby PhoneGap Build, která umožňuje jedním příkazem nahrát
55
zdrojové soubory na server, kde jsou automaticky zkompilovány pro všechny dostupné platformy. Ladit poté lze jen cílový kód pro konkrétní platformu. Ladění zdrojových kódů (HTML, JavaScript) je sice teoreticky možné ve webových prohlížečích, nicméně ty jsou v mnohém odlišné od prostředí PhoneGap obalovače na konkrétním zařízení a celý proces ladění je tak velmi obtížný a prakticky nepoužitelný. Kód specifický pro danou platformu získáme příkazem cordova prepare. Takový kód je poté vytvořen jako projekt pro vývojové prostředí odpovídající dané platformě:
pro Windows Phone jako Visual Studio Solution,
pro Android jako Eclipse projekt,
pro iOS jako xCode projekt.
Takový projekt poté můžeme bezproblémově otevřít v daném vývojovém prostředí, kde již bývá k dispozici plnohodnotný ladící nástroj. Ten pak umožní snadné krokování, zastavování aplikace za běhu, sledování obsahu proměnných apod. Je však třeba mít na paměti, že veškeré úpravy je nutné dělat ve zdrojových kódech PhoneGap projektu, neboť všechny soubory platformně specifických projektů jsou při další kompilaci přepsány. Nemáme-li k dispozici plnohodnotný ladící nástroj pro danou platformu, je v některých případech možné sledovat alespoň chybový výstup emulátorů jednotlivých platforem. Pro Android to lze pomocí nástroje Android Debug Bridge (příkazem adb logcat), pro Windows Phone není jiná možnost, než využít okno Output Window prostředí Visual Studia. Pro testování je možné využít emulátory. Ty jsou k dispozici pro všechny platformy, většinou v různých variantách. Problémem zde může být, že emulátory standardně nemají k dispozici GSM síť, neumožňují vypnout GPS anténu, simulovat slabou baterii apod. K tomu je poté nutné využít již konkrétní zařízení. Vývojová prostředí (např. Android Studio či Microsoft
56
Visual Studio) umožňují připojení ladícího nástroje k fyzickému zařízení (a provádět tzv. Debugging Over USB).
9.10 Ukázková aplikace Implementovaná ukázková aplikace si klade za cíl demonstrovat základní principy, které je možné použít při implementaci komerčních aplikací. Uživatelské rozhraní aplikace sestává z výchozího okna s následující funkcionalitou:
V horní části jsou zobrazeny základní informace o zařízení. Je vypsán název zařízení a operačního systému, ve kterém je aplikace aktuálně spuštěna.
V další části je zobrazena informace o typu aktuálního připojení k internetu – zda-li je uživatel připojen k mobilnímu internetu (2G sítě apod.), k vysokorychlostnímu mobilnímu internetu (3G sítě apod.) či k WiFi.
Obr. 6: Výřez obrazovky ukázkové aplikace – informace o zařízení Zpracování: autor
Následuje tabulka, ve které je po inicializaci GPS senzoru (která proběhne automaticky po spuštění aplikace) zobrazována neustále aktuální poloha získaná z GPS modulu. Konkrétně jsou vypsány GPS souřadnice a číselné vyjádření přesnosti. Všechny tyto informace jsou průběžně aktualizovány.
Obr. 7: Výřez obrazovky ukázkové aplikace – údaje ze senzoru GPS Zpracování: autor
57
V další části jsou k dispozici tlačítka pro ovládání Single Sign-On přihlašování pomocí Facebookového účtu. Po kliknutí na tlačítko „Přihlásit se Facebookem“ je zobrazena standardní přihlašovací obrazovka Facebooku. Na ní má uživatel možnost zadat uživatelské jméno a heslo. Po úspěšném přihlášení je přihlašovací stránka automaticky skryta. Přihlášený uživatel může dále pomocí tlačítka „User info“ zobrazit v tabulce své Facebook ID, jméno a e-mail. Tyto údaje jsou staženy on-line z Facebooku pomocí protokolu OpenGraph. Při dalším klepnutí na tlačítko „Přihlásit se Facebookem“ je již uživatel přihlášen bez zobrazení přihlašovací obrazovky, neboť autentizační token je uložen v lokálním úložišti zařízení. Přihlášený uživatel může dále tento token deaktivovat (odhlásit se) a smazat kliknutím na tlačítko „Odhlásit“. Postup je znázorněn na následujících tří obrázcích.
Obr. 8: Výřez obrazovky ukázkové aplikace – sekce Facebook před přihlášením uživatele. Zpracování: autor
Obr. 9: Výřez obrazovky ukázkové aplikace – přihlašovací obrazovka zobrazená po kliknutí na tlačítko „Přihlásit se Facebookem“ Zpracování: autor 58
Obr. 10: Výřez obrazovky ukázkové aplikace – sekce Facebook po přihlášení uživatele a získání uživatelských informací z Facebooku. Zpracování: autor
V poslední sekci je k dispozici tlačítko „Zaplatit“, po jehož stisknutí se uživateli zobrazí simulovaná platební brána. Na té má uživatel možnost jednoduchým tlačítkem nasimulovat úspěšnou či neúspěšnou platbu. Poté je platební brána automaticky skryta a v tabulce je uživateli zobrazeno ID platby přijaté ze serveru platební brány. To má simulovat
možnosti
přenosu
informací
mezi
platební
bránou
a aplikací.
Ve spodní části okna aplikace jsou vypsány aktuální informace z logu – uživatel má možnost v reálném čase vidět, jaké operace aplikace provádí, jaké požadavky odesílá, případně jaké chyby se vyskytují.
Součástí reálné komerční aplikace pro prodej zboží by byly ještě stránky s výpisem sortimentu, stránky s detaily jednotlivých produktů, možnost přidávat položky do košíku apod. Aby vše fungovalo on-line a uživatel měl možnost pracovat s aktuálními daty, musela by veškerá tato aplikační logika být realizována na serverové straně. Samotná mobilní aplikace by tak pouze odesílala HTTP požadavky (např. ve formátu XML či JSON) a zobrazovala odpovědi v uživatelském rozhraní. Implementace serverové logiky je nad rámec této práce. Odesílání HTTP požadavků z JavaScript kódu a zobrazování výsledků v HTML je technologicky jednoduchá záležitost a především to nijak nesouvisí s platformou PhoneGap ani mobilními aplikacemi obecně, ukázková aplikace tedy tuto funkcionalitu neobsahuje.
59
Ukázková aplikace byla v rámci vývoje otestována
v emulátoru zařízení Galaxy Nexus s operačním systémem Android ,
v emulátoru zařízení Nokia Lumia s operačním systémem Windows Phone,
v reálném zařízení Nokia Lumia 920.
Na následujících obrázcích můžeme vidět výřezy obrazovky zachycující aplikaci v těchto emulátorech a fotografii aplikace spuštěné v zařízení Nokia Lumia.
Obr. 11: Snímek obrazovky ukázkové aplikace spuštěné v emulátorech Android a Windows Phone a zařízení Lumia Zpracování: Autor Ve všech třech případech byla aplikace plně funkční a vzhledově i funkčně shodná. Lze předpokládat, že shodného výsledku by bylo dosaženo i v zařízení BlackBerry 10, kde by však bylo zapotřebí mít k dispozici vývojářský klíč k podpisu aplikace, či v zařízení Apple iPhone, kde by bylo kromě vývojářského klíče nutné použít počítač vybavený systémem Mac OS.
60
9.11 Výhody a nevýhody platformy PhoneGap Jako velká výhoda se v průběhu implementace ukázala vysoká míra abstrakce nad platformně specifickým vývojem. Vývoj pro každou z mobilních platforem se výrazně liší, jsou použity různé principy, různé návrhové vzory a zcela odlišné architektury projektů. Pro vývoj PhoneGap, resp. Cordova aplikací není nutné je znát. Přesto je však pro praktický vývoj, ladění a testování potřeba obsluhovat velké množství nástrojů. Ať už jsou to ladící nástroje, emulátory či jednotlivá SDK, existuje jich vždy mnoho variant v různých verzích a udržet celou tuto sadu nástrojů v takové kombinaci, kdy je vše se vším kompatibilní, je velmi obtížné. Velkým úskalím platformy PhoneGap je obtížný přístup k některým funkcím jednotlivých zařízení. Zatímco používání některých komponent (např. GPS senzor, síťové připojení, notifikační mechanismy) je velmi snadný, jiné komponenty jsou pro PhoneGap vývojáře nedosažitelné (např. vestavěné autentizační mechanismy spjaté s účtem v telefonu). Díky použitému principu pluginů se však tato platforma velmi rychle vyvíjí a rozšiřuje a je pravděpodobné, že chybějící funkcionalita bude v blízké budoucnosti doplněna. Velké množství pluginů se však v některých případech ukázalo i jako nevýhoda. Často bylo obtížné nalézt vhodnou kombinaci komponent tak, aby všechny části aplikace byly mezi sebou kompatibilní. Oproti platformně specifickým vývojovým prostředím (jako např. Visual Studio spolu s Windows Phone SDK) je ladění a testování PhoneGap projektů mnohem obtížnější. Možnost použít jednoduchých a standardizovaných jazyků a technologií (zejména HTML, CSS a JavaScript) však tuto nevýhodu do značné míry kompenzuje. Celkově lze tedy říci, že pro některé typy aplikací je platforma PhoneGap nevhodnou volbou. Pro velkou část aplikací však výhody značně převyšují nevýhody a platforma PhoneGap může výrazně usnadnit vývoj. 61
10 Závěr Prodej zboží přes internet či prostřednictvím zásilkových služeb nabývá stále většího podílu na celkovém objemu obchodování a zaznamenává rovněž prakticky trvalý nárůst. Rozvoj a zdokonalování tohoto způsobu prodeje proto patří k prvořadým zájmům obchodních firem i jejich dodavatelů potřebných informačních a komunikačních technologií. Vývoj a masové rozšíření mobilních zařízení, jako jsou mobilní telefony, tablety, lehké přenosné počítače, přinesl obrovské možnosti jejich využití v oblasti prodeje zboží či služeb. Tématem diplomové práce byl vývoj multiplatformních mobilních aplikací pro prodej zboží, tj. zjednodušeně vývoj aplikací sloužících k podpoře prodeje zboží využitelných na mobilních zařízeních různých typů, výrobců, základního softwarového vybavení. Jedná se velmi rozsáhlou a novou problematiku s vysokou dynamikou vývoje a zároveň perspektivou růstu využití. Pro dosažení cílů práce bylo provedeno:
studium základní dostupné odborné literatury a publikovaných článků k oboru,
poznání platforem používaných na mobilních zařízeních,
nastudování způsobů vývoje, vývojových rámců a nástrojů,
volba a zvládnutí používaných softwarových prostředků, technologií a metod,
instalace vývojových prostředí, SDK, emulátorů platforem,
naprogramování
ukázkové
aplikace
demonstrující
vybranou
funkcionalitu potřebnou k vývoji aplikace pro prodej zboží či služeb,
testování, ladění a ověření funkčnosti na emulátorech i skutečných fyzických zařízeních – mobilních telefonech různých platforem,
62
zpracování a vyhodnocení vývoje multiplatformních aplikací.
V práci byla zvolena platforma Adobe PhoneGap resp. její open source varianta
Apache
Cordova.
V průběhu
studia,
analýzy
i
následné
implementace aplikace se ukázalo, že vývoj na této platformě se vyznačuje mnoha výhodami i nevýhodami. Je zřejmé, že pro některé typy aplikací může použití této technologie výrazně usnadnit vývoj, zatímco pro jiné typy aplikací je zcela nevhodné. Ačkoliv se podařilo pomocí této platformy implementovat veškerou požadovanou funkcionalitu, některé části aplikace by při použití jiných přístupů mohly být naimplementovány výrazně lépe. Lze však s jistotou říci, že výhody, které tvůrci aplikace platforma PhoneGap přináší, jsou nezanedbatelné a před započetím vývoje rozhodně stojí za zvážení. Velkým úskalím se ukázal nedostatek konzistentních a relevantních materiálů a literatury. Práce byla obtížná i z toho pohledu, že v průběhu studia i během implementace
platforma
procházela
vývojem
a
použité
knihovny,
komponenty a nástroje se mnohokrát změnily. Vývoj pro mobilní zařízení je velmi dynamický obor, nástroje jsou vyvíjeny překotným tempem a jednotlivé verze knihoven se od sebe výrazně liší. Stejně tak zařízení, na kterých mají být reálné aplikace provozovány, jsou vyvíjena velmi rychle a každým rokem přinášejí nové, dříve nedostupné možnosti. I to činí multiplatformní vývoj velmi perspektivním, neboť vytvářet a udržovat aplikace pro každou platformu zvlášť by bylo při tomto tempu vývoje velmi náročné.
63
11 Seznam použitých zkratek 11.1 Označení firem Adobe
Adobe Systems Incorporated, USA
Apple
Apple Inc., USA
BlackBerry
BlackBerry Limited, Kanada
Google
Google Inc., USA
Microsoft
Microsoft Corporation, USA
Nokia
Nokia Corporation, Finsko
11.2 Použité zkratky a zkrácená označení Popis významu vychází buď z informací uvedených v této diplomové práci, nebo je převzat z internetu či Wikipedie Android
Rozsáhlá open source platforma, která vznikla zejména pro mobilní zařízení (chytré telefony, PDA, navigace, tablety). Zahrnuje v sobě operační systém (založený na jádru Linux), middleware, uživatelské rozhraní a aplikace.
API
Zkratka pro Application Programming Interface označuje v informatice rozhraní pro programování aplikací
CSS
Kaskádové styly (v anglickém originále Cascading Style Sheets se zkratkou CSS) je jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML.
GPS
Global Positioning System, česky Globální polohovací systém, je vojenský globální družicový polohový systém provozovaný Ministerstvem obrany Spojených států amerických, s jehož
64
pomocí je možno určit polohu a přesný čas kdekoliv na Zemi nebo nad Zemí s přesností do deseti metrů. HTML
HyperText Markup Language, značkovací jazyk pro hypertext. Je hlavním z jazyků pro vytváření stránek v systému World Wide Web, který umožňuje publikaci dokumentů na Internetu.
iOS
iOS je mobilní operační systém vytvořený společností Apple Inc. Původně byl určen pouze pro mobilní telefony iPhone, později se však začal používat i na dalších mobilních zařízeních této firmy, jako jsou iPod Touch, iPad a nejnověji Apple TV.
iPad
Multimediální počítač typu tablet od společnosti Apple. Používá operační systém iOS od Apple
iPhone
iPhone je produkt společnosti Apple, který v sobě spojuje funkce mobilního telefonu s kapesním počítačem. Ovládá se pomocí velkého dotykového displeje s virtuální klávesnicí. Při svém uvedení v roce 2007 iPhone přinesl jako jeden z prvních mobilních telefonů vícedotykové ovládání a zároveň díky vysokým prodejům a oblibě popularizoval celou kategorii smartphonů. iPhone používá operační systém iOS, který je založený na Mac OS X.
.NET
Zastřešující název pro soubor technologií v softwarových produktech, které tvoří celou platformu, která je dostupná nejen pro Web, Windows i Pocket PC. Základní komponentou je Microsoft .NET Framework, prostředí potřebné pro běh aplikací a nabízející jak spouštěcí rozhraní, tak potřebné knihovny. Pro vývoj .NET aplikací vydal Microsoft Visual Studio .NET.
QR kód
Anglicky QR Code je prostředek pro automatizovaný sběr dat. Zkratka vychází z anglického „Quick Response“, tedy kódy rychlé reakce.
65
SDK
Software development kit (SDK nebo "devkit") je zpravidla soubor nástrojů pro vývoj software, který umožňuje tvorbu aplikací pro určitou softwarovou nebo hardwarovou platformu, počítačový systém, herní konzolu, operační systém nebo podobné vývojové platformy
Windows Phone
Obchodní název mobilního operačního systému firmy Microsoft. Jedná se o nástupce systému Windows Mobile, se kterým však není zpětně kompatibilní.
ZIP
Všeobecně rozšířený souborový formát pro kompresi a archivaci dat.
66
12 Seznam použitých zdrojů [1]
WANG, Shuo CHEN a XiaoFeng WANG. Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services. Microsoft Research [online]. 2012 [cit. 2013-11-20]. Dostupné z: http://research.microsoft.com/apps/pubs/default.aspx?id=160659
[2]
OAuth. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013, 2013-10-17 [cit. 2013-1120]. Dostupné z: http://cs.wikipedia.org/wiki/OAuth
[3]
Smartphone. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013, 2013-12-04 [cit. 2013-12-05].
[4]
Average Selling Prices in Each Category in 2012 - iPhone. Mobile World Live: Distimo: the app store market in 2012 [online]. 2013, 201301-01 [cit. 2013-12-05]. Dostupné z: http://www.mobileworldlive.com/distimo-the-app-store-marketin-2012/average-selling-prices-in-each-category-in-2012-iphone
[5]
SCOTT, Austin. The Surprising Numbers Behind Apps. Wall Street Journal: Digits [online]. 2013, [cit. 2013-11-20]. Dostupné z: http://blogs.wsj.com/digits/2013/03/11/the-surprising-numbersbehind-apps/
[6]
GOOGLE INC. Android Developer Tools [online]. 2013 [cit. 2013-1125]. Dostupné z: http://developer.android.com/tools/index.html
[7]
MULLANY, Michael.5 Myths About Mobile Web Performance. Sencha [online]. 2013, 2013-08-01 [cit. 2013-11-20]. Dostupné z: http://www.sencha.com/blog/5-myths-about-mobile-webperformance/ 67
[8]
AVOLA, Greg a Jon RAASCH. Smashing mobile web development: going mobile with HTML5, CSS3 and Javascript [electronic resource]. 2013. vyd. Chichester, U.K.: Wiley, 2013 [cit. 2013-11-15]. Dostupné z: http://site.ebrary.com/lib/masaryk/Doc?id=10657799
[9]
STATCOUNER. GlobalStats StatCounter [online]. 2013, 2013-12-01 [cit. 2013-12-05]. Dostupné z: http://gs.statcounter.com/#mobile_osww-monthly-201212-201311-bar
[10]
POSEJPAL, Jan. StatCounter: Na českém mobilním internetu vede Android. Mobilmania.cz [online]. 2012 [cit. 2013-11-20]. Dostupné z: http://www.mobilmania.cz/statcounter-na-ceskem-mobilniminternetu-vede-android/a-1321239/default.aspx
[11]
STATCOUNTER. About StatCounter [online]. 2013 [cit. 2013-11-20]. Dostupné z: http://gs.statcounter.com/about
[12]
Features and Unsupported APIs. BLACKBERRY LIMITED. Blackberry Developer [online]. 2013 [cit. 2013-11-08]. Dostupné z: http://developer.blackberry.com/android/apisupport/
[13]
SHI, Chuan. HTML5 mobile development cookbook: over 60 recipes for building fast, responsive HTML5 mobile websites for iPhone 5, Android, Windows Phone, and Blackberry. Birmingham, U.K.: Packt Pub., 2012, iii, 235 p. ISBN 9781849691970.
[14]
OLSON, Scott a Scott OLSON. Professional cross-platform mobile development in C#: over 60 recipes for building fast, responsive HTML5 mobile websites for iPhone 5, Android, Windows Phone, and Blackberry. Indianapolis, IN: Wiley, 2012, xxvi, 357 p. ISBN 9781118226032.
[15]
ŠEBOŠÍK, Boris. Multiplatformový vývoj mobilných aplikácií pomocou webových technológií. Brno, 2012. Diplomová práce. Masarykova univerzita, Fakulta informatiky. Vedoucí práce RNDr. Jaroslav Škrabálek, MBA. 68
[16]
PIETRZYK, Matúš. Vývoj multiplatformových aplikácií pre múdre telefóny. Brno, 2013. Bakalářská práce. Masarykova univerzita, Fakulta informatiky. Vedoucí práce doc. RNDr. Vlastislav Dohnal, Ph.D.
[17]
Secure OAuth in Javascript. Stack Overflow [online]. 2013 [cit. 201311-25]. Dostupné z: http://stackoverflow.com/questions/6144826/secure-oauth-injavascript
[18]
JOYENT, Inc. Node.js [online]. [cit. 2013-12-26]. Dostupné z: http://nodejs.org/
[19]
APACHE SOFTWARE FOUNDATION. Apache Cordova [online]. 2013 [cit. 2013-12-26]. Dostupné z: http://cordova.apache.org/
[20]
APACHE SOFTWARE FOUNDATION. The Apache Ant Project [online]. 2013 [cit. 2013-12-26]. Dostupné z: http://ant.apache.org/
[21]
Git. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013 [cit. 2013-12-26]. Dostupné z: http://cs.wikipedia.org/wiki/Git
[22]
ADOBE SYSTEMS INCORPORATED. PhoneGap Build [online]. 2013 [cit. 2013-12-26]. Dostupné z: http://build.phonegap.com
[23]
Facebook Platform. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013, 2013-12-19 [cit. 2014-01-06]. Dostupné z: http://en.wikipedia.org/wiki/Facebook_Platform#Open_Graph_pro tocol
[24]
Open Graph. FACEBOOK. Facebook Developers [online]. 2013 [cit. 2014-01-06]. Dostupné z: https://developers.facebook.com/docs/opengraph/ 69
