Off-line funkcionalita on-line web aplikácií

	Trenčianska Univerzita Alexandra Dubčeka v Trenčíne Fakulta Mechatroniky
	Off-line funkcionalita on-line web aplikácií zadanie práce Bakalárska práca

Autor:	Dušan Pagáč
Pedagogický vedúci:	Ing. Juraj Ďuďák
Študijný odbor:	Mechatronika
Akademický rok	2009/2010

Obsah práce

1.	Štruktúra webovej aplikácie
2.	Technológie off-line web aplikácií
3.	Systémy na vizualizáciu rozvrhu hodín
4.	Návrh používateľského rozhrania rozvrhu FM TnUAD

Abstrakt Bakalárska práca sa zaoberá web aplikáciami, ktoré sú schopné pracovať aj v režime off-line. V prvej kapitole je rozobraná architektúru web aplikácií. Zaoberá sa štruktúrou webovej aplikácie pracujúcej aj v režime off-line. V druhej časti je popísaná technológia Google Gears od firmy Google, ktorá toto umožňuje. Následne sú uvedené výhody a nevýhody tejto technológie a možnosti jej praktického využitia vo webových aplikáciách. V práci je spomenutá aj nová špecifikácia HTML5, ktorá taktiež prináša off-line podporu pre webové aplikácie. V ďalšej časti sa venuje aplikáciám na tvorbu a zobrazovanie rozvrhov a návrhu front-endu rozvrhu Fakulty mechatroniky. Na zabezpečenie off-line funkcionality sme použili rozšírenie Google Gears.

Abstract This bachelor work deals with web applications which are able to work in an off-line mode. The first part is concerned with the architecture of web applications. It is devoted to the structure of web-application able to work also in the off-line mode. The Google Gears technology by the Google company which makes this possible is described in the second part. Consequently, the advantages and the disadvantages are stated as well as the posibilities of the  practical usage in the web aplications. The new specification HTML5 that also offers off-line support for web applications is mentioned in this work, too. The final part is dedicated to the applications used for creation and display of timetables and design of front-end directly for Faculty of mechatronics. The off-line functionality has been ensured by the Google Gears extention.

Úvod

S obrovskou rýchlosťou akou sa internet rozšíril a stal sa každodennou súčasťou nášho života sme si ani neuvedomili, ako sme od neho závislí. Stretávame sa s ním na každom mieste, či už je to v práci, škole alebo domácnosti. Veľký problém nastáva pri nedostupnosti signálu, napríklad v odľahlých častiach alebo pri výpadku pripojenia. Tento problém sa snaží vyriešiť firma Google so svojim open-source rozšírením Google Gears pre internetové prehliadače. Zároveň postupne presadzuje používanie tejto technológie aj vo svojich aplikáciách. Vďaka open-source je možné, aby túto technológiu použil každý. Pre správne pochopenie ako táto technológia pracuje, rozoberieme v prvej kapitole samotnú štruktúru web aplikácií. Následne sa budeme venovať optimálnej štruktúre web aplikácií s podporom režimu off-line, funkčnosti a synchronizácií. Druhá časť tejto práce je zameraná na objasnenie princípu činnosti Google Gears a vysvetľuje prácu s touto technológiou. Spomenuté sú aj webové aplikácie, ktoré túto výhodu podpory v režime off-line v praxi využívajú. Táto kapitola sa venuje aj novej špecifikácií značkovacieho jazyka HTML5, ktorá je v súčasnosti vo vývoji a v budúcnosti má obsahovať podporu off-line aplikácií. Tretia kapitola sa zaoberá systémami na vizualizáciu rozvrhu. V nej si rozoberieme akým spôsobom sa zobrazujú výstupné dáta programov a web aplikácií na tvorbu rozvrhu. Zhodnotíme aké nedostatky spôsobujú neprehľadnosť v používateľskom prostredí. Záverečná časť sa venuje praktickej časti tejto práce, a to návrhu používateľského rozhrania rozvrhu Fakulty mechatroniky a zabezpečeniu funkcionality v režime off-.line.

