Mobilní E-Learningové Nástroje

Mobilní e-learningové nástroje

Martin Holas

Brno, 2009

1 Masarykova univerzita Fakulta informatiky

ZADÁNÍ BAKALÁŘSKÉ PRÁCE

Datum: 25.5.2009 Student(ka): Martin Holas Program: Aplikovaná informatika

Vedoucí práce: Mgr. Tomáš Gregar

Katedra (pracoviště):

Název práce: Mobilní e-learningové nástroje Mobile e-learning tools

Zadání: * Analyzovat nabídku free či open-source nástrojů, utilit, programů pro studijní účely v rámci Aplikované informatiky a provést rešerši nalezených nástrojů * Přitom se zabývat možností využití nástrojů v českém prostředí, v prostředí MU a při studiu Aplikované informatiky na MU; pokusit se identifikovat i ná- stroje, které by se daly využít. * Analyzovat možnost práce se zkoumanými nástroji z kapesních počítačů (PDA), komunikátorů či mobil. * Analyzovat možnosti vývoje studijních nástrojů pro PDA v prostředí .NET a na základě těchto informací naprogramovat aplikaci pro interaktivní podporu studia předmětu IB102 - Automaty a Gramatiky na FI MU.

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, který jsem vypracoval sám. Všechny zdroje a literaturu, které jsem při vypracování použil nebo z nich čerpal, v práci cituji s uvedením úplného odkazu.

Vedoucí práce: Mgr. Tomáš Gregar

3 Shrnutí

Cíle práce jsou tři. Zanalyzovat aktuální nabídku a stav volně či open-source dostupných nástrojů pro podporu studia bakalářského programu Aplikovaná informatika na FI MU. Zhodnotit a po- rovnat postupy vývoje aplikaci pro platformu Windows Mobile. Na základě těchto informací navrhnout a implementovat aplikaci pro podporu studia předmětu „Automaty a gramatiky“, ob- sahující vizualizaci automatů a testování dat.

4 Klíčová slova e-learning, mLearning, PDA, smartphone, Automaty a gramatiky, Windows Mobile

5 Obsah

1 Úvod...... 7 2 Možnosti vývoje aplikací pro mobilní zařízení...... 8 2.1. Platformy a operační systémy...... 8 2.1.1. Definice základních pojmů...... 8 2.1.2. Rozdělení mobilních platforem...... 8 2.2. Nativní kód...... 11 2.3. Spravovaný kód...... 12 3 Analýza dostupných řešení...... 15 3.1. Obecné nástroje pro zobrazení studijních materiálů...... 15 3.2. Překladové slovníky...... 15 3.3. Výkladové slovníky...... 16 3.4. LMS...... 17 3.5. Matematické nástroje...... 17 4 Vývoj v prostředí .NET pro Pocket PC...... 18 4.1. .NET Compact Framework...... 18 4.2. Návrh uživatelského rozhraní pro mobilní platformy...... 19 4.2.1. Ovládací prvky v systémech Windows Mobile...... 20 4.3. Architektura Windows Mobile ...... 24 4.3.1. Knihovna tříd Microsoft.WindowsMobile...... 24 4.3.2. Knihovna tříd Microsoft.WindowsCE.Forms...... 25 5 Aplikace pro vizualizaci konečných automatů...... 27 5.1. Konečný automat...... 27 5.2. Implementace konečného automatu...... 28 5.3. Implementace validace slov nad konečným automatem...... 29 5.4. Uživatelské rozhraní aplikacemi...... 30 5.5. Vstupní a výstupní operace...... 32 6 Závěr...... 34

6 1 Úvod

Vzdělání se stalo v moderním věku synonymem pro úspěšný životní start mladého člověka. V pří- padě informatiky je ovšem možné jít v myšlence dále a bez obav tvrdit, že studium se rychle stalo celkovou náplní života každého člověka, který se této vědní disciplíně věnuje, ať už pracovně nebo ve svém volném čase. Jen málo oborů prochází natolik hektickým, dynamickým vývojem a nic nenaznačuje tomu, že by toto tempo mělo polevit. Spíše naopak. Údělem informatika je tak nejen počáteční investice do časově velmi náročného nabytí počátečních vědomostí na střední či vysoké škole, ale celoživotní přizpůsobování se nejnovějším trendům, technologiím a moderním postu- pům. Je přirozená tendence příjem takového množství informací co nejvíce usnadnit a zeefektivnit. Technologický pokrok takové možnosti přináší a lze je obecně označit pojmem e-learning, podpora vzdělávání s využitím výpočetní techniky a sítě Internet. Obzvláště Internet lze právem považovat za milník ve způsobu, jakým lidstvo chápe získávání informací. Takřka vše a z celého světa je doslova na dosah ruky, otázkou několika kliknutí. Doba vyhledání potřebných informací se s použitím sofistikovaných vyhledávacích algoritmů zkracuje. Jsou k dispozici objemné encyklope- die, odborná diskuzní fóra, elektronické knihy a další materiály. Se stále větším důrazem na miniaturizaci zařízení a rostoucí potřebou moderního člověka být mobilním začíná do popředí vycházet pojem mLearningu. Ten je možné definovat jako mobilní e-learning, tj. podporu vzdělávání s využitím mobilních elektronických prostředků, zpravidla pak osobních komunikátorů, počítačů nebo mobilních telefonů. Nový úhel pohledu na způsob vzdě- lávání znamená pro uživatele větší nezávislost na čase i prostoru, pro vývojáře ovšem také nové vý- zvy. Je nutné vyřešit nejednotnost a omezení standardů, operačních systému, rozlišení displejů mo- bilních zařízení a HW specifikací obecně. Je nutné zanalyzovat také možnosti využití již existují- cích e-learningových materiálů v mobilním prostředí. Cílem práce je takovou analýzu provést, identifikovat možnosti a nástroje pro vývoj aplika- cí pro mobilní e-learning a nakonec uvést příklad a způsob řešení konkrétního projektu.

7 2 Možnosti vývoje aplikací pro mobilní zařízení

2.1. Platformy a operační systémy

2.1.1. Definice základních pojmů

HW Platforma Pojem všeobecně chápaný jako typ hardware, který má společnou podporu množiny aplikací, ope- račních systému a disponuje podobnou (z hlediska využití a kompatibility) skupinou HW komponent, především pak co se týče komunikačních rozhraní s ostatními zařízeními a prvků uživatelské- ho rozhraní. Mezi typické příklady mobilních HW platforem patří Pocket PC, Smartphone, Tablet PC, Palm PC.

SW Platforma Podobně jako v případě HW platformy, ovšem v projekci na software. Jedná se především o prostředí, na kterých fungují aplikace naprogramované pro podporu dané SW platformy. Mezi dvě nejrozšířenější SW platformy patří Java a .NET Framework, resp. odvozené Java Micro Edition a .NET Compact Framework, které jsou zaměřené na použití na mobilních zařízeních.

Operační systém Hlavní řídící program, jehož úlohou je zpřístupnit hardwarové komponenty aplikacím a zprostřed- kovaně i uživatelům. Z hlediska mobilních zařízení jsou typickými představiteli Windows Mobile, Smartphone, Palm OS.

2.2. Základní rozdělení mobilních HW platforem

Pro účely textu jsou dále považována za mobilní zařízení pouze ta, která lze přenášet a manipulovat s nimi v jedné nebo obou rukou. Obecně lze jistě považovat za mobilní platformu i přístroje typu notebook a jiné obdobné velikosti. Pro analýzu praktické aplikace mLearningu jsou ovšem nezají- mavé, neboť svým konceptem silně vycházejí z platformy PC (HW konfigurace, operační systém). Jako takové je tedy lze kategorizovat spíše do oblasti klasického e-learningu.

2.1.2.1. Mobilní telefony Elektronická zařízení pro hlasovou a jinou komunikaci prostřednictvím specializovaných ce- lulárních radiových sítí. Organizace ITU (International Telecommunication Unino) ve statistické databázi World Telecommunication/ICT Indicators Database 2008 uvádí, že v roce 2008 bylo po celém světě rozšířeno přibližně 4,1 milardy uživatelů mobilního telefonu. Z obrázku 2.1. je patrný rapidní nárůst uživatelů mobilních telefonů zvláště ve vyspělých zemích, kde se penetrace mezi obyvatelstvem blíží absolutní hodnotě. Z důvodu masové rozšířenosti se tedy mobilní telefon stává poměrně vhodnou nosnou

