Nástroj pro snadný návrh uºivatelského rozhraní. Petr Mach. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta

ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Bakalá ská práce Nástroj pro snadný návrh uºivatelského rozhraní Petr Mach Vedoucí práce: Ing. Tomá² Novotný Studijní program: Softwarové technologie a management, Bakalá ský Obor: Web a multimedia 9. ledna 2012

iv

v Pod kování Rád bych pod koval rodi m, p ítelkyni a kamarád m za velkou podporu b hem psaní mé bakalá ské práce. Velké díky si zaslouºí také vedoucí práce Ing. Tomá² Novotný za jeho vynikající p ístup, ochotu a trp livost.

vi

vii Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Praze dne 6. 1. 2012.............................................................

viii

Abstract The aim of this bachelor project is to implement a tool for designing and prototyping of a user interface, that will also allow creating of new custon elements. Source les of this tool will be synchronized with a remote storage. Part of the focus of this thesis is creating a module for connecting and communication with the remote storage. Abstrakt Cílem této bakalá ské práce je vytvo it nástroj pro návrh a prototypování uºivatelského rozhraní, který bude zárove umoº ovat vytvá ení ²ablon vlastních ovládacích prvk. Sou asn bude moºné zdrojové soubory nástroje na ítat nebo ukládat ve vzdáleném úloºi²ti podle standardu IMAP. Sou ástí práce je vytvo ení modulu pro p ipojení ke vzdálenému úloºi²ti a komunikaci s ním. ix

x

Obsah 1 Úvod 1 2 Popis problému a specikace cíle 3 2.1 Specikace cíle................................... 3 2.2 Poºadavky...................................... 3 2.2.1 Funk ní poºadavky............................. 3 2.2.2 Nefunk ní poºadavky............................ 4 3 Sou asný stav a návrh e²ení 5 3.1 Volba implementa ního prost edí......................... 5 3.2 Pencil........................................ 5 3.2.1 Funkce................................... 6 3.2.1.1 Návrh............................... 6 3.2.1.2 Export projektu......................... 7 3.2.1.3 Privátní kolekce......................... 7 3.3 IMAP........................................ 7 3.3.1 P íkazy................................... 7 3.3.2 Odpov di serveru.............................. 8 3.3.3 Stavy imapu................................ 8 3.3.4 Flagy.................................... 8 3.4 Návrh e²ení..................................... 8 3.4.1 Komponenty aplikace............................ 9 3.4.1.1 Pencil............................... 9 3.4.1.2 Vrstva propojení s IMAP kontrolerem............. 9 3.4.1.3 IMAP kontroler......................... 9 3.4.1.4 Vrstva pro komunikaci kontroleru se serverem......... 10 3.4.2 Princip................................... 10 4 libimap 11 4.1 Struktura...................................... 11 4.1.1 Core..................................... 11 4.1.2 Controller.................................. 11 4.1.3 Widget................................... 12 4.2 Princip........................................ 12 4.2.1 P ipojení a komunikace.......................... 13 xi

xii OBSAH 4.2.2 Systém volání................................ 13 4.2.2.1 Princip callbacku......................... 15 4.2.2.2 Pouºití callback v knihovn libimap.............. 15 4.2.3 P íkazy klienta............................... 16 4.2.4 P íkazy kontroleru............................. 17 4.2.4.1 Z et zení p íkaz......................... 17 4.2.4.2 Fronta............................... 18 4.3 Implementované p íkazy.............................. 18 4.3.1 APPEND.................................. 18 4.3.2 CREATE.................................. 19 4.3.3 FETCH................................... 19 4.3.4 LIST..................................... 20 4.3.5 LOGIN................................... 20 4.3.6 LOGOUT.................................. 20 4.3.7 SELECT.................................. 20 4.3.8 STORE................................... 21 4.4 Parsování...................................... 21 4.5 Ukázková aplikace pro libimap........................... 22 4.6 libimap-console................................... 23 5 Pencil 25 5.1 Úpravy editoru................................... 25 5.1.1 Úprava ²ablony pro HTML export.................... 25 5.1.2 Prioritní snapping............................. 26 5.1.3 Kopírování prvk Ctrl + taºením..................... 26 5.2 Napojení na libimap................................ 27 5.2.1 Ukládání nastavení............................. 27 5.3 Scéná e....................................... 28 5.3.1 Uloºení souboru na server......................... 28 5.3.2 Staºení souboru ze serveru......................... 29 5.4 Synchronizace zdrojových soubor........................ 29 5.4.1 Princip a pouºití.............................. 29 5.4.2 Implementace................................ 29 5.5 Import a export privátních kolekcí........................ 29 5.5.1 Princip a pouºití.............................. 29 5.5.2 Implementace................................ 30 6 Testování 31 6.1 Pencil........................................ 31 6.2 libimap....................................... 31 6.2.1 Serverové implementace IMAPu...................... 32 6.3 Testovací ú ty.................................... 33 6.4 Testovací aplikace.................................. 33

OBSAH xiii 7 Dal²í vývoj 35 7.1 Pencil........................................ 35 7.1.1 P ímý export UI do HTML........................ 35 7.1.2 Vylep²ení vkládání element z privátních kolekcí............ 35 7.1.3 Layoutovací principy............................ 36 7.1.3.1 Stacking.............................. 36 7.1.3.2 Wrapping............................. 36 7.1.3.3 Anchoring............................. 37 7.1.3.4 Docking.............................. 37 7.2 libimap....................................... 37 7.2.1 Kompletní implementace standardu.................... 37 7.2.2 P íkaz IDLE................................ 38 7.2.3 Platformní nezávislost........................... 38 7.3 MozTextSocketConnection............................. 38 8 Záv r 39 A Seznam pouºitých zkratek 43 B P íklady komunikace s protokolem IMAP 45 B.1 P íkaz APPEND.................................. 45 B.2 P íkaz LIST..................................... 45 B.3 Kompletní komunikace............................... 46 C Instala ní a uºivatelská p íru ka 49 C.1 Spu²t ní aplikace.................................. 49 C.1.1 Windows.................................. 49 C.1.1.1 Pencil............................... 49 C.1.1.2 libimap-test............................ 49 C.1.1.3 libimap-console.......................... 49 C.1.2 Linux.................................... 49 C.1.2.1 Pencil............................... 50 C.1.2.2 libimap-test............................ 50 C.1.2.3 libimap-console.......................... 50 C.2 Nastavení serveru IMAP.............................. 50 C.3 Práce s aplikací................................... 50 D Obsah p iloºeného CD 51

xiv OBSAH

Seznam obrázk 3.1 Snímek hlavního okna programu Pencil...................... 6 3.2 Diagram propojení komponent aplikace...................... 9 4.1 Snímek widgetu - seznam sloºek.......................... 13 4.2 UML class diagram knihovny libimap....................... 14 4.3 Snímek okna ukázkové aplikace.......................... 22 4.4 Snímek okna aplikace libimap-console....................... 24 6.1 Snímek okna testovací aplikace.......................... 34 xv

xvi SEZNAM OBRÁZK

Seznam tabulek 6.1 P ehled testovaných server............................ 33 xvii

xviii SEZNAM TABULEK

Kapitola 1 Úvod V dne²ní dob grackých aplikací se p i návrhu softwaru klade stále v t²í d raz na grackou atraktivitu rozhraní, se kterým bude uºivatel pracovat. Kritickou sou ástí vývoje se tak stává návrh uºivatelského rozhraní, tedy dokument znázor ující rozloºení v²ech prvk v rámci uºivatelského rozhraní programu. Ten pak slouºí programátor m jako p edloha pro samotnou implementaci. Návrh uºivatelského rozhraní má n kolik cykl [3]. B hem nich se tento návrh vylep²uje a jeho nální podoba by m la tém odpovídat vzhledu výsledného produktu. Na samotném za átku vývoje m ºe takovýto návrh tvo it pouze n kolik tverc nakreslených tuºkou na papí e, kde kaºdý udává polohu n kterého funk ního celku, nap. menu u webové stránky. Takto zjednodu²ené uºivatelské rozhraní je jednoduché vytvo it p ímo b hem konzultace s klientem, získat od n j okamºit zp tnou vazbu a p ípadn návrh pozm nit. Tato innost se také nazývá prototypování. B hem vývoje jsou poté jednotlivé funk ní celky podrobn ji rozkresleny a p ípadn op t dolad ny podle p ání klienta. Po dostate ném mnoºství t chto iterací je pak nální návrh p edán grakovi k vytvo ení kone né podoby uºivatelského rozhraní systému. D leºité je, ºe programátor m ºe po kaºdé z iterací obdrºet poslední verzi návrhu a okamºit ji zapracovat, aniº by musel ekat na nální podobu. To samoz ejm ²et í as pot ebný pro vývoj. Existuje ada zp sob návrhu uºivatelského rozhraní[13]. Jednou z nejoblíben j²ích metod je stále kreslení rukou na papír. Jeho hlavní p edností je rychlost a intuitivita takového návrhu, coº je ale výhodné pouze na samém za átku vývoje, kdy je²t není výsledek p íli² komplexní. Nevýhodou kreslení rukou je pom rn komplikovaný postup, pokud je nutné m nit pozici nakreslených prvk. To se v n kterých p ípadech e²í vyst ihnutím papírových "komponent "a jejich následnou manipulací, ale ast ji se v²ak pouºívají softwarové nástroje. Programy pro návrh uºivatelského rozhraní jsou dnes, v dob miniaturních notebook, uº tém stejn rychle pouºitelné jako zmín ná tuºka a papír. Jejich hlavní výhodou je pak jednodu²²í práce s výsledným návrhem, jeho mnohem lep²í vzhled a snaº²í archivace i distribuce. B ºn dostupné nástroje v²ak pracují se zdrojovými soubory pouze lokáln. Pokud je tedy pot eba zdrojové soubory distribuovat, moºnosti jsou nap. odeslat soubor pomocí elektronické po²ty nebo jej nahrát do n jakého typu úloºi²t, a se jiº jedná o p enosný disk nebo FTP server. Jedním z nástroj pro návrh uºivatelských rozhraní je i program Pencil [2]. Zadání této bakalá ské práce umoº uje pokra ovat ve vývoji jiº existujícího e²ení, a po zváºení poºa- 1