Štruktúra webovej aplikácie

Webová aplikácia je aplikácia, ktorá je prístupná pomocou webového prehliadača cez sieť internet a intranet. Skladá sa z viacerých vrstiev. Rozoznávame dvojvrstvové alebo trojvrstvové, niekedy nazývané viacvrstvové.

Dvojvrstvové web aplikácie

Dvojvrstvová aplikácia sa skladá z klientskej a dátovej vrstvy. Klientska vrstva obsahuje väčšinu aplikačnej logiky, s ktorou sa pracuje priamo nad dátovým zdrojom. Takýto dátový zdroj môže byť reprezentovaný relačnou databázou. Ďalšie zdroje môžu byť súbory alebo iné aplikácie. Schému dvojvrstvovej web aplikácie môžeme vidieť na obrázku (Obr 1.1).

Obr 1.1 Schéma dvojvrstvovej web aplikácie. Zdroj: [1]

Nevýhody tohto modelu sa ukázali pri vzrastajúcej komplexnosti klientskych aplikácií. S ich zložitosťou vzrastali aj výkonové nároky na klientské počítače. S masívnym rozšírením aplikácií boli softvérové firmy nútené reagovať na požiadavky klientov. Napríklad zdieľanie zdrojov, obmedzenie dátového prenosu atď. Preto sa začalo uvažovať o trojvrstvovej architektúre, ktorá by tieto požiadavky pokryla.

Trojvrstvové web aplikácie

Riešenie sa našlo v podobe pridania tretej – strednej vrstvy. Samozrejme sa nejednalo len o pridanie ďalšej vrstvy. Bolo nutné špecifikovať jednotlivé vrstvy, respektíve ich úlohu v architektúre. Trojvrstvovú architektúru zobrazuje schéma (Obr. 1.2).

Obr. 1.2 Schéma trojvrstvovej aplikácie. Zdroj: [1]

Zmeny v klientskej vrstve

Najväčšia zmena nastala v prípade klientskej vrstvy. Vďaka novo definovanej aplikačnej vrstve bolo možné logiku aplikácie presunúť na server tejto vrstvy. Celý výpočtový výkon bol prenesený na výkonné servery. Presunutím aplikačnej logiky na jedno miesto sme dosiahli lepšiu možnosť jej zdieľania, správy a dostupnosti. Významnou mierou sa podarilo redukovať dátový prenos, pretože komunikácia je sústredená medzi serverom a dátovým zdrojom.

Aplikačná vrstva

Z pohľadu doby prešla aplikačná vrstva najväčším vývojom. Táto vrstva, resp. aplikačná logika, zaisťuje prístup k dátam, prácu s dátami a ich poskytnutie vo vhodnom formáte (XML, HTML) pre klientskú vrstvu.

Model-View-Controller (MVC)

Model-view-controller je architektonický vzor využívaný pri tvorbe aplikácií, ktorý oddeľuje dátový model, používateľské rozhranie a riadiacu logiku. Vytváranie aplikácie s využitím architektúry MVC vyžaduje tri komponenty:

Model

Model je funkčným a dátovým základom celej aplikácie. Poskytuje prostriedky pre prístup k dátovej základni, stavom aplikácie, ukladaniu a aktualizácií.

View

View zobrazuje obsah Modelu, zaisťuje grafický či iný výstup aplikácie. Cez Model pristupuje k dátam, stavom aplikácie a špecifikuje ako majú byť prezentované. Pri zmene stavu Modelu aktualizuje zobrazenie. V prípade webových aplikácií View generuje príslušný HTML kód, ktorý je odoslaný prehliadaču ako odpoveď na požiadavka.

Controller

Controller definuje správanie aplikácie. Spracováva všetky vstupy a udalosti z používateľského rozhrania. Na ich základe volá príslušné procesy Modelu, mení stav a pod. Podľa udalostí prijatých od používateľa a podľa výsledkov akcií Modelu potom Controller vyberie vhodné View pre ďalšie zobrazenie.