8 platformou vývoje aplikací pro studijní a výukové účely. Výhodná je také implementace řady moderních komunikačních technologií v novějších přístrojích, jmenovitě například Bluetooth, WiFi a GPRS. Z hlediska vývoje mLearning aplikací je platforma částečně nevýhodná kvůli neefektivní- mu ovládání grafických aplikací pomocí numerické klávesnice, malému displeji a také velmi ome- zeným systémovým prostředkům. Aplikace jsou proto omezené jen na velmi jednoduché uživatel- ské rozhraní s krátkými textovými příkazy. Nereálné je zobrazení složitých matematických či infor- matických výrazů, obsáhlých grafů, tabulek, nabídek a jiných grafických prvků. Platforma je využi- telná pro jednoduché aplikace, typicky se zaměřením na výuku jazyka (slovníky, memorování ná- hodně předkládaných výrazů ve stylu funkce Dril informačního systému MU). Platforma je také vhodná pro implementaci multiple-choice testů, odpovědníků atp.

Obrázek 2.1.

Příklad technické specifikace zařízení typu mobilní telefon (Nokia N70): Operační systém: Symbian OS 8.1a Procesor: TI OMAP 1710 220 MHz ROM: 22 MB Displej: 2.1“ TFT s 256k barvami a rozlišením 176x208 pixelů Komunikace: Bluetooth, USB, GPRS, EDGE Rozměry: 108,8mm x 53 mm x 21,8 mm Váha: 126g

9 2.1.2.2. Smartphones Elektronická zařízení s funkcionalitou mobilního telefonu. Přestože neexistuje pevný standard [1], vymezující definici zařízení typu smartphone, lze platformu typicky odlišit od mobilního telefonu větším displejem, často s dotykovým ovládáním, a především některým typem otevřeného mobilní- ho operačního systému (Windows Mobile, Palm OS,...). Standardizované API operačního systému a SW platforem (.NET Compact Framework) značně zeefektivňuje průběh vývoje aplikací, které také mohou disponovat propracovanějším uživatelským rozhraním a pokročilejší funkcionalitou, než je tomu u běžných mobilních telefonů. Častá přítomnost klávesnice typu QWERTY a naopak absence stylusu profiluje aplikace, které je vhodné na platformě smartphone vyvíjet. Jedná se především o mLearning aplikace s dů- razem na textové informace, s většími ovládacími prvky (lze předpokládat ovládání pomocí prstu ruky). Tvrzení dále koresponduje i s omezenými prostředky .NET Compact Framework, která nepodporuje velkou část grafických ovládacích prvků a tříd na platformě smartphone (viz 4.3.1.). Za- řízení typu smartphone jsou vhodné pro vizualizaci jednoduchých grafů a tabulek, tvorbu a zob- razování krátkých textových dokumentů (e-book), textovou a hlasovou komunikaci. Výhodou vý- voje aplikací cílených na platformu smartphone je kompatibilita se zařízeními typu Pocket PC. Opačná kompatibilita bývá ovšem z důvodů pouze částečné podpory .NET Compact Framework komplikovanější a je zpravidla nutné restrukturalizovat grafické uživatelské rozhraní.

Příklad technické specifikace zařízení typu smartphone (Palm Treo 750v): Operační systém: Windows Mobile 5.0 Procesor: Samsung 300MHz ROM: 60 MB Displej: dotykový, 2.5“ TFT s 65536 barvami a rozlišením 240x240 pixelů Komunikace: Bluetooth, IR port, USB, GPRS, EDGE Rozměry: 111mm x 58 mm x 22 mm Váha: 154g

2.1.2.3. PDA (Personal Digital Assistant) Elektronické zařízení s kompletní podporou platforem .NET Compact Framework a Java Micro Edition a plnohodnotnou verzí operačního systému. Přístroje PDA je možné rozdělit na dvě zá- kladní platformy: Pocket PC (Windows Mobile) a Palm (Palm OS). K provádění vstupních operací typicky slouží dotekový displej (LCD displej pokrytý prů- hlednou folií, která je citlivá na dotek). Myš, známou z platformy platformy PC, nahrazuje dote- kové pero (stylus). Aktivním činitelem vstupní operace je displej, pasivním pak dotekové pero. Z tohoto důvodu je možné použít k obsluze zařízení také jiné předměty nebo prst ruky, i když s menší přesností. Uvnitř systému Windows Mobile jsou operace se stylusem reprezentovány jako události vyvolávané tlačítkem myši. Klepnutí stylusem (tap) je proto chápáno jako kliknutí levým tlačítkem myši, poklepání (double-tap) jako dvouklik levého tlačítka myši a podržení na displeji (tap-and- hold) jako kliknutí pravým tlačítkem myši. Tažením stylusu lze simulovat držení levého tlačítka myši. Klávesnice na přístroji PDA obecně přítomna z důvodu maximální mobility není. Její ná- hradou na platformě Pocket PC je SIP (Standard Input Panel), grafická podoba klavesnice typu QWERTY v dolní části displeje, na níž je možné zadávat stylusem jednotlivé znaky1. Více o konfiguraci SIP v prostředí .NET Compact Framework viz 4.2.1. 1 To ovšem není úplně přesné. SIP podporuje několik módů zadávání vstupních dat. Kromě defaultní si- mulace QWERTY klávesnice se jedná především o rozpoznávání psaného písma.

10 Příklad technické specifikace přístroje Pocket PC (Acer n311) Operační systém: Windows Mobile 5.0 Procesor: Samsung S3C2440 400MHz ROM: 128 MB RAM: 68 MB SDRAM Displej: dotykový, 3.7“ TFT s 65536 barvami a rozlišením 480x680 pixelů Komunikace: Bluetooth, IEEE 802.11b WLAN, USB, sériový port Rozměry: 110 mm x 70 mm x 13,7 mm Váha: 135g

Poznámka: Dodatečnou skupinou zařízení je platforma Pocket PC Phone Edition. Jedná se o zařízení PDA s in- tegrovaným hardwarem, zajišťujícím funkcionalitu mobilního telefonu, tj. především hlasovou komunikaci prostřednictvím některé z celulárních radiových sítí. Z hlediska vývoje mLearningové aplikace jde ale o změnu nevýznamnou, neboť kód z běžného Pocket PC je plně kompatibilní a rozšíření možností o telefonní funkce v tomto druhu software je prakticky nevyužitelné. Pokud bude přesto toto rozšíření potřeba, je možné jej v prostředí .NET Compact Framework zpřístupnit prostým přidání reference na jmenný prostor WindowsMobile.Telephony (viz 4.4.1.). Rozdíl mezi koncepcí Pocket PC Phone Edition a Smartphone znázorňuje tabulka 3.1.

Pocket PC Phone Edition Smartphone Použití Datové funkce s podporou tele- Telefonování s podporou datových fonování funkcí Displej QVGA/VGA QVGA Ovládání Vyžaduje obě ruce (stylus) Vyžaduje jednu ruku (klávesnice, joystick) Aplikace Plná sada Windows Mobile Chybí Pocket Word, Pocket Excel, Pocket Outlook, Reader Typické použití Outlook Web Web Hlasová a textová komunikace Hlasová a textová komunikace Tabulka 1: Rozdíl mezi platformami Pocket PC Phone Edition a Smartphone

2.3. Nativní kód

Aplikace naprogramovaná v nativním kódu běží přímo v procesoru daného mobilního zařízení. Ne- výhodou tohoto přístupu je vysoká rozmanitost různých architektur procesorů mobilních přístrojů.

11 Je možné se setkat s procesory rodin MIPS, ARM, Hitachi, PowerPC, x86, které se dále dělí do více větví a typů. Přestože se v současnosti situace ustálila a v rámci platformy Pocket PC lze na- razit prakticky pouze na procesory s architekturou ARM, je při vývoji aplikace žádoucí reflektovat i případné požadavky na kompatibilitu se staršími stroji a tuto zajistit. Takové aplikace je poté nutné překládat a linkovat pro všechny nejpoužívanější procesory, což znepřehledňuje následnou distribuci a prodlužuje vývoj. Samotný vývoj je obecně při programování v nativním kódu složitější a pomalejší než u spravovaného kódu. V některých případech je ovšem silně žádoucí nativní kód využít. Předně nativní kód umožňuje plnou kontrolu nad interakcí s operačním systémem, transparentní obsluhu systémových událostí. Aplikace naprogramovaná v nativním kódu je také rychlejší, neboť může přistupupovat k službám operačního systému, hardwaru a ovladačům přímo a bez použití mezistupně spravovaného prostředí. Je možné lépe optimalizovat pro cílovou platformu. Je otázkou, zda filozofie nativního kódu, používaná zpravidla k tvorbě ovladačů a velmi specializovaných aplikací, vyhovuje poža- davkům, které jsou kladeny při vývoji mLearningových nástrojů. Dle mého názoru nikoliv, neboť spravovaný kód je v běžné aplikaci z uživatelského úhlu pohledu výkonem totožný. Aplikace v nativním kódu lze vyvíjet v programovacím jazyce eMbedded Visual Basic a eMbedded Visual C++. V poslední pěti letech se od jazyka eMbedded Visual Basic opouští a dává přednost eMbedded Visual C++. Důvodem je nejspíše skutečnost, že překladač Visual Basic na roz- díl od překladače C++ nevytváří přímo nativní kód pro příslušný procesor, ale nejdříve generuje meziformu2, která je až poté interpretována na cílové platformě. EMbedded Visual Basic byl využí- ván spíše pro programování jednodušších aplikací, což je ale v přímém rozporu s cíli programování v nativním kódu. U jednoduchých aplikací totiž zpravidla nezávisí na maximální optimalizaci a vý- konu, a proto je výhodnější v jazyce Visual Basic vyvíjet spravovaný kód (konkrétně Visual Basic .NET).

