BAKALÁŘSKÁ PRÁCE. Aplikace optimalizující distribuci obsahu pro mobilní zařízení Martin Hořava

PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY

BAKALÁŘSKÁ PRÁCE

Aplikace optimalizující distribuci obsahu pro mobilní zařízení

2013

Martin Hořava

Anotace Jako výsledek práce je vytvořena aplikace určená pro chytrá zařízení, která za pomocí technik jako je cachování a komprese snižují velikost dat stahovaných přes síť Internet. Dále je součástí aplikace webová služba, která slouží jako poskytovatel dat pro ostatní aplikace. Aplikace měří přenášená data a tudíž je možné provést porovnání o kolik se zmenší velikost datového přenosu použití aplikace oproti použitím webového prohlížeče k prohlédnutí obsahu.

Děkuji svému vedoucímu práce, Mgr. Petru Krajčovi, Ph.D. za jeho cenné rady a připomínky při skvělém vedení práce. Dále děkuji Štěpánu Klokočkovi za jeho pomoc a konzultaci a určitě v neposlední řadě děkuji celé rodině za jejich velkou podporu.

Obsah 1. Úvod 1.1. Cíl práce . . . . . . . . . . . . . . . . . . . 1.2. Motivace . . . . . . . . . . . . . . . . . . . 1.3. Mnou navrhnuté řešení . . . . . . . . . . . 1.4. Alternativní možnosti řešení . . . . . . . . 1.4.1. Appcelator Titanium . . . . . . . . 1.4.2. AT&T Workbench a Antenna Volt 1.4.3. HTML a CSS . . . . . . . . . . . .

. . . . . . .

8 8 8 8 9 9 9 10

2. Architektura aplikace 2.1. Popis serverové aplikace . . . . . . . . . . . . . . . . . . . . . . . 2.2. Popis klientské aplikace . . . . . . . . . . . . . . . . . . . . . . . .

11 11 13

3. Použité technologie 3.1. Serverová aplikace . . . . . . . . . . . . . . 3.1.1. PHP a framework Yiii . . . . . . . . 3.1.2. REST rozhraní . . . . . . . . . . . . 3.2. Klientská aplikace . . . . . . . . . . . . . . . 3.2.1. Phonegap . . . . . . . . . . . . . . . 3.2.2. HTML . . . . . . . . . . . . . . . . . 3.2.3. CSS . . . . . . . . . . . . . . . . . . 3.2.4. Javascript . . . . . . . . . . . . . . . 3.2.5. jQuery . . . . . . . . . . . . . . . . . 3.3. AJAX . . . . . . . . . . . . . . . . . . . . . 3.4. Využívané datové formáty . . . . . . . . . . 3.4.1. JSON . . . . . . . . . . . . . . . . . 3.4.2. XML . . . . . . . . . . . . . . . . . . 3.5. Metody pro snížení objemu přenášených dat 3.6. Šablony . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

16 16 16 17 17 18 19 19 19 19 20 20 20 20 20 21

4. Platformy 4.1. Serverová aplikace 4.1.1. Android . . 4.1.2. iOS . . . . . 4.2. Windows Phone . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

23 23 23 25 26

síti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 27 27

5. Metody snížení 5.1. Cachování . 5.2. Komprese . 5.3. GZIP . . . .

. . . .

. . . .

. . . .

. . . .

přenosu dat . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

po . . . . . .

. . . .

6. Optimalizace času přenosu dat

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

28 4

7. Měření objemu přenášených dat 7.1. Porovnání formátů přenášených dat . . . . . . . . . . . . . . . . . 7.2. Naměřené hodnoty při použití komprimace . . . . . . . . . . . . . 7.3. Porovnání aplikace s webovým prohlížečem . . . . . . . . . . . . .

29 29 29 30

8. Programátorská dokumentace 8.1. Serverová aplikace . . . . . . . . 8.1.1. Třída pro práci s daty . . 8.1.2. Třída zajištující logiku . . 8.1.3. Třídy zajištující zobrazení 8.2. Struktura konfiguračních dat . . . 8.3. Klientské aplikace . . . . . . . . .

32 32 32 32 33 33 33

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

9. Uživatelská dokumentace

35

Závěr

38

Reference

39

A. Obsah přiloženého CD

41

5

Seznam obrázků 1. 2. 3. 4. 5. 6. 7.

Schéma architektury Titanium . . . . . . Schéma architektury Phonegap . . . . . Vrstvy operačního systému Android.[15] Aplikace po spuštění. . . . . . . . . . . . Hlavní okno aplikace. . . . . . . . . . . . Zobrazení jednoho článku. . . . . . . . . Zobrazení modelu about. . . . . . . . . .

6

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

9 18 24 35 35 36 36

Seznam tabulek 1. 2. 3. 4. 5.

Podíl na trhu mobilních operačních systémů. [12] . . . . . . . . . Hodnoty naměřené pro implementované přenosové formáty. . . . . Hodnoty naměřené komprimované a nekomprimované. . . . . . . . Porovnání přenesených dat do aplikace pomocí XML a zobrazení pomocí webového prohlížeče. . . . . . . . . . . . . . . . . . . . . . Porovnání přenesených dat do aplikace pomocí JSON a zobrazení pomocí webového prohlížeče. . . . . . . . . . . . . . . . . . . . . .

7

23 29 30 31 31

1. 1.1.

Úvod Cíl práce

Cílem práce je vytvořit aplikaci pro mobilní zařízení jako jsou tzv. chytré telefony a tablety, která zobrazuje webové stránky s co nejmenšími nároky na datový přenos a procesorový čas. Důvody jsou prosté, přenášená data jsou zpoplatněna a omezena. Navíc pokrytí vysokorychlostním připojením je přístupné pouze ve větších městech, a proto snížením velikosti přenášených dat dojde ke zrychlení aplikace. Aplikace by neměla být náročná na procesor, protože procesor nebývá u levnějších mobilních zařízení výkonný. Mobilní zařízení jsou napájena akumulátory, takže čím nižší jsou nároky na procesor, tím méně se spotřebuje energie a mobilní zařízení vydrží delší dobu běžet. Výhodou aplikace je, že se data ukládají i do paměti mobilního zařízení, čímž umožňuje prohlížet webový obsah bez aktivního internetového připojení. Dalším cílem je, aby byla aplikace přenositelná mezi různými operačními systémy mobilních zařízení (Android, iOS, Windows Phone). Pro zmenšení přenosu dat po síti aplikace využívá několik metod, jako je datově méně náročný formát pro přenos dat, komprimace přenášených dat nebo cachování.

1.2.

Motivace

Motivací pro tuto práci byla snaha o vytvoření jednoduché aplikace k webovým stránkám, s možností prohlížení webových stránek bez internetového připojení a snížení objemu přenášených dat. Trh s mobilními zařízeními se stále rychleji rozvíjí a více lidí si kupuje „chytrý mobilní telefonÿ. Tato zařízení jsou navíc dostupnější a výkonnější. Tudíž je zajisté výhodná možnost jednoduchého vytvoření aplikace k webové prezentaci, jen pomocí zakomponování modulu do webových stránek, který zajistí rozhraní pro přístup klientské aplikace a vytvoření šablony webových stránek pro mobilní klientskou aplikaci.

1.3.

Mnou navrhnuté řešení

Za použití skriptovacího jazyku PHP a frameworku Yii[1] jsem vytvořil serverovou aplikaci. Ta slouží jako modul pro webové aplikace, která poskytuje rozhraní pro přístup klientských aplikací. Tato aplikace slouží také jako poskytovatel dat pro klientské aplikace. Pro klientskou aplikaci, která zobrazuje webové stránky optimalizované pro zařízení s různým rozlišením displeje, je použit hybridní framework Phonegap, který zajišťuje přenositelnost mezi různými operačními systémy. Phonegap staví na technologiích a jazycích HTML5[2], CSS3[3] a JavaScript. Tato aplikace pouze zobrazuje data stažená ze serverové aplikace dle šablony.

8

Titanium Aplikace Plátno

Obrázky

Videa

Ostatní

Javascriptový kód

JavaScriptové rozhraní pro mobilní aplikace

Operační systém

Obrázek 1. Schéma architektury Titanium

1.4.

Alternativní možnosti řešení