2 KAPITOLA 1. ÚVOD davk bylo rozhodnuto vyuºít práv program Pencil. Toto rozhodnutí bylo u in no p edev²ím díky vynikajícím p edchozím zku²enostem s Pencilem z mé strany, i ze strany vedoucího této práce. Druhou ástí zadání je vytvo it synchroniza ní modul pro Pencil, který odstraní vý²e popsané potíºe s distribucí zdrojových soubor. Z tohoto d vodu byla vytvo ena komponenta pro p ipojení k serveru pomocí protokolu IMAP[1], pracovn pojmenovaná libimap, která poslouºí k dal²ímu vývoji komponent projektu ExtBrain Communicator[10]. V následující kapitole 2 je popsán problém, který se tato práce snaºí e²it, dále jsou vymezeny a od vodn ny cíle této práce. Ty jsou poté shrnuty do formálních poºadavk a je nastín na struktura práce. V kapitole 3 je blíºe popsána vyuºívaná aplikace Pencil na za átku práce a poºadované zm ny. Tato kapitola zárove popisuje principy a specika protokolu IMAP pot ebná pro implementaci. Kapitoly 4 a 5 se v nují technické realizaci této práce, tedy vytvo ené knihovn libimap, resp. modikacím programu Pencil. Implementa ní sekce této práce byla pro v t²í p ehlednost rozd lena do dvou samostatných celk. D vodem byl jednak rozsah pot ebný k popisu obou ástí, zárove je v²ak takto patrné, ºe knihovna libimap je úpln odd lena od aplikace Pencil. V kapitole. 6 jsou podrobn rozebrány kroky provedené ohledn testování a lad ní aplikace. Krom standartního uºivatelského testování práce je zde popsána také testovací komponenta, vytvo ená b hem implementace knihovny libimap, a která p ímo její sou ástí. Kapitola 7 nasti uje n které moºnosti a doporu ení, jak na tuto práci navázat v dal²ím vývoji, a to jak co se týká programu Pencil, tak i knihovny libimap.

Kapitola 2 Popis problému a specikace cíle Hlavním výstupem práce je program pro snadný návrh uºivatelského rozhraní, který by krom b ºných funkcí pro práci s grakou m l umoº ovat i jednoduchou denici vlastních prvk. D raz je kladen hlavn na rychlost práce, exibilitu ovládání a podp rných funkcích pro co moºná nejv t²í urychlení procesu návrhu. Jak bylo zmín no v 1. kapitole, b ºné nástroje pro návrh uºivatelských rozhraní pracují pouze s lokálními soubory a distribuce musí probíhat nap. zasláním souboru elektronickou po²tou atp. Proces návrhu uºivatelského rozhraní by bylo moºné je²t dále urychlit, pokud by mohla být distribuce (a archivace) rychlá a intuitivní p ímo z nástroje. 2.1 Specikace cíle Jelikoº zadání umoº uje pouºít existující e²ení, nebylo nutné vytvá et jej od za átku a sta ilo zvolit vhodný nástroj k roz²í ení. Nástroj musí být podporován technologiemi pouºitými v projektu ExtBrain Communicator. To je program zam ený na komunikaci a spolupráci uºivatel a je sou ástí programu Mozilla Thunderbird[8]. Z toho vyplývá pouºití technologií Mozilla Application Frameworku. 2.2 Poºadavky Z p edchozích ástí této kapitoly byly formulovány následující poºadavky na aplikaci. 2.2.1 Funk ní poºadavky 1. Nástroj umoºní návrh uºivatelského rozhraní. 2. Nástroj umoºní denici vlastních ovládacích prvk. 3. Bude moºné na ítat a ukládat zdrojové soubory do vzdáleného úloºi²t p es protokol IMAP. 4. Bude moºné na ítat a ukládat vlastní denice ovládacích prvk do vzdáleného úloºi²t p es protokol IMAP. 3

4 KAPITOLA 2. POPIS PROBLÉMU A SPECIFIKACE CÍLE 5. Nástroj umoºní základní formu synchronizace zdrojových soubor se vzdáleným úloºi²t m. 2.2.2 Nefunk ní poºadavky 1. Nástroj bude postaven na technologii podporované v projektu ExtBrain Communicator. 2. Nástroj i synchroniza ní komponenta budou napsány s d razem na modularitu a snadný dal²í vývoj. 3. Práce s nástrojem nevyºaduje permanentní p ipojení k Internetu.

Kapitola 3 Sou asný stav a návrh e²ení V této kapitole je nejprve popsán proces volby pouºitých technologií, dále jsou rozebrány specika jednotlivých vyvíjených komponent, na samém konci kapitoly je pak navrºen postup p í implementaci. 3.1 Volba implementa ního prost edí Jako implementa ní prost edí pro tuto práci byl ur en Mozilla Application Framework (MAF), protoºe nástroj má být v budoucnu za azen jako sou ást projektu ExtBrain Communicator. Z tohoto d vodu musí být implementován pomocí stejných technologií jako jeho ostatní sou ásti, tedy být napsán v jazyce JavaScript a vyuºívat technologie Mozilla XUL. Tyto podmínky spl uje jediný existující program, a sice práv Pencil. Co se týká synchroniza ního modulu, samoz ejm musí být postaven na stejných technologiích jako nástroj pro který je ur en. Jako cílový standard vzdáleného úloºi²t pouºitého pro práci s programem byl zvolen protokol internetové po²ty IMAP. D vodem je, ºe projekt ExtBrain jiº v sou asnosti protokol IMAP pouºívá pro ostatní komponenty ExtBrain Communicatoru a nebude tedy pot eba z izovat ºádné speciální úloºi²t. 3.2 Pencil Pencil je nástroj pro tvorbu diagram a GUI prototyp z vývojá ské rmy Evolus. Pencil je vyvíjen pod licencí GNU General Public License, má tedy otev ené zdrojové kódy. Program je postaven na Mozilla Application Frameworku a je ²í en zdarma, primárn jako add-on internetového prohlíºe e Mozilla Firefox, ale k dispozici je i samostatná (standalone) verze. Významnou výhodou Pencilu mezi konkuren ními programy je platformová nezávislost, jelikoº MAF podporuje t i nejpouºívan j²í opera ní systémy (Windows, Linux a Mac OS) naprosto bezproblémov. S tímto programem mám zárove vynikající zku²enosti a subjektivn ho adím mezi nejlep²í na trhu. Na obrázku 3.1 je screenshot hlavního okna programu. 5

6 KAPITOLA 3. SOUƒASNÝ STAV A NÁVRH E ENÍ Obrázek 3.1: Snímek hlavního okna programu Pencil 3.2.1 Funkce V následující ásti jsou shrnuty nejd leºit j²í funkce programu Pencil, které návrh uºivatelského rozhraní urychlují a usnad ují. 3.2.1.1 Návrh Program je primárn ur en pro návrh uºivatelských rozhraní (GUI) a vytvá ení jejich prototyp. K tomu jsou k dispozici p eddenované základní elementy, tzv. stencily. Ty jsou uspo ádány do tématických kolekcí. Kolekce je dále moºné vytvá et nebo importovat a b hem práce tak jdou vyuºívat nap. geometrické obrazce, prvky webových stránek i standartní prvky známé z rozhraní GTK nebo Windows. Samostatnou zmínku si zaslouºí kolekce Sketchy GUI, která vzhledem prvk p ipomíná návrh rukou, a tak se pro prototypování mimo ádn hodí. Editor umoº uje v²echny základní operace pro práci s vektorovou grakou, jako je zarovnání, z-ordering (moºnost umístit prvek nad, resp. pod jiný prvek), zm na velikosti nebo rotace. Samoz ejmostí je vytvá ení grackých primitiv (kruh, obdélník atp.), nastavení barev, p echod nebo pouºití obrázk. V rámci jednoho projektu lze pracovat na více stránkách, mezi nimiº lze nadenovat prokliky a simulovat tak navigaci mezi jednotlivými obrazovkami p i pr chodu aplikací. Je