Výhody vzoru MVC

• Jednoduché sprístupnenie pre rôzne druhy klientov. Pre zavedenie podpory ďalšieho klienta stačí nadefinovať len nové View.
• Minimalizácia duplicity zdrojového kódu.
• Rozdelenie vývojárskych úloh a samostatný vývoj jednotlivých častí.
• Znovupoužiteľnosť kódu.
• Vysoká komplexnosť návrhu a jednoduchšia rozšíriteľnosť aplikácie.

Optimálna štruktúra aplikácie s podporou režimu off-line

Webové aplikácie, ktoré sú postavené s podporou off-line režimu majú tendenciu byť štruktúrované tak, že ich dátová vrstva je izolovaná. Väčšina dnešných web aplikácií takto stavaných nie je. Pravdepodobne najvýhodnejšia štruktúra je zobrazená v schéme (Obr. 1.3).

Schéma web aplikácie podporujúcej režime off-line. Zdroj: [1]

Hlavným krokom pre dosiahnutie vhodnej architektúry je vytvorenie lokálnej dátovej vrstvy, ktorá využíva lokálnu databázu. Podľa toho či ste on-line alebo off-line, sa dáta získavajú zo servera alebo z lokálneho úložiska. O prepínanie medzi dátovým vrstvami sa stará prepínač. Prepínač je časť kódu, ktorý rozhoduje odkiaľ sa budú dáta čerpať.

Funkcie dostupné v režime off-line

Nedá sa zabezpečiť, aby všetky dostupné funkcie web aplikácie boli prístupné aj v off-line režime. Je zbytočné kopírovať celú databázu zo servera, keď budeme využívať len časť. Preto je vhodné rozhodnúť, ktoré dáta budú uložené lokálne. Implementovaním logiky rozhodovania do našej aplikácie zabezpečíme, že určité dáta bude získavať z lokálneho úložiska a ďalšie zo servera.

Niektoré dáta nemá zmysel ukladať na lokálny disk a je vhodnejšie ich získavať zo servera. Sú to predovšetkým:

• dáta, ktoré sa menia často alebo dokonca v reálnom čase,
• dáta, ktoré majú zmysel len v režime on-line ako instant messaging,
• dáta, ktoré sú náročné na miesto na disku.

Optimálne riešenie je používať lokálne úložisko čo najviac ako je to možné. Pretože je to obyčajne rýchlejšie ako pripojenie na vzdialený server. Ak chceme, aby aplikácia pracovala čo najviac s lokálnymi dátami, bude toto implementovanie náročnejšie. Preto už pri návrhu aplikácie musíme zvážiť, čo je pre nás výhodnejšie.

Forma off-line aplikácií

Typ aplikácie môže mať modálnu alebo nemodálnu formu. Modálne aplikácie obyčajne rozlišujú on-line a off-line mód indikáciou cez zmenu v používateľskom rozhraní. Používateľ sa podieľa na zmene stavu. Nemodálne aplikácie prechádzajú medzi on-line a off-line stavmi bez zmien v používateľskom rozhraní. Používateľ sa nemusí zúčastňovať na prepínaní stavov. Aplikácia to robí automaticky.

Modálne aplikácie

V modálnych aplikáciách, ak je aplikácia on-line, komunikuje so serverom. Ak je off-line, využíva lokálne zdroje. V prípade zmeny módov je nutná synchronizácia dát.

Výhody:

• Relatívne jednoduchá implementácia.

Nevýhody:

• Používateľ musí pamätať na prepínanie módov. Ak zabudne, nebude mať v off-line móde potrebné dáta alebo bude pracovať on-line  bez podpory off-line úložiska.
• Ak je internetové pripojenie prerušované, používateľ si musí zvoliť jedno z nastavení alebo si bude musieť neustále prepínať medzi módmi podľa stavu pripojenia.
• Keďže lokálne zdroje nie sú vždy aktuálne, nemôžu byť pri pripojení na server využívané na zlepšenie podpory aplikácie.