2.4. Spravovaný (managed) kód

Brian Adams v článku „What is managed code?“ [2] opakuje podstatu nespravovaného (nativního) kódu v protikladu ku spravovanému:

„Contrast this to the unmanaged world: Unmanaged executable files are basically a binary image, x86 code, loaded into memory. The program counter gets put there and that’s the last the OS knows. There are protections in place around memory management and port I/O and so forth, but the system doesn’t actually know what the application is doing. Therefore, it can’t make any gua- rantees about what happens when the application runs.“

Koncept spravovaného kódu vkládá do principů nativního kódu mezistupeň. Zdrojový kód v jazyce vhodném pro spravované prostředí3 je nejdříve kompilátorem přeložen do spravovaného (někdy také označovaného jako bajtového) kódu. Spravovaný kód je na platformě Java označován jako by- tecode, v prostředí .NET pak jako Common Intermediate Language (dříve známo spíše pod zkratkou MSIL - Microsoft Intermediate Language). Zmíněné dva jazyky nejsou zaměnitelné, i když se řídí do jisté míry společným principem. Spravovaný kód je pak na požádání běhovým prostředím velmi efektivně přeložen do skutečného nativního kódu pro danou HW platformu a 2 Tzv. p-code. Díky této vlastnosti je možné považovat eMbedded Visual Basic za jazyk bližší spíše Visual Basic Script než skutečnému Visual Basicu. 3 typicky Java, C#, VB .NET. Méně obvykle i C++, J# nebo Jscript.NET

12 spuštěn pod jeho kontrolou. Pro platformu Java se jedná o prostředí JVM (Java Virtual Machine), v případě platformy .NET je toto prostředí nazýváno CLR (Common Language Runtime). Zřejmou nevýhodou tohoto přístupu je částečná ztráta výkonu, daného kompilací do strojového kódu až v době požadavku na spuštění aplikace (označováno pojmem just-in-time kompilace). V prostředí .NET a nových verzích prostředí Java je pokles výkonu redukován tzv. dynamickou kompilací, kdy není překládán celý kód aplikace jako u statické kompilace, ale pouze aktuálně potřebné části programu. Tato forma adaptivní optimalizace vychází z předpokladu značné pravděpodobnosti, že velké části aplikace nebudou během uživatelské relace vůbec použity. Díky tomuto přístupu je pokles výkonu na obou zmíněných platformách z uživatelského hlediska zane- dbatelný. Spravované prostředí poskytuje na druhou stranu řadu výhod. Jednou z nich je platformová nezávislost, plynoucí z překladu zdrojového kódu do společného bajtového jazyka. Odpovědnost za finální překlad na konkrétní cílovou HW platformu díky tomu připadá na spravované prostředí. Prostředí .NET zajišťuje dokonce interoperabilitu programovacích jazyků (různé části aplikace je díky této vlastnosti možné implementovat v různých jazycích). Tohoto je docíleno pomocí přísné typizace dat a především společného systému typů (Common Type System), který je reprezentován stromovou hierarchií standardních typů. Proměnná typu Integer v programovacím jazyce VB.NET je během překladu do spravovaného kódu přirazena společnému typu Int32. Obdobně se prostředí chová k proměnné int v programovacím jazyce C++ atp. Dalšími výhodami koherentními s faktem, že spravovaný kód je spouštěn pod kontrolou spravovaného prostředí, je zvýšená bezpečnost a efektivnější správa paměti. Prostředí může kont- rolovat, kdo kód spouští, kdo je jeho vlastníkem a jaké potenciálně nebezpečné operace provádí.

2.4.1. Programovací jazyky použitelné pro vývoj spravovaného kódu

●Visual Basic .NET [3] Programovací jazyk vzniklý kompletní restrukturalizací jazyka Visual Basic 6 pro potřeby prostředí .NET. S jazykem VB 6 není zpětně kompatibilní, tzn. kód psaný v jazyce VB 6 nelze přeložit jako kód jazyka VB.NET, přestože existují nástroje pro migraci. Aktuální verze byla uvolněna společně s .NET Framework 3.5 a nese označení Visual Basic 2008 (také Visual Basic 9.0)

●C++/CLI [4] Jazyk, který nahradil zastaralý Visual C++ .NET (prosté rozšíření nespravovaného jazyka C++ o možnosti tvorby spravovaného kódu, např. využitím klíčového slova __gc). C+-+/CLI není plnohodnotným jazykem pro tvorbu spravovaného kódu. Přestože musíme přijmout všechny nevýhody, které vyvolává nespravovaný kód, nelze přehlížet např. výhodu přímého volání nespravovaných tříd jazyka C++ z nespravovaného kódu jazyka C++ bez nutnosti dalších pomůcek (typicky využití modelu COM). Jazyk je popisován standardem ECMA-372.

●C# (také C Sharp) [5] Jazyk navržený speciálně pro použití v prostředí .NET Framework. Aktuální verze byla uvolněna společně s .NET Framework 3.5 a nese označení C# 3.0. Je popisován normami ECMA-344 a ISO/IEC 2370. Více o vývoji v jazyce C# viz kapitola 4.

●J# (také J Sharp) [6] Jazyk, jehož primárním účelem bylo umožnit programátorům v jazyce Java snadný přechod na

13 plaftormu .NET. Z tohoto důvodu má obecně totožnou syntax. Rozdíl spočívá v kompilátoru, který převede zdrojový kód do CIL namísto bajtového kódu platformy Java. Jazyk J# v jeho aktuální verzi 2.0 nepovažuji za příliš vhodný, neboť postrádá oproti C# možnosti pro definici nových delegátů, hodnotových typů a dalších specifik prostředí .NET. V případě potřeby je proto nepodporované technologie nutné programovat v jiném jazyce. Velkou nevýhodou je také skutečnost, že ve srovnání s jazyky VB.NET a C# je dokumentová podpora ze strany společnosti Microsoft minimální.

●Jscript.NET [7] Nástupce jazyka Jscript v prostředí .NET. Zatímco původní Jscript byl čistě skriptovacím jazykem,4 kód napsaný v Jscript.NET je nejdřívě kompilován do CIL a spouštěn pod CLR. Zároveň si ovšem zachovává plnou podporu interpretovaného chování, takže jej lze obdobně jako C# považovat za kompromis mezi filozofií spravovaného a nespravovaného kódu (v tomto případě tedy skriptu). Největší nevýhodou jazyka je chybějící podpora vývojovým prostředím Visual Studio společnosti Microsoft a méně obsáhlá dokumentace než v případě jazyků C# a VB.NET. Aktuální verze jazyka Jscript byla uvolněna společně s .NET Framework 3.5. a je označována jako JScript 8.0.

●Java Objektově orientovaný jazyk s dlouhou tradicí (první verze byla představena v roce 1995), šířený pod licencí GNU Genereral Public License. Podobně jako C# je syntax odvozena z jazyka C++. Výhodou platformy Java je vysoká a oficální podpora alternativní operačních systémů (Linux, Mac OS X, Solaris), zatímco .NET Framework je primárně určen pouze pro operační systémy rodiny Windows a podpora ostatních systému je zajišťována třetími firmami (např. nejběžnější open- source projekt Mono [8] sponzorovaný společností Novell.).

3. Analýza dostupných řešení

4 Programy napsané ve skriptovacím jazyku se před spuštěním nekompilují, ale jsou přímo interpretovány prostředím.

14 Pro účely testování aplikací byl použita sada emulátorů mobilních zařízení, distribuovaná společně s Windows Mobile 5.0 SDK a Microsoft Visual Studio 2008. Analýza se zaměřuje především na použitelnost aplikací v rámci studia bakalářského programu Aplikovaná informatika FI MU.

3.1. Obecné nástroje pro zobrazení studijních materiálů

Protože studijní materiály jsou zpravidla distribuovány ve formátu PDF, je nutné tyto dokumenty vhodnou formou zpřístupnit pro zobrazení na mobilních zařízeních. Optimalizaci PDF dokumentů pro mobilní zařízení je možné provést nástrojem RepliGO PDF Mobilizer, který podporuje platformy platformy Pocket PC (Windows Mobile), Palm (Palm OS), Symbian. Nástroj zmenší velikost dokumentů a připraví dále k prohlížení.

Jediným volně dostupným prohlížečem PDF dokumentů je Adobe Reader for Pocket PC 2.0 a analogické verze pro platformy Palm a Symbian. Program poskytuje poměrně standardní funkce jako přibližování a oddalování dokumentu, na druhou stranu je nenáročný na výkon a má minima- listické, intuitivní uživatelské rozhraní.

