%=========================================================================
% (c) Jakub Jelen, 2012

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%                       Uvod                                %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Úvod}

Pro svoji bakalářskou práci jsem zvolil implementaci programu pro mobilní operační systém webOS. V úvodu bych vás chtěl seznámit s tímto operačním systémem z pohledu uživatelského, jeho vývojem a se způsobem tvorby aplikací pro tuto platformu.

\section{Operační systém webOS}

\subsection{Historie a vývoj}
WebOS je operační systém pro mobilní telefony vyvinutý společností Palm (dříve také  palmOne, Inc., Palm, Inc. a Palm Computing)\cite{wikiPalm}, představený začátkem roku 2009 na veletrhu spotřební elektroniky CES. Již při představení přilákal mnoho pozornosti a získal několik ocenění\cite{wikiPalmPre}. Přes počáteční úspěchy se firma potýkala s mnohými problémy a tak byla již začátkem roku 2010, i se systémem, koupena firmou HP. Ta v systém vkládala velké naděje a měla v plánu používat jej v různých vestavěných systémech. Ale již koncem roku 2011 bylo ohlášeno uvolnění systému jako OpenSource. Komunita se ujala otevřeného zdrojového kódu a dnes, v roce 2012, existují funkční porty webOS na telefony jiných výrobců. Jméno se změnilo na Open webOS a za vývojem stojí skupina GRAM\cite{openWebOS}, stále sponzorovaná firmou HP.


\subsection{Technická data}
Systém je v základu linuxové jádro, stejně jako má Android, ale uživatelské rozhraní a aplikace jsou postaveny, jak už název napovídá, na webových technologiích - javascriptu, HTML a CSS. Aplikace jsou spouštěny v prostředí WebKit. Systém splňuje všechny předpoklady pro použití na chytrém telefonu včetně připojení k WiFi, datovým sítím operátora, GPS přijímače, Bletooth modulu a standardního 3.5mm jack audio výstupu. Dalším předpokladem pro dobré využití chytrého telefonu je dostatek aplikaci, ale o tom až dále.

Operační systém je primárně ovládán přes dotykový displej, jehož dotyková vrstva přesahuje zobrazovací plochu a umožňuje zadávat dotyková gesta (pohyby)\footnote{Z angličtiny Gestures -- gesta, Swipes -- pohyby, tahy} pro funkce \uv{zpět} či otevření launcheru. Až do druhé verze systému se počítalo s druhou vstupní metodou a to přítomnou hardwarovou QWERTY klávesnicí\footnote{Rozložení se liší podle cílového trhu}. Klávesnice navazovala na precizní klávesnice původních přístrojů Treo od Palmu, průkopníků smartphonů a i přes relativně malé rozměry se velmi dobře používá. Ve verzi webOS 3.0, která je určena pro tablety bez hardwarové klávesnice je vstupem pouze dotykový displej se softwarovou klávesnicí.

I přes neúspěchy na trhu obsahuje systém mnoho pokrokových funkcí, jako třeba nepřekonaný multitasking s použitím karet reprezentujících aplikace nebo jednoduchý systém notifikací, na který někteří uživatelé nedají dopustit. Vývoj všech mobilních operačních systémů jde rychle dopředu a některé z úspěšných věcí postupně pronikají i do jiných operačních systémů.


\section{Aplikace}
Jak již bylo zmíněno výše, původní koncept byl postavit aplikace pouze na webových technologiích, kterým rozumí skoro každý a tak bude velmi jednoduché získat mnoho aplikací třetích stran. Ze začátku to vypadalo jako velmi dobrý tah, ale toto rozhodnutí s sebou neslo několik, na první pohled trochu skrytých, úskalí:
\begin{itemize}
 \item Většina zdrojového kódu je v ne příliš oblíbeném Javascriptu
 \item Interpretace Javascriptu je pomalá, což je dost znát na prvních telefonech
 \item Některé věci prostě v Javascriptu udělat nejdou (programování blíže HW -- i když Palm vytvořil rozhraní pro komunikaci javascriptu se službami OS)
\end{itemize}

I přesto vzniklo mnoho zajímavých aplikací pro tuto platformu. Ze začátku byly do tohoto systému vkládány velké naděje jako nástupce starého dobrého Palm OS, k záchraně oslabující společnosti Palm a jako velké konkurence iPhonu. Palm ale v té době neměl rychlé dodavatele a nezvládl distribuci do celého světa. Jelikož trh s mobilními telefony jde velmi rychle dopředu, dnes (podzim 2012), po třech letech, exituje jen malá komunita uživatelů, kteří tento systém používají, kteří pro něj vyvíjejí aplikace a kteří na něj nedají dopustit. Celkový počet aplikací je v řádu pár tisíc.

