České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Bakalářská práce
Modul pro práci s rozsáhlými dokumenty pro Android Lukáš Daniš
Vedoucí práce: Ing. Tomáš Novotný Studijní program: Softwarové technologie a management Obor: Softwarové inženýrství Květen 2012
iv
Poděkování Děkuji panu Ing. Tomášovi Novotnému, který mi pomohl vybrat téma této práce. Dále mu děkuji za jeho vedení a cenné rady.
v
vi
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 pro 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 21. 5. 2012
vii
.............................................
viii
Abstract The goal of this work is to create an implementation of large electronic documents reader for touchscreen controlled mobile devices, which have Android operating system. The resulting application offers viewing of documents, adding, modifying and deleting additional information in these documents and offers a possibility of synchronization. The content of the work is also a documentation.
Abstrakt Cílem této práce je vytvořit implementaci čtečky rozsáhlých elektronických dokumentů pro mobilní zařízení ovladatelné dotykovým displejem, která disponují operačním systémem Android. Výsledná aplikace umožňuje prohlížení dokumentů, přidávání, modifikaci a mazání dodatečných informací v těchto dokumentech a nabízí možnost synchronizace. Obsahem práce je i dokumentace.
ix
x
Obsah Kapitola 1 Úvod ........................................................................................................................ 1 1.1 Android............................................................................................................................ 1 1.2 Elektronické čtečky ......................................................................................................... 1 1.3 Stručný popis kapitol........................................................................................................ 1 Kapitola 2 Popis problému, specifikace cíle ............................................................................. 3 2.1 Cíle práce......................................................................................................................... 3 2.2 Konkrétní podoba aplikace.............................................................................................. 3 2.3 Popis problému a jeho řešení .......................................................................................... 4 2.4 Existující implementace .................................................................................................. 4 Kapitola 3 Analýza a návrh řešení ............................................................................................ 7 3.1 Vývojová infrastruktura .................................................................................................. 7 3.1.1 Použité vývojové prostředí........................................................................................ 7 3.1.2 Použitý verzovací software ...................................................................................... 7 3.2 Analýza............................................................................................................................ 7 3.2.1 Deklarace záměru ..................................................................................................... 8 3.2.2 Uživatelské role........................................................................................................ 8 3.2.3 Funkční požadavky .................................................................................................. 8 3.2.4 Případy užití a scénáře.............................................................................................. 9 3.2.5 Nefunkční požadavky............................................................................................... 9 3.2.5 Zdroje elektronických dokumentů.......................................................................... 10 3.3 Návrh řešení .................................................................................................................. 10 3.3.1 Ukládání dat ........................................................................................................... 10 3.3.2 Návrh grafického uživatelského rozhranní ............................................................ 11 3.3.3 Návrh architektury.................................................................................................. 14 3.3.4 Softwarové moduly ................................................................................................ 14 3.3.5 Životní cyklus obrazovek aplikace......................................................................... 16 3.3.6 Popis interakce mezi moduly ................................................................................. 16 Kapitola 4 Realizace................................................................................................................. 19 4.1 Struktura aplikace........................................................................................................... 19 4.1.1 Konfigurační soubory.............................................................................................. 19 4.1.2 Java balíčky ............................................................................................................. 20 4.1.2 Diagramy tříd vybraných balíčků............................................................................ 20 4.2 Popis vybraných částí aplikace ...................................................................................... 22 4.2.1 Práce s SQLite databází........................................................................................... 22 4.2.2 Seznamy .................................................................................................................. 22 4.2.3 IMAP synchronizace ............................................................................................... 24 4.2.4 HTTP synchronizace ............................................................................................... 25 4.2.5 Hypertextové odkazy a formátování textů .............................................................. 26 4.2.6 Vyhledávání ............................................................................................................ 26 4.3 Grafické uživatelské rozhranní....................................................................................... 27 4.3.1 Konfigurační XML GUI......................................................................................... 27 4.3.2 Výsledné grafické uživatelské rozhranní ............................................................... 28 4.4 Použité externí knihovny............................................................................................ 30 Kapitola 5 Testování ............................................................................................................... 31
xi
5.1 Testování uživatelského rozhranní................................................................................. 31 5.1.1 Řazení hlavního navigačního seznamu ................................................................... 31 5.1.2 Dialogová okna ....................................................................................................... 32 5.1.3 Rychlá navigace při čtení dokumentů ..................................................................... 32 5.1.4 Další aspekty čtecího okna ...................................................................................... 32 5.1.5 Jiné aspekty GUI ..................................................................................................... 33 5.2 Funkční testování ........................................................................................................... 33 5.2.1 IMAP synchronizace ............................................................................................... 33 5.2.2 Přenositelnost dokumentů ....................................................................................... 34 5.3 Výkonnostní testování.................................................................................................... 34 5.3.1 Databáze .................................................................................................................. 34 5.3.2 Práce s XML............................................................................................................ 35 5.4 Shrnutí testování............................................................................................................. 36 Kapitola 6 Závěr....................................................................................................................... 37 6.1 Možnosti vylepšení .................................................................................................... 37 Literatura a použité zdroje........................................................................................................ 39 Příloha A Šablona XML dokumentů...................................................................................... 41 Příloha B Seznam použitých zkratek...................................................................................... 43
xii
Seznam obrázků Obrázek 1 - Foto editačního okna ............................................................................................. 5 Obrázek 2 - Foto okna pro IMAP údaje .................................................................................... 5 Obrázek 3 - Funkční požadavky................................................................................................ 8 Obrázek 4 - Případ užití IMAP synchronizace.......................................................................... 9 Obrázek 5 - Schéma databáze ................................................................................................. 11 Obrázek 6 - Návrh hlavního okna aplikace ............................................................................. 12 Obrázek 7 - Návrh editačního okna......................................................................................... 13 Obrázek 8 - Návrh okna pro prohlížení dokumentu................................................................ 13 Obrázek 9 - Návrh okna pro IMAP synchronizaci.................................................................. 14 Obrázek 10 - Stavový diagram obrazovek .............................................................................. 17 Obrázek 11 - Diagram tříd balíku HTTP ................................................................................ 21 Obrázek 12 - Diagram tříd balíku Adapters ............................................................................ 21 Obrázek 13 - Sekvenční diagram umístění položky................................................................ 24 Obrázek 14 - Sekvenční diagram IMAP synchronizace ......................................................... 25 Obrázek 15 - Sekvenční diagram HTTP synchronizace ......................................................... 26 Obrázek 16 - Foto hlavního okna............................................................................................ 28 Obrázek 17 - Foto prohlížecího okna ...................................................................................... 28 Obrázek 18 - Foto editačního okna ......................................................................................... 29 Obrázek 19 - Foto okna pro IMAP údaje ................................................................................ 29 Obrázek A.1 - XML šablona pro import a export ................................................................... 41
xiii
xiv
Seznam tabulek Tabulka 1 Tabulka 2 Tabulka 3 Tabulka 4 Tabulka 5
xv
- Popis vlastností aplikace ........................................................................................ 3 - Scénář IMAP synchronizace.................................................................................. 9 - Popis konfiguračních XML souborů.................................................................... 19 - Popis Java balíčků................................................................................................ 20 - Seznam použitých knihoven ................................................................................ 30
xvi
Kapitola 1 Úvod Předmětem této práce je návrh a implementace aplikace umožňující práci s rozsáhlými textovými dokumenty pro operační systém Android. Samozřejmostí je přívětivé uživatelské rozhranní, které bohatě využívá možností dotykového ovládání. Tato aplikace by byla vhodná pro uživatele, kteří by si rádi pohodlně přečetli rozsáhlejší dokumenty, případně si je chtěli modifikovat dle jejich preferencí. Jméno aplikace bude ExtbrainReader dle názvu projektu Extbrain, do kterého tato aplikace spadá.
1.1 Android Android od firmy Google je platforma pro mobilní zařízení, která se skládá z operačního systému, klíčových aplikací a middleware. Nejprve byla využita v mobilních telefonech, posléze i ve větších zařízeních, např. tabletu.
1.2 Elektronické čtečky Protože se v dnešní době digitalizují knihy, různé publikace a texty, je dnes vysoká poptávka po programech, které umožňují lidem rychle a efektivně shánět tyto elektronické dokumenty a zároveň je umožňují pohodlně prohlížet, případně nabízejí další funkce, např. dělat si vlastní virtuální knihovny. Pro Android těchto aplikací existuje mnoho, příklady najdete v jedné z nadcházejících kapitol. Předmětem této bakalářské práce je aplikace částečně připomínající elektronickou čtečku.
1.3 Stručný popis kapitol Kapitola 2 detailněji popisuje cíle práce, také obsahuje popis podobných aplikací a potencionální přínos ExtbrainReaderu. V kapitole 3 se nachází analýza a návrh, které naznačují, jak bude výsledná aplikace fungovat a jak by měla vypadat. Obsahem kapitoly 4 je popis, jak vypadá finální verze realizace aplikace. V kapitole 5 jsou rozebrány veškeré problémy během vývoje, změny od návrhové části k realizaci a popis veškerého testování aplikace. Kapitola 6 poskytuje shrnutí výsledků řešení a jejich porovnání se zadáním práce.
1
2
Kapitola 2 Popis problému, specifikace cíle 2.1 Cíle práce Hlavním cílem této práce je implementovat program pro mobilní zařízení běžící na platformě Android, který umožňuje uživateli prohlížet, vytvářet, mazat a modifikovat elektronické dokumenty, případně k nim přidávat dodatečné informace, jako např. hypertextové odkazy nebo poznámky. Tyto dodatečné informace lze editovat nebo mazat. Velký důraz je kladen na podporu velice rozsáhlých dokumentů. Tato položka by zároveň měla být největším přínosem celé práce, protože některé již existující aplikace se znatelně zpomalují při práci s většími dokumenty. V dokumentech lze full-textově vyhledávat a lze v nich synchronizovat pomocí protokolů IMAP a HTTP. Aplikace musí být velice optimalizovaná z důvodu specifikací mobilní platformy, která je velice omezena svými výpočetními a paměťovými možnostmi oproti dnešním PC. Dále je nutno dávat pozor na další omezení, která operační systém Android skýtá. Navazujícím cílem této bakalářské práce je vytvoření zprávy, která je součástí tohoto textu. Tato zpráva by měla vysvětlit implementaci netriviálních součástí řešení a výsledky testování.
2.2 Konkrétní podoba aplikace Aplikace by se měla částečně podobat jiným programům, které mají podobnou funkci. Protože zařízení s Androidem jsou ovládána dotykovým displejem, je nutné, aby ovládání bylo co nejpohodlnější. Důležitou vlastností je možnost přenosu dokumentů na jiná zařízení pomocí několika způsobů. Viz tabulka níže pro bližší popis vlastností aplikace. Tabulka 1: Popis vlastností aplikace
Aplikace obsahuje několik oken, mezi kterými se přepíná v závislosti na aktuální situaci Při spuštění se zobrazí okno s rychlou navigací pomocí rolovacího Navigace seznamu se stromovou strukturou. Zde se také vytvářejí nové dokumenty. Toto okno a také každý dokument či část dokumentu obsahuje menu, které nabízí další funkce. Položky v seznamu lze libovolně řadit nebo vnořovat. Okno prohlížení dokumentů umožňuje zobrazení obsahu elektronických Prohlížení dokumentů s podporou formátování a hypertextových odkazů. Odkazy mohou být externí, tj. při kliknutí se otevře webový prohlížeč, nebo interní, které jsou zpracovány uvnitř aplikace a výsledkem je skok na jiný dokument či jinou část stejného dokumentu. Toto okno obsahuje vyhledávací textové pole pro full-textové vyhledávání v rámci aktuálního dokumentu. Synchronizace Další funkcí aplikace je synchronizace, která dle zvoleného protokolu a cílových údajů provede výměnu dat mezi aplikací a cílem. Přes IMAP se synchronizuje s emailovým účtem a synchronizace je oboustranná. Přes HTTP se data pouze stahují. Poslední důležitou funkcí je přidávání a případná modifikace nebo smazání Modifikace poznámek k dokumentům. Obrazovky
3
2.3 Popis problému a jeho řešení Některé existující čtečky mohou mít problém při čtení velice rozsáhlých souborů, kdy na méně výkonných zařízeních dochází ke zpomalení při práci s takovou aplikací.. Aplikace, jež je předmětem této práce, by měla tenhle problém řešit načítáním aktuální části z větší struktury dokumentu. Dokument bude po částech uložen do databáze, ze které se pak při manipulaci vytáhnou pouze aktuálně viditelná data. Dokument je uložen stromově a obsahuje např. části typu hlavní nadpis, kapitola, podkapitola a další. Záleží, jak budou dokumenty strukturovány. Struktura této bakalářské práce by mohla být příkladem.
2.4 Existující implementace Pro platformu Android existuje mnoho aplikací typu prohlížeče a správy dokumentů. Většina existujících aplikací slouží jako čtečky elektronických knih. Příkladem budiž Amazon Kindle, IReader a FBReader a jiné. Tyto čtečky mají většinou podporu zobrazování PDF dokumentů, ale hlavním rozdílem oproti výsledku této práce je, že tyto čtečky mají podporu mnoha různých formátů elektronických knih. Jedním z nich je formát PDB, který je podporován právě programem IReader. PDB formát je odvozenina z formátu souborů pro platformu Palm OS, takže jeho použití není omezeno pouze na elektronickou knihu či dokument. Další z formátů je EPUB, který je používán např. čtečkou jménem Aldiko. EPUB formát je téměř identický s veleznámým formátem ZIP, který je používán ke kompresi souborů. Obsahem těchto EPUB souborů jsou XHTML dokumenty, které tvoří texty knih. S pomocí dalších souborů, které obsahují informace o knize, případně určují řazení textových částí, pak čtečka dobře pozná, co chce uživatel právě číst. Veškeré testy jiných čteček byly provedeny na emulátoru z důvodu tehdejší nedostupnosti reálného zařízení, nicméně, na emulátoru se aplikace chová stejně, jak v reálném zařízení, což potvrdil aktuálnější test na reálném zařízení. Testované čtečky neumožňují modifikaci knih. Výhodou ExtbrainReaderu oproti těmto čtečkám by mohla být právě možnost si tyto dokumenty vytvářet a sám editovat. Vlastností ExtbrainReaderu bude podpora HTML dokumentů, které lze importovat z XML souboru strukturovaného dle určené šablony. Nevýhodou této aplikace bude zřejmě chybějící podpora zobrazování obrázků. IReader IReader je jednou z nejpopulárnějších čteček elektronických knih pro platformu Android. Mnoho funkcí, kterými disponuje, jsou identické s plánovanými funkcemi ExtbrainReaderu. Testována byla na Android emulátoru, kde nešla použít bez SD karty. Aplikace nebyla moc uživatelsky přívětivá, nebyla k nalezení ani žádná nápověda, a proto by někteří lidé mohli mít problém s používáním aplikace, protože by nevěděli, co se jak dělá. IReader umožňuje měnit grafické prostředí a podporuje obrázky. Výhodou je podpora velkého množství formátů knih. Na obrázku 1 na vedlejší straně je ukázána tato čtečka při prohlížení svých adresářů.
4
Obrázek 1: iReader – foto z emulátoru
AldikoReader AldikoReader používá formát knih EPUB. Testovaná verze aplikace je více uživatelsky přívětivá než IReader. Nabízí rovněž možnost změnit grafické prostředí. Nabízí ke stažení mnoho knih zdarma, ale převážně cizojazyčné. Aldiko umožňuje přechod mezi denním a nočním režimem, ale tato funkce nebyla na emulátoru dobře testovatelná. Bylo otestováno několik dalších čteček, ale funkce jsou většinou identické. Na obrázku 2 je zobrazena virtuální knihovna této čtečky.
Obrázek 2: AldikoReader – foto z emulátoru 5
6
Kapitola 3 Analýza a návrh řešení Obsahem této kapitoly jsou, jak už název napovídá, dvě hlavní části. Cílem analýzy je důkladně rozebrat, co má být výsledkem projektu a jakým způsobem toho nejlépe dosáhnout. Návrhová část na základě analytické části obsahuje informace, jak by měla vypadat následná realizace.
3.1 Vývojová infrastruktura Každý softwarový projekt by měl využívat infrastrukturu, do které patří vývojové prostředí a ideálně i verzovací systém.
3.1.1 Použité vývojové prostředí Pro platformu Android lze aplikace vyvíjet ve více programovacích jazycích, ale zdaleka nejpoužívanější jazyk pro Android je Java. Jazyk je sice sám o sobě multiplatformní, ale aplikace psané pro Android nejsou určeny pro jiné platformy. Vývoj probíhal v prostředí Eclipse Helios na platformě Windows XP s nainstalovaným Android add-onem. Dále byl použít balík Android SDK, který obsahuje i vzorové aplikace a hlavně emulátor, který umožňuje testovat aplikaci během vývoje. Android API, které je součástí Android add-onu, obsahuje předpřipravené třídy pro práci s Androidem. Je podporováno velké množství knihoven z Java API, ale většinu knihoven pro grafiku má Android vlastní. UML diagramy byly vytvořeny pomocí CASE nástroje Enterprise Architect a Visual Paradigm. Pro návrh uživatelského rozhranní byly využity dva programy, Pencil Evolus a DroidDraw. Pencil Evolus byl použit na předběžné nakreslení návrhu grafického rozhranní. DroidDraw byl použit pro vytvoření konfiguračních XML souborů pro grafiku. Snímky aplikace jsou vytvořeny emulátorem a upraveny programem IrfanView. Veškeré programy použité při vývoji byly ve verzi pro Windows.
3.1.2 Použitý verzovací software Během vývoje byl využíván verzovací systém Mercurial, což je systém umožňující decentralizovanou správu, sdílení souborů a hlavně jejich zálohu.
3.2 Analýza Tato část kapitoly ukazuje, čeho by měl být výsledný softwarový produkt schopen a jak by měly vypadat jeho funkce. Najdete zde několik UML diagramů, které popisují některé funkce. UML je grafický jazyk sloužící při návrhu softwarových projektů jako vizuální reprezentace návrhů, či k jejich dokumentaci.
7
3.2.1 Deklarace záměru Cílem projektu je vývoj a následná dokumentace softwarové produktu, který slouží uživatelům pro práci s rozsáhlými elektronickými dokumenty na mobilních telefonech s dotykovým displejem. Dotykový displej nabízí zajímavé možnosti ovládacího rozhranní umožňující velmi pohodlnou manipulaci s dokumenty, proto je jedním z hlavních cílů vytvořit co nejintuitivnější ovládání. Zvoleným neměnným jazykem aplikace je angličtina, protože tímto jazykem mluví velmi široké spektrum uživatelů a většina dostupných aplikací pro Android je v angličtině také. Dokumentace výsledného softwarového produktu je vhodná pro další případnou práci na tomto produktu.
3.2.2 Uživatelské role Vzhledem k cílové platformě a také k povaze softwarového produktu existuje pouze jediná uživatelská role a tou je Uživatel. Tato role má přístup ke všem funkcím aplikace.
3.2.3 Funkční požadavky Už samotné zadání této bakalářské práce nastiňuje jak funkční, tak nefunkční požadavky pro výsledný produkt. Na obrázku 3 je zobrazen UML diagram znázorňující výpis funkčních požadavků, tj. funkcí, kterými má aplikace disponovat.
Obrázek 3: Funkční požadavky
8
3.2.4 Případy užití a scénáře Případy užití a následně scénáře demonstrují interakci mezi aplikací a uživatelem. Uživatel zvolí nějakou funkci, aplikace korektně odpoví a tuto funkci provede, či případně odmítne, protože nejsou splněny všechny předpoklady pro provedení. Pokud tato událost nastane, je označena ve scénáři rozlišovacím písmenem kroku. Vzhledem k množství funkcí je těchto případů užití mnoho, ale diagram by se příliš nelišil, proto je zde pro přehlednost uveden jako příklad pouze jeden z nich. Viz obrázek 4 pro diagram a tabulka 2 pro scénář k tomuto diagramu.
Obrázek 4: Případ užití - Synchronizace IMAP
Tabulka 2: Scénář IMAP synchronizace
Scénář k případu užití - Synchronizace přes IMAP
1. Uživatel zadá přihlašovací údaje na svůj emailový účet a zadá IMAP adresář. 2. Uživatel klikne na tlačítko pro spuštění synchronizace. 3. Systém vyhodnotí zadané údaje. 4a. Systém neprovede synchronizaci z důvodu špatných údajů, nebo protože zadaný účet nemá povolen IMAP přístup. 4b. Systém provede synchronizaci a pak přesměruje uživatele na hlavní navigační obrazovku. Pokud uživatel zadá špatné údaje, tak mu aplikace navrhne opravu podle odhadu, kde má asi chybu, když jde třeba o formát emailové adresy. Pokud je formát správně, ale údaje nesouhlasí, např. špatné heslo, nebo je nedovolený IMAP přístup, tak je uživatel systémem upozorněn, že emailový server odmítl přihlášení z důvodu nekorektních údajů, neexistujícího účtu či že nebyl nalezen zadaný poštovní server.
3.2.5 Nefunkční požadavky Nefunkční požadavky jsou takové požadavky, které nepopisují, co přesně má výsledný softwarový produkt za funkce, ale vyhraňují, za jakých podmínek a jak má fungovat. Na další straně jsou uvedeny nefunkční požadavky pro tento projekt.
9
•
Aplikace je určena pro mobilní telefony s dotykovým displejem a operačním systémem Android, ideálně ve verzi 2.2 Froyo.
•
Zachování efektivního výkonu i při čtení velice rozsáhlých dokumentů.
•
Ukládání dat do databáze SQLite, možnost volit databázový soubor.
•
Pohodlné uživatelské rozhranní, které využije možností dotykového displeje.
•
Podpora pro široké spektrum velikostí displeje a hustoty zobrazení.
3.2.5 Zdroje elektronických dokumentů •
Vytvoření vlastních dokumentů v aplikaci, případně externí modifikace exportovaných dokumentů. Externí modifikace je vhodnější pro formátování textu pomocí HTML značek.
•
Synchronizace nebo přenos dříve vytvořených dokumentů mezi zařízeními a soubory.
3.3 Návrh řešení V této části kapitoly je popisována konkrétnější forma výsledného softwarového produktu. Vývoj probíhá iterativně, proto většina diagramů obsahuje přesnější popis výsledné aplikace.
3.3.1 Ukládání dat Android nabízí několik způsobů jak ukládat a pracovat s daty. Níže jsou popsány tyto způsoby a také, který způsob byl předem vybrán pro tuto bakalářskou práci. •
Uložení dat do souboru, který je uložen na vnitřním nebo vnějším úložišti, převážně na paměťových SD kartách.
•
Uložení do SQLite databáze v interní paměti nebo na SD kartě. Tato databáze nemá tak rozsáhlé možnosti, jako nejrozšířenější databáze Oracle, MySQL nebo PostgreSQL. Velice znatelným rozdílem je skutečnost, že SQLite nepodporuje velikou část SQL příkazů, pro příklad uvádím RIGHT OUTER JOIN nebo FULL OUTER JOIN, SELECT nebo DELETE řádků z více tabulek naráz.
Vzhledem k tomu, že jeden z hlavních nefunkčních požadavků je dostatečná výkonnost aplikace i při prohlížení velice rozsáhlých elektronických dokumentů, tak se sama nabízí možnost ukládání do databáze SQLite. I když SQLite nemá podporu mnoha SQL příkazů, tak je pro ExtbrainReader dostatečná. Návrh databáze pro aplikaci je díky jejímu typu velice jednoduchý a je zobrazen na obrázku 5 na další straně.
10
Obrázek 5: Schéma databáze
Databáze pro tuto aplikaci nevyžaduje relace mezi tabulkami, či cizí klíče, protože poznámky a části dokumentů budou ukládány do samostatných tabulek. Pro rychlejší nahrávání dat je dále nutné vytvořit databázový index k tabulce DocumentTable, který bude indexovat sloupec ordinal, neboli řazení. Indexy zvětšují náročnost na velikost úložiště dat, ale v tomto případě se vyplatí, protože velice urychlují vytahování správných dat z tabulky. Pro IMAP synchronizaci bude použita pomocná tabulka v podobném formátu, jako tabulka DocumentTable.
3.3.2 Návrh grafického uživatelského rozhranní Aplikace bude mít několik oken přes celou obrazovku nabízející požadované funkce, případně i dialogová okna. Všechny grafické podoby oken jsou definovány v XML souborech, pomocí kterých Android sestaví přesné rozvržení všech grafických prvků na obrazovce. Pomocí XML souborů se nastavuje mnoho dalších věcí, od jména aplikace přes definování hlavního okna až po omezení počtu instancí jednoho okna. Také definuje položky výběrových menu. XML soubory pro grafické rozhranní jsou navrhovány pomocí programu DroidDraw, ve kterém lze naklikat požadované rozvržení rozhranní a následně vygenerovat XML, které je nutné dále upravit v Eclipse na relativní hodnoty. Je nutné do XML souborů zadat hodnoty v pixelech jako dp, tj. density pixels („hustotní“ pixely). To znamená, že jeden density pixel obsahuje určitý počet skutečných pixelů. Tato relativní hodnota je důležitá, protože obrazovky mobilních zařízení se liší v poměru stran i v rozlišení. Pro podporu více typů displeje je taky velice nutné používat relativní rozvržení grafických prvků, protože pevně nastavené pixelové hodnoty „[X, Y]“ pro pozici na obrazovce mohou ve výsledku vytvořit jiný vzhled na různých displejích, případně omezit velikost okna.
11
Hlavní okno
Po spuštění aplikace se zobrazí okno, které obsahuje rolovací seznam se stromovou strukturou ukazující hierarchii uvnitř dokumentu. Každá položka v seznamu obsahuje menu vyvolatelné dlouhým stiskem položky. Menu by mělo obsahovat možnost vymazání nebo editování dokumentu. Krátký poklik na položku zapne jiné okno. Pokud dokument obsahuje text, tak se otevře zobrazovací okno. Pokud je dokument prázdný, otevře se okno editace dokumentu. Hlavní okno bude mít také vlastní menu vyvolatelné hardwarovým tlačítkem telefonu. Menu obsahuje položky synchronizace a změny databázového souboru. Každá položka seznamu má ikonku nalevo. Podržením ikonky je aktivována možnost řazení. Položka se zařadí tam kde ji uživatel pustí. Pomocí hardware tlačítka lupy se aktivuje vyhledávácí box nahoře. Tlačítka v okně slouží pro vytvoření nového dokumentu a pro posouvání stránek seznamu. Viz obrázek 6 na návrh hlavního okna.
Obrázek 6: Hlavní okno aplikace (s kontextovým menu nad položkou nalevo)
Okno editace
Okno editace obsahuje textová pole pro jméno dokumentu (či jeho části) a pro jeho obsah. Dále jsou zde tlačítka Save a Cancel, jejichž význam není třeba popisovat. Pokud je označen jakýkoli text uvnitř obsahové části, je možnost na tomto konkrétním místě dlouhým dotykem zavolat možnost vytvoření hypertextového odkazu na jinou položku nebo na poznámku, kterou je nutné vytvořit. Návrh editačního okna je na obrázku 7 na vedlejší straně.
12
Obrázek 7: Editační okno Prohlížení dokumentu
Na obrázku 8 je okno prohlížení dokumentu, které nabídne rychlou navigaci pomocí tlačítek Up, Home, Next a Previous. Lupou lze aktivovat vyhledávání, které by mělo po vyhledání skočit na hledanou položku a zobrazit všechny výskyty hledaného textu. Dále je zde tlačítko pro vyhledávání ve všech dokumentech. Toto okno nabídne rychlé stránkování pomocí rychlých tahů prstem do stran. Kliknutí na hypertextový odkaz provede skok na cíl odkazu, pokud existuje. Případně je zobrazeno dialogové okno s poznámkou. Dialogové okno nabízí i rychlou editaci poznámky.
Obrázek 8: Okno prohlížení dokumentu IMAP
Okno IMAP synchronizace obsahuje textová pole pro zadání přístupových údajů a jméno synchronizovaného IMAP adresáře. Viz obrázek 9 na další straně.
13
Obrázek 9: Okno IMAP synchronizace Odkazy a poznámky
Okna pro vybrání cíle odkazu nebo pro vytvoření poznámky nabízí pouze tuto jedinou funkci. Cíl odkazu bude vybrán ze seznamu položek, nebo je žádost o vytvoření odkazu stornována. Poznámka se napíše do textového pole a potvrdí či stornuje. Tyto okna by měla být téměř identická s hlavním oknem a analogicky s oknem editace dokumentů.
3.3.3 Návrh architektury Protože předmětem této práce je vysoce interaktivní aplikace, bylo by nejspíše vhodné využít softwarovou architekturu MVC, ale ukázalo se, že MVC není nejlepší architekturou pro Android. Android API obsahuje třídy pro práci s uživatelským rozhranním. Každé okno aplikace je tvořeno instancí třídy, která je potomkem třídy Activity, která se stará o zobrazování a o přidělení ovládacích prvků zobrazovaným objektům. Dialogová okna jsou tvořeny instancí třídy Dialog, či jejími potomky. Třída Activity slouží jako View i Controller, takže by vzor MVC nebyl přesně dodržen, proto ExtbrainReader nepoužívá architekturu MVC. ExtbrainReader by měl oddělovat datovou vrstvu od presentační vrstvy několika způsoby. Příkladem jsou rolovací seznamy, do kterých se data vkládají pomocí prostředníka, který potřebná data získá z datové vrstvy. Tento prostředník se dá označit za část byznys vrstvy. O zobrazování grafických prvků této aplikace se starají výše popsané Android třídy Activity a Dialog, které se rovněž starají o volání dalších obrazovek a přijímání událostí od uživatele.
3.3.4 Softwarové moduly Každá obrazovka reprezentovaná Android třídou Activity by měla mít přístup ke svému specifikému modulu, který se stará o funkce, které aktuální obrazovka nabízí. Třídy náležící do určitého modulu se budou nacházet ve stejných balíčcích, aby tímto byla zavedena přehledná struktura.
14
Editace
Modul editace textů slouží k editaci dokumentů a poznámek. Modul umožní ukládat nebo stornovat změny, vytvářet hypertextové odkazy a nové poznámky i dokumenty. Do tohoto modulu se dá také zařadit slučování více verzí stejné zprávy při IMAP synchronizaci. Prohlížení
Modul prohlížení dokumentů slouží pro zobrazení aktuální části dokumentu na obrazovce, pro správu rychlé navigace a vytváření tabulky „poddokumentů“. Modul zároveň slouží pro zobrazování výsledků vyhledávání. Cíle hypertextových odkazů
Modul hledání by měl sloužit pro vyhledání cíle textových odkazů a pro předání výsledků Activity, která tento cíl zobrazí, pokud existuje. Zpracování HTML (XML)
Modul HTTP synchronizace se postará o vytvoření požadavku GET a na zadanou URL adresu tento požadavek odešle. Modul dále obsahuje třídy pro validaci staženého HTML textového řetězce, pro rozložení textu a postupného uložení struktury do databáze dle určené XML šablony (viz Příloha A). Tento modul zároveň umožňuje dokumenty ve struktuře dle šablony generovat. Práce s poštovním účtem
Modul IMAP synchronizace se stará o příjem přihlašovacích údajů k účtu elektronické pošty a o obousměrnou synchronizaci mezi emailovým účtem a databází na mobilním zařízení. Co položka v databázi, to email v emailové schránce. V databázi v mobilním zařízení jsou po první synchronizaci uložena data umožňující zrychlení další synchronizace se stejným účtem a adresářem, protože se stahují pouze celé nové zprávy pro uložení do mobilu a IMAP hlavičky dalších zpráv pro případné vyhledání smazaných položek a znovuobnovení. Přístup k datům a k SD kartě
Modul pro práci s SQLite databází umožňuje otevírání či vytváření databázových souborů a dále definuje SQL rozkazy ze skupin DDL (data definition language) pro definici a úpravu tabulek a DML (data manipulation language) pro manipulaci a vyhledávání dat. Modul dále pracuje s úložištěm.
Komunikace s datovým modulem Všechny moduly komunikují s posledním uvedeným databázovým modulem, protože přístup k těmto datům je vždy požadován. Přístup je přes prostředníka k databázi.
15
3.3.5 Životní cyklus obrazovek aplikace Android umožňuje přechod z obrazovky na obrazovku uvnitř i vně aplikace, respektive z jedné Activity na druhou. Je nutné nadefinovat, co se stane při přesunu z obrazovky A na obrazovku B. Pokaždé je zavolána metoda onPause(), která dle názvu obrazovku pozastaví. Android pak udržuje tuto obrazovku v paměti, dokud se na ni uživatel nevrátí, či ji úplně nevypne. Pokud je Activity v pozastaveném režimu a pomalu dochází operační pamět, tak hrozí, že Android obrazovku zrecykluje pro uvolnění paměti pro aplikaci s vyšší prioritou zavoláním metody onDestroy(), a tím by uživatel mohl přijít o neuložená data. Proto je nutné, aby byla data uložena, když je Activity pozastavena. Když se uživatel vrátí zpět na obrazovku A, tak je zavolána metoda onResume(), ve které se dají uložená data znovu načíst. Všechny výše vypsané metody jsou standardní metody Android třídy Activity, ale je nutné v každém potomkovi třídy Activity, kde každý potomek reprezentuje jednu obrazovku, tyto metody překrýt svojí implementací, respektive překrytím doplnit funkčnost a uvnitř zároveň zavolat metodu od supertřídy Activity. Každá Activity třída při prvním spuštění zavolá sekvenci metod onStart() a onCreate(). Překrývání druhé jmenované metody je základem programování pro Android.
3.3.6 Popis interakce mezi moduly Spuštění aplikace
Když je spuštěna aplikace, je spuštěna instance defaultní Activity třídy určené v hlavním konfiguračním XML, tj. MainActivity. Přechod mezi obrazovkami
Dle akcí uživatele, který si zvolí operaci, se aplikace přepíná mezi obrazovkami, přičemž se obrazovky (respektive dané Activity) na pozadí pozastaví metodou onPause(). Vyhledávání cíle odkazu
Modul vyhledávání přijme data od DocumentActivity, která slouží jako obrazovka pro čtení dokumentů, nalezne pomocí těchto dat cíl odkazu a výsledek pošle zpět. Editace
Modul editace je přístupný opět z hlavní obrazovky. MainActivity předá ID položky, kterou je editována, do okna EditActivity, které si pomocí datového modulu obstará data k aktuálnímu ID a zobrazí je v editačních textových polích. Pokud chce uživatel data uložit, tak EditActivity zadá příkaz pomocí databázového modulu a příslušný záznam je aktualizován. MainActivity je během této operace pozastavena, ale čeká na odpověď z EditActivity. Po přijetí odpovědi MainActivity provede po metodě onResume() metodu onActivityResult(). Tuto metodu je rovněž nutno překrýt aby navigační okno bylo informováno o stavu dokumentu a případně u něj změnilo ikonku. Nové dokumenty
V MainActivity lze vytvořit kompletně nový prázdný dokument. Po potvrzení zadá MainActivity příkaz do databáze pomocí databázového modulu a je vytvořen nový záznam v databázi.
16
Prohlížení dokumentů
Funkce prohlížení dokumentů a vnitřní rychlá navigace jsou součástí DocumentActivity. DocumentActivity zpracovává kliknutí na vnitřní hypertextové odkazy v dokumentech. V hlavním konfiguračním XML souboru má DocumentActivity definován filtr na konkrétní Intenty. Intenty neboli „úmysly“ slouží v Android aplikacích jako vstup a výstup z Activity. Kliknutí na hypertextový odkaz vytvoří Intent, pomocí kterého DocumentActivity zjistí ID položky, na kterou chce uživatel přejít. Pro nalezení tohoto ID je použit vyhledávací modul. ID je předáno databázovému modulu, který vytáhne správná data z databáze. Synchronizace pomocí HTTP
MainActivity umožní vyvolat dialog, který přijme URL adresu, ze které chce uživatel stáhnout XML text. URL adresa je předána HTTP synchronizačnímu modulu, který se postará o stažení, kontrolu a uložení dat do databáze, opět s pomocí databázového modulu. Interakce obrazovek a modulů
Většina modulů je svázána s Activity, se kterou pracuje. Obrázek 10 níže ukazuje interakce mezi obrazovkami, který zároveň naznačuje, jak se navzájem volají moduly. Jedná se o diagram stavů, který ukazuje aktuálně viditelnou obrazovku jako stav. Pokud není dle názvu Activity jasné k čemu slouží, viz kapitola 4.1.2, tabulka 4 pro upřesnění.
Obrázek 10: Stavový diagram obrazovek
17
18
Kapitola 4 Realizace Obsahem této kapitoly je popis implementace s velkým důrazem na nestandardní části. Nejprve bylo nutné vytvořit Android projekt v Eclipse Helios pod názvem ExtbrainReader.
4.1 Struktura aplikace 4.1.1 Konfigurační soubory Celá aplikace se skládá z balíčků obsahující Java třídy a z konfiguračních souborů XML. Tyto soubory jsou většinou uloženy v adresáři ExtbrainReader/res do příslušného podadresáře. Tabulka 3: Popis konfiguračních XML souborů
Adresář pro uložení konfiguračních souborů pro grafické rozvržení. Příklad viz podkapitola 4.3 Grafické uživatelské rozhranní. res/drawable Adresáře pro uložení veškerých externích grafických souborů jako třeba ikony. Těchto adresářů je více a jsou označeny ldpi, mdpi, hdpi. Tyto přípony určují, jestli jde o grafický soubor pro displej s nízkou, střední nebo vysokou hustotou pixelů na palec. Nutné je, aby obrázek (ikona atd.) byl uložen v drawable-mdpi reprezentující střední hustotu. Je velice vhodné doplnit i další adresáře o stejný obrázek, ale s menším či větším rozlišením do příslušných adresářů. Android tak ví podle displeje zařízení, na kterém běží, jaký má použít zdroj obrázku. Pokud je obrázek uložen pouze v drawable-mdpi, tak se Android snaží přepočítat velikost na menší či větší displej a tuto velikost upraví. Adresář, ve kterém jsou v tomto projektu uloženy dva soubory. Jeden res/values (strings.xml) definuje důležité hodnoty, z něhož nejdůležitější je název aplikace, případně popisy u vyhledávacích boxů. Soubory definující položky a ikonky veškerých menu. res/menu V rámci projektu je zde soubor (colors.xml) definující barvu některých res/color textových polí v závislosti na tom, jestli textové pole je aktuálně vybráno nebo ne. Zde je obsažen jediný soubor (searchable.xml), kde je definováno, odkud má res/xml vyhledávací box vyhledat popisy svých komponent. Zde je vlastně odkaz na již zmíněný strings.xml. res/layout
Jediný velice důležitý XML soubor (AndroidManifest.xml) je přímo v adresáři projektu. Obsahuje velice důležitá nastavení, určuje třeba minimální nebo doporučenou verzi Androidu pro běh aplikace, přístupová práva (tato aplikace kromě základních práv požaduje i přístup na internet a na externí úložiště), definuje jednotlivé Activity včetně modu spuštění, defaultní Activity a Activity pro zpracovávání dat z vyhledávacího boxu.
19
4.1.2 Java balíčky Každý modul aplikace je ve svém balíčku. Níže je rozepsána balíčková struktura aplikace. Základním balíčkem, který tyto balíčky obsahuje, je net.extbrain.app.ExtbrainReader. Tento tečkový zápis je standardem jmenování balíčků při implementaci pro Android. Pro další popis je použit název ExtbrainReader. Tabulka 4: Popis Java balíčků
ExtbrainReader
ExtbrainReader.Adapters
ExtbrainReader.Database
ExtbrainReader.Editation ExtbrainReader.Widgets
ExtbrainReader.IMAP ExtbrainReader.HTTP ExtbrainReader.Search ExtbrainReader.Dialogs
Tento balíček obsahuje všechny ostatní balíčky obsahující moduly aplikace a všechny třídy Activity, jmenovitě MainActivity pro hlavní obrazovku, SyncActivity pro synchronizaci přes IMAP, LinkActivity pro vytváření odkazů, DocumentActivity pro prohlížení dokumentů, EditActivity pro editaci dokumentů a SearchActivity pro zobrazení výsledků full-textového vyhledávání. Balíček obsahující podtřídy Android třídy Adapter sloužící pro komunikaci mezi rolovacími seznamy a datovou vrstvou. MyEfficientAdapter slouží pro hlavní navigační seznam v MainActivity a pro seznam cílů pro textový odkaz v LinkActivity. SearchAdapter slouží pro seznam vyhledaných dokumentů. Balíček obsahuje třídu pro práci s databází, která funguje jako prostředník mezi databází a aplikací. Další třídy se starají o přípravu pro databázové soubory na SD kartě a pomocné práce s úložištěm. Balíček pomocných tříd při editaci textů. Nachází se zde i třída pro trojcestné slučování různých verzí dokumentů. Balíček obsahuje třídu reprezentující grafický prvek rolovací seznam, který je rozšířen o funkci přetahování položek. Balíček obsahující třídy, které zprostředkovávají IMAP synchronizaci. Zde jsou třídy pro HTTP synchronizaci a práci s HMTL dokumenty. Pomocný balíček obsahující třídu, která vyhledává cíle hypertextových odkazů. Balíček Dialogs obsahuje třídy definující většinu použitých dialogů v aplikaci.
4.1.2 Diagramy tříd vybraných balíčků Obrázky 11 a 12 na další straně ukazují, z čeho se skládají balíčky HTTP a Adapters. HTTP balík slouží jak pro import, tak i export dokumentů. Importuje se ze souborů z webu pomocí HTTP GET. Oproti zadání je přidána možnost přímého importu ze souboru. Pokud DocumentImporter dostane parametr fileName = null, tak je zavolán HTTP požadavek. Když má fileName nenulovou hodnotu, tak se ExtbrainReader pokusí importovat data ze souboru. Třídy z Adapters slouží pro napojení dat na rolovací seznam a jejich zobrazení.
20
Obrázek 11: Diagram tříd balíku HTTP
Obrázek 12: Diagram tříd balíku Adapters
21
4.2 Popis vybraných částí aplikace 4.2.1 Práce s SQLite databází Pro to aby uživatel mohl používat aplikaci, je nutné, aby měl vloženou SD kartu, protože veškeré databázové soubory budou uloženy zde. Uživatel bude moci vzít konkrétní databázový soubor, který předtím v aplikaci ExtbrainReader vytvořil, vložit ho do jiného zařízení a pomocí ExtbrainReader ho otevřít. Uživatel si rovněž v této aplikaci může zvolit adresář, kam chce soubory ukládat. Soubory budou značeny příponou .sqlite. Pro práci s databází SQLite je vytvořena třída DB, která se stará o vytváření či otvírání databázových souborů a jsou zde definovány všechny potřebné SQL příkazy pro manipulaci s daty. Tato třída funguje jako Content Provider, v tomto případě to znamená, že pouze zpřístupňuje data z jiné vrstvy. Třída DB obsahuje veškeré definice DML SQL příkazů a vnitřní třídu DatabaseHelper, která se stará o načítání databáze ze souboru, její otvírání a zavírání, a také vytváření nových souborů databáze. Do této podtřídy patří veškeré DDL příkazy SQL. I když v rámci aplikace ExtbrainReader kvůli jejímu typu moc nezáleží na bezpečnosti, tak jsou DDL příkazy definovány tak, aby byly odolné proti SQL Injection útokům. Toho lze dosáhnout vložením otazníku do SQL příkazu jako cíl klauzule WHERE a přidáním správného požadavku jako další parametr metody rawQuery(). Viz zdrojový kód 1. public Cursor getImapFolderData(String folder){ Cursor cursor = db.rawQuery("select * from IMAPsupport where folder = ?", new String[]{folder}); if (cursor != null) { cursor.moveToFirst(); } return cursor; }
Zdrojový kód 1: DML SQL příkaz vs SQL Injection
4.2.2 Seznamy Seznamy reprezentované Android třídou ListView jsou pouze vizuální reprezentací. Data pro zobrazení jsou u ListView určena speciálními Android třídami Adapter, ve kterých lze definovat, jak budou vypadat řádky seznamu a odkud mají brát data k zobrazení. Pro hlavní okno s navigačním seznamem je vytvořena třída MyEfficientAdapter, která je velice vhodná pro mobilní zařízení. Existuje mnoho typů už definovaných adaptérů, ale většina pracuje neefektivně při zobrazování nových řádků. Efektivní Adapter
Neefektivně ve výše zmíněném případě znamená, že při každém zobrazeném řádku seznamu je pomocí Android třídy Inflater z XML souboru načtena grafická struktura řádku jako instance Android třídy View. Tento proces je relativně náročný a je to poznat na spotřebě energie baterie. MyEfficientAdapter pracuje rozdílně, pomocí třídy Inflater získá z XML souboru data pouze na jednu celou obrazovku seznamu a při rolování recykluje předchozí View s tím, že ho aktualizuje. Dalším výsledkem je o hodně rychlejší reakce seznamu při rolování. 22
@Override public View getView(int position, View convertView, ViewGroup parent) { ViewHolder holder = null; if (convertView == null) { convertView = inflater.inflate(R.layout.row, null); holder = new ViewHolder(); holder.imageopen = (ImageView) convertView .findViewById(R.id.imageopen); holder.text = (TextView) convertView.findViewById(R.id.text); holder.selectivetext = (TextView) convertView .findViewById(R.id.selectivetext); convertView.setTag(holder); } else { holder = (ViewHolder) convertView.getTag(); } holder = this.setHolderParameters(holder, position); RelativeLayout rel = (RelativeLayout) convertView; rel.setPadding(cursor.getInt(3) * 13, 0, 0, 0); return convertView; }
Zdrojový kód 2: MyEfficientAdapter – metoda getView() Zdrojový kód 2 ukazuje, jak MyEfficientAdapter překrývá rodičovskou metodu getView() tak, aby volání této metody při rolování seznamu recyklovalo předchozí instance třídy View. Tato metoda je volána automaticky, když je třeba vykreslit další položku seznamu. Než je zaplněna celá část seznamu viditelná na displeji, tak je volána podčást, kde convertView je null a pomocí Android definované metody setTag() je uložena „vzpomínka“ aktuálního convertView dle atributů proměnné holder. Jakmile je třeba načíst položku, která dosud nebyla zobrazena, tak je tato „vzpomínka“ vyvolána (getTag()) a je z ní vrácena instance třídy ViewHolder. Protože holder už zná z minula reference na všechny své součásti, nemusel si je vyhledat v XML souboru. Řazení v seznamu
Základní ListView neumožňuje tzv. Drag and Drop („přetáhni a pusť“), které je třeba pro řazení seznamu tahem. Pro tuto možnost je vytvořena třída MyListView jako potomek ListView, která volá metody rozhranní DragListener, DropListener a HighlightListener. Tyto rozhranní deklarují metody, co se má stát během tažení a puštění tažené položky. Hlavní okno MainActivity, které MyListView obsahuje, přiřadí MyListView instance pomocných anonymních vnitřních tříd implementujících tyto rozhranní. Toto přiřazení je provedeno při vytvoření MainActivity v rámci metody onCreate(). Jakmile dojde k řazení, tak MyListView zneviditelní původní položku a vytvoří její kopii pod prstem uživatele. Při umístění položky MyListView pomocí jedné z výše uvedených anonymních tříd zavolá MyEfficientAdapter, který implementuje rozhranní DropListener. Ten následně metodou onDrop() zajistí, aby se položka zařadila jak na displeji, tak i v databázi. Při řazení tahem se zvýrazní pravděpodobná pozice umístění před puštěním položky. Lze nejen řadit, ale i zanořovat, respektive přiřadit poddokument k dokumentu. MyListView zobrazuje u každé položky ikonku, která slouží jako informace o tom, jestli je dokument prázdný nebo ne. Ikonka také slouží jako startovní pozice pro chycení položky při řazení.
23
Na obrázku 13 je zobrazen sekvenční diagram, který popisuje, co se děje při puštění položky nad cílem.
Obrázek 13: Sekvenční diagram umístění položky
4.2.3 IMAP synchronizace IMAP synchronizaci zpřístupní třída ImapSyncManager, která přijme přihlašovací údaje z okna SyncActivity. Poté, co jsou data přijata, následuje pokus o připojení k emailovému účtu. Po úspěšném připojení si aplikace vymění data s emailovým serverem tak, aby na obou stranách byla shodná aktuální data. Při synchronizaci se zkontroluje obsah zadaného poštovního adresáře a případné nové zprávy jsou staženy. Poté jsou nahrány na poštovní server nové zprávy z mobilu či tabletu. Pokud existují dvě verze jedné zprávy v mobilu a v IMAP adresáři, tak dojde ke sloučení zpráv v jednu do nejaktuálnější verze. K tomuto pomáhá ukládání poslední společné verze dokumentu. Jakmile jsou dohromady tři různé verze textu, tak proběhne tzv. Three-Way Merge („trojcestné sloučení“). Pro tuto funkci je použita knihovna diff-match-patch [8]. Výsledkem je ideálně co nejpřesnější aktuální verze obsahující všechny změny. Mohou nastat konflikty, protože se obě verze, jak na poštovním serveru, tak v zařízení, mohou lišit od originálu ve stejném místě. Toto je možné např. synchronizací poštovního účtu s jiným zařízením obsahujícím stejný dokument (stejný dle unikátního identifikátoru). Protože mohou nastat konflikty, je nutné, aby uživatel předem určil, jakou verzi dokumentu v rámci konfliktů chce jako aktuální, pomocí zaškrtávacího tlačítka v SyncActivity. Pro práci s poštovním serverem byla využita knihovna Java Mail API [9]. Nebyla použita oficiální verze této knihovny, protože oficiální plnohodnotná verze Java Mail API používá komponenty AWT, které s Android nejsou, nebo během vývoje nebyly, kompatibilní. Port této knihovny pro Android jsou modifikované JAR balíčky mail, activation a additional. Balíček mail.jar poskytuje nutné třídy pro práci s poštovním účtem, activation.jar poskytuje třídy z Java Activation Framework a additional.jar nahrazuje závislosti mezi zbytkem Java Mail a AWT komponentami. Tato synchronizace může být časově náročná. 24
Protože Android násilně ukončuje všechny aplikace, které se dlouho neozývají, tak by mohl byl problém, kdyby synchronizace probíhala v primárním vlákně. Proto IMAP synchronizace běží na jiném vlákně. Obrázek 14 na další straně popisuje konkrétní interakce mezi třídami během synchronizace.
Obrázek 14: Sekvenční diagram IMAP synchronizace Poznámka k obrázku 14:
Na obrázek se nevešla třída DB a interakce mezi jí a třídami ImapSyncManager a ImapMessageExtractor. Interakcí je mnoho, proto by byl obrázek velice nepřehledný, nicméně jde jen o přístup k databázi pomocí předpřipravených příkazů SQL. Označení <<metaclass>> ImapUtil značí že jde o třídu, která poskytuje pouze statické metody, které jsou během synchronizace volány.
4.2.4 HTTP synchronizace HTTP synchronizaci provádí třída HtmlDocumentExtractor, která přijme URL adresu z dialogu v MainActivity okně, a s pomocí dalších pomocných tříd provede HTTP GET požadavek na server. Stáhne HTML texty vnořené v XML řetězci jako obsah sekcí CDATA, aby nedošlo k chybám při parsování entit. XML řetězec je následně podle šablony struktury dokumentu uložen po HTML částech do databáze. Při extrakci dat je ještě kontrolována struktura XML, jestli je ve formátu šablony. Formát šablony viz příloha A. Veškerá práce s XML soubory probíhá na jiném vlákně. Aktivně je využíván DOM parser. Na obrázku 15 na další straně je sekvenční diagram znázorňující tuto synchronizaci.
25
Obrázek 15: Sekvenční diagram HTTP synchronizace
4.2.5 Hypertextové odkazy a formátování textů Pro zobrazování textů aplikace hojně využívá Android textový prvek TextView. V základu TextView neumožňuje klikání ani formátování textů, pokud je mu jako text přiřazen objekt typu String. Pomocí Android třídy Html lze HTML String převést do objektu Spanned, který už bere v úvahu formátování. Formátování je určeno HTML kódem dle formátovacích značek. Kvůli funkci formátování byl HTML vybrán jako zdrojový kód dokumentů. TextView reaguje na jakýkoli textový odkaz uvnitř Spanned objektu, který byl vytvořen pomocí značky
. Pomocí předpony textového odkazu TextView ví, co má udělat při kliknutí na odkaz. Typické jsou reakce na odkazy typu „mailto//:“ nebo „http//:“. Kliknutí na takovýto odkaz vyvolá Intent a Android otevře vhodnou aplikaci, která tento Intent může použít jako vstup. Protože požadavkem na tuto aplikaci je zpracovávání vnitřních křížových odkazů, je nutné definovat svoji vlastní předponu. Předponou aplikace ExtbrainReader je „ext.reader//:“. Aby Android věděl, jaká aplikace či dokonce Activity má Intent přijmout, tak je v AndroidManifest.xml v elementu DocumentActivity definován filtr IntentFilter, který odesílá všechny odfiltrované Intenty do DocumentActivity. Ta si pomocí třídy LinkJumper zjistí cíl odkazu uvnitř aplikace. Pokud tento cíl existuje, tak je cíl ihned zobrazen. Pokud neexistuje, je uživatel obeznámen Toast zprávou. Toast zprávy jsou v aplikaci použity ve více případech. Jsou to rychlé zprávy které na pár sekund probliknou uprostřed obrazovky.
4.2.6 Vyhledávání Aplikace umožňuje vyhledávání uvnitř i vně dokumentů. Vyhledávání vně dokumentů je implementováno jako standardní Android vyskakovací box pod horní hranou displeje. Vyhledávací box pomocí potvrzovacího tlačítka lupy zavolá Intent obsahující flag ACTION_SEARCH. Bylo nutné nadefinovat v AndroidManifest.xml do elementu reprezentující SearchResultActivity IntentFilter, který zpracovává vyhledávací Intenty pocházející z této aplikace. Zároveň je nutné nadefinovat, odkud lze zavolat Android
26
vyhledávací box. Nadefinovány jsou MainActivity a SearchResultActivity, které obě plní funkci navigačního seznamu, a proto se intuitivně hodí pro příjem vyhledávání.
4.3 Grafické uživatelské rozhranní Tato podkapitola obsahuje příklad konfiguračního XML souboru rozvržení grafiky, obrázky z hotové aplikace a jejich popis.
4.3.1 Konfigurační XML GUI
Zdrojový kód 3: searchlayout.xml
Zdrojový kód 3 výše definuje rozvržení grafiky na obrazovce SearchResultActivity, která zobrazuje seznam nalezených výsledků vyhledávání. Jako kořenový element je zde definován RelativeLayout (relativní rozvržení), který určuje, že vše uvnitř bude zobrazeno relativně, tzn. že pozice objektů budou definovány pouze vzájemnou polohou. Nejsou žádné pevně stanovené hodnoty výšky a šířky, ve které se zobrazí levý horní roh grafického prvku. Viz atributy elementu ListView (rolovací seznam) ve Zdrojovém kódu 3. Atributy jsou definovány ve jmenném prostoru android, takže např. atribut layout_alignParentTop s hodnotou true určuje, že ListView má být přilepen k horní hraně svého rodiče, v tomhle případě RelativeLayout. Protože je zde obsažen i podobný atribut končící názvem Bottom, tak to znamená, že ListView se má zobrazovat na celé obrazovce, pokud je dostatek položek v seznamu. Atributy layout_width a layout_height obsahují hodnotu určující, jestli se grafický prvek zobrazí tak, že se roztáhne na výšku (šířku) svého rodiče (hodnota „fill_parent“), nebo pouze do velikosti, jakou vyžaduje obsah uvnitř grafického prvku (hodnota „wrap_content“). Tento XML soubor je velice jednoduchý, všechny ostatní grafické konfigurační soubory jsou několikanásobně větší. Kdyby v kořenovém elementu byly kromě ListView ještě další elementy, tak by bylo nutné definovat pomocí atributu layout_below (top, left, right) relativní pozici u každého elementu. Všechny XML soubory s definicí grafického rozvržení využívají RelativeLayout pro podporu co nejvyššího spektra velikostí a hustoty zobrazení displejů. Každý grafický prvek v XML má definováno své id, pomocí kterého lze zpřístupnit grafický prvek pro práci v Java třídách.
27
4.3.2 Výsledné grafické uživatelské rozhranní Na obrázcích níže jsou ukázány nejdůležitějších obrazovek ExtbrainReaderu. Obrázek 16 znázorňuje hlavní navigační obrazovku, na kterou se uživatel dostane, když zapne aplikaci. Uprostřed je aktivováno menu nad položkou. Napravo je zobrazeno menu vyvolatelné hardware tlačítkem menu.
Obrázek 16: Hlavní okno
Obrázek 17 ukazuje, jak vypadá prohlížení dokumentů. Na levé straně obrázku je dokument po vnitřním vyhledávání. Napravo je vidět právě zobrazená poznámka.
Obrázek 17: Prohlížecí okno
28
Na obrázku 18 je zobrazeno editační okno. Na pravé straně je vyvoláno menu umožňující vytvořit poznámku nebo hypertextový odkaz. Ze zvoleného textu se následně stane příslušný odkaz.
Obrázek 18: Editační okno
Okno pro zadání údajů pro IMAP synchronizaci je zobrazeno na obrázku 19. Zaškrtávací tlačítko v levém dolním rohu slouží pro určení, zda uživatel chce v případě konfliktů zvolit verzi dokumentu, kterou má v zařízení, a nebo na poštovním účtu.
Obrázek 19: Okno pro IMAP údaje
29
4.4 Použité externí knihovny Následující tabulka 5 popisuje veškeré během vývoje v projektu použité externí knihovny. Tabulka 5: Seznam použitých knihoven Název
Licence
Popis
Android API 8
Apache License 2.0
Jsoup diff-patch-match
MIT License Apache License 2.0
Java mail API (port pro Android)
GNU GPL v2
knihovna s Android třídami (součástí Android SDK) HTML parser knihovna pro rozdílové a slučovací práce s texty knihovna pro práci s mailovým účtem
Odkaz http://developer.android .com/sdk/ android-2.2.html http://jsoup.org/ http://code.google.com/ p/google-diff-matchpatch/ http://code.google.com/p /javamail-android/
30
Kapitola 5 Testování Obsahem této kapitoly jsou veškeré testy, které byly během vývoje prováděny. Jsou zde zahrnuty testy uživatelského rozhranní a funkčnosti. Výkonnostní testy prováděl autor této práce. Další testy prováděl testovací tým, který se skládal z lidí, kteří už dříve pracovali na projektu Extbrain při tvorbě jiných aplikací, a další nezávislí uživatelé. Funkčního testování se účastnil i autor, jeho přátelé a vedoucí práce. Testování probíhalo na Android emulátoru a na různých reálných zařízeních včetně tabletu.
5.1 Testování uživatelského rozhranní Zde jsou popsány první nápady na některé aspekty uživatelského rozhranní a následná změny na aktuální podobu dle vyjádření testerů. Pro testery byl vytvořen testovací dokument, který je přepracovanou verzí části dokumentu z [5]. Tento dokument je přiložen i pro hodnotící této práce. Dokument je příkladem, jaké části HTML dokáže Android textový prvek TextView zobrazit, a také co zobrazit nedokáže. Dokument zároveň ukazuje limity aplikace při načítání některých částí v rámci emulátoru, protože ty největší části dokumentů se načítaly několik vteřin.
5.1.1 Řazení hlavního navigačního seznamu Původní stav
V úvodních stádiích vývoje bylo řazení navigačního seznamu řešeno jinak, než v aktuální verzi. Implementačně jsou všechny použité verze řazení téměř identické, ale funkčně se chovaly jinak. V úvodu řazení fungovalo tak, že uživatel chytil ikonku položky seznamu a jakmile položku pustil, tak se položka umístila nad nebo pod položku, na které uživatel taženou položku pustil. Směr posunutí nad nebo pod se určil dle směru, odkud uživatel položku táhnul. Vnořování dokumentu do dokumentu se původně realizovalo puštěním tažené položky přímo nad ikonkou cílové položky. Toto vše se uživatelům zdálo zmatečné. Od testerů přišla žádost na nápravu a přání, aby aplikace ukazovala, kam se položka přesune. Stav po úpravě
Nový systém řazení sice stále požaduje pouštění tažené položky nad jinou položkou, ale celkově je realizován jinak. Při tažení aplikace zvýrazňuje pozici, kam se položka s velkou pravděpodobností přesune. Položky, nad kterýma uživatel táhne taženou položku, jsou průběžně zvýrazňovány. Když se zvýrazní střed, znamená to, že tažená položka se vnoří do cílové. Horní nebo dolní osvícená strana analogicky ukazuje jakým směrem se položka přesune, když nejde o vnoření. Nelze rodičovský dokument přiřadit pod svého potomka. Po přesunu dokumentu, který obsahuje další části, jsou rovněž přesunuty na správnou pozici i veškeří potomci. Rovněž pro přehlednost jsou použity jiné ikony od různých autorů známých pouze pod přezdívkami z [10], které napovídají, jestli je dokument prázdný, nebo jestli je nadřazený jinému dokumentu. 31
5.1.2 Dialogová okna Původní stav
Ze začátku aplikace nevyužívala dialogová okna. Testeři namítli, že se dialogy hodí například při editaci souborů. Některé aplikace pro Android se uživatele ptají, co mají udělat, když uživatel stiskne tlačítko „zpět“. ExtbrainReader vždy zrušil provedené úpravy bez zeptání. Stav po úpravě
Aplikace používá více různých dialogů s mnoha funkcemi. Speciální dialog, zvaný ProgressDialog, je použit při delších operacích. Zobrazuje kolečko nahrávání, které se točí. Uživatel vidí, že aplikace pracuje, a zároveň dialog slouží k zamezení nechtěných interakcí uživatele při těchto delších operacích. Během synchronizací je tento dialog zobrazen a jsou blokovány veškeré akce, které by mohly ovlivnit konzistenci databáze.
5.1.3 Rychlá navigace při čtení dokumentů Původní stav
Původní verze navigace byla řešena jako textová pole obsahující hypertextové odkazy. Testerům přišlo toto ovládání nezvyklé. Rovněž se jim nelíbilo zobrazování poznámek ve stejném okně jako dokumenty. Stav po úpravě
Navigace je řešena obrázkovými tlačítky s ikonkami třetích stran [10], které ovládají skoky na předchozí, další, nadřazenou, nebo kořenovou položku. Přesuny na vedlejší položky lze rovněž realizovat rychlým táhnutím prstem do boků displeje. Poznámky se zobrazují ve formě dialogu.
5.1.4 Další aspekty čtecího okna Původní stav
Vnitřní vyhledávání pouze vyznačilo nalezené texty a vyhledávací okno nebylo možné aktivovat stisknutím tlačítka „lupy“. Stav po úpravě
Aktivace vyhledávání je nyní uživatelsky přívětivější. Obrazovka se přesune na první nalezenou položku při vyhledávání. Opětovné stisknutí softwarového tlačítka „lupy“ provede skok na další případnou shodu.
32
5.1.5 Jiné aspekty GUI Původní stav
Testeři se nevyjádřili kladně k původní verzi vkládání textových odkazů, které fungovalo tak, že uživatel vybral možnost vložení odkazu a na další obrazovce musel kromě cíle odkazu napsat i popisek odkazu. Neucelený vzhled aplikace byl rovněž další výtkou uživatelů. Rovněž byl vznesen požadavek na zobrazení posledního dokumentu po spuštění aplikace. Stav po úpravě
Odkazy se vkládají po zvolení textu, ze kterého se po vytvoření stane popisek aktivního odkazu. Aplikace se snaží celkově dodržovat stejný vzhled na všech obrazovkách, převážně světlé zbarvení a stejné písmo.
5.2 Funkční testování Tato část kapitoly popisuje testování funkcí programu s důrazem na to, proč a jak se změnila implementace několika funkcí od původně smýšlené podoby.
5.2.1 IMAP synchronizace První verze
V původním návrhu a následně i první realizaci IMAP umožňoval pouze jednostrannou synchronizaci, což bylo velmi nepraktické, protože by tato synchronizace byla v podstatě málo nebo namáhavě využitelná pro uživatele, který by si první musel na poštovní účet poslat maily, které by dodržovaly určitou strukturu a musely by mít IMAP identifikační hlavičky. Druhá verze
Zde už fungovala obousměrná synchronizace, ale na poštovním serveru byly dokumenty ukládány v takovém formátu, který pro každý rodičovský dokument vytvořil jiný IMAP adresář a následně mohla celá struktura dokumentů vypadat velice neefektivně a hlavně byla velmi neefektivní práce s poštovním serverem. Také nemohlo být v žádném případě zaručeno správné pořadí dokumentů při uložení do databáze. Testeři namítli, že by se měl celý obsah aktuální databáze uložit do jediné IMAP složky na poštovním serveru a nějak zaručit, aby bylo možno zachovat pořadí a zároveň zanoření dokumentů. Konečná verze
Aktuální verze IMAP synchronizace ukládá maily do zvoleného adresáře, poznámky do podadresáře, a je přidán i kontrolní mail obsahující pořadí dokumentů v databázi mobilního zařízení. Záleží jak moc uživatel modifikuje pořadí, případně smaže některé položky v telefonu nebo v poštovním účtu, aby se po synchronizaci stáhly smazané položky z poštovního účtu a zařadily se na správnou pozici. Pokud už je struktura dokumentů velice 33
rozdílná, tak není zaručeno pořadí dokumentů, jako před synchronizací. Tato verze synchronizace je efektivnější, rychlejší a méně náročná na přenos dat, což je velice vhodné z důvodu vysokých cen internetu v mobilu. Navíc stále existuje FUP.
5.2.2 Přenositelnost dokumentů Požadavkem uživatelů bylo přidání nových funkcí se kterými se při zadání práce nepočítalo. Výsledkem je přidání funkce importu dokumentů ze souboru bez nutnosti stahování takovýchto souborů z webu. Rovněž se původně nepočítalo s možností změny databázového souboru. Výsledkem je možnost výběru databázového souboru, ale pouze na SD kartě. Tato možnost následně při výkonnostním testování vytvořilo podstatnou slabinu aplikace, kterou emulátor nedokázal zachytit. Pro další informace o této slabině viz podkapitola 5.3.1. Zobrazování HTML Android grafický prvek TextView nedokáže interpretovat mnoho HTML značek. Do očí bijícím příkladem jsou rozsypané texty tam, kde by měla být tabulka. Oproti tomu formát textů zvládá TextView bravurně. HTML je převáděno do formátovacího textu pomocí třídy a metody Html.FromHtml(). Existují i jiné možnosti, jak formátovat text, ale výše zmíněná funkce se hodí i kvůli podpoře hypertextových odkazů.
5.3 Výkonnostní testování Požadavkem na tuto aplikace je možnost práce s velice rozsáhlými dokumenty, ale i ExtbrainReader má určité limity nalezené při testech. Některé limity se daly posunout dál pomocí jiného způsobu implementace.
5.3.1 Databáze Byly testovány schopnosti databáze a nalezeny případné možnosti, jak databázové operace urychlit. Byl proveden zátěžový test s více než 200 tisíci řádky v databázi. Obsahem databáze byla část XML souboru obsahující zálohu části databáze ze serveru Wikipedia [11]. Soubor, který měl velikost 180 MB, byl z části přeložen na dávku SQL vkládacích příkazů. Externě pomocí nástroje sqlite3, který je součástí Android SDK, byla vytvořena testovací databáze a spuštěna dávka vkládacích příkazů uvnitř. Tato databáze byla testována ExtbrainReaderem v emulátoru, kde šlo procházet databázi relativně svižně díky optimalizacím databáze a selektivními dotazy na menší část dat. Cursory a transakce
Dotazy na SQLite databázi vracejí referenci na výsledky pomocí třídy Cursor. Tato třída ale umožňuje do paměti uložit pouze jeden megabajt dat, která obsahují adresy položek v databázi, ne položky samotné. ExtbrainReader zamezuje překročení maximální velikosti tím, že seznam položek, které se mají zobrazit, je načítán po stránkách po 50 řádcích. Při každém načtení jiné stránky je poslán dotaz databázi na dalších 50 řádků. Aby databáze nemusela provádět prohledání celé tabulky, je definován index hlídající sloupec pořadí. Aplikace si jen musí pamatovat hodnoty sloupce pořadí pro první a poslední položku každé stránky, aby mohla rychle přistupovat k další či předchozí stránce. Velké urychlení přineslo
34
i použití transakcí na více příkazů za sebou, protože SQLite v základu dělá transakci pro každý příkaz zvlášť. Commit operace je pomalá. Rychlost zápisu do databáze
Jak už bylo v podkapitole 5.2.2 naznačeno, tak práce s databází, která je uložena na SD kartě, může být na některých zařízeních slabinou ExtbrainReaderu. Protože si testeři přáli větší přenositelnost elektronických dokumentů, tak existuje již dříve zmíněná funkce výběru databázového souboru pouze z SD karty. Následkem je problém s pomalým zápisem na některé SD karty. Protože je mnoho výrobců hardwaru, který běží na platformě Android, tak existuje i více možných problémů na různých telefonech a tabletech. ExtbrainReader byl nejdéle testován na tabletu Point of View Mobii Tegra 10. Není to velice výkonný tablet, ale je určitě součástí středního proudu zařízení. Během tří testů, které byly provedeny zhruba jednou za měsíc, byly patrné nestálé a více negativní změny výkonu při práci s SD kartou. Synchronizace IMAP, která při stahování zpráv potřebuje zapisovat do databáze, při prvním testu přenosu velkého testovacího souboru [5] trvala minutu a půl. Během posledního nedávného testu trvala synchronizace téměř prázdného dokumentu s pár znaky více než tři minuty. Na stejném zařízení trvá zápis dlouho, ale našly se i chvíle, kdy byly reakce bleskurychlé. Oproti tomu čtecí operace jsou mnohonásobně rychlejší, než v emulátoru. Testeři k tomuto aspektu neměli žádné připomínky, takže je možné, že problém je ojedinělý nebo málo pravděpodobný pro další zařízení. Na mobilním telefonu pana vedoucího práce fungovala aplikace bez znatelného zpomalení zápisu. K jiným fyzickým zařízením neměl autor této práce přístup. Paměťové karty v budoucnosti
Sběr informací u přátel a u vedoucího této práce naznačil, že nejen Android, ale i ostatní konkurenční platformy mají problém při práci s daty na SD kartě u některých aplikací. V poslední době navíc výrobci pomalu ustupují od používání paměťových karet, které nahrazují větší interní pamětí v zařízeních. Příkladem budiž zařízení značky Apple, které paměťové karty nepodporují, a u budoucí generace tato podpora bude nejspíše chybět dál.
5.3.2 Práce s XML Původní implementace pro extrakci dat z XML využívala knihovnu Jsoup [7]. Během testů bylo zjištěno, že zpracovávání XML touto knihovnou je velice neefektivní, převážně paměťově. Nároky na paměť při práci byly enormní, takže velice často byla vidět výjimka outOfMemory. Maximální velikost dokumentů, které JSOUP v emulátoru zvládal, byla 180 KB. Využitá paměť dosáhlá při takto malém souboru přes 9 MB. Při exportu aplikace byl zprvu využit DOM parser, ale paměťově i výpočetně efektivnější bylo funkci přepracovat, aby rekurzivně nalepila text do třídy StringBuilder a následně uložila pomocí třídy BufferedWriter do souboru. Přepracována verze importu dat jak ze souboru, tak ze vstupního datového proudu získaného požadavkem HTTP GET, využívá DOM parser. Funkce je rychlejší a paměť při importu zhruba jednomegabajtového testovacího dokumentu nepřekročila 4.5 MB. Důvodem, proč byla nejdříve vybrána knihovna Jsoup, je snadná práce s HTML soubory. Finální verze využívající CDATA v XML souboru umožňuje v XML souborech uložit jakkoli strukturovaný text i při použití speciálních znaků nebo entit.
35
5.4 Shrnutí testování Veškeré požadavky výsledného produktu byly velice dobře formulované, takže většinu aspektů, jak u GUI, tak i u funkcí aplikace, nebylo nutné přepracovávat s výjimkou výše zmíněných situací. Na aktuální verzi byly názory testerů nejednoznačné, protože každý preferuje například vzhled aplikace a rozvržení tlačítek jinak. Veškeré jednoznačně chybně navržené věci byly přepracovány. Mezi opravenými věcmi bylo i pár drobností. Příkladem je třeba přednastavení cesty do aktuálního adresáře na SD kartě v dialogu. Návrh autora této práce je, aby byly zrušené veškeré možnosti práce s paměťovými kartami. Na místo toho je doporučeno využití databáze v hlavní paměti, protože dnešní paměťové možnosti jsou více než přijatelné a hlavní paměť je rychlejší.
36
Kapitola 6 Závěr Cílem této práce byl návrh a následná implementace aplikace ExtbrainReader, která by umožňovala práci s rozsáhlými strukturovanými dokumenty na mobilních zařízením běžících na platformě Android. Nejdůležitějšími požadavky byla možnost vytvářet a editovat dokumenty, přidávat si k dokumentům dodatečné informace, jako třeba poznámky a interní křížové hypertextové odkazy, a možnost si tyto dokumenty synchronizovat přes IMAP a přes HTTP. Neméně důležitým požadavkem bylo vytvoření přívětivého uživatelského rozhranní, které by umožňovalo aplikaci pohodlně ovládat pomocí dotykového displeje. Veškeré tyto požadavky byly splněny a bylo přidáno i pár dalších aspektů. Tyto aspekty byly objeveny při průzkumu podobných aplikací a při uživatelském testování. Aplikace se snaží dodržovat jakési konvence, které jsou dané ostatními podobnými aplikacemi, například zapamatování posledního otevřeného souboru a poslední čtené stránky dokumentu. Realizace aplikace byla náročnější, než byla má veškerá očekávání. Tato bakalářská práce je mojí první větší prací s platformou Android, která nebyla během začátku vývoje dostatečně zdokumentována. Během realizace jsem se postupně učil nové postupy pro implementaci aplikací pro Android dle toho, co bylo aktuálně třeba vyřešit, ale celkově mi tato platforma moc nesedla. Protože nejsem majitelem žádného zařízení s dotykovým displejem, natož s Androidem, tak jsem měl zpočátku malé možnosti testování aplikace. Nevěděl jsem, jak by mělo vypadat uživatelské rozhranní na telefonech s dotykovým displejem. Protože vývoj probíhal iterativně, tak se mi postupně podařilo dle připomínek testerů aplikaci vyladit do finální podoby. Přínosem ExtbrainReaderu oproti podobným aplikacím je možnost editace dokumentů, jejich synchronizace a možnost pracovat s dlouhými dokumenty, která byla umožněna jejich stromovým strukturováním v databázi. Nevýhodou oproti ostatním aplikacím je chybějící podpora PDF dokumentů, se kterou se v zadání nepočítalo. Práci na ExtbrainReaderu hodnotím smíšeně, pocity ze začátku vývoje byly při absolutní neznalosti platformy Android spíše negativní. Kdybych měl hodnotit podle posledního období, tak bych mohl být spokojen s tím co, jsem se během vývoje na takto rozsáhlém projektu naučil. Tvorba aplikace vyžadovala široké spektrum znalostí naučených během studia.
6.1 Možnosti vylepšení Pokud by někdo (nebo já) měl pracovat dál na aplikaci ExtbrainReader, tak bych navrhoval, aby se během dalšího vývoje zaměřil na větší možnosti strukturování a formátování textů, které není ideální kvůli nedostatečné podpoře interpretace HTML značek v textu, například tabulek. Aby aplikace mohla být více atraktivní pro běžné uživatele, tak je nutné, aby byla přidána podpora jiných standardizovaných formátů elektronických knih a podpora obrázků v dokumentech. Možnost prohlížení PDF dokumentů by byla znatelným vylepšením. Pro zaručení výkonnosti na více zařízeních by bylo vhodné umožnit pracovat s databází ve vnitřní paměti bez nutnosti mít paměťovou kartu. 37
38
Literatura a použité zdroje [1] Oficiální dokumentační stránka Android Developers[online].[cit. 18. 5. 2012]: http://developer.android.com/index.html [2] Stránka StackOverflow – rady při programovacích problémech[online].[cit. 18. 5. 2012]: http://stackoverflow.com/ [3] Domovská stránka s dokumentací SQLite[online].[cit. 16. 5. 2012] : http://www.sqlite.org/docs.html [4] Tutorial UML 2.0 od autorů Enterprise Architect[online].[cit. 16. 5. 2012]: http://www.sparxsystems.com/uml-tutorial.html [5] Mendel Cooper, Advanced Bash Scripting Guide[online].[cit. 1. 3. 2012]: http://tldp.org/LDP/abs/html/ [6] Lukáš Marek, Programování pro Android v příkladech[online]. [cit. 16. 5. 2012]: http://www.root.cz/clanky/programovani-pro-android-v-prikladech/ [7] Jonathan Hedley, Jsoup Java html parser[online].[cit. 1. 4. 2012]: http://jsoup.org/ [8] Neil Fraser, diff-match-patch library[online]. [cit. 2. 5. 2012]: http://code.google.com/p/google-diff-match-patch/ [9] Java Mail API – Android port[online]. [cit. 18. 5. 2012]: http://code.google.com/p/javamail-android/ [10] Find Icons[online].[cit. 18. 5. 2012]: http://findicons.com/ [11] Wiki Abstracts[online].[cit. 18. 5. 2012]: http://dumps.wikimedia.org/cswiki/20111026/cswiki-20111026-abstract.xml
39
40
Příloha A Šablona XML dokumentů pro HTTP synchronizaci
Obrázek A.1 - XML šablona pro import a export
41
42
Příloha B Seznam použitých zkratek CASE Computer-Aided Software Engineering CDATA Character data DOM Document Object Model EPUB Electronic publication GUI Graphic User Interface HTML HyperText Markup Language HTTP HyperText Transfer Protocol IMAP Internet Message Acces Protocol MVC Model View Controller PDB Palm Database PDF Portable Document Format SD Secure Digital SQL Structured Query Language UML Unified Modelling Language URL Uniform Resource Locator XHTML Extensible HyperText Markup Language XML Extensible Markup Language
43