Pro prohlížení elektronických knih ve formátu PDB nebo PRC je možné použít open-source nástroj Haali Reader 2.0. Nevýhodou tohoto nástroje je relativní zastaralost, neboť jeho vývoj byl pozastaven v roce 2003 na verzi 2.0b264. Přesto podporuje různé módy zobrazování textu, vyhledávání v textu, ClearType fonty a také externí překladové slovníky.

Webové dokumenty lze prohlížet typicky v mobilních verzích nejpoužívanějších webových prohlí- žečů pro platformu PC. Jsou jimi Opera Mobile 9.5, Internet Explorer a Mozilla Fennec (postavený na jádru prohlížeče Mozilla Firefox). Pouze Fennec je šířen jako open-source. Všechny prohlížeče nabízejí obdobnou funkcionalitu, Opera Mobile a Fennec lépe podporují standardy a optimalizují web pro prohlí žení na mobilních zařízeních. Výhodou prohlížeče Internet Explorer je, že je šířen spolu s operačním systémem Windows Mobile, tedy není třeba dodatečné instalace. Výhodou Opera Mobile oproti Mozilla Fennec je téměř poloviční velikost, tj. 5.3MB oproti 9.3MB.

3.2. Překladové slovníky

Volně přístupná služba slovnik.cz poskytuje velmi rozsáhlé slovníky pro překlad mezi češtinou a světovými jazyky. Jako databáze významových dvojic zde byly použity materiály poskytnuté vý- robcem komerčního programu PC Translator, firmou Langsoft. Optimalizace stránek pro zobrazení na displeji PDA je minimální. Obsahově nerelevantní postranní lišty s reklamními odkazy na sponzory projektu není možné odstranit a manipulace s ovládacími prvky je tak pro uživatele velmi nepohodlná, zvláště po zobrazení panelu SIP.

Služba wordbook.cz byla založena na Open Source projektu GNU/FDL Anglicko-Český slovník, který zahrnuje databázi významových dvojic pro anglicko-český překlad. Optimalizace stránek pro

15 PDA zařízení je na vynikající úrovni, především díky minimalistickému přístupu k designu.

Přímo z GNU/FDL Anglicko-Českého slovníku vychází i k projektu přidružený webový vyhle- dávač. Webové prohlížeče pro Windows Mobile 5.0 si nicméně s použitými kaskádovými styly ne- poradí ideálním způsobem a především hlavní nabídka se zobrazuje špatně.

Další webové implementace slovníku firmy Langsoft a GNU/FDL Anglicko-Českého slovníku: http://slovniky.centrum.cz> http://slovnik.tiscali.cz http://slovnik.seznam.cz http://www.pooh.cz/slovnik http://www.enviweb.cz http://www.instinkt-cz.com/slovnik.php

Freeware nebo open-source obdoba komerčních slovníků, umožňujících offline prohlížení, neexistuje. K implementaci vlastního slovníku je možné využít GNU/FDL Anglicko-Český slovník, ob- sahující aktuálně 140 000 významových dvojic. Jako doplňující materiál lze použít méně obsáhlé otevřeného slovníky Davida Zbírala.

3.3. Výkladové slovníky – tezaury

Podobně jako v případě překladových slovníků chybí kvalitně zpracovaný offline slovník, zatímco kvalitativně rovnocenných webových služeb je k dispozici více než deset.

Příklad nejvýznamnějších webových slovníků: http://slovnik-cizich-slov.abz.cz http://www.slovník-cizich-slov.cz http://www.slovnik-cizich-slov-on-line.cz http://www.slovnik-cizich-slov.uzdroje.com

Při implementaci výkladového slovníku se jeví jako nejpodstatnější úkol nalezení vhodné databáze slovníkových pojmů. Inspiraci lze hledat na platformě Palm, resp. ve freewarovém nástroji mdop freeware dictionary (URL: ). Vytvoření konverze programu pro mobilní platformu by nemělo představovat vážný problem vzhledem k faktu, že databáze je uložena ve standardním dokumentu typu PDB (Palmpilot Database/Document File).

Z výše zmíněného produktu vychází mimo jiné i webová služba slovnik-cizich-slov.abz.cz, jejíž autor výchozí databázi značně rozšířil umožněním aktualizace a přidávání nových hesel běžnými návštěvníky webu. Z hlediska akademického prostředí je proto korektnost jejího použití značně dis- kutabilní. Výhodou je nicméně triviální uložení dat v běžném textovém souboru, který umožňuje další bezproblémové zpracování.

Jako vhodný doplňující materiál je možné použít slovník českých slovních tvarů projektu OpenOffice.org, vytvořený doc. RNDr. Pavlem Smržem s působištěm na Fakultě informatiky Ma- sarykovy univerzity v Brně.

16 3.3. Learning managment systems (LMS)

LMS je aplikací pro administraci a organizaci výuky, zpravidla na bázi webového rozhraní. Více se problematice LMS věnuje Bc. Michaela Miovská v práci Mobilní e-learningové nástroje [9].

3.4. Matematické nástroje

Oproti jiným oblastem je nabídka matematických aplikací pro mobilní zařízení poměrně obsáhlá:

●Calc98 v5.3 Freeware počítací software s dlouhou tradicí. Podmínkou použití je po uplynutí 90 dnů zkušební lhůty bezplatná registrace. Nejnovější verze pro Windows Mobile s vylepšeným uživatelským rozhraním je již komerční povahy, přesto lze považovat Calc98 v5.3. za zřejmě nejlepší freeware tohoto druhu. K dispozici je podrobná dokumentace více než deset různých výpočetních módů (normální, statistický, finanční, uživatelský, několik fyzikálních, binární, hexadecimální, maticový a s komplexními čísly). Součástí aplikace je i periodická tabulka chemických prvků, přehled fyzikálních konstant a ASCII tabulka.

●EasyCalc Vědecká kalkulačka, určená pro platformu Palm. Je založena na zadávání matematických formulí, které následně provedeny stisknutím tlačítka EXE. Podporuje vizualizaci grafů v různých souřadnicích a všechny funkce běžné pro obdobné vědecké kalkulátory.

●Gnuplot 4.2.5 Velmi propracovaná open-source utilita pro vizualizaci 2D a 3D grafů, u které byl později vytvořen port pro platformu Pocket PC.

●Eigenmath PPC Port open-source algebraického systému eigenmath s obdobnou funkcionalitou.

●LME for Pocket PC Prozatím ve stadiu technologického dema. V budoucnu se může jednat o použitelný port jazyka LME pro numerické výpočty, který je kompatibilní se systémem Matlab.

4 Vývoj v prostředí .NET pro Pocket PC

Prostředí .NET poskytuje z hlediska vývojáře bohatou knihovnu, která poskytuje téměř ty samé

17 možnosti jako rozhraní Windows API. Mimo to ovšem také zpřístupňuje jednoduchým způsobem další moderní technologie. Podporuje efektivní přístup k datům pomocí množiny komponent ADO.NET. Vylepšuje podporu dynamických webových stránek pomocí komponent ASP.NET (za- staralá technologie ASP byla v důsledku využití interpretovaných skriptovacích jazyků méně efek- tivní) a v neposlední řadě i webových služeb. A mnohé další. Kompletnímu výčtu možností a tech- nologií implementovaných v prostředí .NET se v textu zabývat nebudeme. Důvodem je skutečnost, že pro účely vývoje aplikací pro mobilní platformy společnost Microsoft vyvinula SW platformu .NET Compact Framework. Nejpodstatnějším rozdílem oproti plné verzi .NET Framework je skutečnost, že v kompaktní je vzhledem ke specifickým nárokům mobilních platforem obsažena přibližně třetina funkcionality. Vybrány byly tedy třídy, které nejlépe odpovídají zpravidla silně omezeným systémovým prostředkům mobilních zařízení, ať už se jedná o omezení výkonová (procesor) či prostorová (paměť, uživatelský vstup). V souladu s předchozím má samotný .NET Compact Framework také menší požadavky na uložnou kapacitu počítače. Výhodami návrhu .NET Compact Framework jakožto podmnožiny stabilní a prověřené ar- chitektury jsou samozřejmě zdědění všech dobrých vlastností . NET Framework a spravovaného objektového kódu jako takového (více viz 3.3.) a snadná adaptace vývojářů se zkušenostmi s programovaním aplikací pro platformu PC, kteří proto mohou až na výjimky (.NET CF obsahuje také několik vlastností a tříd, speciálně vytvořených pro účely mobilních zařízení) dále úročit své znalosti. Na druhou stranu není možné podceňovat jistá potenciálně komplikující úskalí. Především je zcela nezbytné věnovat pečlivou pozornost návrhu aplikace a analýze prostředků, které budou k vyřešení problému použity. .NET Compact Framework řadu tříd podporuje pouze částečně. Typickým příkladem může být objektový model GDI+, sloužící k vykreslování grafických objektů prostřednictvím kontextu zařízení (zde reprezentovaného třídou System.Drawing.Graphics). Zatímco v plném .NET Framework poskytuje model GDI+ poměrně propracované možnosti vykreslování bezierových křivek a dalších pokročilých objektů, v kompaktní verzi celá řada metod chybí a GDI+ tak lze být využito pouze k vykreslení základních primitiv (úsečka, poly- gon, elipsa, obdélník, text). Jako další příklady mohou posloužit XML se značně omezenými možnostmi a ovládací prvek ListView, nepodporující v kompaktní verzi vlastnost GridLines. Analýzu podobných problémů naštěstí značně ulehčuje podrobná dokumentace Microsoft Document Network, obsahující u každé třídy, metody nebo vlastnosti výčet podporovaných platforem, včetně označení verzí. Alternativně lze použít filtrování informací.