3.3. IMAP 7 moºné t mto stránkám nastavit i masky pr hlednosti a d dit je mezi sebou, coº návrh zna n urychluje. 3.2.1.2 Export projektu Pencil umoº uje export projekt jako obrázk, PDF dokument nebo HTML stránek. Zatímco první dva zmi ovaní slouºí hlavn pro ú ely dokumentace, HTML export ve spojení s proklikem mezi okny d lá z Pencilu výkonný nástroj pro prezentaci prototyp GUI i se scéná i pouºití. Takto vygenerovaný prototyp lze tém p ímo pouºít i k uºivatelskému testování návrhu GUI. 3.2.1.3 Privátní kolekce Silnou funkcí Pencilu je i moºnost jednodu²e vytvá et tzv. privátní kolekce. Jakoukoliv vytvo enou skupinu prvk lze uloºit jako prvek privátní kolekce a pozd ji kdykoliv pouºít, bez nutnosti je explicitn kopírovat. Navíc jsou takto vytvo ené prvky snadno dostupné z palety. 3.3 IMAP Internet Message Access Protocol (IMAP) je jedním ze dvou nejznám j²ích standard pro výb r elektronické po²ty. Druhým takovým standardem je Post Office Protocol (POP). V t²ina klient pro elektronickou po²tu v dne²ní dob podporuje oba tyto protokoly. Podpora IMAPu na stran serveru je samoz ejmostí u v t²iny populárních poskytovatel schránek elektronické po²ty. V sou asnosti se pouºívá IMAP verze 4, revize.1, který je popsán v RFC3501[1]. Následuje stru ný p ehled princip a specik protokolu IMAP, které bylo pot eba p i implementaci zohlednit. Více informací a plná specikace protokolu, viz. RFC3501[1]. 3.3.1 P íkazy Komunikace se serverem po protokolu IMAP je ist textová a probíhá formou zaslání zprávy s klientským p íkazem a obdrºení zprávy se serverovou odpov dí. Kaºdý p íkaz musí být p ed odesláním na server ukon en správným zalomení na konci ádku, tzv. CLRF, tedy v JavaScriptu textovým et zcem \r\n. Na za átku v²ech p íkaz zaslaných na server se musí nacházet tzv. tag, tedy identikátor p íkazu. Krom toho, ºe nesmí obsahovat mezery, záleºí tvar takového tagu na klientském za ízení a slouºí pouze ke spárování poºadavku klienta s odpov dí serveru. Nej ast ji se tagy uvádí jako alfanumerická sekvence nebo pouze v íselné form. Pokud je tedy uveden nap. p íkaz ve tvaru "P ÍKAZ1 parametr1 parametr2" a je odeslaný jako tvrtý v po adí, znamená to, ºe na server je odesláno 03 P ÍKAZ1 parametr1 parametr2\r\n.

8 KAPITOLA 3. SOUƒASNÝ STAV A NÁVRH E ENÍ 3.3.2 Odpov di serveru Server m ºe poslat jednu ze t í druh odpov dí - status response (informace o stavu serveru nebo provedení p íkazu), server data (data vyºádaná od serveru) a command continuation request (informace o p ijetí p edchozí ásti zprávy a výzva k pokra ování posílání dat). Je p esn p edepsáno, jaký druh odpov di a se pouºije po jakém volání. Prvn jmenovaný status response klient obdrºí vºdy. Server m ºe ve speciálních p ípadech taktéº poslat zprávu nevyºádanou. 3.3.3 Stavy imapu Po navázání spojení se klient nachází v jednom z následujících ty stav : 1. Not Authenticated State 2. Authenticated State 3. Selected State 4. Logout State Pro kaºdý p íkaz jsou denovány stavy, ve kterém jej lze pouºít. P íkaz m ºe být, a v t²inou je, povolen ve více stavech, nap. p íkaz CAPABILITY lze zavolat v prvních t ech, p íkaz APPEND lze pouºít pouze v druhém a t etím. 3.3.4 Flagy Protokol IMAP podporuje p i azení tzv. ag, neboli jakýchsi atribut, ke kaºdé zpráv. Pouºití nej ast ji spo ívá v ozna ení p e tené, smazané nebo d leºité zprávy. N které servery zárove pouºívají tento mechanismus k ozna ení zprávy s p ílohou pro rychlej²í manipulaci. Výhoda spo ívá v moºnosti tyto agy nastavit a nem nit p itom samotné t lo zprávy. N které servery umoº ují také vytvo ení a uloºení vlastních ag. To je výhodné zejména interní pot eby klienta. 3.4 Návrh e²ení Pencil ve své standartní verzi ºádnou formu synchronizace se vzdáleným úloºi²t m nepodporuje, je proto nutné vytvo it modul, který ji umoºní. Tento musí vyuºívat pro p ipojení komponentu klienta protokolu IMAP.

3.4. NÁVRH E ENÍ 9 3.4.1 Komponenty aplikace V následující ásti bude rozebrán návrh rozd lení b hu programu do komponent (vrstev) a jejich funkce. Tento model byl zvolen kv li odd lení funk ních celk od sebe a p edev²ím od programu Pencil. 1. Pencil 2. Vrstva propojení s IMAP kontrolerem 3. IMAP kontroler 4. Vrstva pro komunikaci se serverem Tyto komponenty jsou vzájemn propojeny, komunikují spolu vºdy pouze sousední vrstvy. komunikaci Obrázek 3.2: Diagram propojení komponent aplikace 3.4.1.1 Pencil Pencil je roz²i ovaná aplikace, do které musí být na vhodná místa dopln ny volání propojovací vrstvy. Prakticky se jedná o umíst ní ovládácích prvk na vhodné místo do grackého rozhraní aplikace a jejich p i azení metodám propojovací vrstvy. 3.4.1.2 Vrstva propojení s IMAP kontrolerem Tato vrstva obsahuje logiku jak Pencilu, tak IMAP kontroleru. Metoda volaná z p edchozí vrstvy zde v závislosti na úkonu obstará data od aplikace, spustí kontroler a po provedení akce zpracuje výsledky. Poté se ukon í. 3.4.1.3 IMAP kontroler Klientský kontroler pro IMAP zprost edkovává p ijetí p íkaz od vy²²í vrstvy, jejich vykonání prost ednictvím spojení se serverem, které je popsáno níºe, a navrácení výsledk. V této vrstv jsou denovány jednotlivé díl í úkoly pro kaºdou z podporovaných operací a popsány jako sekvence p íkaz dle protokolu IMAP. Zárove je nutné obstarávat parsování výsledk, aby bylo moºné zjistit sou asný stav a ur it dal²í akci pot ebnou k vykonání operace.

10 KAPITOLA 3. SOUƒASNÝ STAV A NÁVRH E ENÍ 3.4.1.4 Vrstva pro komunikaci kontroleru se serverem Nejniº²í vrstva aplikace obsahují zprost edkovává samotnou sí ovou komunikaci se serverem. Jejím u elem je obalovat serverové p íkazy protokolu a v ur itém rozsahu také zpracovávat p ijaté výsledky. Tato vrstva musí být co nejobecn j²í a naprosto nezávislá na programu Pencil, aby mohla být pouºita i pro jiné aplikace. 3.4.2 Princip Cílem je vyuºít co nejvíce z nativní funkcionality Pencilu, aby nedocházelo ke zbyte né duplikaci kódu, a jelikoº Pencil jiº obsahuje vyzkou²ené mechanismy pro ukládání a na ítaní soubor lokáln, bylo by dobré je vyuºít, namísto implementace vlastních. Synchronizace soubor na server byla proto vy e²ena následující sekvencí úkon : 1. P evedení zdrojového souboru sou asného projektu na binární data 2. Upload souboru jako p ílohy nové zprávy 3. Archivování p edchozí verze souboru Podobný princip existuje i pro stahování soubor ze serveru. Pouze ukládání souboru na disk musí být implementováno samostatn, protoºe Pencil binární data nepodporuje. 1. Výb r souboru ze soubor uloºených na serveru 2. Staºení vybraného souboru 3. Uloºení souboru na lokální disk 4. Otev ení souboru z disku nativní metodou Pencilu Tyto dva mechanismy fungují podobn jak pro projekty návrhu uºivatelského rozhraní, tak i pro soubory s privátními kolekcemi.

Kapitola 4 libimap Cílem práce práce bylo vytvo it implementaci klientské ásti protokolu IMAP v jazyce JavaScript, vyuºívající komponent Mozilla Application Frameworku a tím pádem pouºitelný v programu Pencil a komponentách projektu ExtBrain Communicator. P i vývoji byl proto kladen velký d raz na modularitu kódu a tento klient byl implementován jako samostatná knihovna, nikoliv jako sou ást programu Pencil. Knihovna byla pracovn pojmenována libimap. 4.1 Struktura V této sekci je popsána struktura soubor tvo ící knihovnu libimap a kontroler p edstavující jednu mezivrstvu mezi knihovnou a aplika ní logikou programu Pencil, viz. 3.4.1. 4.1.1 Core Jádro knihovny libimap tvo í ty i JavaScriptové t ídy v adresá i Core. Core/ IMAPClient.js IMAPResponse.js MozExtbrainToolkit.js Util.js T ída IMAPClient implementuje celou funkcionalitu klienta pro protokol IMAP, t ída pro p ipojení a komunikaci po síti je zprost edkována modulem MozExtbrainToolkit. T ída IMAPResponse vytvá í sktrukturu pro p ijatou odpov a stará se o základní parsování, viz 4.4. Soubor Util pak obsahuje pomocné funkce pro knihovnu. 4.1.2 Controller V adresá i Controller se nacházejí soubory p ímo vyuºívající knihovnu libimap. Jedná se o mezi lánek mezi nativní funkcionalitou Pencilu a jádrem knihovny. Krom Javascriptového kódu jiº tento adresá obsahuje i soubory XUL. 11