Dokumentace k vývoji aplikací obsahuje podrobný popis životního cyklu aplikace, který pomáhá vývojáři zorientovat se v mnoha možnostech spouštění aplikace, běhu na pozadí, řešit alokaci prostředků a přístup ke službám systému. Dále obsahuje seznam bodů, které má dobrá aplikace splňovat -- jak z hlediska vzhledového, chování, nebo práce s pamětí. Vše zde nemá cenu citovat, protože toto není primárním cílem této práce.

\subsection{Frameworky}
Pro tvorbu aplikací přišel palm s Mojo frameworkem, který obsahuje widgety uživatelského rozhraní a základní strukturu aplikace. Widgety uživatelského rozhraní jsou ve formě html části pro umístění do DOM a javascriptové inicializace. Toto použití je docela rozvláčné a díky tomu s příchodem nových verzí od HP, vznikl nový framework Enyo, který tyto dvě části spojil a umístil do struktury v Javascriptu, která určuje zanoření a zároveň zajišťuje inicializaci jednotlivých elementů.

Samotný Mojo Framework podporuje tvorbu aplikací podle architektonického vzoru MVC\footnote{Model - View - Controller}. Podle toho jsou také pojmenované výchozí adresáře ve struktuře aplikace.


\subsection{Nativní aplikace}
Jak již jsem výše naznačil, Javascript není všemocný. A toto si brzy uvědomili i inženýři z Palmu. Dalším logickým krokem bylo umožnit vyvíjet nativní aplikace. Nativním částem se v prostředí webOS říká \uv{Plugin}. K javascriptovému SDK bylo přidáno PDK\footnote{Plugin Development Kit}. Tyto aplikace lze psát v C/C++, využívat SDL pro grafické části a pomocí dalších rozhraní komunikovat se zbytkem systému. Díky tomu bylo na webOS portováno několik her, včetně celosvětově oblíbených Angry Birds.

\subsection{Hybridní aplikace}
Pomyslným vrcholem, co lze z webOS získat, jsou hybridní aplikace. Jedná se o uživatelské rozhraní napsané v jednom z výše zmíněných frameworků, tudíž vzhledově nevybočuje z řady výchozích aplikací, podporuje koncepty dobré aplikace\cite{appChecklist}. Druhou částí je potom tzv. plugin, což je spustitelný soubor napsaný v C/C++, zkompilovaný pro architekturu ARM, se kterým může aplikace obousměrně komunikovat a který může provádět výpočetně náročnější úkoly, nebo obsahovat části již napsané v tomto jazyce pro jiné platformy.

Právě tento koncept jsem vybral pro tvorbu své aplikace. 

\section{Wherigo}
Wherigo je hra pro zařízení s GPS, která přenáší dobrodružství do reálného světa. V přístroji se odehrává virtuální svět, který je ovládán pomocí GPS a často interaguje s reálným okolím. Jedná se v základu o rozšíření Geocachingu, ale lze vytvořit i nezávislé turistické průvodce.

\subsection{Historie}
Systém byl vyvinut společností Groundspeak v roce 2008, primárně pro GPS přístroje značky Garmin a pro kapesní počítače s operačním systémem Pocket PC (Microsoft).\cite{wherigo} Brzy si získal mnoho uživatelů a začaly vznikat zajímavé hry. Samotný Groundspeak od vydání prvních Alpha a Beta verzí mnoho nového neudělal, ale komunita brzy začala tvořit vlastní přehrávače a editory. Z editorů bych zmínil pouze docela nové české URWIGO, ale existujícím přehrávačům se věnuji o trochu více, protože to bude náplní mé práce.

\subsection{Přehrávače}
Přehrávač wherigo cartridge má za úkol provést hráče fyzickými místy a dodat mu prvky virtuální reality na displayi zařízení.

\paragraph{openWIG}
Jako první přehrávač vznikl openWIG od autora Matejcik\cite{wig_matejcik} (Jan Matějek) z pražské UK. Na přehrávači začal pracovat již v roce 2008 a dokázal vytvořit ekvivalentní program bez jakékoliv dokumentace a podpory Groundspeaku. Přehrávač je implementován v Javě, primárně pro mobilní telefony (J2ME), ale knihovnu využil také pro vytvoření desktop verze

\paragraph{WhereYouGo}
Projekt Wherigo přehrávače pro Android vznikl v roce 2010 a autorem je Jiří Mlavec z ČVUT\cite{wig_android}. Tímto počinem se dostalo wherigo na velmi rozšířenou platformu.

\paragraph{PiGo, později Wherigo}
Aplikace napsaná pro širokou základnu telefonů, pro přístroje Apple. Konkrétního autora se mi nepodařilo dohledat, ale tato aplikace je vytvořena s podporou Groundspeaku.