4.1. Omezení a specifika NET Compact Framework

●.NET CF nepodporuje ASP.NET. K podobnému účelu je možné použít ASP.NET mobile Web Controls.

●.NET CF nepodporuje volání metod GetCurrentDirectory a SetCurrentDirectory. Za defaultní cestu se považuje kořenový adresář zařízení, nikoliv tedy adresář aplikace, jak je tomu v .NET Framework. Toto je nutné brát v úvahu během práce s názvem souboru bez specifikace plné cesty a nejlépe plnou cestu definovat. Pro určení adresáře aplikace je možné použít následující kód.

string strAppDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetModul es()[0].FullyQualifiedName);

18 ●.NET CF podporuje pouze podmnožinu komponent ADO.NET. Taktéž chybí podpora OLE DB. V souvislosti se službou SQL Server nejsou podporovány distribuované transakce, připojení přes kolébku, šifrované připojení a connection pooling (zařízení tedy může mít pouze velmi málo paralelních připojení ke službě SQL Server).

●.NET CF nepodporuje asynchronní delegáty.

●Zatímco v .NET Framework bylo možné přistupovat k vlastnostem i u disposed objektů, v kompaktní verzi takový pokus téměř vždy selže.

●Během dělení velkými čísly či naopak velmi malými je nutné počítat se zaokrouhlováním.

●.NET CF nepodporuje události Activated a Deactivated u formulářů.

4.2. Design uživatelského rozhraní pro mobilní platformy

Při návrhu grafického rozhraní je nutné pamatovat na řadu skutečností. Veškeré texty a popisky ovládácích prvků by měly být dobře čitelné, což lze zajistit vhodnou volbou barvy (a zákonitě tedy i kontrastu s pozadím). Je vhodné vyhnout se při návrhu příliš malým velikostem písmen, přestože omezený prostor několikapalcového displeje zpravidla vybízí k opaku. Společnost Microsoft ve specifikaci Windows Mobile 5.0 SDK uvádí jako optimální velikost 8 nebo 9 pixelů pro font Tahoma. Nejvhodnější je však ponechat rozhodnutí na uživateli a umožnit v samostatném dialogu možnost vybrání hodnot jednotlivých atributů písmen a barev.

Aplikace pro operační systém Windows Mobile může využívat prakticky celou paletu ovládacích prvků, známých z běžných graficky orientovaných systémů. Během návrhu uživatelského rozhraní je nezbytné zvážit a řídit se následujícími obecnými pravidly: ● popisky ovládacích prvků by měly být maximálně stručné a výstižné ● pokud ovládací prvek reprezentuje potvrzení či výběr akce, měl by být pojmenován v pozitivní formě, tj. „Potvrzuji“ namísto „Nezamítám.“ ● ovládací prvky s podobnou funkcionalitou by měly být na displeji seskupovány do logických celků. ● chování ovládacích prvků by mělo být maximálně předvídatelné (např. tlačítko s popiskem Další přepne kontext aplikace na následující prvek) ● ovládací prvky by měly mít dostatečnou velikost pro ergonomicky kvalitní manipulaci (viz tabulka 4.1.).

Metoda ovládání Minimální rozměry ovládacího prvku stylus 20x20 pixelů ruka (prst) 40x40 pixelů Tabulka 4.1 – Minimální rozměry ovládacích prvků

19 4.2.1. Základní ovládací prvky v systémech Windows Mobile (Pocket PC) Následuje popis základních ovládacích prvků, využívaných v aplikacích postavených na platformě .NET Compact Framework. Na tomto místě je nutné upozornit, že část komponent není podporována na platformě smartphone, což je také důvodem stíženého portování aplikací z platformy Pocket PC. Ovládací prvky obsažené ve jmenném prostoru Microsoft.WindowsCE.Forms (ro- zuměj unikátní pro rodinu operačních systémů Windows CE) jsou označeny podtržením.

● Checkbox. Poskytuje funkcionalitu pro implementaci výběru podmnožiny nabízených prvků. Je dobrým programátorským stylem udržovat během návrhu rozumnou míru ovládacích prvků checkbox. Pokud je nutné nechat uživatele pracovat s větším množstvím položek, vždy je výhodné zvážit alternativu v podobě libovolného druhu seznamu (např. List View).

● Radiobutton. Ovládací prvek, který lze použít k implementaci výběru právě jednoho prvku z množiny položek. Jeho použití v uživatelském rozhraní není vhodné. Důvodem je v první řadě chybějící podpora třídy Groupbox v .NET Compact Framework, která musí být v případě potřeby nahrazována složitěji, zpravidla využitím kontejneru Panel.

Druhým problémem je náročnost na plochu displeje. Každá položka výběru musí být na obrazovce viditelná v jeden okamžik, což může při jejich větším počtu působit nepře- hledně. Alternativně tedy doporučuji spíše využití prostorově úspornějších komponent pro výběr prvku, zejména pak list box a combox.

● ListBox. Standardní seznam.

● ComboBox. Obdobně jako ListBox, zobrazena je však pouze aktuálně vybraná položka. Výhodou oproti ListBoxu je úspora místa na displeji, nevýhodou menší přehlednost (uživatel nevidí na první pohled všechny položky seznamu).

● ListView. Reprezentuje také seznam, ovšem s bohatší funkcionalitou než ListBox. Ovládací prvek ListView obsahuje metody pro třídění, podporuje zobrazení grafických prvků jako jsou checkboxy nebo ikony. Umožňuje navíc seznam zobrazit v jednom ze čtyř dostupných módů (viz tabulka 4.2).

20 Název zobrazení Způsob zobrazení každé položky LargeIcon Velké ikony s popiskem pod nimi. Details Detailní zobrazení SmallIcon Malé ikony s popiskem vedle nich. List Malé ikony s popiskem vedle nich. Položky jsou uspořádané do sloupců bez hlavičky. Tabulka 4.2. - Módy zobrazení komponenty ListView

● Treeview. Vykreslení stromové hierarchie prvků. Ovládací prvek Treeview umožňuje u zobrazených prvků vykreslení checkboxu nebo ikony, což usnadňuje manipulaci uživatele s celou struk- turou. Nejčastěji se využívá k zobrazení adresářové struktury a obsahu XML souborů.

● Button. Standardní tlačítko.

● Label. Standardní popisek.

● Link Label. Popisek s možností hyperlinku.5

● MainMenu. Reprezentuje hlavní nabídku formuláře, zobrazenou v dolní části displeje. Na platformě Pocket PC je v levé části umístěno tlačítko s nejčastěji volanou akcí. Uprostřed je ikona pro vyvolání vstupního panelu SIP. V pravé části je poté situována rozbalovací nabídka s další- mi funkcemi formuláře. Jednotlivé položky v menu jsou reprezentovány třídou MenuItem. V případě potřeby více podobných hlavních nabídek na jednom formuláři je situace zkomplikována absencí metody CloneMenu() v prostředí .NET Compact Framework. Al- ternativní nabídky je proto nutné konstruovat ručně, dynamickou tvorbou, odebíráním a za- řazováním objektů MenuItem.

● ContextMenu. Běžná kontextová nabídka, kterou lze svázat s ovládacími prvky, které ji podporují, typicky formulář, seznamy a tabulky. Na platformě Pocket PC lze vyvolat kontextovou nabídku po- držením stylusu na displeji (tap-and-hold). Tato akce dále vyvolá událost OnPopup. Ačko- liv událost OnPopup nepředává pozici, na které došlo k vyvolání kontextové nabídky, a sama nabídka ani neobsahuje žádnou vlastnost s touto funkcionalitou, koordináty lze jednoduše zjistit následujícím příkazem:

contextMenuPos = this.PointToClient(Control.MousePosition);

5 Třídu ToolStripLabel, která do jisté míry nahrazuje jak Label, tak Link Label, prostředí .NET Custom Framework prozatím nepodporuje.