12 KAPITOLA 4. LIBIMAP Controller/ ImapClientController.js ImapConfig.js ImapLoadFile.js ImapLoadFile.xul IMAPParser.js ImapSaveFile.js ImapSaveFile.xul 4.1.3 Widget B hem vytvá ení Controlleru a vzorové libimap aplikace (viz 4.5) bylo vytvo eno také n kolik miniaturních pomocných komponent, tzv. widget v jazyce XUL. Ty jsou k dispozici pro pouºití v kontroleru k vykonání a vykonávají akce typu zadání p ihla²ovacích údaj k ú tu nebo zobrazení seznamu zpráv. Tyto drobné komponenty jsou sou ástí knihovny libimap, jelikoº je pravd podobné, ºe ostatní aplikace vyuºívající knihovnu je mohou pot ebovat také. Adresá Widget obsahuje zdrojové soubory t chto komponent. Widget/ FolderListDialog.js FolderListDialog.xul FolderListWidget.js MessageListDialog.js MessageListDialog.xul MessageListWidget.js MessageViewDialog.js MessageViewDialog.xul MessageViewWidget.js ServerSpecsDialog.js ServerSpecsDialog.xul ServerSpecsWidget.js UserCredentialsDialog.js UserCredentialsDialog.xul UserCredentialsWidget.js P íklad widgetu, konkrétn okna se seznamem zpráv ve sloºce, je na obrázku 4.1. 4.2 Princip V této sekci jsou popsány principy b hu knihovny libimap rozd lené podle funk ních celk. Na obrázku 4.2 je struktura jádra knihovny a propojení jednotlivých t íd zachycena jako UML diagram.

4.2. PRINCIP 13 Obrázek 4.1: Snímek widgetu - seznam sloºek 4.2.1 P ipojení a komunikace O zaji²t ní p ipojení a zprost edkování komunikace se serverem v pr b hu práce s klientem se stará t ída vytvo ená návrhovým vzorem factory v modulu MozExtbrainToolkit. Tento modul musí implementovat rozhraní IExtbrainToolkit a zprost edkovává funkce, které klient pouºívá nad rámec standardního JavaScriptu. Práv kv li zachování modularity navíc také vytvá í t ídu pro komunikaci po síti. Vyuºití jiné t ídy je tedy moºné bez jakéhokoliv zásahu do klienta, sta í pouze v kontroleru aplikace pouºít jinou realizaci IExtbrainToolkit. Sí ová t ída musí spl ovat kritéria p edepsaná rozhraním IIMAPConnection, aby s ní klient dokázal pracovat. V p ípad této práce je tou t ídou MozTextSocketConnection. Ta pro sv j b h vyuºívá XPCOM[9] komponentu zabývající se komunikací po síti, uvád ná pod názvem Necko. Samotná komunikace se serverem probíhá pomocí sluºby nsisockettransportservice, která umoº uje vytvo it tzv. transport. Ten se p ipojí k serveru s nastaveným typem p ipojení a otev e vstupní a výstupní streamy mezi aplikací a serverem. Do výstupního streamu aplikace posílá p íkazy serveru a naslouchá na vstupním streamu, kam server zasílá odpov di. V prvních verzích této práce byla komunikace zprost edkována synchronn, tzn. klient odeslal na server p íkaz a teprve poté za al na vstupním streamu ekat na odpov. Tento p ístup se hned na za átku testování ukázal jako naivní a nedosta ující, viz 6.2. Proto musela být celá p ipojovací t ída p epsána a nyní pouºívá asynchronní spojení mezi klientskou a serverovou ástí. Toto asynchronní spojení vyuºívá komponenty nsiinputstreampump a její metody asyncread. P íchozí data jsou shromaº ována, dokud není odpov kompletní, teprve pak se pomocí callbacku p edá klientovi. 4.2.2 Systém volání Kv li vý²e zmín nému asynchronnímu p ipojení se nedá mezi jednotlivými t ídami (a asto ani v jejich rámci) komunikovat standardním zp sobem, kdy je kód p ehledn pod

14 KAPITOLA 4. LIBIMAP libimap-core <<Interface>> IExtBrainToolkit +createconnection(config : object) +atob() +btoa() +getuuid() MozExtBrainToolkit IMAPClient -tag : Number -state : IMAPState -responsehandlers : object -inittimer : Object +IMAPClient(connection : IIMAPConnection) +init(callback : function) +simplecommand(config : object) -gettag() -assertstate(allowedstates : Array) -closeconnection() -sendrequest(request : String) +login() +list() +select() +fetch() +append() +logout() +store() +create() +capability() +unselect() conn <<Interface>> IIMAPConnection +IIMAPConnection(config : object) +connect(handler : object) +sendrequest(request : String) +disconnect() MozTextSocketConnection +host : String +port : Number +type : String IMAPResponse +tag : Number +status : String +result : String +msg : String -parseresponse() +tostring() <<enumeration>> IMAPState +NOT_AUTHENTICATED +AUTHENTICATED +SELECTED +LOGOUT Obrázek 4.2: UML class diagram knihovny libimap