Nemodálne aplikácie

V prípade nemodálnych aplikácií pracuje aplikácia s predpokladom off-line stavu alebo možnosti náhodnej straty pripojenia. Aplikácia využíva lokálne zdroje v maximálne možnej miere, a keď je server dosiahnuteľný, prebieha neustála synchronizácia dát. Tá prebieha taktiež pri prechode do on-line stavu.

Výhody:

• Používateľ sa nemusí starať o to, či je pripojený alebo v akom je stave jeho aplikácia

(on-line/off-line).

• Aplikácia pracuje plynulo aj v prípade prerušovaného pripojenia.
• Keďže je lokálny zdroj aktualizovaný, môže byť využívaný na optimalizáciu serverového pripojenia.

Nevýhody:

• Náročná implementácia.
• Musí sa dbať na to, aby proces synchronizácie nezabral príliš veľa zdrojov a nespôsobil spomalenie celej aplikácie.
• Testovanie aplikácie ja náročnejšie, keďže logika synchronizácie sa deje na pozadí a nie ako odozva na špecifický krok používateľa.

Synchronizácia dát

Bez ohľadu na pripojenie alebo modálnu stratégiu dáta v lokálnej databáze vystupujú zo synchronizácie so serverovými dátami. Napríklad v týchto prípadoch:

• Používateľ urobí zmeny v off-line stave.
• Dáta na serveri sú zdieľané a môžu byť zmenené externými subjektmi.
• Dáta prichádzajú z vonkajšieho zdroja (RSS).

Proces odstraňovania týchto rozdielov tak, že dva zdroje sa stávajú totožnými, nazývame synchronizácia. Existuje mnoho prístupov k synchronizácii, ale žiadny nie je výhodný pre všetky situácie. Vybrané riešenie by malo byť čo najvýhodnejšie pre našu aplikáciu.

Pre príklad sú uvádzané dve všeobecné synchronizačné stratégie.

Manuálna synchronizácia

Najjednoduchší spôsob synchronizácie je tzv. manuálna synchronizácia. Manuálna preto, lebo používateľ sám volí čas synchronizácie. Môže byť implementovaná jednoducho nahraním všetkých starých dát na server a následným stiahnutím novej kópie dát zo serveru pred prechodom na off-line stav.

Manuálna synchronizácia ma nasledovné požiadavky:

• Objem dát dostatočne malý na stiahnutie v primeranom čase.
• Používateľ sám stanovuje prechod do režimu off-line, väčšinou tlačidlom v používateľskom prostredí.

Problémy tejto metódy a jej off-line módu:

• Užívatelia nie vždy vedia okamžitý stav svojho pripojenia. Internetové pripojenie môže byť náhle odpojené alebo prerušované.
• Užívatelia môžu zabudnúť synchronizovať dáta pred prechodom do stavu off-line.

Manuálna synchronizácia môže byť na začiatok vhodným spôsobom synchronizácie, najmä kvôli relatívne jednoduchej implementácii. Bohužiaľ, vyžaduje uvedomelosť používateľa a jeho zapojenie do procesu synchronizácie.

Synchronizácia na pozadí

V prípade synchronizácie na pozadí aplikácia neustále synchronizuje dáta medzi lokálnym zdrojom a serverom. To môže byť uskutočňované opakovanými pokusmi pripájať sa na server alebo v lepšom prípade umožniť serveru presúvať dáta ku klientovi.

Výhody synchronizácie na pozadí:

• Dáta sú pripravené vždy, keď sa používateľ rozhodne pre prechod do režimu off-line alebo je náhodne odpojený.
• Zlepšenie výkonu v prípade využívania pomalého internetového pripojenia.

Nevýhody:

• Nevýhodou je možnosť spomalenia pri kopírovaní dát na pozadí. Spomalenie sa dá minimalizovať využitím rôznych možností (Google Gears WorkerPool).

Architektúra web aplikácie so synchronizáciou na pozadí. Zdroj: [1]