21 ● SaveFileDialog, LoadFileDialog. Standardní dialogová okna pro výběr souboru pro uložení nebo načtení dat. V prostředí .NET Compact Framework není v těchto ovládacích prvcích implementována vlastnost AcceptButton a CancelButton, podobné funkcionality je tedy nutné dosáhnout vhodnou obsluhou stisku příslušných kláves.

Obrázek 4.1. - Komponenta SaveFileDialog

● InputPanel 6 . Spravovaná implementace ovládacího prvku SIP, umožňující přeprogramování jeho impli- citního chování.7 Zobrazení SIP je řízeno vlastností Enabled. Rozměry SIP lze získat po- mocí vlastnosti Bounds, rozměry viditelné části formuláře pak reprezentuje vlastnost VisibleDesktop.

6 Obdobou třídy InputPanel je na platformě Smartphone třída InputModeEditor. 7 Při vytvoření nového projektu ve Visual Studio, na formulář je automaticky umístěna hlavní nabídka s přepínačem zobrazení a ukrytí SIP. Pokud je SIP aktivní, uživatelský vstup je směrován do ovládacího prvku, který má aktuálně fokus.

22 Nejčastějším využitím ovládacího prvku InputPanel je změna rozložení a velikostí ostatních ovládacích prvků na formuláři v reakci na změnu vlastnosti Enabled tak, aby komponenta SIP nezakrývala relevantní údaje a vstupní pole. Této funkcionality lze dosáh- nout obsluhou události EnabledChanged.

● Notification. Spravovaná implementace systémových oznámení v operačních systémech Windows CE. Po vytvoření objektu Notification jej lze zobrazit nastavením vlastnosti Visible na hodnotu true (vyvolá událost BalloonChanged). Vlastnost InitialDuration odpovídá době, po který zůstane oznámení aktivní (defaultně 10s). Jestliže uživatel klikne na oznámení před uply- nutím definované doby, je vyvolána událost ResponseSubmitted.

● HardwareButton. Umožnuje předefinovat chování tlačítka na přístroji a svázat ho tak s libovolným jiným ovládacím prvkem. Po vytvoření instance HardwareButton je nutné odkázat vlastností AssociatedControl na požadovaný ovládací prvek. Dále je třeba nastavit vlastnost HardwareKey na některou ze sedmi hodnot, definovaných výčtem HardwareKeys.8 Více než šest tlačítek tedy není s využitím tohoto ovládacího prvku překonfigurovat, a to ani v případě, že cílový přístroj větším počtem disponuje. Také je nutné vzít v úvahu omezení některých operačních systémů. Windows Mobile 2003 podporuje pouze čtyři tlačítka, Windows Mobile 5.0 pět tlačítek a Windows Mobile 6.0 šest tlačítek. Pokud je vyžadována zpětná kompatibilita aplikace, je možné ji zaručit podmíně- ným překladem kódu nebo obsluhou výjimky NotSupportedException, kterou vyvolává vý- čet HardwareKeys při pokusu o zpřístupnění systémem nepodporované hodnoty.

● Document List. Představuje spravovanou implementaci nativního ovládacího prvku DocList, tj. dialogové okno pro zobrazování a správu dokumentů Word a Excel (v jim odpovídajících aplikacích Pocket Word a Pocket Excel je ostatně tato komponenta využita). Dialogové okno poskytuje uživateli prostředky pro manipulaci s dokumentovými soubory (výběr, mazání, kopí- rování a přesun, přejmenování), třídění podle kritérií, zasílání e-mailem nebo prostřednictvím infračerveného rozhraní.

Poznámky: Definice klávesových zkratek a mnemonics není na platformě Pocket PC příliš relevantní. Mnemonics (jednoznakové zkratky pro položky nabídky) mají smysl na platformě Smartphone a mobilních telefonech, kde lze svázat položky menu s číselnou klávesnicí, která na zařízeních PDA chybí. Klávesové zkratky (CTRL+A, CTRL+B,...) jsou využitelné pouze za předpokladu připojení externí klávesnice. Tento druh periferního zařízení je ovšem mezi uživateli rozšířený spíše mino- ritně, neboť je relativně nákladný a koliduje s přirozenou filozofií maximální mobility přístroje. V případě implementace je přesto nutné dbát zažitých standardů a snažit se být kompatibilní s ostat- ními aplikacemi (zvýšení předvídatelnosti chování aplikace).

Návrh menu je vhodné podřídit předpokládané frekvenci využívání funkcí uživatelem. V levé části hlavního menu by měla být umístěna nejčastěji využívaná funkce v daném kontextu aplikace, v pravé části pak několik méně využívaných funkcí. Jen výjimečně využívané funkce je výhodné umístit do podnabídky. S ohledem na prostorová omezení displeje silně nedoporučuji aplikovat na

8 {None, ApplicationKey1, ..., ApplicationKey6}

23 nabídku více než tři stupně zanoření. Pokud je to nezbytné, návrhář by měl zvážit umístění těchto funkcí na samostatný formulář.

Více o návrhu uživatelského rozhraní viz [Programujeme mobilní aplikace ve Visual Studiu .NET, str. 232]

4.3. Architektura systému Windows Mobile

Vzhledem ke značnému paměťovému omezení, absenci stránkování virtuální paměti a zpravidla i závislosti přístroje na bateriovém zdroji energie jsou operační systémy na mobilních platformách unikátní konceptem správy systémových prostředků. Vzhledem ke skutečnosti, že systém Windows Mobile umožňuje zobrazení pouze maximalizovaných oken, označuje se aktuálně zobrazená aplikace jako aktivní. Zbylé běžící aplikace jsou označovány jako neaktivní. Předně je nutné pochopit způsob, jakým se operační systém Windows Mobile vyrovnává s potenciálním nedostatkem volné operační paměti. V případě takového nedostatku zašle shell ope- račního systému nejdéle neaktivní aplikaci zprávu WM_HIBERNATE, kterou žádá o uvolnění systémových prostředků. Pokud aplikace obsahuje obslužnou metodu, tato by měla zajistit přechod aplikace do stavu hibernace. Tím se zpravidla rozumí uvolnění držené paměti, uvolnění co největší- ho počtu postradatelných objektů (dynamicky vytvořené ovládací prvky, Graphics objekty atd.) a uložení svého stavu. Obsluha zprávy WM_HIBERNATE není pro aplikaci povinná, přesto poměrně žádoucí, neboť nevede k tak častému restartování programu a souvisejícímu zatížení systému. Pokud není uvolnění paměti dostatečné, systém Windows mobile pokračuje v zasílání zpráv dalším aplikacím, přičemž frekvence zasílání roste úměrně klesající volné paměti. Více o obsluze hibernace a jiných systémových zpráv ve spravovaném kódu viz 4.3.2. Pokud úroveň volné paměti klesne pod tzv. stav low-memory, definovaný hodnotou 2MB, hrozí pád aktivní aplikace. Aby mu zabránil, shell operačního systému začne rozesílat namísto zprávy WM_HIBERNATE zprávu WM_CLOSE dle stejného schématu, čímž vynutí úplné ukon- čení nejdéle neaktivních aplikací. Aplikací, u nichž je nutné zajistit konzistentní chování mezi jednotlivými spuštěními, musí na zprávu WM_CLOSE do osmi sekund zareagovat uložením všech relevantních dat, zpravidla do nějakého dočasného souboru. Pokud nedojde k uvolnění dostatečného množství paměti ani po ukončení všech neak- tivních aplikací a systém dosáhne tzv. stavu critical-memory (24 kB volné paměti), dojde k vyvo- lání dialogového okna s informací o nedostatku volné paměti. Zároveň s vyvoláním okna dojde k pozastavení zbytku systému. Po uzavření okna uživatelem se aktivní aplikace automaticky ukončí zasláním zprávy WM_CLOSE.

4.3.1. Knihovna tříd Microsoft.WindowsMobile Windows Mobile 5.0 SDK nabízí mimo jiné knihovnu WindowsMobile, obsahující množinu tříd, doplňujících funkcionalitu prostředí .NET Compact Framework o techniky práce se specifickými prostředky systému Windows Mobile. Knihovna je složena z následujících jmenných prostorů:

●WindowsMobile.Configuration Obsahuje třídu ConfigurationManager, implementující možnost zasílání konfiguračních XML souborů, které se buď zpracují nebo otestují. Tento jmenný prostor je využitelný spíše pro použití na platformě Smartphone, pro platformu Pocket PC neposkytuje dostatek relevantních funkcí.

24 Proto se jí nebude dále v textu zabývano.

●WindowsMobile.Forms Obsahuje třídy CameraCaptionDialog, ChooseContactDialog, SelectPictureDialog. Třídy v tomto jmenném prostoru poskytují možnost vytvoření uniformních dialogových oken pro záznam kamery (včetně podrobných možností nastavení), výběr z kontaktů uložených v paměti mobilního zařízení a výběr obrázku v adresářové struktuře. Protože se jedná o třídy s velmi okrajovým využitím, nebude se jimi v textu dále zabýváno.