4.2. PRINCIP 15 sebou v blocích a p íkaz nebo volání se provede práv po skon ení volání p edchozího. Naproti tomu s asynchronními voláními se pr b h programu kontroluje pomocí volání speciálních funkcí, tzv. callback. Tento p ístup bohuºel v JavaScriptu pom rn zt ºuje orientaci v kódu, pro korektní b h knihovny je v²ak nezbytný. 4.2.2.1 Princip callbacku Tento systém je podobný jako nap. u technologie AJAX, která je v dne²ní dob asto pouºívaná p i vývoji webových aplikací. Princip je vysv tlen na následujícím útrºku kódu. var callback = function(data){ print('callback: ' + data); //dal²í akce b hu programu } var data = getasynchronousdata(callback); print('standardní return: ' + data); M jme metodu getasynchronousdata, která provádí n jakou asynchronní innost. Touto inností m ºe být nap. tení ze souboru, sí ová komunikace atp. Metoda je navrºena tak, ºe po skon ení akce zavolá metodu callback, která jí p i²la jako parametr a p edá jí získaná data. Výpis programu bude vypadat následovn : standardní return: undefined callback: získaná data To je zp sobeno práv asynchronním p ístupem metody getasynchronousdata. Ve chvíli, kdy má být ukon ena standardním zp sobem, nejsou je²t data k dispozici. Jakmile k dispozici budou, zavolá se v²ak metoda callback a celé workow se posune dál. 4.2.2.2 Pouºití callback v knihovn libimap Pro p edávání dat v rámci knihovny a kontroleru bylo nutné implementovat celkem t i úrovn callback. Na niº²í úrovni je to vrstva pro propagaci p ijaté serverové zprávy ze t ídy MozTextSocketConnection do t ídy IMAPClient. Tento callback je sou ástí klienta, navíc není p íli² komplexní a není proto nutné jej p íli² rozebírat. Druhá (vy²²í) úrove slouºí k propagaci dat mezi kontrolerem a klientem IMAPClient a kaºdý kontroler, který chce klienta pouºívat, musí tento callback implementovat v zadaném formátu. Tento callback je JavaScriptový objekt, který p ijímá odpov di od klienta a musí obsahovat metody pro následující p íkazy: okay fail unexpected

16 KAPITOLA 4. LIBIMAP error Metoda pro kaºdý z t chto p ípad dostává jeden parametr. V p ípad prvních t ech je to objekt s odpov dí, v posledním z nich pak objekt chyby, která nastala. Tento callback objekt se p edává instanci t ídy IMAPClient jako parametr v její metod init(). Klient pak po p ijetí kaºdé zprávy od serveru vyhodnotí, jaká metoda callbacku se má pouºít a p edá jí tuto zprávu rozparsovanou do struktury IMAPResponse. Roli ve výb ru pat i né metody hraje status serverové zprávy a její tag. V implementaci kontroleru jak pro Pencil, tak i pro vzorovou aplikaci je princip takový, ºe metody okay a fail dál propagují p ijaté odpov di do p íslu²ných metod callback t etí úrovn. T etí vrstva callbacku není pro funkci knihovny nutná, ale jak jiº bylo uvedeno, vyuºívají ji ob implementace kontroleru v této práci. Tato vrstva se pouºívá pro denování posloupnosti p íkaz v rámci kontroleru, a tedy kontrolu toku programu. Callback je op t objekt s metodami denovanými pro stavy okay a fail. D vody pro toto chování jsou podrobn ji rozebrány v ásti 4.2.4. 4.2.3 P íkazy klienta V²echny p íkazy, které klient posílá na server mají ze specikace podobnou strukturu. V rámci kaºdého volání se pak musí vykonat následující: Ov ení platnosti p íkazu v sou asném stavu Vytvo ení nového tagu Registrace p íkazu pro pozd j²í manipulaci s odpov dí Formátování p íkazu pro IMAP server Odeslání na server Pro zamezení duplikování kódu, a s tím spojenou moºnost zanesení chyb do programu, byla ve t íd IMAPClient vytvo ena metoda simplecommand 1. Ta jako argument p ijme kon- gura ní objekt klientského p íkazu, a poté zformuje a navrátí metodu zaji² ující v²echny vý²e uvedené kroky. Denice nových p íkaz pro klienta je proto velmi jednoduchá, je pot eba pouze nadenovat ásti specické pro konkrétní p íkaz, bez nutnosti starat se o ásti spole né v²em p íkaz m podle specikace. Následující kód ilustruje pouºití metody simplecommand na p íkladu klientského p íkazu LOGOUT this.logout = this.simplecommand({ allowedstates : [ IMAPState.NOT_AUTHENTICATED, IMAPState.AUTHENTICATED, IMAPState.SELECTED ], command : function() { 1 Název simplecommand implikuje existenci metody advancedcommand, pro pot ebu p íkaz v sou asné verzi knihovny v²ak implementace ºádných pokro ilej²ích mechanism nebyla nutná. Pojmenování bylo zachováno pro p ípad, ºe v rámci budoucího vývoje by bylo pot eba takovou metodu skute n pouºít.

4.2. PRINCIP 17 return "LOGOUT"; }, handler : { okay : function(scope, response) {... }, fail : function(scope, response) {... } } }); 4.2.4 P íkazy kontroleru Je z ejmé, ºe kontroler musí denovat metody pro práci s klientem a ºe tato metoda nemusí obsahovat vºdy jen jeden p íkaz. Protoºe ale kontroler musí pracovat s asynchronními výstupy z klienta, bylo nutné navrhnout a implementovat speciální p ístup ke kontrole toku programu. Za azeny byly dv metody, první pro vytvo ení funk ních celk z atomických p íkazu pro klienta, druhá pro vytvo ení sekvence t chto celk za ú elem provedení ur itého úkonu. 4.2.4.1 Z et zení p íkaz Tato metoda vyuºívá se objektu, jeº v²echny díl í kroky zapouzd uje s tím, ºe tyto jednotlivé ásti jsou za sebe napojeny takovým zp sobem, ºe metoda handleru okay jednoho bloku volá metodu command druhého atd. Pro jednoduchost a konzistenci je jako vstupní bod do tohoto bloku metoda o stejném názvu jako zapouzd ující objekt s prexem run. Zde je zjednodu²ený p íklad metody action kontroleru, vytvo ené z et zením nekolika p íkaz pro klienta. Controller.runAction = function() { this.action.step1.command(this); }; Controller.action = { step1 : { command : function(scope) { scope.client.foo(bar); }, okay : function(scope, response) { scope.action.step2.command(scope) } }, step2 : { command : function(scope, sequencenr) { scope.client.foo2(bar2);

18 KAPITOLA 4. LIBIMAP }; } }, okay : function(scope, response) {... } Tento postup je vícemén asynchronním ekvivalentem standardního: scope.client.foo(bar); scope.client.foo2(bar2);... 4.2.4.2 Fronta V kontroleru pouºitém pro Pencil je implementován je²t jeden mechanismus pro denování sekvencí, a sice fronta metod k vykonání tzv. scéná e. Ta se naplní p i vytvá ení kontroleru referencemi na jeho asynchronní bloky v poºadovaném po adí. Do kontroleru je zavedena nová metoda runnext, kterou vºdy poslední lánek kaºdého bloku zavolá a p edá tak ízení dále. Metoda runnext vºdy vyzvedne a zavolá první metodu z fronty, jeº je na ad. Více o pouºití fronty viz 5.3 Následuje p íklad fronty asynchronních metod kontroleru, denující scéná pro staºení seznamu zpráv: c.commandqueue = [ c.runconnect, c.runselectfolder, c.rungetmessagelist, c.rundisconnect ]; 4.3 Implementované p íkazy Pro pot eby této práce nebylo nutné implementovat v²echny p íkazy klientské ásti protokolu IMAP tak, jak je denuje RFC3501[1]. Následuje seznam implementovaných p íkaz v abecedním po adí, stav, ve kterém je lze volat, jejich funkce, tvar a p ípadn i odpov di na n : 4.3.1 APPEND P íkaz APPEND p idá do dané sloºky poslaný text jako novou zprávu. Podle specikace by text m l být ve formátu stanoveném v RFC2822[12]. P íkaz lze odeslat ve stavech Authenticated a Selected, má následující tvar. Hranaté závorky udávají nepovinné údaje. APPEND <název sloºky> [seznam flag ] [datum/ as] <délka zprávy> Server na správn formulovaný p íkaz odpoví ºádostí o pokra ování requestu, na eº klient za²le samotnou zprávu o dané délce. V p ípad úsp ²ného p idání zprávy pak server za²le zprávu OK APPEND completed. Více viz B.1

4.3. IMPLEMENTOVANÉ P ÍKAZY 19 4.3.2 CREATE P íkaz CREATE vytvo í ve schránce novou sloºku se zadaným jménem. P íkaz lze volat ve stavech Authenticated a Selected v tomto tvaru: CREATE <název sloºky> 4.3.3 FETCH Volání FETCH vyzvedne z aktuáln vybrané sloºky dotázaná data. Tento p íkaz je pouºitelný pouze ve stavu Selected v následujícím tvaru: FETCH <sekvence> <poloºky ke staºení nebo makro> Parametr sekvence ur uje, které zprávy se mají stahovat. Tvar tohoto patrametru pro v²echny zprávy je 1:*, lze pouºívat intervaly, nap. 3:7 a nebo si vyºádat pouze jednu konkrétní zprávu zadáním jejího po adí ve sloºce, nap. 8. Druhý parametr ur uje formát dat, která má klient o ekávat. Je moºné explicitn vyjmenovat co je pot eba stahovat a není tak pot eba si vºdy vyºádat kompletní data zprávy, pokud nejsou pot eba. Lze také pouºít denované makro, na výb r jsou t i, a sice ALL, FAST a FULL. V této práci jsou pouºity vlastní denice poloºek s daty uºite nými pro pouºití v Pencilu a ukázkové aplikaci knihovny libimap. Uvedeny jsou v náledujícím bloku, první z nich se dotazuje pouze na data z hlavi ky a je tak vhodný pro stahování seznamu zpráv ve sloºce. Druhá pak stahuje rovnou i t lo zprávy v etn p íloh, hodí se proto hlavn k pouºití pro jedinou konkrétní zprávu a nem la být pouºita pro stahování interval zpráv nebo dokonce v²ech zpráv ve sloºce. Dodrºení t chto mechanism optimalizuje datové p enosy mezi klientem a serverem a zaji² uje tak i ochranu b hu programu p ed zdánlivým zamrznutím, zp sobeným ne inností klienta b hem stahování a zpracování dat[6]. Za zmínku stojí pouºití BODY.PEEK v prvním p íklad. Narozdíl od samostatného BODY totiº umoº uje stáhnout data zprávy, aniº by se tato zpráva automaticky ozna ila jako p e tená. (FLAGS BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID TO)]) (FLAGS BODY[HEADER.FIELDS (DATE FROM SUBJECT MESSAGE-ID TO)] BODY[TEXT]) Server na p íkaz odpovídá nejprve netagovanou odpov dí s vyºádanými daty a poté zakon í p enos odpov dí s tagem a statusem.

20 KAPITOLA 4. LIBIMAP 4.3.4 LIST Pomocí p íkazu LIST lze zobrazit seznam sloºek na serveru. P íkaz je pouºitelný ve stavech Authenticated a Selected v následujícím tvaru: LIST <reference> <název mailboxu> Server na p íkaz odpoví nejprve netagovaným seznamem sloºek vyhovujícím hledaným parametr m a poté i tagovaným oznámením o úsp ²ném pr b hu p íkazu. Pro více informací a p íklady viz B.2 4.3.5 LOGIN Protokol IMAP popisuje n kolik moºností autentizace uºivatele. Jelikoº v²ak v t²ina IMAP server podporuje za²ifrovaný p ístup p es SSL, zabezpe ení p enosu bylo p enecháno komponent frameworku zaji² ující spojení a implementovat posta ilo pouze p íkaz LOGIN. Ten posílá serveru uºivatelské jméno a heslo uºivatele, coº by bylo nebezpe né u ne²ifrovaného p ipojení, ale je v po ádku, pokud celé spojení probíhá po SSL kanále. P íkaz je serveru poslán ve stavu Not Authenticated a má tvar LOGIN username password Na p íkaz server odpovídá výpisem schopností serveru (CAPABILITY) v p ípad úsp chu, nebo chybovou hlá²kou AUTHENTICATIONFAILED, pokud byly zadány chybné údaje. Po úsp ²ném provedení tohoto p íkazu se klient nachází ve stavu Authenticated. 4.3.6 LOGOUT P íkaz LOGOUT informuje server o tom, ºe klient je p ipraven ukon it spojení se serverem. Po úsp ²ném provedení p íkazu se klient nachází ve stavu Logout. P íkaz lze odeslat ve v²ech stavech autentizace a má tvar LOGOUT bez parametr. Server na p íkaz reaguje netagovanou odpov dí BYE, po které ukon uje komunikaci. Klient by m l vºdy zav ít komunika ní kanál teprve po obdrºení této odpov di. 4.3.7 SELECT P íkaz SELECT vybere sloºku se zadaným jménem. Po úsp ²ném pr b hu tohoto p íkazu se klient nachází ve stavu Selected. P íkaz lze volat ve stavu Authenticated v tomto tvaru: SELECT <název sloºky> Pokud b hem vybírání sloºky nedo²lo k chyb, server odpoví sérií netagovaných dat, obsahující stav vybrané sloºky jako nap. agy v ní pouºité, po et zpráv celkem, po et nep e tených, atp. Teprve po odeslání v²ech t chto informací po²le server tagovanou zprávu o úsp ²ném pr b hu p íkazu.