Existuje řada možností, jak vytvořit mobilní aplikaci s webovým obsahem. Nejvhodnější volbou je použití hybridního frameworku, který je většinou implementovaný jako JavaScriptová knihovna a ta je implementovaná pro více mobilních operačních systémů. Tyto implementace zajišťují možnost přenositelnosti aplikace mezi různými operačními systémy. Samotná mobilní webová aplikace je tedy napsaná v HTML5, CSS3 a JavaScriptu. 1.4.1.

Appcelator Titanium

Jednou z možností je open source framework Appcelator Titanium. Tento framework umožňuje vytváření aplikací pro mobilní zařízení v jazyku JavaScript. Nevýhoda tohoto frameworku je, že lze použít pro vývoj aplikace pouze JavaScript, protože tento framework poskytuje rozhraní pouze pro JavaScriptový kód. Tudíž musí být jak uživatelské rozhraní, tak logika napsaná v Javascriptu[4]. Architektura je vyobrazena na obrázku 1. 1.4.2.

AT&T Workbench a Antenna Volt

Tyto dva frameworky poskytují možnost spustit HTML5 kód. Toto řešení má však nevýhodu v tom, že při spuštění aplikace se musí aplikace autentizovat u tzv. back-end serveru, odkud si po autentizaci stáhne data, která jsou poté zobrazena. Uživatel vidí pouze jednu ikonku na svém zařízení, kde se po spuštění 9

objeví seznam všech možných aplikací, které daná aplikace obsahuje. Tento postup je určen pro použití ve firemních aplikacích a tam, kde je nutné často mezi aplikacemi přepínat. [4] 1.4.3.

HTML a CSS

Další možností je řešení v podobě webové stránky. Tato webová stránka může být prohlížena přes webový prohlížeč. Nevýhodou v tomto řešení však je, že se při každém načtení stránky musí stáhnout všechna data a navíc webový prohlížeč neumožňuje prohlížet webové stránky, pokud není připojen k internetu.

10

2.

Architektura aplikace

Aplikace vytvořená jako výsledek této práce se skládá ze dvou částí a to ze serverové a klientské části. Serverová část aplikace je webová aplikace, která běží na PHP serveru. Tato webová aplikace poskytuje rozhraní pro klientskou aplikaci ke stažení dat. Programátor definuje konfigurační data aplikace, konfigurační data šablony a šablonu. Předpokládá se, že data jako obsah webové stránky jsou již uložena v serverové části aplikace. Klientská aplikace si stáhne ze serverové části konfigurační data a data obsahu webu, uloží je do paměti mobilního zařízení a poté je vykreslí na displej v podobě webové stránky. Aplikace je implementovaná dle paradigmatu REST[5]. Serverová část aplikace je poskytovatel dat pro klientskou aplikaci a klientská část aplikace tyto data stahuje, uchovává a zobrazuje na displej.

2.1.

Popis serverové aplikace

Serverová část aplikace je implementovaná jako modul pro webové aplikace, které jsou vytvořeny za použití frameworku Yii. Předpokladem je tedy již vytvořená webová aplikace do které se modul začlení. Díky tomuto webová aplikace poskytuje přes rozhraní serverové aplikace data pro klientskou aplikaci. Serverová aplikace je zdroj dat pro klientskou aplikaci. Příkladem takovéto aplikace může být aplikace blog, která je součástí této práce. Umožňuje zobrazovat a upravovat články přes webový prohlížeč. Přidáním modulu do aplikace blogu je zpřístupněno rozhraní, přes které je možné stáhnout data, které obsahují texty článků. Mimo to je možné stáhnout programátorem vytvořená konfigurační data, konfigurační data pro šablonu a šablonu. Serverová část aplikace zpracovává požadavky klientské části aplikace, která vyšle požadavek tak, že přistoupí na URL adresu. Dle parametrů uvedených v URL adrese specifikuje svůj požadavek. Jaké parametry může klientská aplikace nastavit, je určeno v konfiguračních datech šablony. Serverová část aplikace dle parametrů připraví data odpovědi. Tato data poté převede do formátu JSON nebo XML dle podpory klientské aplikace. Pokud aplikace podporuje oba dva formáty, je zvolen JSON z důvodu jeho menší velikosti. Pokud klientská část aplikace podporuje komprimaci dat, jsou data zkomprimována pomocí algoritmu GZIP a odeslána do klientské aplikace protokolem HTTP. Příkladem je aplikace součástí této práce. Klientská aplikace chce stáhnout data o článku, který má ID jedna. V konfiguraci je uložena URL adresa serveru, v konfiguračních datech šablony je uložena relativní URL adresa rozhraní ke stažení jednoho článku textu dle jeho ID. Výsledná URL adresa bude vypadat takto: http://url serveru/blog/index.php/api/list?model=post&id=1.

11