●WindowsMobile.PocketOutlook Velmi obsáhlá množina tříd, umožňujících externí přístup k funkcím aplikace Pocket Outlook. Taktéž se jedná o velmi specifickou záležitost, proto se jí nebude v textu dále zabýváno.

●WindowsMobile.Status Jmenný prostor Status poskytuje přístup k systémovým vlastnostem. Obsahuje abstraktní třídu StateBase, kterou dále implementují třídy SystemState a RegistryState. Třída RegistryState umožňuje přímý přístup k položkám systémového registru (vlastnosti Key, ValueName a CurrentValue). Třída SystemState obsahuje několik desítek převážně statických vlastností9, odráže- jících aktuální stav systému (datum, čas, poloha displeje, stav baterie, počet úloh, přítomnost periferních zařízení, ActiveSync, atd.).

●WindowsMobile.Telephony Jmenný prostor Telephony obsahuje jedinou třídu Phone, implementující vytáčení telefonních čísel dle zadaných kritérií. Není podporováno platformou Pocket PC, proto se nebude v textu dále zabýváno.

Poznámka: Knihovna WindowsMobile neposkytuje v mnoha směrech funkcionalitu odpovídající potřebám vývojáře. Především chybí dostatečně silný mechanismus reakce na závažné změny stavu systému jako přechod do stavu hibernace.

4.3.2. Knihovna tříd Microsoft.WindowsCE.Forms Mimo ovládací komponenty HardwareButton, InputPanel, Notification (viz 4.2.1.) a jim náležejících výjimek definuje knihovna tříd Microsoft.WindowsCE.Forms důležitou funkcionalitu, umožňující ve spravovaném prostředí pracovat se službami operačního systému. Následuje výčet nejdůležitějších:

●SystemSettings Statická třída obsahující vlastnosti ScreenOrientation a Platform. Vlastnost ScreenOrientation je čtyřprvkovým výčtem s hodnotami Angle0, Angle90, Angle180 a Angle270, reprezentujícími jednotlivá natočení obrazovky. Standardně se využívá Angle0 (tzv. „portrait“ orientace) a Angle90 (tzv. „landscape“ orientace). Výčtová vlastnost Platform reprezentuje typ HW platformy, na které je aplikace spuštěna. Možnými hodnotami jsou PocketPC, Smartphone a WinCEGeneric (ostatní platformy s operačním systémem typu Windows CE). Vlastnost Platform je důležitá při vývoji cíleně multiplatformních aplikací, neboť umožňuje odpovídajícím způsobem upravovat uživatelské rozhraní. 9 Kompletní výčet lze viz [10] v seznamu literatury