4.4. PARSOVÁNÍ 21 4.3.8 STORE P íkaz STORE slouºí k modikaci dat zprávy. P íkaz je pouºitelný ve stavu Selected v tomto tvaru: STORE <sekvence> <editovaná poloºka> <nová hodnota> Parametr sekvence je totoºný se stejným parametrem u p íkazu FETCH. P íkaz umí dle RFC3501 m nit pouze jedinou poloºku zprávy, a sice její agy. Podporované jsou t i módy, FLAGS, +FLAGS a -FLAGS. První z nich nahradí zprávám jejich agy novými hodnotami, dal²í dva tyto nové hodnoty do stávajícího seznamu ag p idají, resp. je odeberou. Po úsp ²ném p i azení ag po²le server stejnou netagovanou odpov jako u p íkazu FETCH. Teprve poté oznámí úsp ch volání. 4.4 Parsování Jelikoº ve²kerá komunikace probíhá textov, je nutné zprávy p ícházející od serveru parsovat do pouºitelné podoby. Parsování má v jád e knihovny libimap celkem dva stupn, t etí stupe je pak nutné zavést v rámci kontroleru klienta. První z t chto stup parsování probíhá okamºit po obdrºení odpov di od serveru a má za úkol vytvo it z textu odpov di strukturu ImapResponse, se kterou je pak aplikace schopna dále pracovat. Toto po áte ní parsování je p ímo sou ástí t ídy ImapClient a projde jím kaºdá zachycená odpov. První stupe parsování musí být obecný a stejný pro v²echny odpov di, parsuje se tedy pouze status zprávy, viz 3.3.2 status response a zbytek je ponechán ke zpracování na pozd ji. Rozparsovaná struktura odpov di obsahuje následující pole: tag zkratka statusu (OK, NO, BAD) podrobn j²í popis výsledku p íkazu zbytek zprávy Druhý stupe parsování vyuºívají pouze p íkazy LIST a FETCH, které jako data odpov di obdrºí seznam n kolika poloºek. Tento stupe v obou p ípadech rozd lí tento textový seznam na jednotlivé poloºky p ed p edáním rozparsované odpov di kontroleru, u p íkazu LIST pak dokonce rozparsuje odpov celou. Vyuºívá p i tom faktu, ºe p ijaté odpov di mají p esn p edepsaný formát. Z tohoto d vodu m ºe být stejn jako první stupe p ímo sou ástí t ídy ImapClient. Cílem takovéhoto designu je provád t co moºná nejv t²í mnoºství práce v jád e knihovny, spole ném pro v²echny aplikace, které tuto knihovnu budou pouºívat, a uleh it tak co nejvíce tvorbu aplika n závislého kontroleru. T etí (a poslední) stupe parsování zprávy se volá p ímo z kontroleru, v p ípad Pencilu tedy t ídy ImapClientController. Tento stupe vyuºívá pouze p íkaz FETCH a nem ºe uº být sou ástí jádra knihovny, protoºe vyºaduje znalost p esného formátu p ijímané zprávy. Pro pot eby této práce byla vytvo ena funkcionalita na parsování IMAPParser, která umí parsovat odpov di na FETCH pro formát, v jakém jej kontroler pouºívá.

22 KAPITOLA 4. LIBIMAP 4.5 Ukázková aplikace pro libimap Jak jiº bylo uvedeno, k ovládání libimap knihovny je zapot ebí implementovat tzv. kontroler. Jelikoº má být knihovna uvoln na k dal²ímu pouºití, musí být kontroler sou ástí balí ku její distribuce. Jelikoº je Pencil pom rn rozsáhlou aplikací, není vhodné, aby byl do tohoto balí ku zahrnut práv kontroler pouºitý pro Pencil, a bylo proto pot eba implementovat nový, ukázkový kontroler, na kterém budou demonstrovány v²echny principy práce s knihovnou libimap. Obrázek 4.3: Snímek okna ukázkové aplikace Byla proto navrºena a implementována jednoduchá aplikace umoº ující následující scéná : 1. P ipojení k serveru 2. Autentikace serveru 3. Zobrazení seznamu sloºek 4. Volba konkrétní sloºky 5. Zobrazení seznamu zpráv ve sloºce

4.6. LIBIMAP-CONSOLE 23 6. Staºení a zobrazení konkrétní zprávy 7. Uloºení p íloh zprávy 8. P idání agu zpráv 9. Odebrání agu zprávy 10. Odhlá²ení V této aplikaci jsou n které metody kontroleru spou²t ny stiskem tla ítka, ostatní metody jsou s nimi pak spojeny do sekvence, viz 4.2.4.1. Aplikace pouºívá v²echny dostupné widgety, snaºí se v²ak z d vodu p ehlednosti z stat co nejjednodu²²í. Na obrázku 4.3 je snímek okna ukázkové aplikace s pouºitým widgetem pro volbu sloºky. 4.6 libimap-console P íkladem miniaplikace vyuºívající knihovnu libimap mimo kontext Pencilu je program s pracovním názvem libimap-console. Jedná se o lightweight emulátor terminálu p ipojeného k serveru p es protokol IMAP. Impulsem pro vznik této aplikace byla pot eba ru n testovat p ipojení k serveru p es protokol IMAP a vid t tak p esn v²echny klientské p íkazy i odpov di serveru. D íve k tomuto ú elu dob e slouºila aplikace PuTTY[14], ta v²ak není nadále pouºitelná, protoºe nepodporuje zabezpe ené p ipojení k IMAPu na portu 993 a v t²ina IMAP server uº p estala pouºívat nezabezpe ený port 443. Druhá alternativa, unixový open-source ssl toolkit openssl[11] zase v opera ním systému Kubuntu Linux (jinde testován nebyl) p estává komunikovat po p ijetí odpov di na první p íkaz. Aplikace byla pojata jako HTML stránka nastylovaná pomocí CSS, s jednoduchým JavaScriptovým klientem. Jedná se o siln odleh enou verzi knihovny libimap, která zaji² uje pouze následující funkcionalitu: 1. Navazuje spojení se serverem 2. P ijímá od uºivatele textový vstup 3. Odesílá tento vstup na server 4. Tiskne serverovou odpov do výstupního okna Kv li závislosti na komponentách Mozilla XPCOM je aplikace pouºitelná pouze v prohlíºe i Firefox, i to je v²ak malá cena za funk ní nástroj usnad ující vývoj. Na obrázku 4.4 je screenshot okna aplikace libimap-console p ipojené k serveru.

24 KAPITOLA 4. LIBIMAP Obrázek 4.4: Snímek okna aplikace libimap-console

Kapitola 5 Pencil 5.1 Úpravy editoru A koliv je program Pencil jiº v základu velice silným nástrojem pro tvorbu GUI, samoz ejm v n m existují n které chyby a nedostatky. ƒást této práce se proto zabývá jejich odstran ním nebo vylep²ením. Následuje seznam provedených zm n a jejich popis: Úprava ²ablony pro HTML export Prioritní snapping Kopírování prvk Ctrl+taºením Tyto zm ny byly navrºeny vedoucím práce po zku²enostech s programem Pencil i jinými nástroji pro návrh uºivatelských rozhraní a nástroji na tvorbu graky obecn. Jelikoº se jedná o vylep²ení stávajících funkcí programu, je moºné jejich budoucí za len ní do standardní distribuce Pencilu. 5.1.1 Úprava ²ablony pro HTML export Standardní verze Pencilu obsahuje ²ablonu pro export do HTML nazvanou GUI Prototyping, jejíº HTML kód v²ak obsahoval chyby vedoucí k nesprávnému zobrazení v internetových prohlíºe ích. HTML kód bylo nutné z v t²í ásti p epsat a provést drobné zm ny designu, aby bylo zaji²t no korektní zobrazení v r zných prohlíºe ích i velikostech okna. Pouºití knihovny je následovné: 1. Zvolte Tools - Manage Export Template - Install New Template 2. Vyberte soubor.zip se ²ablonou 3. Otev ete projekt k exportu 4. Zvolte File - Export Document - Single web page 5. Zvolte rozsah exportu 25

