Zobrazenie zdroja stránky Off-line funkcionalita on-line web aplikácií

{{Hlavička_FM
|{{PAGENAME}}|
Dušan Pagáč|
Ing. Juraj Ďuďák|
2009/2010
|Semetrálna práca
|Mechatronika
}} 
[[Kategória:Študentské práce]]
[[Kategória:Bakalárske práce]]
[[Kategória:Informatika]]
[[Kategória:php]]
[[Kategória:web]]
<H1_CSS chapter="1"/>
<div class="sideBox">
{| class="" border=0 cellpadding=5
|+ Obsah práce
|-
| 1.
| [[Off-line funkcionalita on-line web aplikácií|Štruktúra webovej aplikácie]]
|-
| 2.
| [[Off-line funkcionalita on-line web aplikácií_2|Google Gears ]]
|-
| 3.
| [[Off-line funkcionalita on-line web aplikácií_3|HTML 5]]
|-
| 4
| [[Off-line funkcionalita on-line web aplikácií_4|Systémy na vizualizáciu rozvrhu ]]
|-
| 5
| [[Off-line funkcionalita on-line web aplikácií5|Používateľské rozhranie rozvrhu fakulty mechatroniky]]
|-
| 6
| [[Off-line funkcionalita on-line web aplikácií_6|Záver]]
|}
</div>
__TOC__
{{Abstrakt
|Práca sa zaoberá on-line aplikáciami, ktoré sú schopné pracovať aj v režime off-line. V prvej č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. Použitie Google Gears pre rozvrh fakulty mechatroniky je analyzované v druhej časti.  Posledná časť sa venuje návrhu používateľského rozhrania pre rozvrh fakulty mechatroniky a funkčnosti tejto webovej aplikácie v režime offline.
|This work deals with on-line applications which are able to work in off-line mode. The first part is devoted to description of Google Gears technology by Google company. Consequently, the advantages and disadvantages are stated as well as the posibilities of practical usage in web aplications. The usage of Google Gears for faculty of mechatronics is analyzed in the second part. The final part is dedicated to design of user interface directly for faculty of mechatronics and functionality this web aplication in off-line mode.
}}

=Š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).

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 klientske 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==

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 klientske 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.
===Zmeny v klientskej vrstve===

Najväčšou zmena nastala u vrstvy klientskej. 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 klientsku vrstvu.

==Model-View-Controller (MVC)==
Model-view-controller je architektonický vzor využívaný pri tvorbe aplikácií, ktorý oddeľuje dátový model, uží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===
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í.
===Controller===
Controller definuje správanie aplikácie. Spracováva všetky vstupy a udalosti z užívateľského rozhrania. Na ich základe volá príslušné procesy Modelu, mení stav a pod. Podľa udalostí prijatých od užívateľa a podľa výsledkov akcií Modelu potom Controller 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í.
*Znovu použ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). 

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 offline mód indikáciou cez zmenu v užívateľskom rozhraní. Užívateľ sa podieľa na zmene stavu.
Nemodálne aplikácie prechádzajú medzi on-line a off-line stavmi bez zmien v užívateľskom rozhraní. Uží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:

*Uží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é, uží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 straty pripojenia kedykoľvek.  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:

*Užívateľ sa nemusí starať o to či je pripojený alebo v akom je stave jeho aplikácia (on-line alebo 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 uží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 prípadoch keď:

*Uží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 uží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. 
*Užívateľ sám stanovuje prechod do režimu off-line, väčšinou tlačidlom v uží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ť uží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 uží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).