25 ●MobileDevice Třída obsahující statickou událost Hibernate, zodpovídající za informování aplikace, resp. vlákna, o blížícím se nedostatku systémových prostředků. Je vysoce žádoucí událost Hibernate obsloužit standardním předáním obslužné rutiny, která připraví aplikaci pro stav hibernace zálohováním relevantních dat: public void OnHibernate(Object sender, EventArgs e); { //obslužný kód }

MobileDevice.Hibernate += new EventHandler(OnHibernate);

●MessageWindow Třída poskytující prostředky k zasílání a zpracování zpráv operačního systému. Zasílat zprávy je možné pomocí statických metod PostMessage (zašle zprávu k okamžitému zpracování) a SendMessage (zašle zprávu a vyčká na zpracování metodou WndProc). Protože je metoda WndProc virtuální, nelze třídu MessageWindow využívat v aplikaci přímo, ale vždy je nutné nejdříve vytvořit potomka, který tuto metodu překryje. Jeden ze způsobů takového překrytí ukazuje následující ukázka:

protected override void WndProc(ref Message msg) { switch(msg.Msg) { case WM_SOMEMESSAGE: //zpracuj msg.WParam; //zpracuj msg.LParam; break; } base.WndProc(ref msg); }

●LogFont Třída LogFont spravovanou implementací nativní struktury LOGFONT, umožňující definování transformace fontu zobrazeného textu. Nejčastěji používanou transformací je rotace o určitý úhel, které lze dosáhnout nastavením vlastnosti Escapement.

5 Aplikace pro vizualizaci konečných automatů

26 Cíle implementace aplikace: ●poskytnout uživateli prostředí pro interaktivní tvorbu konečného automatu ●poskytnout uživateli možnost ukládat konečný graf formou XML nebo obrázku ●poskytnout uživateli možnost testovat nad konečným automatem sadu dat, zadanou buďto manuálně nebo nahráním ze souboru ●poskytnout uživateli možnost testování dat vizualizovat

Použité programové prostředky: ●Visual Studio 2008 ●C# ●Windows Mobile 5.0 SDK ●Windows Mobile 5.0 Pocket PC Emulator ●Microsoft ActiveSync 4.1.0.

Aplikace reálně testována na přístroji: ●Pocket PC Acer n311 (specifikace přístroje viz 3.1.2.3.)

5.1. Konečný automat

Konečný automat M je pětice (Q, Σ, δ, q0, F), kde:

Q je neprázdná konečná množina stavů, Σ je konečná vstupní abeceda, δ: Q x Σ → Q je parciální přechodová funkce q0 je počáteční stav, F je konečná množina koncových stavů.

Lze také definovat rozšířenou přechodovou funkci δ': Q x Σ* → Q induktivně k délce slova Σ* předpisem

 q ,=q pro ∀ q∈Q

 q ,wa= q ,w,a je−li  q ,w a  q ,w,a definováno

Slovo w je akceptováno konečným automatem M, pokud rozšířená přechodová funkce vrací ko- nečný stav.

5.2. Implementace konečného automatu

27 Po zvážení a vyzkoušení několika alternativ jsem se rozhodl pro následující implementaci trojice tříd, reprezentujících strukturu konečného automatu a základní funkcionality na něm.

Třída Node odpovídá stavu konečného automatu. Obsahuje privátní členské proměnné val (hodnota), x (souřadnice na ose x) a y (souřadnice na ose y). Proměnná val představuje pouze označení stavu, které si zvolí sám uživatel. Na samotné operace s konečným automatem nemá vliv. Třída Node dále obsahuje konstruktor, inicializující tyto proměnné, a veřejné vlastnosti, umožňující jejich čtení a zápis. Nakonec třída Node překrývá metodu ToString. Třída Edge odpovídá rozšířené přechodové funkci mezi stavy konečného automatu, resp. orientované hraně mezi stavy při jeho vizualizaci. Obsahuje soukromé členské proměnné startNodeId (identifikátor počátečního stavu hrany) a endNodeId (identifikátor koncového stavu hrany) a jim příslušné veřejné vlastnosti. Ohodnocení hrany je uloženo v členské proměnné values, která je řetězcem hranou akceptovaných slov oddělených mezerou. Přidávat a odebírat slova je možné pomocí veřejných metod addVal a removeVal. V implementaci těchto metod je použita metoda Parse, vracející pole hranou akceptovaných slov. I třída Edge překrývá metodu ToString. Třída Edge dále obsahuje vlastnost Type, vracející typ hrany v závislosti na tom, zda se jedná o epsilon hranu, tedy hranu přijímající prázdné slovo Epsilon. Toto má dále smysl při vizualizaci grafu. Možné hodnoty vlastnosti Type definuje výčtový typ TypeOfEdge.

public enum TypeOfEdge { Nothing = 0, Normal = 1, Epsilon = 2 } Výčtový typ TypeOfEdge

Konečně třída FiniteAutomaton reprezentuje celý konečný automat. Obsahuje soukromé členské proměnné nodes (slovník identifikátorů a jim náležejících stavů), edges (seznam hran), startNode (počáteční stav), endNodes (seznam koncových stavů) a activeNodes (seznam aktivních uzlů v době validace nějakého slova). Třída je navržena tak, aby u každého stavu udržovala unikátní celo- číselný identifikátor, jehož výběr zajišťuje soukromá metoda FirstFreeId. Použití identifikátorů zjednodušuje manipulaci s konečným automatem nejen na interní úrovni, ale i na vnější prostřednictvím veřejných metod addNode, RemoveNode, addEndNode, removeEndNode, addEdge, removeEdge, FindEdge (nalezení hrany na základě identifikátoru jejího počátečního a koncového stavu). Třída FiniteAutomaton překrývá metodu ToString, ve které využívá stejných metod držených stavů a hran mezi nimi.

5.3. Implementace validace slov nad konečným automatem

28 Třída FiniteAutomaton obsahuje dále soukromou členskou proměnnou activeNodes generického typu List, ve které je průběžně aktualizován seznam aktivních stavů při validaci slova nad konečným automatem.

public struct ActiveNode { public int id; //identifikátor stavu public string word; //zbývající část validovaného slova

public ActiveNode(int id, string word) //konstruktor { this.id = id; this.word = word; } } Text 1: Implementace struktury ActiveNode

Validace slova nad konečným automatem je implementována veřejnou metodou validateWord, vra- cející pravdivostní hodnotu v závislosti na tom, zda slovo konečný automat rozpoznává nebo ne. Jádro mechanismu validace slova je však umístěno ve veřejné metodě validatingNext, reprezentující provedení jednoho kroku v algoritmu validace a odpovídající úpravě seznamu aktivních stavů activeNodes. Metoda validateWord je pak pouhým pouhým opakováním metody validatingNext, dokud není slovo rozpoznáno (úspěch) nebo není seznam activeNodes prázdný (neúspěch). Toto rozdělení algoritmu do dvou samostatných metod je velmi důležité, neboť umožňuje následnou bezproblémovou vizualizaci jednotlivých kroků algoritmu stejně jako snadné otestování balíku dat bez vizualizace.

Pokud není seznam activeNodes prázdný vyber první aktivní stav T ze seznamu activeNodes; activeEdges = všechny hrany vycházející ze stavu T; s = T.word; odeber stav T ze seznamu activeNodes; opakuj pro každou hranu e v activeEdges opakuj pro každé slovo w na hraně e pokud (s == w) a zároveň (koncový stav e je také koncovým stavem FA) algoritmus končí hodnotou TRUE; pokud (w je prefixem s) přidej do seznamu activeNodes nový stav algoritmus končí hodnotou FALSE; Pseudokód metody validatingNext

29 Výsledky validace mohou být zobrazeny na samostatném dialogovém formuláři ValidationResultsDlg, na kterém se nachází jediná komponenta typu ListView.

5.4. Uživatelské rozhraní aplikace

Největším problémem návrhu uživatelského rozhraní bylo intuitivním způsobem uživateli zpřístupnit veškeré potřebné funkce pro editaci konečného automatu na omezeném prostoru displeje mobilního zařízení. Po zvážení všech alternativ jsem se rozhodl obecné funkce umístit do hlavní nabídky, zatímco funkce přímo související s manipulací konkrétními prvky konečného automatu do kontextové nabídky. Kontextová nabídka dynamicky přizpůsobuje svůj obsah dle pozice, na které došlo k jejímu vyvolání. Tato dynamická adaptace je realizována prostým přiřazením již existují- cích objektů typu MenuItem, které jsou všechny vytvořeny v době volání konstruktoru editačního

Obrázek 5.1 - Ukázka uživatelského rozhraní aplikace formuláře FiniteAutomatonEditorForm. Vytvářet instance objektů až v krajním případě nutnosti, tj.

30 v době, kdy dojde k jejich prvnímu použití, jsem nepovažoval za nutné. Je totiž prakticky jisté, že uživatel využije během práce s konečným automatem každý z možných scénářů kontextové na- bídky (vytvoření nové stavu, editace stavu, editace hrany).

Možné scénáře, které mohou nastat při dotyku stylusu s tělem editačního formuláře10:

●double-tap •vytvoření nového stavu, pokud A=B a na pozici B je volné místo, tj. není zde umístěn ještě žádný stav

●tap-and-move •přesun stavu na pozici A na pozici B, pokud je na pozici B volné místo •připojení hrany na pozici A ke stavu na pozici B, pokud na pozici B nějaký stav existuje

●tap-and-hold •vyvolání kontextové nabídky pro editaci stavu, pokud na pozici B nějaký stav existuje. Tato kontextová nabídka obsahuje možnost smazání stavu, jeho přejmenování a definování, zda se jedná o počáteční nebo konečný stav konečného automatu. •vyvolání kontextové nabídky pro editaci hrany, pokud na pozici B nějaká hrana existuje. Tato kontextová nabídka obsahuje možnost smazání hrany, editaci jejího ohodnocení •vyvolání kontextové nabídky pro vytvoření nového stavu, pokud na pozici B neexistuje žádný stav ani hrana

Poznámky: Smazání stavu automaticky smaže i k němu přiléhající hrany.

Prázdná hodnota v ohodnocení hrany je v grafickém rozhraní dle zvyklosti reprezentována sku- tečně jako znak ε. V případě editace je ovšem pro uživatele problematické zadávat pomocí panelu SIP znaky řecké abecedy. Proto je tato hodnota interně ukládána jako klíčové slovo \eps.

Vykreslování konečného automatu je realizováno pomocí prostředků technologie GDI+. I přes omezení funkcionality GDI+ v prostředí .NET Compact Framework jsem považoval tento způsob za dostatečný. Vykreslovat pokročilou grafiku není v aplikaci potřebné. Počáteční stav konečného automatu je defaultně zvýrazněn červenooranžovou barvou (Color.OrangeRed), konečné stavy pak barvou zelenožlutou (Color.GreenYellow). Aktivní stavy během vizualizace validace slova jsou zvýrazněny žlutou barvou, ale tak, aby nedocházelo k překrytí informací o počátečních a kon- cových stavech. Problémové byla identifikace hrany podle libovolného bodu na displeji. Po připo- čítání určité tolerance během označení uživatelem, která je daná tloušťkou špičky stylusu, se tento úkol ukázal být pro mobilní platformu poměrně výpočetně náročným. Rozhodl jsem se proto definovat aktivní oblasti o rozměrech 6x6 pixelu ve ¾ délky každé hrany, které uživatel může použít k manipulaci s hranou. Tyto oblasti jsou vykreslovány jako světle růžové kruhy.

Vykreslení konečného automatu je provedeno pomocí členské soukromé metody DrawGraph ve tří-

10 Pro jednoduchost uvažujme souřadnice v době dotyku stylusu a displeje jako A, zatímco souřadnice v době, kdy stylus displej opouští, jako B.

31 dě FiniteAutomatonEditor. Tato metoda je volána v obslužné metodě pro událost OnPaint. Pokud není třeba překreslovat celý graf, jsou na některých místech vykresleny stavy nebo hrany přímo po- mocí soukromých metod DrawNode nebo DrawEdge.

5.5. Vstupní a výstupní operace

Graf může být uložen ve formě XML dokumentu nebo obrázku ve formátu GIF. Sada testovacích dat je ukládána ve formě obyčejného textového dokumentu, kde každý řádek obsahuje jedno slovo k validaci. Následuje ukázka reprezentace konečného automatu v XML dokumentu.

32 40 58 156 79 84 201 205 145 0 1 3 0 1 1 2

Ukázka reprezentace konečného automatu v dokumentu XML

33 6 Závěr

Dle předpokladu je mLearning fenoménem, který teprve čeká na masové rozšíření a podporu. Přestože kvalitní aplikace pro mobilní zařízení v současnosti dostupná jsou, s výjimkou systému LMS a portů open-source matematických aplikací se jedná o komerční řešení. Největším problé- mem je tedy nedostatek volně dostupných a otevřených aplikací. Dalším problémem je opomíjení mobilních zařízení tvůrci webových stránek, kteří stále považují optimalizaci webových stránek pro mobilní prohlížeče za okrajovou, neekonomickou činnost. Z analýzy vývojových nástrojů a programovacích jazyků na druhou stranu vyplývá, že existují velmi silné SW platformy, na kterých lze aplikace rychle a efektivně vytvářet. Spolu s dostupností výkonných mobilních zařízení pro širokou uživatelskou základnu je tedy možné se oprávněně do- mnívat, že v budoucích letech si získá potenciál mLearningu pozornosti ze strany vývojářů mnohem více.

34 Příloha

Přiložený CD disk obsahuje zdrojový kód aplikace pro vizualizaci konečného automatu.

35 Literatura

[1] Analysis: What is a smart phone? Dostupné na URL http://networks.silicon.com/mobile/0,39024665,39156391,00.htm [2] Adams, Brian. What is managed code? Dostupné na URL [3] Microsoft. Visual Basic .NET Language Specification Dostupné na URL http://msdn.microsoft.com/en-us/library/aa712050(VS.71).aspx [4] ECMA. C++/CLI Language Specification Dostupné na URL http://www.ecma-international.org/publications/files/ECMA- ST/ECMA-372.pdf [5] ECMA. C# Language Specification Dostupné na URL http://www.ecma-international.org/publications/files/ecma- st/ECMA-334.pdf [6] Microsoft. Visual J# Reference Dostupné na URL http://msdn.microsoft.com/en-us/library/hyx4hd7e(VS.80).aspx [7] Microsoft. Getting Started With JScript Dostupné na URL http://msdn.microsoft.com/en-us/library/3bf5fs13.aspx [8] Mono Documentation Library Dostupné na URL http://www.go-mono.com/docs/ [9] Miovská, Michaela. Mobilní e-learningové nástroje. Brno, 2009. [10] Microsoft. Microsoft Developer Network. Dostupné na http://www.msdn.com [11] Microsoft. Windows Mobile 5.0 Pocket PC SDK Documentation [12] Robinson, Simon. C# Programujeme profesionálně. Vydáno nakl. Cpress, 2003. [13] Lacko, Luboslav. Programujeme mobilní aplikace ve Visual Studiu .NET. Vydáno nakl. Cpress, 2004.