26 KAPITOLA 5. PENCIL 6. Vyberte ²ablonu GUI Prototyping mod, cestu k exportovanému projektu a stiskn te Finish 7. Otev ete soubor index.html ve zvoleném adresá i 5.1.2 Prioritní snapping Pencil v základu obsahuje tzv. Snapping. Snapping funguje na principu p ichytávání objekt k x, resp. y sou adnicím dal²ích objekt b hem taºení my²í. Toto chování usnad uje zarovnávání objekt k sob. U kaºdého objektu jsou pro snapping v jedné ose k dispozici r zné sou adnice. Nej ast ji to jsou horní a spodní hrana objektu v horizontální ose, resp. jeho levý a pravý okraj ve vertikální ose. Sou adnice st edu objektu jsou zahrnuty v obou osách. Tento mechanismus je b ºn pouºívaný v nástrojích pro práci s grakou, ve standardní verzi Pencilu jsou v²ak n které nedostatky a byly proto navrºeny zm ny k jejich odstran ní. První vylep²ení snappingu spo ívalo v zahrnutí sou adnic okna editoru p i výpo tu snappingu. Pencil z n jakého d vodu tato data nezahrnoval, tato drobná modikace tak umoºnila p ichycení objektu ke kraj m okna. To je výhodné nap. p i roztahování objektu na celou plochu okna nebo p i centrování prvk na st ed okna. Dal²ím vylep²ením bylo vylad ní rozhodovací úrovn, kdy se má je²t taºený objekt p ichytit. Rozhodovací úrove je v Pencilu standardn nastavena p íli² nízko, pro p ichycení objektu tak bylo d íve nutné jej dotáhnout aº tém p esn na poºadované místo. Vylep²ení v podob zvý²ení rozhodovací úrovn po pe livém otestování vedlo k plynulej²í práci s programem b hem návrhu. Nejvýznamn j²í zm nou funkcionality snappingu v²ak byla implementace prioritního snappingu, tedy principu, kdy se objekt spí²e p ichytí k objektu stejného typu. Tato funkce velice usnad uje práci, pokud se v okn nachází velké mnoºství prvk na r zných sou adnicích. Standardní chování p i snappingu je pak trhané, jelikoº program neví, ke kterému prvku chce uºivatel snapping provést. Má implementace prioritního snappingu vychází z p edpokladu, ºe prvky stejného typu mají být pravd podobn zarovnané k sob spí²e, neº objekty r zné, nap. tla ítko bude v t²inou zarovnáno k jinému tla ítku spí²e, neº k textovému prvku nebo tverci. Algoritmus pro snapping primárn hledá p ichycení k objekt m stejného typu, s nepartn vy²²í rozhodovací úrovní neº p i b ºném postupu. Teprve kdyº není vyhodnocena ºádná shoda, hledá se snapping standardním zp sobem. Tím je docíleno toho, ºe pro objekty stejného typu je snapping nalezen p ednostn. 5.1.3 Kopírování prvk Ctrl + taºením Urychlené kopírovaní objektu pomocí taºení se stisknutou klávesou Ctrl je standardní sou ástí v t²iny nástroj pro práci s grakou i textových editor a je s podivem, ºe Pencil zatím tuto funkci neobsahoval. Objekt bylo nutné nejprve zkopírovat do schránky, poté jej ze schránky vloºit do okna editoru, a teprve poté p esouvat. Doprogramování této funkce do programu tak výrazným zp sobem urychlilo vytvá ení opakujících se prvk na stránce, jako jsou nap. ádky formulá e, tla ítka apod. Tato nová funkcionalita se nijak neli²í od chování jiných editor, je tedy moºné tímto zp sobem kopírovat i více vybraných objekt naráz. Pro aktivaci této funkcionality byla zvolena klávesa Ctrl práv proto, ºe je k tomuto ú elu pouºívaná prakticky ve v²ech nástrojích, které toto chování umoº ují. Tato forma konzistence

5.2. NAPOJENÍ NA LIBIMAP 27 zaji² uje, ºe nový uºivatel programu funcionalitu snadno objeví a intuitivn za ne pouºívat, pokud uº s ní má p edchozí zku²enosti z jiných aplikací. 5.2 Napojení na libimap Jakmile byla vytvo ena a otestována knihovna libimap, a vytvo en kontroler s pot ebnými funkcemi, mohl být napojen na funkcionalitu Pencilu. Kód se pro p ehlednost nachází ve struktu e zdrojových soubor v adresá i ExtBrain. Ten má následující hierarchii: ExtBrain/ Connectors/ Css/ libimap/ Controller/ Core/ Widget/ K propojení musely být vytvo eny nebo modikovány metody n kterých objekt Pencilu. Tyto metody se nacházejí v adresá i Connectors. Princip tohoto obohacení výchozích objekt Pencilu spo ívá v roz²í ení prototypu existující metody o metodu s jiným názvem. Metody tak nemusí být ve stejném souboru, sta í jen z místa jejich pouºití importovat nejprve originální objekt a poté jeho roz²í ení z adresá e Connectors. 5.2.1 Ukládání nastavení Z d vod uºivatelské p ív tivosti jsou do globálních nastavení aplikace ukládána tato nastavení, a to hned po jejich prvním vypln ní: Adresa serveru Pouºitý port P epína pouºití SSL módu Uºivatelské jméno ú tu na serveru Heslo k ú tu na serveru Email uºivatele (pro jeho identikaci na serveru) Ve výsledku je tedy uºivatelský vstup poºadován pouze b hem prvního p ipojení k serveru, poté jiº probíhá pln automaticky. V²echny tyto volby je v²ak moºné zm nit v nastavení aplikace volbou Settings - Options pod záloºkou IMAP.

28 KAPITOLA 5. PENCIL 5.3 Scéná e Pouºití knihovny libimap v programu Pencil bylo : Uloºení souboru na server Staºení souboru ze serveru Pro práci klienta byly tedy vytvo eny komponenty pro provedení t chto operací ImapLoad- File, resp. ImapSaveFile. Vstupním bodem z metod objekt Pencilu do komponent knihovny libimap jsou takto pojmenované soubory v jazyce XUL, které denují frontu úkol (viz 4.2.4.2) pot ebných k provedení pat i né operace. Operace je spu²t na otev ením jednoho z t chto soubor metodou window.opendialog() a p edání kongura ního objektu jako parametru, viz následující p íklad uloºení souboru z metody kontroleru: var confobj = { filetype : IMAPConfig.tag.project, name : this.doc.properties.name, filepath : this.filepath, msgid : msgid, oldmsgid : oldmessageid, text: IMAPConfig.tag.project + ": " + this.doc.properties.name, out : null }; window.opendialog("../extbrain/libimap/controller/imapsavefile.xul", "Save IMAP Document", "chrome,dialog, modal", confobj); Ob tyto operace rozepsány do tzv. scéná jsou uvedeny níºe. Tyto scéná e a popisujících sekvenci provedených akcí: 5.3.1 Uloºení souboru na server 1. P ipojení na server 2. Autentizace uºivatele 3. Získání seznamu sloºek 4. Vybrání p íslu²né sloºky 5. Získání seznamu zpráv 6. Výb r zvolené zprávy 7. Staºení vybrané zprávy 8. Uloºení p ílohy zprávy na disk 9. Odpojení se od serveru

5.4. SYNCHRONIZACE ZDROJOVÝCH SOUBOR 29 5.3.2 Staºení souboru ze serveru 1. P ipojení na server 2. Autentizace uºivatele 3. Získání seznamu sloºek 4. Vybrání p íslu²né sloºky 5. Na tení souboru z disku 6. Formování zprávy 7. Uloºení zprávy na server 8. Odpojení se od serveru 5.4 Synchronizace zdrojových soubor 5.4.1 Princip a pouºití Staºení a otev ení nového souboru ze serveru probíhá volbou File - Open from IMAP. Klient se poté p ipojí k serveru a nabídne uºivateli seznam projekt k na tení. Po zvolení jednoho z nich je tento staºen, otev en a p ipraven k práci. Se souborem se dá manipulovat stejn jako s oby ejnými zdrojovými soubory Pencilu, je moºné si ho tedy nap. uloºit lokáln pro pozd j²í práci. Uloºení otv eného projektu z IMAPu, stejn jako první upload nového projektu, se provádí volbou File - Save to IMAP. Program pak automaticky nahraje projekt na server. Pokud byl projekt otev en z IMAPu, je b hem uploadu archivována jeho stará verze. P i prvním uploadu projektu na server je nutné zjistit, jaký název se má pro uloºený projekt pouºít. V p ípad nového projektu, který je²t nebyl uloºen je uºivatel dotázán na název projektu, jinak je tento název odvozen ze jména souboru. 5.4.2 Implementace Funkcionalita byla napojena do hlavního kontroleru Pencilu. Stejná komponenta zprost edkovává i ukládání a na ítání zdrojových soubor lokáln na disk, umíst ní bodu napojení je tedy správné. Byly implementovány metody saveimapdocument a loadimapdocument, které ve spojení s pat i nými scéná i, viz 5.3, ovládají kontroler a IMAP klienta. 5.5 Import a export privátních kolekcí 5.5.1 Princip a pouºití Pouºití funkcionality je konzistentní s p ístupem Pencilu k privátním kolekcím obecn, tedy ze záloºky My Stus v palet nástroj v levé ásti okna. Kliknutí pravého tla ítka v