\chapter{Analýza aplikace a návrh}

Úkol vytvořit přehrávač Wherigo catridgí s sebou nese mnoho úskalí, stejně jako přenos aplikace na tuto platformu. V první části vás zkusím seznámit se samotnou hrou a tím co vše je potřeba řešit.

% ostatni implementace
\section{WHERIGO}

\subsection{Wherigo cartridge}
Základním stavebním prvkem, který v této aplikaci budu muset řešit je právě Wherigo cartridge - soubor, který lze stáhnout ze stránek hry a který obsahuje konkrétní hru. Konkrétně tedy hlavičku s metadaty cartridge, hlavní zkompilovaný bytekód jazyka Lua a nakonec další soubory (obrázky, zvuky, ...) související se hrou. Formát cartridge není nikde oficiálně zveřejněn, ale byla zdokumentována tvůrci portů na jiné platformy, ale pro přehlednost je zde také umístěna, jako příloha číslo \ref{struktura}.

Soubor cartridge je zpracováván objektem nad vstupním proudem. Objekt řeší základní datové typy dle přílohy, postupně prochází celý soubor, extrahuje soubory uložené v cartridge. Obsah hlavičky je předáván do databáze otevřených cartridges.



\section{Databáze her}
Pro rychlý přehled o uložených cartridges v telefonu je v aplikaci použita jednoduchá databáze s hlavičkami extrahovanými z cartridges. Dále zde musí být příznak o rozbalení cartridge - extrakce souborů do datového adresáře aplikace, o aktuálním stavu hry a o případném dokončení. Po odstranění cartridge z databáze musí být odstraněny dočasné soubory z paměti telefonu, aby nedocházelo k plnění paměti.



\section{Lua}
Ze souboru cartrige získáme zkompilovaný zdrojový kód Lua (Lua Bytekód), který v podstatě stačí interpretovat. Jako interpret jsem zvolil oficiální interpret ze stránky lua.org. Jedná se o zdrojové kódy v C, které lze pomocí překladače zkompilovat pro cílovou architekturu mobilního telefonu.

\subsection{Propojení interpretu s C++}
Po tomto základním přiblížení se problému je třeba vyřešit další detail: Zdrojové kódy vyžadují (direktiva require) knihovnu Wherigo. Zde je opět problém, že tato knihovna není nikde definovaná a mohu vycházet pouze ze zdrojových kódů pro jiné platformy a zdrojových kódů Lua her, které mám k dispozici.

Je tedy potřeba zpřístupnit pro hru objekty z knihovny Wherigo. To lze udělat dvěma způsoby:
\begin{itemize}
	\item Třídy definovat v C++ a exportovat do Lua VM přes nějaké rozšíření
	\item Třídy definovat v Lua, pouze funkce ovládající UI (výstup) definovat v C++.
\end{itemize}

Aplikace je událostmi řízená. Mezi nejčastější události patří změna pozice. Důležité události jsou start, uložení, ukončení a nebo obnovení cartridge z uložené pozice. Tyto události mohou ovlivňovat zobrazení v uživatelském rozhraní.


\section{Chování aplikace}
Aplikace po načtení volá funkci cartridge.OnStart(). Výstup na obrazovku je řešen funkcí pro zprávy: Wherigo.MessageBox(), která vyžaduje implementaci a volání funkce uživatelského rozhraní.

Změna pozice GPS může vést ke vstupu do zóny, nebo jejímu opuštění -- to může změnit seznam předmětů a akcí, které má uživatel k dispozici a vyvolat změnu v uživatelském rozhraní.

Stejně tak uživatelské rozhraní požaduje data po pluginu a nepřímo ovládá model v pozadí.




%\subsection{Interpretace Lua bytekódu}
%Původní můj dojem byl, že dostanu celý zdrojový kód, ale brzy jsem byl vyveden  z omylu a bylo mi jasné, že na mě bude čekat pouze binární formát, ke kterému by mi žádná teorie formálních jazyků a gramatik nebyla vůbec platná. Proto jsem se začal rozhlížet po vhodném interpretu pro jazyk C/C++ a brzy jsem jej našel na oficiální stránce jazyka Lua. Brzy se mi podařilo tuto knihovnu přeložit pro cílovou architekturu a spustit první hello world v Lua. Po tomto kroku jsem měl dveře vývoje přehrávače otevřené a zbytek už je pouze spojení s uživatelským rozhraním, navržení Lua datových objektů a vzájemné spolupráci a komunikaci.