Dále je uvedena ukázka odpovědi serverové části aplikace ve formátu JSON bez komprimace: [ { "id":"1", "title":"Welcome!", "content":"This blog system is developed using Yii. It is meant to demonstrate how to use Yii to build a complete real-world application. Complete source code may be found in the Yii releases. Feel free to try this system by writing new posts and posting comments.", "tags":"yii, blog", "status":"2", "create\_time":"1230952187", "update\_time":"1230952187", "author\_id":"1" } ] Ve výše uvedené ukázce jsou data ID článku, titulku článku textu (title), jeho obsah (content), tagy přiřazené ke článku (tags), status (status), který označuje, zdali je článek publikovaný, nepublikovaný nebo archivovaný. Dále čas vytvoření (create time) a čas poslední úpravy (update time) v sekundách od roku 1970 a ID autora článku (author id). Serverová aplikace dále obsahuje uložená konfigurační data a data šablony pro úpravu vzhledu výstupu dat. Tato data si již musí programátor upravit sám dle jednotlivých požadavků aplikace. Pro komunikaci je nezbytné mít výchozí URL adresu uloženou v klientské aplikaci, aby klientská aplikace věděla odkud si má stáhnout konfigurační data. Tato konfigurační data jsou v podobě pole asociativních polí, která obsahují proměnné se specifickými názvy a hodnotami nezbytnými pro chod aplikace. Tato konfigurační data musí programátor sám specifikovat a uložit do serverové aplikace. Konfigurační data mohou vypadat takto: { ’serverUrl’ => ’http://server_url/blog/index.php/api/’, ’model’ => ’post’, ’templateAddress’ => ’template/’, } Hodnota klíče serverUrl udává URL adresu odkud se mají stahovat ostatní data. Model označuje výchozí model, který se vykreslí v klientské aplikaci. Hodnota templateAddress označuje hodnotu pro relativní URL adresu, ze které si 12

klientská část aplikace stáhne konfigurační data pro šablonu. Ukázková data jsou z aplikace, která je součástí práce.

2.2.

Popis klientské aplikace

Klientská část aplikace stahuje konfigurační data, data šablony a data obsahu, která poté vykreslí na displej zařízení. Po spuštění klientská aplikace zjistí, zdali má uložená v paměti konfigurační data. Pokud nejsou konfigurační data uložena nebo již mohou být neaktuální (jsou starší, než například 24 hodin), aplikace vyšle požadavek na server o stažení dat nových. Pokud má uložená data v zařízení, tak nastaví parametr updateTime s hodnotou poslední aktualizace a server tak může vrátit pouze odpověď, že data jsou aktuální. Jinak aplikace stáhne konfigurační data ze serveru, uloží je do paměti a načte je. Po načtení konfiguračních dat aplikace provede stejný postup s konfiguračními daty pro šablonu. Po stažení, aktualizaci nebo pouhým načtením konfiguračních dat šablony z paměti aplikace zkontroluje, zdali jsou v paměti uloženy všechny potřebné soubory šablony. Aktualizace konfiguračních souborů a souborů pro šablonu probíhá stejně jako u konfiguračních dat pro aplikaci. Po určitém nastaveném intervalu se aplikace dotazuje serveru, zdali jsou novější data šablony. Pokud není aktualizace, pokračuje jejich načtením. Ukázka konfiguračních dat šablony z aplikace, která je součástí práce: { ’models’ => array( ’post’, ’about’, ), ’templateFiles’ => array( ’about’ => array( ’html’ => ’about.html’, ), ’post’ => array( ’html’ => ’post.html’, ’css’ => ’style.css’, ), ’modelAddresses’ => array( ’post’ => array( ’content’ => ’list?model={model}&id={id}&tag={tag}’, ’structure’ => ’structure/{model}/’, ), ), ’filesNames’ => array( ’post’ => array( ’content’ => ’model-{tag}-{id}.txt’, 13

’structure’ => ’stucture.txt’, ), ), ’formatStrings’ => array( ’post’ => array( ’structure’ => "

{name}

", ’content’ => "

{title}

Tags: {tags}
{content}

", ), ), ’elements’ => array( ’post’ => array( ’content’, ’structure’, ), ), ’files’ => array( ’post.html’, ’style.css’, ’about.html’, ), } • models – pole modelů, které definují, jaké stránky se budou vykreslovat. Pojem model zde označuje název určité množiny dat, která zahrnuje elementy modelu, adresy ke stažení dat a další. Zde v tomto případě označuje, že zde budou dva modely a to post a about. • elements – obsahuje seznam názvů elementů šablony. Například pro menu je zde element structure, pro obsah element content. • templateFiles – označuje pole názvů souborů pro HTML a CSS soubory šablony, rozdělené dle modelů. Zde model post obsahuje HTML soubor post.html a CSS soubor style.css. • modelAddresses – je pole relativních URL adres, odkud si má aplikace stahovat data pro jednotlivé elementy. Části textu označené například {model} jsou proměnné, za které jsou poté doplněny hodnoty z proměnných objektu šablony v klientské aplikaci. • filesNames – obsahuje pole názvů souborů pro uložení dat v mobilním zařízení. Do souborů se ukládají stahovaná data obsahu. Například pokud se stáhne náhled všech článků, budou tato data uložena do souboru model--.txt, pokud budou stahovat data pro článek textu označený ID 1, bude název souboru pro uložení obsahu model--1.txt.

14

• formatStrings – označuje pole formátovacích řetězců šablony. Při vykreslení webové stránky jsou pak stažená data obsahu dle jejich klíčů vypsána do webové stránky. Při vypisování dat se použije právě tento formátovací text, kde {name} je nahrazeno za hodnotu proměnné name dat obsahu. Je nutno takto specifikovat formátovací řetězce, protože může být jeden formátovací řetězec vložen vícekrát s různými hodnotami. Například takto je tomu při vykreslení menu, kde je formátovací řetězec pro jednu položku a tato položka se vykreslí vícekrát s různými hodnotami pro jednotlivé položky v menu. • files – obsahuje pole názvů souborů šablony, které je nutné stáhnout pro vykreslení stránky. Po přípravě všech konfiguračních dat a šablony aplikace vyšle požadavek na server o stažení samotných dat, které má vykreslit do šablony. Pokud má aplikace nějaká data uložená, nastaví opět parametr updateTime a server tak může poslat pouze aktualizace nebo odpověď, že jsou data aktuální. Aplikace si stažená data opět uloží do paměti zařízení. Poté klientská část aplikace načte HTML stránku šablony, CSS soubor a vypíše stažená data obsahu do šablony dle formátovacích řetězců a vykreslí připravenou šablonu na displej. Vykreslení webové stránky je provedeno za pomocí knihovny webového prohlížeče implementovaného přímo v operačním sytému mobilního zařízení. Aplikace si tedy, jak již bylo zmíněno, ukládá všechna stahovaná data z důvodu toho, aby při dalším vykreslení webové stránky mohla data pouze načíst z paměti a nemusela se všechna data stahovat znovu. Klientská aplikace provádí sloučení dat uložených a stažených a uchovává pouze aktuální data, takže nejsou uložena redundantně.

15

3.

Použité technologie

Aplikace vytvořená v rámci této práce je rozdělena na serverovou a klientskou část. Toto rozdělení je zvolené, protože je předpokládané, že máme k dispozici webovou aplikaci, která může sloužit jako zdroj dat. Klientská aplikace sama o sobě primárně nebude sloužit jako zdroj dat, bude pouze uchovávat a zobrazovat data, která přijme od serveru.

3.1.

Serverová aplikace

Jak již bylo zmíněno dříve, serverová aplikace je postavena na frameworku Yii, který je naprogramován v jazyce PHP (5.1.0 a vyšší). Je to framework určený pro tvorbu webových aplikací, objektově orientovaný používající paradigma modelview-controller (MVC)1 , což je paradigma, které má za úlohu oddělit funkční, datovou a prezenční část aplikace. Také implementuje vytváření automatického kódu pro aplikace, CRUD2 , PHPUnit3 , systém výjimek a logování a další. Kód generovaný komponentami Yii frameworku je dle XHTML[6] standardu. 3.1.1.

PHP a framework Yiii

PHP je skriptovací jazyk interpretovaný na webovém serveru. Webový server musí mít nainstalovaný modul PHP a za jeho pomoci PHP generuje webovou stránku. PHP je multiparadigmový jazyk, který může být použit jako procedurální, funkcionální, objektově orientovaný a reflektivní. V této práci a frameworku se PHP používá dle objektově orientovaného paradigmatu. Skriptovací jazyk PHP je přímo vytvořen pro vytváření webových aplikací, a tudíž byl zvolen i pro vytvoření serverové aplikace pro tuto práci. Navíc je PHP nezávislý na použité platformě a poskytovatelé webových hostingů, dalo by se říci, jej považují za výchozí jazyk pro psaní webových aplikací, čili jeho výhodou je i široká podpora. Yii je open–source framework určený pro vývoj webových aplikací v skriptovacím jazyce PHP, který je určený jak pro malé, tak pro rozsáhlé projekty, což umožňuje jeho široké využití. Dále Yii obsahuje implementované nástroje pro pomoc testování a debugování aplikací se širokou dokumentací. [1] Yii implementuje paradigma model–view–controller, což je široce rozšířené paradigma pro programování webových aplikací, které má za cíl oddělit od sebe logiku, data a uživatelské rozhraní. Model reprezentuje informace a pravidla pro zaručení správnosti dat, view obsahuje elementy uživatelského rozhraní jako jsou 1

Rozdělení aplikace na tři části: view - grafický či textový výstup, controller - logika aplikace, model - reprezentuje datovou část společně pro práci s daty. 2 Create-Read-Update-Delete - rozhraní poskytující funkce pro práci s databází v podobě funkcí pro vytvoření, čtení, aktualizaci a mazání dat. 3 PHPUnit je framework pro testování aplikací v PHP, který patří do rodiny xUnit testovacích frameworků.

16

textová pole, tlačítka a další. Controller se stará o logiku a o správnou komunikaci mezi daty a uživatelským rozhraním. Užitečným rozšířením Yii frameworku založeném na PHP Data Objects (PDO)4 je Yii Data Access Objects (DAO), které poskytuje objektově orientovaný přístup k datům s jednotným rozhraním pro různé SŘBD. Toto rozšíření poskytuje objektově orientované metody pro vytváření dotazů, a také díky této implementaci zvyšuje bezpečnost proti útokům jako jsou SQL injection a podobně. Důvody, proč byl zvolen framework pro vytváření webové aplikace, jsou poskytnutí základní funkcionality a zjednodušení velmi používaných operací jako jsou například operace s databází. Navíc také zaručuje určitou míru bezpečnosti, kterou programátor nemusí ošetřovat a je k dispozici velmi velké množství modulů, které značně rozšiřují funkcionalitu frameworku. 3.1.2.

REST rozhraní

Rozhraní pro přístup k datům, které poskytuje modul serverové aplikace, bylo zvoleno dle architektury REST (Representational State Transfer), které je narozdíl od jiných architektur, jako například SOAP[7], orientováno datově. Rozhraní implementuje čtyři metody, GET, PUT, POST a DELETE pro práci s daty. Metoda GET slouží k výpisu dat v požadovaném formátu (typicky XML nebo JSON), metoda PUT pro aktualizaci stávajících dat, POST pro uložení nových dat a DELETE pro smazání již uložených dat. Pro potřeby aplikace bylo implementováno rozhraní pouze pro metodu GET, neboť klientská aplikace se zaměřuje pouze na zobrazení webového obsahu a ostatní metody v tomto případě postrádají smysl. [5] Architektura REST byla zvolena z důvodu toho, že je možné její data posílat v jakémkoli přenosovém formátu (obecně používané XML a JSON) ale i třeba pouze jako obyčejný text. Nevyžaduje pouze specifický datový formát XML, jako je tomu u architektury SOAP a navíc není nutné posílat hlavičku a tzv. obálku jako je tomu u architektury SOAP, čímž se přenáší méně dat.

3.2.

Klientská aplikace

Klientská aplikace je vytvořena na frameworku Phonegap. Tento framework je implementovaný v několika jazycích, Java pro Android, C# pro Windows Phone, Objective-C pro iOS a další, čímž zajišťuje možnost vytvářet aplikace pro různé operační systémy mobilních zařízení. Aplikace vytvořená na tomto frameworku funguje na principu toho, že se vykreslí webová stránka pomocí tzv. web view, což je knihovna webového prohlížeče implementovaná přímo v mobilním operačním systému. Framework poskytuje rozhraní, které je přístupné přes JavaScript, 4

PDO je rozšíření, které poskytuje konzistentní rozhraní pro přístup k databázi. Poskytuje abstraktní vrstvu nad databází, čili pro různé databáze je možné použít stejné dotazy.

17

Mobilní zařízení Mobilní aplikace Web view HTML

JS

CSS

JavaScriptové rozhraní Phonegap

Rozhraní pro aplikace Operační systém

Obrázek 2. Schéma architektury Phonegap a které rozšiřuje funkcionalitu JavaScriptu o další možnosti, jako je ukládání souborů, přenos souborů po síti, přístup k senzorům, přístup k databázi a další. V dalších kapitolách je uveden popis frameworku Phonegap a popis technologií, které framework používá. Použitím technologií dále popsaných je vytvořena webová aplikace. Kód který je tvořen těmito technologiemi je multiplatformní a tudíž k vytvoření aplikace pro konkrétní operační systém stačí pouze zkompilovat kód pomocí příslušného nástroje. 3.2.1.

Phonegap

Jak již bylo zmíněno, framework Phonegap umožňuje vytváření mobilní aplikace za pomocí použití tzv. webových technologií, neboli jazyků HTML, CSS a JavaScript. Framework Phonegap přidává do mobilní aplikace funkcionalitu v podobě vykreslení webové stránky a dále rozšiřuje funkcionalitu JavaScriptu. Přidává například možnost přistupovat k lokálnímu úložišti, přístup k senzorům jako je GPS, senzor natočení zařízení a další. Díky této rozšířené funkcionalitě jsou možnosti webových mobilních aplikací mnohem bližší k mobilním aplikacím vytvořeným za pomoci programovacích jazyků nativně určených pro dané platformy. Schéma architektury aplikace vytvořené pomocí frameworku Phonegap je vidět na obrázku 2. Grafickým uživatelským rozhraním takové aplikace je načtená webová stránka přes celý displej. Po spuštění aplikace se načte výchozí HTML stránka, která je nastavená ve webové aplikaci. Uživatel interaguje s elementy webové stránky jako 18

jsou odkazy, tlačítka, textové pole a další. Pomocí tohoto je také řešena navigace v aplikaci. Je možné plně využívat možností formátování pomocí CSS3. 3.2.2.

HTML

HTML[8] je značkovací jazyk pro vytváření webových stránek a ostatních informací, které zobrazuje webový prohlížeč. HTML stránka obsahuje stromovou strukturu elementů. Elementy jsou většinou párové, ale párovost není vyžadována. HTML stránka může obsahovat kromě HTML tagů také kód Javascriptu nebo CSS. Framework Phonegap podporuje i HTML5, což je specifikace jazyka HTML z roku 2012, která značně rozšiřuje jeho možnosti. 3.2.3.

CSS

Cascading Style Sheets (CSS) je jazyk používaný pro formátování vzhledu HTML, popřípadě XHTML stránky. CSS bylo vytvořeno k odlišení obsahu stránky od prezentace, proto CSS upravuje vzhled webové stránky. Pomocí CSS může měnit vlastnosti elementů stránky, které určují vlastnosti vzhledu jako jsou například okraje, barva či obrázek pozadí, šířka, výška a v CSS3 podpora animací a dalších pokročilejších grafických efektů, což jsou například stíny písem a obrázků. Příkladem animací u CSS může být posouvání nebo rotace obrázku během nastaveného časového úseku. 3.2.4.

Javascript

Javascript je multiparadigmatický programovací jazyk implementovaný původně webovými prohlížeči, ale časem si našel uplatnění i v jiných oblastech jako je programování aplikací pro prostředí Metro ve Windows 8. Javascript je slabě dynamicky typovaný se syntaxí, která je ovlivněna programovacím jazykem C a Java. Podporuje více paradigmat a to objektově orientované, procedurální a funkcionální. Javascript byl zamýšlen pro použití jako programovací jazyk, který bude měnit obsah webové stránky, komunikovat s uživatelem, provádět asynchronní operace atd. Těchto asynchronních operací využívá AJAX. 3.2.5.

jQuery

jQuery je malá JavaScriptová knihovna, optimalizovaná pro usnadnění práce s dokumenty a kontrolu dat formulářů. Umožňuje pracovat s elementy DOM5 , vytvářet animace, zpracovávat události a dále také vytvářet AJAX aplikace. 5

Document Object Model je multiplatformní, konvence nezávislá na použitém jazyce, pro reprezentaci a interakci s objekty HTML, XHTML a XML dokumentu.

19

3.3.

AJAX

AJAX je akronym pro asynchronní JavaScript a XML. AJAX se u webových aplikací používá k asynchronním přenosům dat mezi prohlížečem a serverem, k čemuž používá XMLHttpRequest6 . Hlavní výhodou AJAXu je, že není nutné znovu načítat celou stránku, výstupní webová stránka se upraví na straně klienta (prohlížeče). Ukázkovým příkladem je například našeptávač při vyhledávání.

3.4.

Využívané datové formáty

Pro přenos dat mezi serverovou a klientskou částí aplikace je použit formát JSON[9]. Bylo provedeno měření pro porovnání velikosti přenesených dat a formát JSON se ukázal jako méně náročný, než formát XML viz měření v kapitole 7. Ostatní formáty dat bylo nevýhodné použít již z toho důvodu, že použitý programovací jazyk JavaScript nemá implementovanou funkci, která převede přijatá data z textové reprezentace do objektové reprezentace jazyka JavaScript. Implementace takovéto funkce např. pro formát YAML byla výpočetně náročnější a tudíž nevýhodná pro výslednou aplikaci. 3.4.1.

JSON

Javascript Object Notation (JSON) je textový formát pro výměnu dat. Založený na programovacím jazyku JavaScript, určený pro reprezentaci datových struktur a asociovaných polí, v Javascriptu zvaných objekty. Formát JSON je nezávislý na programovacích jazycích, funkce pro převod mezi textovou a objektovou reprezentací jsou implementovány v několika dalších programovacích jazycích. 3.4.2.

XML

Extensible Markup Language (XML) je obecný značkovací jazyk vyvinutý konsorciem W3C. Jazyk je určen k serializaci dat a následného uložení nebo výměny s jinou aplikací. Dokument ve formátu XML obsahuje stromovou strukturu elementů, kde jeden element je párový tag s případnou hodnotou. Tag je slovo složené ze znaků a–z uzavřené mezi dvěma lomenými závorkami.

3.5.

Metody pro snížení objemu přenášených dat

Pro minimalizaci přenosu dat aplikace využívá metod cachování, komprese a formáty dat. Cachování probíhá na principu, že se při stažení konfiguračních dat, dat šablony nebo obsahu uloží do paměti zařízení. Při odpovědi server pouze 6

XMLHttpRequest definuje rozhraní pro skriptovací jazyky spuštěné na straně klienta (webového prohlížeče) a přímou komunikaci se serverem.

20

odesílá nová požadovaná data, jejich aktualizaci a seznam hodnot ID starších dat pro zajištění aktuálnosti dat v klientské aplikaci. Tento seznam je odesílán, aby se neaktuální data, která jsou již smazána ze serveru, nezobrazovala stále v aplikaci. Aplikace tedy porovná seznam ID se seznamem ID svých uložených dat a pokud má uložená nějaká data s ID, které není v odpovědi od serveru, tak je smaže. Tento případ samozřejmě platí při odesílání většího počtu dat, čili nějakého seznamu, například seznamu jednotlivých článků. Dále aplikace využívá komprese dat. Komprimace přenášených dat je zajištěna na úrovni protokolu HTTP a v hlavičce se nastaví příznak komprimace a klientská aplikace automaticky dekomprimuje data. Tato funkčnost je zajištěna na úrovni mobilního operačního systému, což zajišťuje rychlejší dekomprimaci dat, než pokud by byla zajištěna na úrovni implementace frameworku nebo dokonce implementovaná až v samotné aplikaci v JavaScriptu. Toto bohužel s sebou nese jednu nevýhodu a to, že je implementovaný pouze algoritmus GZIP[10] a Deflate[11]. Implementace jiného komprimačního algoritmu je tedy nepraktická z výkonnostního pohledu. Dalším výrazným snížením velikosti přenášených dat je volba formátu přenášených dat. Aplikace podporuje nejpoužívanější dva formáty XML a JSON. Důvody jsou prosté, formát XML patří mezi nejpoužívanější přenosové formáty a formát JSON výrazně snižuje velikost přenášených dat. Výsledky přesného měření a porovnání těchto dvou formátů včetně porovnání s komprimací dat, jsou popsány v kapitole 7. Kvůli použití co možná nejméně náročné technologie je v aplikaci implementováno více technologií pro porovnání jejich účinnosti. Bohužel možnost implementace širší palety přenosových formátů a komprimačních algoritmů je značně omezena použitými jazyky, proto jsem se omezil na výše zmíněné techniky.

3.6.

Šablony

Klientská část aplikace používá šablony. Šablonu lze stáhnout pouze jednou a poté se při dalším načtení webové stránky se stejnými nebo s jinými daty, stahují pouze data pro šablonu a šablona samotná se již nemusí stahovat, což zrychluje aplikaci a zmenšuje objem stažených dat. Šablony fungují tak, že se vytvoří jedna šablona pro vzhled webové stránky a určí se pozice, kam se vloží obsah. Šablona u klientských aplikací je v podobě HTML, CSS souborů. Klientské aplikace při prvním spuštění s aktivním internetovým připojením stáhnou všechny soubory šablon a poté při dalším načtení stránky se klientská aplikace dotazuje serveru pouze o stažení dat, čímž ušetří datový přenos o velikost dat šablony, čili o velikost HTML, CSS souborů. Popřípadně může šablona obsahovat i knihovny JavaScriptu, pokud se jedná o kód například s vizuálními efekty animace apod. Vložení textového obsahu do šablony probíhá tak, že se do souboru index.html za pomocí JavaScriptového skriptu vloží obsah stránky HTML. Název souboru 21

šablony je uložen v konfiguraci a nachází se uložený v paměti ve složce template. Dále jsou vloženy soubory CSS. Tato fáze probíhá ještě před vykreslením výstupu na displej, tudíž uživatel vidí pouze obrázek identifikující, že aplikace pracuje a po seskládaní výsledné stránky ze všech souborů a dat je stránka vykreslena na displeji mobilního zařízení.

22

4.

Platformy

Dalším požadavkem na aplikace je multiplatformnost. Phonegap zajišťuje možnost použití aplikace až na sedmi operačních systémech určených pro mobilní zařízení. V rámci této práce je klientská část aplikace implementována pro tři operační systémy. Dva nejpoužívanější a nejrychleji se rozšiřující, což jsou Android a iOS, jak ukazuje tabulka 1. a pro operační systém Windows Phone od společnosti Microsoft.

4.1.

Serverová aplikace

Aplikaci serverovou je možné spustit na různých platformách díky zvolenému programovacímu jazyku PHP. Webový server s modulem PHP je multiplatformní, proto je možné spustit jej na většině operačních systémů.

Android iOS Windows Phone Ostatní

Podíl na trhu 2011 v % 52,9 23,0 1.5 22,6

Podíl na trhu 2012 v % 70,1 21,0 2,6 6,4

Tabulka 1. Podíl na trhu mobilních operačních systémů. [12]

4.1.1.

Android

Android je operační systém založený na linuxovém jádře navržený pro zařízení s dotykovou obrazovkou jako jsou chytré telefony a tablety. Je to open source platforma a Google zveřejňuje jeho zdrojové kódy pod licencí Apache. To umožňuje, aby byl Android volně upravován a zdarma šířen pro vývojáře a výrobce mobilních zařízení. Má velmi širokou základnu vývojářů, a proto obchod Google Play obsahuje nepřeberné množství různých aplikací, jen pro zajímavost koncem roku 2012 jich bylo přibližně 700 000[13]. Android je dobrou volbou pro uživatele, kteří potřebují levný a upravitelný operační systém. Tyto vlastnosti pomohly, aby se Android stal nejrozšířenějším operačním systémem pro mobilní zařízení. V roce 2010 předběhl Symbian, který byl původně nejrozšířenějším. Během třetí čtvrtiny roku 2012 měl Android 75 %[14] podíl na trhu chytrých telefonů. Operační systém Android je založen na monolitickém Linuxovém jádře, dále obsahuje middleware7 , rozhraní a aplikace. Architektura Androidu je rozdělena do pěti vrstev, jak je vidět na obrázku 3. 7 Aplikace, která poskytuje služby operačního systému pro aplikace. Konkrétněji u Androidu například knihovna webového prohlížeče, datové úložiště atd.

23

Obrázek 3. Vrstvy operačního systému Android.[15] • Jádro operačního systému – tvoří abstraktní vrstvu mezi použitým hardwarem a softwarem. Jak již bylo zmíněno, Android je založen na Linuxovém jádře a využívá jeho funkcionalitu jako je správa paměti, správa sítí, správu procesů, multitasking a ovladače. Jedním z hlavních důvodů použití Linuxového jádra byla možnost snadného sestavení na různých zařízeních a tím zaručená přenositelnost. • Knihovny – jsou napsané v programovacím jazyku C/C++ a využívá různé komponenty systému. Jeho funkcionalita je poskytnuta přes rozhraní Android Application Framework. Jsou to například Media Libraries (knihovna pro přehrávání video a audio formátů), LibWebCore (knihovna webového prohlížeče), SQLite (odlehčená relační databázová knihovna), libc (odvozená z BSD standardní knihovny C upravené pro přenosná zařízení), OpenGL (knihovna pro vykreslení 3D grafiky) a další. • Android Runtime – vrstva obsahuje virtuální stroj zvaný Dalvik vyvinutý pro Android. Dalvik Virtual Machine (DVM) je registrově orientovaná architektura, která využívá vlastností Linuxového jádra, jako je správa paměti nebo vláken. Dalvik je optimalizovaný pro mobilní zařízení za účelem úspory energie a výkonu. Překlad aplikací pro Android probíhá tak, že se aplikace přeloží do Java Byte kódu jako běžné aplikace a poté se pomocí 24

Dalvik překladače spustí kód na DVM. • Aplication framework – nejdůležitější vrstvou pro vývojáře, protože poskytuje přístup ke službám, které mohou být použity přímo v aplikacích. Základní sada služeb zahrnuje například sadu prvků View (využívány pro sestavení uživatelského rozhraní, textového pole, tlačítek atd.), content providers (umožňují přístup k obsahu jako jsou kontakty), resource manager (poskytuje přístup ke zdrojům), notification manager (umožňuje všem aplikacím zobrazit vlastní upozornění ve stavovém řádku) a activity manager (řídí životní cyklus aplikace a slouží pro orientaci v zásobníku s aplikacemi). • nejvyšší vrstvu pak tvoří základní aplikace, které používají uživatelé jako například emailový klient, kalendář, SMS a další. 4.1.2.

iOS

iOS je mobilní operační systém vytvořený společností Apple. iOS je odlehčený operační systém Mac OS X, je založen na unixovém jádře Darwin. Apple neposkytuje licenci k instalování iOS na jiném zařízení, než je iPhone, iPod, iPad a Apple TV. Ovládání operačního systému je založeno na dotykovém ovládání. Operační systém lze rozdělit na čtyři vrstvy: jádro operačního systému, vrstva služeb, médií a Cocoa Touch[16]. • Vrstva Cocoa Touch – je to abstrakční vrstva operačního systému napsaná v Objective-C, která poskytuje frameworky pro tvorbu aplikací. Například framework Foundation Kit, který poskytuje rozhraní pro práci s třídami pro datové struktury, UIKit, který poskytuje třídy rozhraní pro práci s objekty grafického uživatelského rozhraní. Tato vrstva také implementuje například multitasking a rozpoznávání dotykových gest. • Vrstva médií – vrstva poskytující framework pro práci s OpenGL, Core text8 , Image I/O9 a další. Dále poskytuje technologie pro přehrávání zvuku jako je OpenAL10 , AV Foundation11 včetně rozhraní pro přehrávání systémových upozornění, vibrací a podobně. • Vrstva služeb – poskytuje rozhraní pro práci s objekty typu Block12 , SQL databázi SQLLite, podporu parsování XML dokumentů a další. • Jádro operačního systému – nejnižší vrstvou je jádro operačního systému, které poskytuje nízkoúrovňové funkce ostatním technologiím. Vytváří abstrakční vrstvu nad daným hardwarem. 8

Engine pro vykreslování textu. Framework umožňující čtení a zápis grafických formátů. 10 Poskytuje rozhraní pro práci se 3D zvukem. 11 Sada Objective-C rozhraní pro správu přehrávání a záznamu zvuku. 12 Objekt typu Block reprezentuje anonymní funkci. 9

25

4.2.

Windows Phone

Windows phone je mobilní operační systém vyvíjený firmou Microsoft. Windows Phone 7 je založen na jádře operačního systému Windows Embedded CE. Microsoft vyvinul novější verzi Windows Phone 8, která není zpětně kompatibilní s Windows Phone 7, protože je založena na jádře Windows NT. Aplikace je možné zkompilovat i pro Windows Phone 8, ale z technických důvodů to není součástí práce.

26

5.

Metody snížení přenosu dat po síti

Pro snížení objemu dat přenášených po síti se používají metody komprese a cachování dat.

5.1.

Cachování

Všechna data, která aplikace stahuje ze serveru, jsou rovnou i ukládána do paměti zařízení. Díky této vlastnosti je při opakovaném požadavku na data odeslaná také z klientské aplikace poslední datum stažení, server poté odešle seznam ID, aby se zamezilo, že v aplikaci budou zůstávat neaktuální data a dále seznam nových dat, která ještě nejsou uloženy v aplikaci. Aplikace si poté aktualizuje data uložená v zařízení.

5.2.

Komprese

Pro snížení přenosu dat po síti je použita komprimace GZIP. Framework Phonegap použitý pro klientskou aplikaci podporuje komprimaci přenášených dat pomocí komprimačního algoritmu GZIP. Zvolení jiného komprimačního algoritmu by nebylo jednoduché, jelikož Phonegap nepodporuje nativně dekomprimaci přenášených dat. Implementaci jiného komprimačního modulu by bylo možné vyřešit za pomocí modulu, který však musí být napsán zvlášť v každém programovacím jazyce pro danou platformu. Implementace dekomprimačního algoritmu v jazyce Javascript není dobrým řešením, protože provádět poměrně složitý dekomprimační proces by bylo velmi neefektivní a každá komprimace respektive dekomprimace by si vyžádala velké množství procesorového času.

5.3.

GZIP

Komprimační algoritmus GZIP je algoritmus vyznačující se vysokou mírou komprimace, což je jeho velkou výhodou. Jeho komprimační poměr je lepší, než u mnoha jiných algoritmů, které nejsou zdarma. Gzip je šířen pod licencí GPU13 . Komprimace je založena na algoritmu Deflate, který je kombinací algoritmů LZ77 a Huffmanova[17]. Více informací o komprimaci je možné nalézt v [18].

13

General Public Licence je licence, kdy kód může být volně šířen a dále upravován pod podmínkou, že dále zůstane pod licencí GPU[19].

27

6.

Optimalizace času přenosu dat

Dle knihy High performance web sites[20] trvá při načtení stránky přibližně 80 – 90 % času stažení komponent webové stránky, což se povedlo z části zredukovat. Klientská aplikace si totiž stáhne šablonu (komponenty webové stránky) při prvním načtení. Tedy první načtení stránky a CSS stylů by trvalo stejně dlouho. Od druhého je však každé další načtení stránky kratší, pokud se nejedná o načtení stránky až po intervalu, kdy se aplikace dotazuje, jestli nejsou změny v šabloně a konfiguračních datech. Pokud není aktualizace, server odešle pouze odpověď, že není aktualizace a neposílá data. Tedy v nejhorším případě pokud by se stáhla pouze při jednom požadavku konfigurační data, při druhém data šablony a při třetím samotná data, tak by aplikace při každém dalším požadavku ušetřila 2/3 času potřebného ke stažení všech dat webové stránky. Je navíc velmi pravděpodobné, že šablona nebude obsahovat pouze konfigurační data. V tom případě se pak ušetření času pro stažení dat do klientské aplikace snižuje mnohem více. Výsledné zrychlení aplikace je pozorovatelné i pro uživatele, protože se aplikace zrychlí o více jak 66 % času. Celý čas načtení webové stránky v aplikaci trvá více jak jednu vteřinu. Dle měření v aplikaci nebyla odpověď od serveru rychlejší než půl vteřiny.

28

7.

Měření objemu přenášených dat

Na serverové straně aplikace je funkce, která změří velikost odesílaných dat do aplikace. Měření probíhá na základě toho, že se spočítá délka řetězce, čímž získáme přibližnou velikost stahovaných dat v bajtech. Pro zjednodušení měření jsou články napsány bez diakritiky, aby při použitém kódování UTF-8 platil vztah, že jeden znak zabírá jeden bajt. Tato hodnota je poté uložena do databáze serverové části aplikace společně s informací o tom, jaký formát byl použit, zdali byla použita komprimace. Do tohoto měření není započítaná hlavička, kterou přidává přenosový protokol HTTP, což ale není problém, protože tato hlavička je zanedbána při každém měření. Výsledky měření nejsou úplně přesné, což ani nebylo úkolem. Důležité je porovnat do jaké míry se použitím daného formátu nebo provedením komprimace ušetřilo přenášených dat. Tento poměr se zajisté bude také lišit podle toho, jak velký objem přenášených dat je, protože u velmi malých dat může komprimace mít negativní účinek v tom slova smyslu, že jsou komprimovaná data větší, než původní. Tomuto efektu je však zde zamezeno tak, že je přidaná podmínka nekomprimovat řetězce, které jsou kratší než 150 B. V tomto případě se zbytečně provádí komprimace a výsledek má navíc větší velikost. Dále je spočítáno o kolik procent se zmenšila velikost dat oproti jejich původní velikosti.

7.1.

Porovnání formátů přenášených dat

Množina podporovaných formátů je nevelká, obsahuje pouze formát XML a JSON. Naměřených hodnot bylo za dobu testování aplikace uloženo do databáze přes tisíc, což jsou všechny možné požadavky od klientské aplikace a z nich je vypočítaná průměrná hodnota pro každý formát. Tyto hodnoty bychom mohli považovat za hodnoty získané simulací používáním aplikace. Získané hodnoty jsou uvedeny v tabulce 2. XML JSON 2984,87 1391,59

Ušetření dat v % 53,38

Tabulka 2. Hodnoty naměřené pro implementované přenosové formáty. Dle naměřených výsledků uvedených v tabulce 2. dochází přibližně k 53,4 % úspoře datového objemu přenášených dat při použití datového formátu JSON oproti použití formátu XML bez použití komprimace. Tato data jsou uvedena přibližně, protože data jednotlivých formátů dat jsou zaokrouhlena.

7.2.

Naměřené hodnoty při použití komprimace

Další snížení objemu přenášených dat je možné provést za pomocí kompri29

mace. Jako metoda komprimace bylo zvolena již výše popsaná metoda GZIP. Výsledky jsou uvedeny v tabulce 3. se zaokrouhlením na setiny bajtu. Formát dat XML JSON

Velikost dat Velikost komprimovaných dat 2984,87 349,07 1391,59 293,47

Zmenšení o % 88,36 78,91

Tabulka 3. Hodnoty naměřené komprimované a nekomprimované.

Tabulka 3. ukazuje velikostní rozdíly mezi daty s a bez použití komprimace. Data jsou stejná jako v předešlém případě tabulky 2. V tabulce je uvedena velikost dat v bajtech pro přenosový formát XML a JSON s použitím a bez použití komprimace. Poslední sloupec obsahuje hodnotu, o kolik procent se snížila velikost dat při použití komprimace.

7.3.

Porovnání aplikace s webovým prohlížečem

Další měření pro porovnání ušetření přenášených dat ze strany klientské části aplikace bylo provedeno tak, že byla načtena stránka index, kde jsou vypsány náhledy všech článků, které jsou velké maximálně 150 znaků. Toto načtení je považováno za první načtení stránky, a tak je započítána velikost konfiguračních dat a šablony, která mají velikost 1372 bajtů. Dále je změřena velikost při načtení nejmenšího (18 znaků) a největšího článku (34685 znaků) s konfiguračními daty a šablonou uloženou v paměti zařízení, takže se stáhla pouze data obsahu. Druhý pohled je z webového prohlížeče. Pro co nejpodobnější měření bylo provedeno měření tak, že byl změřen počet znaků HTML dokumentu zobrazeného ve webovém prohlížeči. K tomu byla přičtena hodnota velikosti CSS souborů o velikosti 26800 bajtů. První hodnota měření byla naměřena po načtení stránky indexu se všemi články blogu, druhá hodnota po zobrazení nejkratšího článku a třetí hodnota po zobrazení nejdelšího článku na blogu, které jsou totožné s měřenými články uvedenými v předešlém měření. Ke všem těmto naměřeným hodnotám byla přičtena velikost CSS souborů. Pro zjednodušení předpokládáme, že se CSS při každém požadavku stahovaly, protože cílem práce je přibližně porovnat velikosti přenášených dat. Tato měření byla provedena pro formát XML a hodnoty jsou uvedeny v tabulce 4. Ve sloupci prohlížeč je uvedená velikost celé webové stránky zobrazené ve webovém prohlížeči, poté velikost pro formát XML nekomprimované a procentuální zmenšení velikosti formátu XML a stránky v prohlížeči. Dále je uvedená velikost přenosového formátu XML, který je navíc zkomprimován a procentuální zmenšení oproti velikosti webové stránky prohlížené webovým prohlížečem. Porovnání s přenosovým datovým formátem JSON je uvedeno v tabulce 5. V prvním sloupci jsou stejné hodnoty jako v předešlé tabulce 4., což jsou hodnoty 30

velikosti stránky zobrazené webovým prohlížečem. Dále jsou uvedeny hodnoty pro nekomprimovaný formát JSON a procentuální zmenšení oproti velikosti stránky z webového prohlížeče. Ve sloupci JSON k. jsou uvedeny hodnoty formátu JSON komprimované. V posledním sloupci je uvedené procentuální zmenšení komprimovaných dat oproti velikosti stránky ve webovém prohlížeči.

index kratší článek delší článek

Prohlížeč XML 407424 3819 + 1416 73568 258 348974 34972

Zmenšení % 87,15 99,65 89,98

XML k. 2188 + 620 175 397

Zmenšení % 93,10 99,76 99,89

Tabulka 4. Porovnání přenesených dat do aplikace pomocí XML a zobrazení pomocí webového prohlížeče.

index kratší článek delší článek

Prohlížeč JSON 407424 3368 + 887 73568 155 348974 34869

Zmenšení % 98,96 99,79 90,00

JSON k. 2126 + 474 127 340

Zmenšení % 99,36 99,83 99,90

Tabulka 5. Porovnání přenesených dat do aplikace pomocí JSON a zobrazení pomocí webového prohlížeče.

Jak vyplývá z druhého měření, lze za pomocí těchto technik ušetřit až 99,9 % přenášených dat při použití formátu JSON a komprimace. Je to ideální případ a dokonce může být velmi častý. Například pro případ aplikace pro zobrazování aktuálních zpráv. Je pravděpodobné, že při spuštění, pokud již nejsou uložena, se stáhnout konfigurační data, šablony a zobrazí se seznam zpráv s nadpisy. Poté si uživatel s vysokou pravděpodobností vybere nějakou zprávu, která jej zaujala a při jejím čtení se mohou stáhnout pouze data a již zde může dojít až k výše zmíněnému snížení o 99,9 % velikosti přenášených dat.

31

8.

Programátorská dokumentace

8.1.

Serverová aplikace

Při požadavku na server je zavolána třída ApiController, která zpracuje požadavek, pracuje s třídy pro modely dat a poté vytiskne odpověď pro klientskou aplikaci. 8.1.1.

Třída pro práci s daty

Třídy označované jako model přímo korespondují s daty uloženými v databázi. Díky této korespondenci a implementaci funkcí, které pracují s daty, tak můžeme pohodlně pracovat s daty, která jsou uložena v databázi, stejně jako s objektem, který má své atributy s daty. 8.1.2.

Třída zajištující logiku

Třída ApiController je třída, která dědí z třídy Controller, která je již ve frameworku Yii implementována. Třída obsahuje několik funkcí, které implementují různé akce vyvolané dotazem klientské aplikace. Akce je vybrána na základě parametrů předaných pomocí URL adresy dotazu. Každá akce je zavolána přes svoji specifickou adresu. Dle zadané adresy jsou volané tyto funkce: • actionConfig – tato třída zavolá funkci pro odeslání požadavku, které předá jako parametr asociativní pole s hodnotami nastavení. • actionTemlate – funkce, která zavolá funkci pro odeslání požadavku a předá jí parametr s asociativním polem, které obsahuje hodnoty nastavení pro šablonu stránky. Je to například seznam modelů, seznam formátovacích řetězců, seznam elementů a další. • actionFiles – je funkce, která načte soubor uložený na serveru a jeho obsah odešle klientské aplikaci. • actionList, actionView, actionStructure – požadavek klientské aplikace musí obsahovat také model, na který se dotazuje s časem poslední aktualizace a po případně ještě ID jednotlivých položek. Funkce se tak dotáže databáze všechna data, která jsou novější, než je poslední čas aktualizace poslaný klientskou aplikací a také o seznam identifikátorů dat, která jsou starší, než je čas poslední změny. Funkce poté tato data překopíruje do asociativního pole a předá je funkci, která data odešle klientské aplikaci. Je důležité, aby tato funkce vracela identifikátory starších dat z důvodu toho, že se některá data mohou již smazat a nejsou aktuální.

32

8.1.3.

Třídy zajištující zobrazení

Výstup serverové aplikace obsahuje pouze neformátovaný textový výstup. Z toho důvodu je zbytečné rozdělovat výpis textového řetězce bez formátování do samostatné třídy a o výpis je postaráno již ve ApiController.

8.2.

Struktura konfiguračních dat

Struktura a ukázka konfiguračních dat je uvedena v kapitole 2.1., konfiguračních dat šablony v kapitole 2.2. a stahovaných dat klientské části aplikace blogu je v kapitole 2.1.

8.3.

Klientské aplikace

Klientská aplikace obsahuje tyto třídy: • Config je třída, která obsahuje proměnné s hodnotami konfiguračních dat. Dále tato třída obsahuje funkce pro stažení dat ze serveru a načtení dat ze souboru. • Controller je třída, která je volaná po načtení webové stránky. Tato třída zajistí inicializaci ostatních tříd a dále obsahuje funkci ProcessContent, která je zavolána po stažení dat šablony. Tato funkce zavolá funkci ProcessPartContent pro každý element stránky. Mimo toho také provede kontrolu, zdali konfigurační data jsou načtena. Dále funkce ProcessPartContent načte data z paměti mobilního zařízení, vyšle požadavek na server ke stažení dat pro element stránky. Po stažení provede sloučení stažených dat a dat, která jsou uložena v paměti zařízení. Zavolá funkci pro uložení dat opět do paměti zařízení a poté funkci PrintData pro vykreslení webové stránky. • Template je třída, která je inicializovaná po třídě konfigurace. Po stažení a načtení konfiguračních dat se zavolá funkce loadFromServer, která zajistí zavolání funkci buďto, pokud je připojení k internetu aktivní, ke stažení konfiguračních dat šablony ze serveru a nebo jejich načtení ze souboru. Pokud není možné soubor načíst nebo není nalezen, je zavolána funkce onError, která vypíše hlášení uživateli o chybějících datech a nutnosti připojit se k internetu. Bez aktivního připojení k internetu nelze dále aplikaci spouštět. V opačném případě, pokud jsou data stažena nebo jsou jsou uložena v paměti, tak jsou z ní načtena a dále je vytvořeno menu aplikace. Menu aplikace slouží ke stažení dat jiného modelu a následnému zobrazení jeho dat. Například u demonstrující aplikace je tímto modelem model post, což

33

je model14 , který obsahuje šablonu pro vykreslení příspěvků blogu. Dále jsou vyplněny adresy, neboli jsou přidány hodnoty do proměnných, které se nacházejí v odkazech uložených v konfiguračním souboru. Poté je vložena HTML stránka šablony a jsou načteny CSS soubory. Poté je již zavolána funkce ProcessContent pro zpracování dat webové stránky. • Communication je třída, která vytváří abstrakční vrstvu pro funkce stažení dat ze serveru. • Connection je soubor obsahující dvě funkce s funkcí connectionStatus pro získání statusu připojení. Status připojení označuje typ připojení, jako je WiFi, 2G, 3G a další. Druhou funkcí je pak funkce isConnection, která vrací pravdivostní hodnotu pravda nebo nepravda dle toho, zdali je aktivní připojení k internetu nebo není. • data obsahuje funkce pro výpis dat dle šablony. Z dat se zde dle formátovacího řetězce vytvoří textový výstup, který je pak vložen jako obsah elementu, který je určen v konfiguraci šablony. • files je třída s metodami pro načítání a zápis dat do paměti zařízení. Dále obsahuje metody pro stahování dat ze serveru.

14

Pro upřesnění, model zde slouží jako pojem pro souhrn určitých dat, které se stahují do klientské aplikace. Může se jednat o data modulu webové aplikace, nebo pouze o jednu statickou webovou stránku. Data modelu včetně šablony jsou vykreslena jako jedna webová stránka.

34

9.

Uživatelská dokumentace

Po spuštění se aplikace maximalizuje přes celý displej a uživateli zobrazí animaci rotujícího kolečka, aby uživatel věděl, že aplikace pracuje, jak je vidět na obrázku 4. Poté co si aplikace stáhne a načte všechna potřebná data k zobrazení webové stránky, je zobrazeno hlavní okno aplikace včetně textů a šablony. Hlavní okno aplikace klientské části aplikace obsahuje tři části, a to menu, seznam tagů a poté seznam článků textu, jak je vidět na obrázku 5. Menu aplikace bude ve výchozím stavu zobrazeno a umístěno nahoře. Texty článků jsou zkrácené a obsahují maximálně 150 znaků a mají funkci náhledu článku.

Obrázek 4. Aplikace po spuštění.

Obrázek 5. Hlavní okno aplikace. Po kliknutí na nějaký z možných tagů (štítků) se zobrazí seznam článků blogu, které jsou označeny daným tagem. Toto označení je určeno tím, jakým tagem 35

Obrázek 6. Zobrazení jednoho článku. v serverové části aplikace ho uživatel označí. Tato data jsou tedy pouze zobrazována a řazena dle tagů. Okno s články, kde jsou pouze určité tagy vypadá obdobně jako hlavní okno aplikace, akorát obsahuje jiné články. Kliknutím na některý název článku se načte celý obsah článku. Ukázkou je obrázek 6. Po kliknutí na položku menu se načte model a zobrazí se opět na displeji. Například u aplikace po kliknutí na menu about, se načte model s názvem about a vykreslí se jeho šablona s daty, jak je vidět na obrázku 7. Tento model obsahuje pouze statická data šablony a neobsahuje tudíž žádné aktivní elementy, které by měnili svůj obsah.

Obrázek 7. Zobrazení modelu about. Pomocí tlačítka zpět se lze vracet zpět v prohlížení webových stránek. Zmáčknutím tlačítka zpět při vrácení se zpět na začátek prohlížení webových stránek 36

se aplikace ukončí. Při dvojitém rychlém zmáčknutí tlačítka zpět se u Androidu 4.0 a vyšším aplikace ukončí.

37

Závěr Byla vytvořena přenositelná aplikace pro tři mobilní operační systémy. Tato aplikace obsahuje stejný kód, pouze je kompilován do tří klientských aplikací pro tři různé platformy mobilních operačních systémů. Dále je vytvořena aplikace typu server, která poskytuje data pro klientské aplikace. Dle provedených měření lze zmenšit přenášený datový objem po síti až o 99,9 %, což určitě stojí za využití při programování mobilních aplikací, které vyžadují využití internetového připojení v době, kdy mobilní připojení k internetu je poskytováno pouze s omezeným datovým limitem.

38

Reference [1] About Yii: Yii framework [online], [cit. 2013–07–19]. Dostupné z: http://www.yiiframework.com/about/ [2] HTML 5.1 Nightly: A vocabulary and associated APIs for HTML and XHTML [online], [cit. 2013–08–01]. Dostupné z: http://www.w3.org/html/wg/drafts/html/master/ [3] Cascading Style Sheets (CSS) Snapshot 2010: W3C Working Group Note 12 May 2011 [online], [cit. 2013–08–01]. Dostupné z: http://www.w3.org/TR/CSS/ [4] WARGO, John M. PhoneGap essentials: building cross–platform mobile apps. Upper Saddle River, NJ: Addison–Wesley, c2012, xxiv, 359 p. ISBN 03–218– 1429–0 [5] Representational State Transfer (REST) [online], [cit. 2013–08–01]. Dostupné z: http://www.ics.uci.edu/˜fielding/pubs/dissertation/rest arch style.htm [6] XHTMLTM 1.0 The Extensible HyperText Markup Language (Second Edition) [online] [cit. 2013–08–02]. Dostupné z: http://www.w3.org/TR/xhtml1/ [7] SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) [online], [cit. 2013–08–01]. Dostupné z: http://www.w3.org/TR/soap12-part1/ [8] HTML 4.01 Specification [online], http://www.w3.org/TR/REC-html40/

[cit.

2013–08–02].

Dostupné

z:

[9] The application/json Media Type for JavaScript Object Notation (JSON) [online], [cit. 2013–08–02]. Dostupné z: http://www.ietf.org/rfc/rfc4627.txt [10] GZIP file format specification version 4.3 [online], [cit. 2013–08–02]. Dostupné z: http://www.gzip.org/zlib/rfc-gzip.html [11] DEFLATE Compressed Data Format Specification version 1.3 [online], [cit. 2013–08–02]. Dostupné z: http://www.ietf.org/rfc/rfc1951.txt [12] Android and iOS Combine for 91.1 % of the Worldwide Smartphone OS Market in 4Q12 and 87.6 % for the Year, According to IDC [online], [cit. 2013-0728]. Dostupné z: http://www.idc.com/getdoc.jsp?containerId=prUS23946013 [13] Google Play Matches Apple’s iOS With 700,000 Apps [online], [cit. 2013– 07–20]. Dostupné z: http://www.tomsguide.com/us/Google–Play–Android– Apple–iOS,new s–16235.html

39

[14] Android Marks Fourth Anniversary Since Launch with 75.0 % Market Share in Third Quarter, According to IDC [online], [cit. 2013–07–20]. Dostupné z: http://www.idc.com/getdoc.jsp?containerId=prUS23771812 [15] Android SDK [online], [cit. 2013–07–20]. Dostupné z: howpublished = http://ows.edb.utexas.edu/site/collaborative–bluetooth–edumanet/ android– sdk–2 [16] iOS Technology Overview: Cocoa Touch Layer [online], [cit. 2013–08–01]. Dostupné online z: http://developer.apple.com/library/ios/#documentation/ miscellaneous/conceptual/iphoneostechoverview/iPhoneOSTechnologies/iPho neOSTechnologies.html [17] GZIP Intrudaction http://www.gzip.org/

[online],

[cit.

2013–07–20].

Dostupné

z:

[18] An Explanation of the DEFLATE Algorithm [online], [cit. 2013–07–20]. Dostupné z: http://www.gzip.org/deflate.html [19] General Public Licence [online], http://www.gnu.org/licenses/gpl.html

[cit.

2013–07–20].

Dostupné

z:

[20] SOUDERS, Steve. High performance web sites: essential knowledge for frontend engineers. Farnham: O’Reilly, c2007, xix, 146 p. ISBN 05–965–2930–9.

40

A.

Obsah přiloženého CD

bin/ Obsahuje tři instalátory pro klientské aplikace pro operační systémy Android, Windows Phone a iOS. Dále obsahuje soubory spustitelné na webovém serveru serverové aplikace blogu. Adresář serverové aplikace je včetně frameworku Yii, který vyžaduje SQL databázi. Nastavení údajů pro připojení k databázi je popsáno v souboru readme.txt na DVD. doc/ Adresář obsahující elektronickou verzi bakalářské práce a ZIP archiv obsahující zdrojové kódy a všechny potřebné soubory k vygenerování PDF souboru bakalářské práce. src/ Obsahuje všechny zdrojové kódy a projekty pro jejich zkompilování a spuštění. Projekty klientských částí aplikace jsou rozděleny do adresářů dle operačních systémů spolu s projektem serverové části aplikace. readme.txt Instrukce pro instalaci a spuštění klientských a serverové části aplikace. Obsahuje také informace o webové aplikaci blog již nasazené v provozu včetně přihlašovacích údajů. Navíc CD/DVD obsahuje: install/ Instalátory vývojových prostředí pro aplikace a aplikaci pro spuštění webového serveru.

41