30 KAPITOLA 5. PENCIL tomto okn vyvolá kontextové menu s volbami pro správu privátních kolekcí v programu Pencil. Volba Import new private collection from IMAP se p ipojí k serveru a nabídne uºivateli seznam dostupných privátních kolekcí. Pokud si uºivatel n jakou zvolí, je staºena a nainstalována stejným zp sobem jako lokální. Druhá volba související s IMAPem je Export this collection to IMAP. Tato volba lze pouºít ve stejném p ípad jako b ºný export, tedy pouze pokud je kontextové menu vyvoláno nad existující kolekcí. Po stisknutí je exportovaná kolekce uploadována na server. 5.5.2 Implementace Tato funcionalita byla napojena do manaºeru privátních kolekcí Pencilu, která obaluje v²echny metody pro práci s privátními kolekcemi. Pro ovládání této funkcionality vznikly dv metody, a sice importnewimapcollection a exportimapcollection. V rámci druhé zmín né v²ak byla provedena je²t drobná modikace funkce Pencilu, a sice refaktorizace ásti p vodní metody exportcollection do metody _exportcolectiontofile. Jedná se o spole nou ást, kterou nyní mohou vyuºívat ob exportní metody a nedochází tak ke zbyte né duplikaci kódu.

Kapitola 6 Testování Aplikace byla b hem vývoje pr b ºn testována, a to jak na funkcionalitu, tak i pouºitelnost uºivatelského rozhraní. 6.1 Pencil Vzhledem k tomu, ºe Pencil jako aplikace byl jiº jeho vývojá i vylad n, tato ást testování byla v nována uºivatelskému rozhraní propojení programu s klientem protokolu IMAP. Práce s tímto klientem by v²ak m la být co nejvíce automatická a uºivatele by nem la ru²it od práce. Z tohoto d vodu jsou ve²kerá uºivatelská nastavení knihovny po prvním zadání uloºena do globálních preferencí programu a práce pak probíhá bez nutnosti uºivatelského vstupu. P esto se b hem testování s uºivateli objevily n které nedostatky. První verzi byla vytknuta p íli²ná prototypovost a byly podniknuty kroky k jejímu vylep²ení. Byly nap. odstran ny prvky typu prompt, p ijímající textový vstup od uºivatele, a jako jejich náhrada byly implementovány vlastní kontrolní prvky. Druhým p íkladem je, ºe uºivatel byl p vodn dotazován na specikaci serveru a p ihla²ovací údaje ve dvou krocích. Tyto dva kroky byly kv li lep²í p ehlednosti a zrychlení celého procesu slou eny do jednoho. Dal²í zm na se týká za i²t ní chybových hlá²ek programu. Ty jsou v n kterých p ípadech bohuºel nutné, poda ilo se ale zjednodu²it nap. autentikaci uºivatele v p ípad, ºe zadá ²patné p ihla²ovací údaje. Pokud server po prvním ²patném zadání odmítne uºivatele znovu autentizovat, dojde automaticky k odpojení a znovup ipojení bez nutnosti uºivatelské akce. 6.2 libimap Testování knihovny libimap muselo být o mnoho rozsáhlej²í neº testování n kolika p ípad uºivatelského vstupu v Pencilu. Asi nejvýznamn j²í nahlá²eným problémem bylo (na²t stí hned v za átku vývoje) mrznoucí uºivatelské rozhraní b hem ekání na odpov. To bylo zp sobeno synchronní implementací komunikace se serverem, program neodpovídal po celou dobu co klient ekal na zprávu od serveru. Kv li této chyb byla komunikace p epsána asynchronn, coº se ukázalo jako správné rozhodnutí. 31

32 KAPITOLA 6. TESTOVÁNÍ Dal²ím nedostatkem byla absence timeoutu p i pokusu o p ípojení se k serveru. I tato funkce v²ak jiº byla do programu dopln na. 6.2.1 Serverové implementace IMAPu Rozsáhlé testování muselo také prob hnout ohledn pouºitelnosti knihovny na b ºn pouºívaných serverech podporujících IMAP. Testovány byly serverové implementace emailových komponent následujících server : gmail.com feld.cvut.cz aol.com centrum.cz e-fractal.cz yahoo.com Tato fáze testování velmi pomohla vylep²it implementaci klienta, protoºe jednotlivé systémy se od sebe li²í. To je dáno faktem, ºe specikace RFC3501[1] není p íli² striktní a nechává volbu n kterých chování na rozhodnutí vývojá. To samoz ejm p idává práci vývojá m klientských aplikací, jelikoº musí své programy p izp sobit v²em z nich. P íkladem takto rozdílného chování je nap. podpora ukládání vlastních ag (viz 3.3.4) u zpráv. První dva jmenované (gmail.com a feld.cvut.cz) pln podporují p idávání t chto ag ke zprávám p i jejich nahrávání na server, tak jak to vyplývá z RFC3501. Zárove je samoz ejm moºné s nimi manipulovat pomocí p íkazu STORE. Firemní server e-fractal.cz s implementací IMAPu Kerio Connect[4] a free mail sluºba na yahoo.com vlastní agy nepodporují a jsou nejstriktn j²í ze v²ech jmenovaných, protoºe pokud jim v rámci p íkazu APPEND p ijde neznámý ag, celý p íkaz selºe a celá zpráva p enesená na server zanikne. Server se v²ak alespo chová konzistentn i p i pouºití p íkazu STORE, který p i pouºití vlastního agu selºe také. Naproti tomu server centrum.cz sice tyto tagy také nepodporuje, ale jeho p ístup mi osobn p ijde lep²í. Pokud serveru p ijde poºadavek na vlastní ag, je tento ag ignorován, zbytek p íkazu ale prob hne dob e. To platí jak pro p íkaz APPEND, tak i STORE. Nevýhodou samoz ejm je, ºe klient s takovýmto postupem musí po ítat a ne ekat p ítomnost ag u zpráv. Server aol.com je specický je²t více, protoºe agy sice ignoruje a výsledným chováním odpovídá p edchozím dv ma, ale navíc, p i pokusu o dodate né vytvo ení vlastního agu voláním p íkazu STORE odpoví, jako by vytvo ení tohoto agu dopadlo úsp ²n. Navíc, p estoºe tento ag nelze nijak pouºívat, objeví se mezi ostatními dostupnými agy, coº je²t více poukazuje na nesmyslnost návrhu této serverové implementace. Program musel být modikován, aby zahrnoval mechanismus pro v²echny tyto p ípady a umoºnil alespo omezené pouºití i nepodporovaných server. Nyní podle podpory uºivatelských ag na serveru zvolí pro p ipojení jeden ze dvou mód. První z nich funguje tak jak

6.3. TESTOVACÍ ÚƒTY 33 bylo zamý²leno a popsáno, zatímco druhý vynechává vytvá ení uºivatelských ag p i ukládání projekt na server. Ze stejného d vodu není moºné ltrovat obsah sloºky práv podle typu, proto výb r souboru pro otev ení projektu i import privátní kolekce zobrazí v druhém módu oba typy. Uºivatel je na provoz ve druhém (nepodporovaném) módu upozorn n p i prvním p ipojení. 6.3 Testovací ú ty Pro vyzkou²ení této práce následuje p ehled server, na kterých bylo provád no testování programu a p ihla²ovací údaje k nim. Z bezpe nostních d vod samoz ejm není moºné poskytnout uºivatelská jména a hesla k osobním ú t m, kde to v²ak provozovatel umoºnil, tam byly vytvo eny ú ty speciáln pro testování. Adresa serveru Port Typ Uºivatelské jméno Heslo Implementace imap.gmail.com 993 ssl test.imap.cz testimap Gimap imap.feld.cvut.cz 993 ssl...... Cyrus IMAP v2.4.12 imap.aol.com 993 ssl test.imap.cz account imap.centrum.cz 993 ssl test.imap.cz testimap balimap mail.e-fractal.cz 993 ssl...... Kerio Connect imap.mail.yahoo.com 993 ssl test.imapcz testimap Tabulka 6.1: P ehled testovaných server 6.4 Testovací aplikace Soub ºn s vývojem knihovny libimap byla vyvíjena i aplikace s testovacím scéná em. Jejím úkolem je vyzkou²et mechanismy a p íkazy knihovny na testovacích datech. Po kaºdé modikaci bylo tímto testem ov eno zachování funk nosti aplikace jako celku. V praxi je tato praktika nazývána Test Driven Development[7] Jelikoº vývoj knihovny byl problematický a zdrojový kód se v pr b hu implementace n kolikrát zm nil v podstat od základ, tento soubor test se ukázal jako neocenitelný. Na obrázku 6.1 je screenshot okna aplikace testovacího scéná e knihovny libimap.

34 KAPITOLA 6. TESTOVÁNÍ Obrázek 6.1: Snímek okna testovací aplikace