%\subsection{Komunikace Lua kódu s C aneb Embeded Lua}
%Po analýze zdrojových kódů v jazyce Lua (generované Wherigo Builderem) a komunikaci s autorem OpenWIG jsem získal představu o fungování celé aplikace a o nutnosti tyto dvě části kódu úzce provázat a umožnit obousměrnou komunikaci. Samotná aplikace neběží v onload po načtení zdrojového kódu, ale jedná se o událostmi řízenou aplikaci (změna pozice, start cartridge, ...).

\chapter{Implementace a spuštění na cílové platformě}

\begin{comment}
\section{Instalace software pro vývoj}
Ze stránek pro vývojáře palm je potřeba stáhnout SDK kit, ... TODO

\section{Příprava zařízeni pro vývoj}
Pro vývoj na běžném zařízení je potřeba provést několik věcí.

\subsection{Aktivace vývojářského módu}
Vývojářský mód lze na rozdíl od konkurenčních platforem odemknout zadáním textu \texttt{webos20090606} nebo Konami kódu \texttt{upupdowndownleftrightleftrightbastart} do univerálního vyhledávacího pole a v aplikaci \uv{Developer Mode Enabler} tuto volbu potvrdit.

Po restartu přístroj nabootuje v režimu, který umožňuje instalovat aplikace z počítače a přistupovat k chybovým a ladícím výpisům aplikace

\subsection{SSH a příkazová řádka v přístroji}
Pro přístup k shellu v přístroji je třeba nainstalovat do telefonu SSH. To lze provést připojením zařízení k počítači a spuštěním utility z nainstalovaného vývojového kitu:

\texttt{pdk-device-install install}

Po restartu získáme přístup přes putty k příkazové řádce, kde můžeme debugovat aplikace přímo na zařízení například pomocí gdb. 

\subsection{Enyo framework pro starší přístroje}
Aplikace pro starší přístroje (Pre, Pixi, systém verze 1.x) jsou napsány ve Frameworku Mojo a systém v základním stavu neobsahuje Enyo framework. Ten se automaticky doinstaluje společně s aplikací Maps z oficiálního katalogu.
\end{comment}

\section{Podpůrné nástroje}

HP podporuje pro vývoj PDK pouze operační systém Windows a Mac a proto vývoj probíhal právě na platformě Windows.

\subsection{Makefile}
Pro rozumné sestavení převzatých zdrojových kódů interpretu Lua a vlastního C++ kódu je Makefile nejjednodušší řešení. Po instalaci GNU Make a nastavení potřebných proměnných systému jsem byl schopen zkompilovat první hello world.

Dále pomocí Makefile provádím balení aplikace do .ipk balíčku, který mohu nainstalovat do zařízení, do emulátoru, nebo rovnou na nějaké platformě spustit. %todo Toto trochu zcivilizovat, ať to odpovídá realitě.
Vycházel jsem z vzorového makefile na oficiálním vývojářském webu \cite{pdkTutorial3}.



\section{Komunikace mezi částmi aplikace}

Pro ověření funkčnosti komunikace mezi uživatelským rozhraním (co nejvíce zjednodušeno) a nativní aplikací běžící na pozadí jsem vytvořil jednoduchý projekt, který tuto funkčnost ověřoval. Mezi požadavky pro funkčnost patří (podle samples/FileTree z PDK):
\begin{itemize}
	\item V javascriptu
	\begin{itemize}
		\item připojit spustitelný soubor se kterým se bude komunikovat
		\item určit jeho metody, které lze volat
		\item implementovat zpracování asynchronních odpovědí
	\end{itemize}
	\item V C++ pluginu:
	\begin{itemize}
		\item Registrovat handlery pro přijímání volání (přes PDL\_* funkce)
		\item Zpracování parametrů z Javascriptu a zabalení návratové hodnoty do JSON
		\item Oznámit javascriptová části dokončení inicializace
		\item V programové smyčce odchytit uživatelské události
	\end{itemize}
	\item V appinfo.json zveřejnit položku "plug-ins": true
	\item Do výsledného balíčku přidat: 
	\begin{itemize}
		\item spustitelný soubor plugin (kompilovaný pro danou architekturu)
		\item soubor package.properties obsahující nastavení atributů spustitelnosti souboru plugin
		\item soubor plugin\_appinfo.json obsahující informace o spustitelné aplikaci (viz zdrojové kódy)
	\end{itemize}
\end{itemize}
O tomto bych chtěl napsat nějaký jednoduchý článek i se zdrojovými kódy, protože toto není nikdy popsáno. (a protože mě to zrovna nefunguje)







\chapter{Závěr}
Závěrečná kapitola obsahuje zhodnocení dosažených výsledků se zvlášť vyznačeným vlastním přínosem studenta. Povinně se zde objeví i zhodnocení z pohledu dalšího vývoje projektu, student uvede náměty vycházející ze zkušeností s řešeným projektem a uvede rovněž návaznosti na právě dokončené projekty.

%=========================================================================
