QI klient pro operační systém Android

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta QI klient pro operační systém Android Diplomová práce Vedoucí práce: Ing. Petr Jedlička, Ph.D. Bc. Ondřej Stehlík Brno 2014

2 Na tomto místě chci poděkovat vedoucímu práce, Ing. Petru Jedličkovi, Ph.D., za jeho cenné rady a čas, který mi vedením práce věnoval. Děkuji také společnosti it2b, s. r. o. za poskytnuté zdroje, bez kterých by nebylo možné aplikaci vyvinout. Mé poděkování rovněž patří Mgr. Radku Foltýnovi, za jeho nápady při vývoji mobilní aplikace a Ing. Jiřímu Šimkovi, za rady spojené s programování maker na straně aplikačního serveru QI.

3 Prohlašuji, že jsem tuto práci: QI klient pro operační systém Android vypracoval samostatně a veškeré použité prameny a informace uvádím v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 14. května

4 4 Abstract Stehlík, O. QI client for operating system Android. Diploma thesis. Brno The diploma thesis is focused on the design and implementation of the remote access to ERP system QI. The paper explains theoretical basics of the programming applications for Android platform, web services based on the SOAP protocol, the information system QI and development tool QI Builder. On the basis of the requirements the solution of mobile client is designed, implemented and tested. In conclusion, the achieved results are discussed as well as the future possibilities are presented. Keywords Android, information system QI, SOAP, QI Builder, remote access Abstrakt Stehlík, O. QI klient pro operační systém Android. Diplomová práce. Brno Diplomová práce se zabývá návrhem a implementací řešení vzdáleného přístupu do ERP systému QI. V práci jsou vysvětleny teoretické základy programování aplikací pro platformu Android, webových služeb založených na protokolu SOAP, informačního systému QI a vývojového nástroje QI Builder. Na základě požadavků je navrženo, implementováno a otestováno řešení mobilního klienta. Na závěr jsou dosažené výsledky diskutovány a navrženy možnosti dalšího vývoje. Klíčová slova Android, informační systém QI, SOAP, QI Builder, vzdálený přístup

5 OBSAH 5 Obsah 1 Úvod 7 2 Cíl práce 8 3 Technologický aparát Webové služby a SOAP Webová služba XML Protokol SOAP WSDL Android aplikace Platforma Android a její vývoj Programovací jazyk a vývojové nástroje Struktura projektu Podpora různých typů obrazovky Definice rozložení prvků Kontejnery a widgety Aktivity Seznamy Úložiště dat Vlákna Databáze SQLite a práce s daty v OS Android Databáze SQLite SQLite v OS Android Třída Cursor a třída ContentValues Informační systém QI a nástroj QI Builder Informační systém QI Architektura systému Distribuce a implementace QI Builder Makrojazyk QI QI webové služby Souhrn požadavků Obecný popis Funkční požadavky Nefunkční požadavky Analýza a návrh Datový model Systém Třída DatabaseManager

6 OBSAH Třída FormGenerator Třída InputManager Třída QiConnector Třída AppSettings Procesy Přihlášení uživatele Synchronizace databáze Vložení a odstranění položky Návrh uživatelského rozhraní Implementace Klient Systém identifikátorů atributů Parametrizace viditelnosti atributů Formulářová aktivita Výběrová aktivita Aktivita kalendáře a aktivita denních událostí Generování a parsování XML Komunikace s aplikačním serverem QI Server Podpora XML Implementovaná makra Testování 64 8 Diskuse 65 9 Závěr Literatura 67 A Diagramy aktivit procesů v systému 69 B CD se zdrojovými kódy aplikace a maker 72

7 1 ÚVOD 7 1 Úvod Rozvoj mobilních technologií umožnil jejich využití i v oblastech informačních systémů pro plánování zdrojů (ERP). Uživatelé se mohou prostřednictvím svých tabletů nebo chytrých mobilních telefonů k těmto systémům připojovat nezávisle na místě, na kterém se nachází. Tito uživatelé jsou pak závislí pouze na připojení k síti Internet, což pro většinu z nich nepředstavuje problém. Funkcionalita zmíněných informačních systémů je obvykle velmi rozsáhlá a bylo by proto složité a neefektivní mobilním zařízením plně nahrazovat desktopového klienta informačního systému. Lze spíše uvažovat o zprostředkování vybrané podmnožiny funkcí, které by uživatel ve svém mobilním telefonu nebo tabletu využil. Jedním z ERP systémů dostupných na českém trhu je informační systém QI. Výrobce tohoto systému ani jeho partneři v době psaní této práce neposkytovali svým klientům přístup k aplikačnímu serveru z mobilní aplikace a tato práce si dává za cíl tuto mezeru vyplnit. QI firmám poskytuje, stejně jako jiné ERP systémy, podporu pro výrobu, logistiku, sklady, účetnictví, správu majetku, obchod a marketing. Pro mobilní aplikaci byly vybrány funkce týkající se jednotlivých uživatelů a obchodních partnerů společnosti. Citlivou oblastí ERP systémů jsou v nich uložená data, která musí být nějakým způsobem zabezpečena proti zneužití. Při implementaci zmíněných klientů je třeba se zaměřit zejména na zabezpečení přenosu dat, který je uskutečněn prostřednictvím sítě Internet. QI za tímto účelem implementuje několik algoritmů, které je možné využít pro šifrování dat. Prvním a zcela zásadním bodem návrhu aplikace je samozřejmě volba platformy, na které bude aplikace spouštěna. V současné době vládne trhu mobilních zařízení platforma Android a významný podíl na trhu má také operační systém ios nebo Windows Phone. Vzhledem k dominanci systému Android bude mobilní klient informačního systému QI navržen a implementován právě pro tuto platformu.

8 2 CÍL PRÁCE 8 2 Cíl práce Cílem diplomové práce je umožnit vzdálený přístup do ERP systému QI prostřednictvím mobilní aplikace pro operační systém Android. Mobilní klient umožní uživateli spravovat své úkoly a kalendář v systému QI a poskytne přehled obchodních partnerů včetně správy jejich bankovních účtů, členů a jejich kontaktů. Programovým výstupem bude uživatelsky přívětivá, spolehlivá a bezpečná Android aplikace, do které se uživatel bude přihlašovat stejně jako do konkrétní instance systému QI. Aplikaci bude třeba navrhnout, implementovat a poté funkčnost ověřit ve firemním prostředí.

9 3 TECHNOLOGICKÝ APARÁT 9 3 Technologický aparát 3.1 Webové služby a SOAP Obsahem této kapitoly je popis webové služby a s ní souvisejícího protokolu SOAP a jazyka WSDL. Rovněž jsou zde představeny základy značkovacího jazyka XML, který ve sféře webových služeb často slouží k reprezentaci dat Webová služba Jak uvádí Snell (2002), webová služba je prostřednictvím sítě přístupné rozhraní k poskytovaným funkcím aplikace. Jedná se tedy o rozhraní mezi zdrojovým kódem aplikace (serveru) a zdrojovým kódem klienta. Jelikož je toto rozhraní abstraktní vrstvou, není nijak závislé na konkrétní platformě nebo programovacím jazyku. To znamená, že prostřednictvím jakéhokoliv programovacího jazyka, který webové služby podporuje, lze k těmto službám přistupovat. Je tak možné např. přistupovat k aplikaci naprogramované v jazyce C++ z aplikace naprogramované v jazyce Java. A stejně tak nezáleží ani na konkrétní platformě. Webová služba musí být schopná přijímat a odesílat zprávy prostřednictvím standardních Internetových protokolů. Nejběžnější formou využívání webové služby je volání procedury (běžící na serveru) s určitými parametry. Pokud metoda vrací nějaký výsledek, je odeslán jako odpověď XML XML (Extensible Markup Language) je značkovací jazyk, definující množinu pravidel pro strukturování dokumentů ve stromovém formátu, který je čitelný jak člověkem, tak strojem. Ačkoliv bylo XML navrženo primárně pro strukturu dokumentů, je používáno také jako reprezentace různých druhů dat (např. ve webových službách). Jak uvádí Skonnard a Gudgin (2006), dokumenty, které vyhovují specifikacím XML 1.0, se mohou skládat z několika syntaktických prvků, na tomto místě budou uvedeny nejzákladnější z nich. Elementy nejčastěji se vyskytující prvky v XML dokumentu. Každý z těchto dokumentů musí obsahovat právě jeden kořenový element, což je prvek nejvyšší úrovně. Elementy jsou identifikovány libovolným jménem a každý z nich může obsahovat několik potomků. Zápis pomocí elementů je na následující ukázce: <Osoby> <Osoba> <jmeno>jan</jmeno> <prijmeni >Novák</prijmeni > </Osoba> <Osoba>

10 3.1 Webové služby a SOAP 10 <jmeno>j o s e f </jmeno> <prijmeni >Tichý </prijmeni > </Osoba> </Osoby> Atributy místo dětských elementů, které popisují určité vlastnosti rodičovského elementu je možné využít atributy elementu. Také lze tímto způsobem specifikovat další informace o elementu tzv. metadata. Atribut je tvořen dvojící jméno a hodnota. <Osoby> <Osoba jmeno= Jan p r i j m e n i = Novák /> <Osoba jmeno= J o s e f p r i j m e n i = Tichý /> </Osoby> Jmenné prostory jelikož je v XML možné volit vlastní jména elementů a atributů, mohlo by dojít ke konfliktu například pokud by více vývojářů použilo stejné jméno. Proto lze pomocí jmenných prostorů tyto lokální jména odlišit. Označení jmenného prostoru, vychází ze specifikace URI (Uniform Resource Identifier jednotný identifikátor zdroje) viz ukázka jednoho z možných způsobů zápisu níže. Elementy nebo atributy, které leží v konkrétním jmenném prostoru jsou nazývány kvalifikované, naopak ty, které v žádném jmenném prostoru neleží, jsou tzv. nekvalifikované. <p r e f i x : Osoby xlmns : p r e f i x = urn : example org : J e d i n c i > <! K v a l i f i k o v a n ý element a k v a l i f i k o v a n é a t r i b u t y > <Osoba p r e f i x : jmeno= Jan p r e f i x : p r i j m e n i = Novák /> <! N e k v a l i f i k o v a n ý element a nekv. a t r i b u t y > <Osoba jmeno= J o s e f p r i j m e n i = Tichý /> </ p r e f i x : Osoby> Protokol SOAP SOAP (Simple Object Access Protocol) je standardizovaný protokol pro obalování zpráv, které jsou přenášeny mezi dvěma aplikacemi. Jeho specifikace definuje pouze obálku přenášených informací a množinu pravidel pro transformaci aplikací (metod) do struktury XML. (Snell, 2002) SOAP zprávy jsou složeny z kořenového elementu Envelope (obálka, která identifikuje SOAP zprávu), volitelně dětským elementem Header (sdělení kontextových informací souvisejících se zpracováním zprávy) a povinně dalším dětským elementem Body (obsahuje samotnou zprávu). Všechny tyto elementy spadají do jednotného jmenného prostoru ve verzi protokolu 1.1 a ve verzi 1.2. Na následující ukázce je příklad požadavku na získání kontaktů:

11 3.1 Webové služby a SOAP 11 <soap : Envelope xmlns : soap= http : / /www. w3. org /2001/06/ soap envelope > <soap : Body> <n : getcontacts xmlns : n= urn : C o n t a c t s S e r v i c e > <i d x s i : type= xsd : i n t > 15 </id> </n : getcontacts > </soap : Body> </soap : Envelope> Jak uvádí Skonnard a Gudgin (2006), zvláštním případem zprávy obsažené v SOAP odpovědi je upozornění na chybu, která vznikla při zpracování požadavku. Taková zpráva může obsahovat až 4 elementy: faultcode obsahuje automaticky generovanou hodnotu, která specifikuje typ chyby. faultstring obsahuje textový popis chyby. faultactor specifikuje uzel, u kterého chyba nastala. Pokud se jedná o konečného příjemce požadavku, nemusí být tento element vložen. faultdetails je element používaný k přenosu informací o chybách specifických pro danou aplikaci. Protokol SOAP nijak neomezuje výběr transportního protokolu, kterým budou zprávy vyměňovány. Lze proto použít jak HTTP, tak např. FTP, TCP nebo SMTP. Nicméně nejčastěji používaným protokolem je HTTP. (Snell, 2002) WSDL Účelem webových služeb je skrze síť poskytnout vybranou funkcionalitu aplikace. Aby však uživatelé byli schopni ke službě přistupovat, je třeba nějakým způsobem popsat, co služba nabízí a jak lze tuto službu využívat. K tomotu účelu lze využít na XML založeném jazyku WSDL (Web Services Description Language). Výhodou je, že ve většině případů nemusí vývojář ručně definovat WSDL mnoho nástrojů pro vytváření webových služeb dokáže WSDL automaticky generovat. Na straně klienta je naopak možné ušetřit mnoho řádků kódu (a vyvarovat se tak případným chybám) automatickým vygenerováním metod pro přístup k webovým službám. Tyto metody jsou generovány právě z poskytnutého dokumentu WSDL. (Snell, 2002) Například prostředí Microsoft Visual Studio tuto funkcionalitu podporuje a práce s webovými službami je zde velmi jednoduchá. Ne všechna vývojová prostředí však touto funkcionalitou přímo disponují. Např. do prostředí Eclipse je nutné explicitně vložit plugin, který automatické generování metod podporuje.

12 3.2 Android aplikace 12 Jsou však také případy, kdy není možné využít přímo generování metod z WSDL a je nutné použít některou z knihoven třetích stran pro práci s webovými službami. Metodám těchto knihoven je nutné předat informace, které vývojář nalezne právě ve WSDL specifikace poskytovatele, název služby, parametry služby a jiné. 3.2 Android aplikace V této sekci jsou popsána podstatná fakta, týkající se platformy Android a programování aplikací pro tuto platformu. Je zde představena historie OS Android, důležité části systému, principy návrhu uživatelského rozhraní, základní třídy a jejich metody apod Platforma Android a její vývoj Android je otevřený (open source) operační systém (OS), založený na OS Linux Kernel a určený pro mobilní zařízení. Primárně je navržen pro zařízení s dotykovým displejem chytré telefony, tablety nebo také fotoaparáty. Historie současné platformy Android sahá do roku 2003, kdy v Kalifornii vznikla společnost Android Inc., která měla v úmyslu vyvíjet OS pro digitální videokamery. Od tohoto záměru však ustoupila a zaměřila se na vývoj OS pro chytré telefony, čímž konkurovala operačním systémům jako Symbian a Windows Mobile. V roce 2005 koupila firmu Android společnost Google Inc., která chtěla své aktivity rozšířit i do mobilní sféry. O dva roky později byl představen OS Android a v roce 2008 se již prodával první chytrý telefon s tímto systémem HTC Dream. (Smith a Friesen, 2011) Architekturu tohoto systému Google nazývá jako Android stack a lze ji rozdělit do 4 vrstev. (The beginner s guide to Android, 2013) Linux Kernel nejnižší vrstva systému, která nikdy přímo nekomunikuje s uživatelem ani vývojářem. Je základem celého systému a mimo jiné se stará o abstrakci hardwaru, správu paměti nebo např. správu spojení. Nativní knihovny sada knihoven, které řídí systém při zpracování různých typů dat. Patří sem knihovny WebKit (webové jádro), SQLite (databáze), SSL (2D grafika), OpenGL (3D grafika) a další. Na této vrstě se nachází také knihovny jádra a Dalvik Virtual Machine software, který se stará o běh aplikací, více v sekci Aplikační rámec knihovny, k nimž uživatelské aplikace přímo přistupují. Jedná se o Resource manager (správa různých typů zdrojů), Location manager (správa polohy), Activity manager (správa aktivit), Window manager (správa displeje) a jiné.

13 3.2 Android aplikace 13 Aplikace vrstva, k níž přímo přistupuje uživatel. Jako příklad aplikací je možné uvést SMS klienta, aplikaci obsluhující hovory, webový prohlížeč, přehrávač multimédií, apod. Google vydává nové verze systému obvykle každých 6 až 9 měsíců. Jednotlivé verze jsou popsány číslem, jménem a úrovní API (Application Programming Interface). Pojmenování vychází ze sladkostí (např. Gingerbread perník). K je nejvyužívanější verzí systému Android Jelly Bean, viz obr. 1 a tab. 1. (Dashboards) Podle statistik za rok 2013 byl OS Android nainstalován ve většině prodaných chytrých telefonů (78,1 %), další dvě místa obsadil ios (17,6 %) a Windows Phone (3 %), viz obr. 2. (Whittaker, 2014) Obrázek 1: Graf podílů jednotlivých verzí k (Dashboards) Tabulka 1: Podíly jednotlivých verzí k (Dashboards) Verze Označení API Podíl 2.2 Froyo 8 1, 2 % 2.3 Gingerbread % 3.2 Honeycomb 13 0, 1 % 4.0 Ice Cream Sandwich 15 15, 2 % , 3 % 4.2 Jelly Bean 17 17, 1 % , 6 % 4.4 KitKat 19 2, 5 % Programovací jazyk a vývojové nástroje Doporučeným programovacím jazykem, ve kterém lze vyvíjet Android aplikace, je jazyk Java. Existují však i jiné varianty za zmínku stojí zejména prostředí Phone- Gap, ve kterém se využívá jazyka HTML, JavaScript a CSS. Touto variantou získá

14 3.2 Android aplikace 14 Obrázek 2: Graf podílů OS v prodaných smartphonech v roce 2013 programátor možnost vyvinout jednu aplikaci a nasadit ji do zařízení s různým operačním systémem (Android, ios, WindowsPhone, ). Problémem však může být kompatibilita s jednotlivými systémy a jejich verzemi, velikost aplikace, správa paměti a také obtížné testování. (Allen, 2013) Jak již bylo uvedeno v sekci 3.2.1, jednou z nejdůležitějších součástí systému Android je virtuální stroj Dalvik (DVM). Aplikace je převedena na tzv. bajtový kód, což je optimalizovaná sada instrukcí, kterou DVM interpretuje. Od verze 2.3 Android navíc obsahuje Just In Time kompilátor za běhu se zkompilují vybrané části bajtového kódu do kódu nativního, což zrychluje běh systému. Zbytek kódu je interpretován. (Allen, 2013; Schildt, 2012) Ačkoliv principiálně vychází DVM z funkcionality Java Virtual Machine (JVM), jsou zde určité rozdíly zatímco architektura DVM je založená na registrech, architektura JVM je zásobníková. Dalším rozdílem jsou typy souborů, do kterých se kompiluje bajtový kód u DVM jsou to soubory typu.dex, u JVM.class. Oproti Java Virtual Machine je Dalvik optimalizován pro zařízení s omezenou operační pamětí a výkonem procesoru, v jeden okamžik je také možné spustit několik jeho instancí (několik aplikací). U obou zmíněných virtuálních strojů se o automatickou správu paměti stará garbage collector. (Palandurkar, 2013) K tomu, aby bylo možné využívat nástroje pro tvorbu Android aplikací, je třeba vývojovému prostředí poskytnout Android SDK (Software Development Kit). Tuto sadu vývojář získá z webových stránek společnosti Google ( kde je také možné stáhnout celý balík ADT (Android Developer Tools), jehož obsahem je jak SDK, tak Eclipse IDE (Integrated Development Environment). Ačkoliv je prostředí Eclipse hojně využívané a podporované, existují i jiné varianty, ve kterých lze Android aplikace vyvíjet. Např. v roce 2013 Google představil

15 3.2 Android aplikace 15 Android Studio, což je IDE založené na IntelliJ Idea Java IDE a zaměřené výhradně na vývoj aplikací pro platformu Android. Toto prostředí je tedy méně komplexní než Eclipse, ale naopak více uživatelsky přívětivé pro Android vývojáře. Obsahuje několik funkcí, navržených speciálně pro Android šablony pro vývoj aplikací se standardním designem, nástroje pro řešení problémů s kompatibilitou verzí a další užitečné funkce. (Jackson, 2013) Pro jazyk Java je k dispozici velké množství knihoven třetích stran JAR soubory, které je možné přibalit k aplikaci a rozšířit tak funkcionalitu. I přesto, že virtuální stroj Dalvik není stejný jako virtuální stroj Javy, mnoho z těchto knihoven je možné v prostředí Android využívat. Ne všechny jsou však pro tento systém přijatelné jsou příliš velké (roste velikost aplikace), předpokládají spuštění na výkonném CPU nebo očekávají novější virtuální stroj. Proto jsou vítány knihovny s otevřeným zdrojovým kódem, kde může vývojář upravit knihovnou podle svých potřeb a také ji může přeložit současně se svou aplikací. (Murphy, 2011) Spustit a ladit aplikaci je možné na reálném zařízení nebo na emulátoru, což je software simulující Android zařízení. Emulátor je výhodné využít pro testování různých typů zařízení, která nemá vývojář k dispozici. Při vytváření virtuálního zařízení je mimo jiné možné specifikovat verzi systému Android, velikost paměti SD karty (stejné množství paměti bude obsazeno v počítači, na kterém je emulátor spuštěn), rozlišení obrazovky a velikost paměti RAM. K tomu, aby bylo možné spustit aplikaci na zařízení, je třeba v nastavení povolit ladění USB. (Allen, 2013) Pro ladění aplikace v Eclipse IDE je již připraven JDWP-compliant debugger a není třeba žádné další nastavení. Pokud vývojář pracuje v jiném IDE, může využít debuggeru tohoto prostředí, je ho však nutné připojit na správný port. (Debugging) Struktura projektu Projekt Android se skládá z několika důležitých součástí (složek), které popisují jak design, tak funkcionalitu aplikace: src zdrojové kódy aplikace. gen obsah této složky je generován automaticky, jakákoliv úprava obsahu není doporučena. Mimo jiné tato složka obsahuje třídu R, ve které jsou zaznamenány adresy paměti, kde jsou uloženy veškeré aplikační zdroje (návrhy, řetězce, barvy, obrázky, a další). Třídu R programátor využívá právě k přístupu k aplikačním zdrojům. Tedy např. k vyhledání návrhu Activity.findViewById(R.id.formLayout) nebo řetězce Context.getResources().getString(R.string.formTitle). libs na toto místo jsou vkládány knihovny třetích stran. bin výstupní složka sestavení aplikace. Nachází se zde instalační soubor apk. res obsahuje zdroje aplikace, více viz níže.

16 3.2 Android aplikace 16 assets tato složka je určena pro paměťově náročnější formáty, jako je audio, video nebo velké obrázky. K těmto zdrojům je třeba přistupovat přes třídu AssetManager. AndroidManifest řídící XML soubor popisující základy aplikace a jejích komponent. Uvádí se zde, pro které verze (API) systému Android je aplikace určena, jaká potřebuje aplikace povolení, která musí uživatel potvrdit při instalaci (např. zápis nebo čtení z paměti, přístup k Internetu, ) nebo podporované typy displeje. Dále jsou zde mimo jiné definovány jednotlivé aktivity (viz sekce 3.2.7) a poskytované služby. (Murphy, 2011) Jak již bylo zmíněno výše, důležitou součástí projektu jsou jeho zdroje, ke kterým vývojář přistupuje přes třídu R. Jedná se o návrhy, obrázky, řetězce, identifikátory, styly, hodnoty, barvy a další. Zdroje jsou rozděleny do složek podle jejich typu. Na tomto místě budou zmíněny nejpoužívanější z nich. drawable do této kategorie vývojář vkládá obrazové zdroje, jako např. ikony, které jsou součástí uživatelského rozhraní aplikace. Systém Android podporuje obrázky formátu PNG, JPEG, BMP, WEBP a GIF. Používání souborů GIF však není oficiálně doporučováno a podpora formátu WEBP byla přidána až jako součást verze Ice Cream Sandwich (4.0) jedná se o formát poskytující přibližně o 40 % lepší kompresi než JPEG. Do složky drawable lze také vkládat XML soubory definující vzhled, který je následně možné přiřazovat položkám návrhu. Pro tento typ návrhu lze využít některou z řady možností, které Android nabízí (Shape, Layer list, Clip, ). (App Resources) layout složka obsahující návrhy rozložení prvků jednotlivých aktivit (více aktivit však může sdílet jeden návrh). Tvorbou návrhů se podrobněji zabývají sekce a menu do této složky jsou vkládány XML soubory, které definují strukturu menu. Ve zdrojovém kódu aktivity je pak třeba aktivitě přiřadit konkrétní návrh menu tedy pokud aktivita menu voleb využívá. Menu uživatel vyvolá stisknutím tlačítka na zařízení (obvykle se jedná o hardwarové tlačítko). Standardní menu voleb se skládá z maximálně 6 položek, a pokud má položek více, je poslední položka označena jako Další, čímž lze přepnout menu do módu s ostatními položkami. values po vytvoření nového projektu jsou zde umístěny soubory strings.xml, styles.xml a dimens.xml, obsah složky je však možné rozšířit např. o soubor colors.xml. I když je vhodné pojmenování zachovat, nemá na funkci vliv. Všechny níže uvedené položky jsou vkládány jako potomci kořenového elementu resources. Rozhodující je název vkládaného elementu ten obsahuje atribut name, který slouží k identifikaci položky při odkazování ze zdrojového kódu nebo z návrhu rozvržení. Soubor s definicí několika položek by mohl vypadat následovně. (Allen, 2013)

17 3.2 Android aplikace 17 <r e s o u r c e s > <! D e f i n i c e r e t e z c e > <s t r i n g name= app_name >QI c l i e n t </s t r i n g > <! D e f i n i c e rozmeru > <dimen name= r a d i u s >16dp</dimen> <! D e f i n i c e barvy > <c o l o r name= blueevent >#37c7ba </c o l o r > </r e s o u r c e s > Dále je popsán význam základních elementů, které jsou vkládány jako potomci elementu resources. string definuje řetězce využívané v uživatelském rozhraní aplikace. Jedná se zejména o nadpisy, upozornění, text ve formulářích nebo různé tipy. Řetězce je samozřejmě možné definovat napevno ve zdrojovém kódu, tato možnost však není doporučována. Nespornou výhodou umístění všech řetězců na jednom místě je jednoduchá editace a možnost internacionalizace aplikace. style umožňuje vývojáři zapouzdřit sadu atributů, kterou lze využívat opakovaně. Např. lze definovat styl, který bude přiřazen textovým polím. V tomto stylu může programátor mimo jiné definovat barvu pozadí, barvu písma, velikost písma, apod. V souboru styles.xml je také definován základní styl celé aplikace, který je pojmenován AppBaseTheme a vývojář ho může editovat stejně jako jiné styly např. nastavit základní barvu pozadí. Zároveň platí hierarchie stylů pokud bude mít základní styl definovanou červenou barvu pozadí a kontejner v návrhu zelenou, použije se zelená. dimen definuje rozměry, které lze využít zejména v návrhu rozložení (např. odsazení okraje prvku). Rozměry lze uvádět v jednotkách, které odpovídají skutečným rozměrům obrazovky v milimetrech (mm), palcích (in), bodech (pt) nebo pixelech (px). V praxi jsou však využívané spíše jednotky, které nejsou závislé na konkrétním zařízení. Jedná se o dip (densityindependent pixels) nebo sp (scale-independent pixels). Přičemž pro velikost písma je vhodné používat sp zohledňuje i uživatelovo nastavení velikosti písma. Pokud je hustota pixelů displeje 160 dpi (density per inch), pak platí 1 dp = 1 px. Přepočet dip na px lze provést pomocí vzorce px = dip (dpi/160). Rozměry je výhodné definovat zejména v případě, kdy je daný rozměr použit na více místech. color specifikuje barvy, které jsou využívány v uživatelském rozhraní. Stejně jako např. u řetězců je možné barvu uvést přímo ve zdrojovém kódu, ale položky definované na jednom místě jsou lepším řešením. Barvy se v systému Android specifikují jako hexadecimální RGB hodnoty, při-

18 3.2 Android aplikace 18 čemž lze navíc definovat alfa kanál (průhlednost) ve formátu #ARGB nebo #AARRGGBB. Odkazování na zdroje je možné ze zdrojového kódu nebo z návrhu rozložení. Jak již bylo uvedeno výše v této sekci, ve zdrojovém kódu slouží k odkazování třída R např. R.drawable.image, R.strings.title nebo R.color.blue. V návrhu rozložení je možné se odkazovat (Murphy, 2011) Podpora různých typů obrazovky Jelikož operační systém Android využívá celá řada zařízení, je zde také celá řada typů displejů, které mohou aplikaci zobrazit. Displeje se liší v rozlišení a velikosti, tedy také v poměru stran a hustotě obrazových bodů. Při návrhu rozložení je tak třeba myslet spíše na pravidla, než na absolutní umístění jednotlivých prvků v návrhu je tedy vhodné určovat jejich pozici relativně, nikoliv absolutně. Dále by se měl vývojář vyvarovat zadávání rozměrů v jednotkách, které jsou pevně spjaty se skutečnými rozměry obrazovky (např. pixely) a raději využít dip nebo sp. Proč nepoužívat prvně jmenované jednotky je zřejmé z obr. 3. (Allen, 2013) Obrázek 3: Výsledek špatného návrhu zadání rozměrů v px Systém Android umožňuje škálovat zařízení podle velikosti jejich displeje a hustoty obrazových bodů. Lze tak např. vytvořit odlišné návrhy pro zařízení s malým

19 3.2 Android aplikace 19 nebo velkým displejem nebo také vložit ikony různých velikostí podle hustoty pixelů displeje. Škálování zařízení podle délky úhlopříčky v palcích (inches) a podle hustoty px (dpi) je patrné z obr. 4. Obrázek 4: Škálování displejů podle velikosti a hustoty px (Supporting Multiple Screens) Důležité je také poskytnout aplikaci různé velikosti ikon a v návrhu jim ponechat původní rozměry Android je sice schopen za běhu upravit velikost obrázku (pokud vývojář nastaví, kolik má obrázek zabírat dip), ale výsledek nemusí být optimální. Jako základ je považována střední hustota px (mdpi) ikony pro hdpi displeje by měly být 1.5 větší, pro xhdpi 2 a pro xxhdpi 3 větší než pro mdpi. (Iconography) Rozlišit zdroje podle typu displeje lze provést vytvořením složek v kořenovém adresáři projektu s názvem typu zdroje (např. drawable) a přidáním pomlčky s označením typu displeje drawable-mdpi, drawable-hdpi-large, layout-large, apod. Do těchto adresářů je pak možné vložit zdroj se stejným označením a různým obsahem Android vybere, který soubor je určen pro konkrétní zařízení. Pokud je v zařízení s hdpi displejem vyžadována ikona umístěná pouze v adresáři drawable-mdpi, bude použita, její rozměry však pravděpodobně budou příliš malé. Je také možné vytvořit odlišné návrhy rozložení prvků podle módu orientace displeje (portait na výšku nebo landscape na šířku). Pro landscape je třeba založit adresář s příponou -land a pro portait -port. (Murphy, 2011) Definice rozložení prvků Pro každou zobrazovanou aktivitu je třeba definovat rozvržení zobrazovaných prvků (widgetů). To může vývojář udělat dvěma způsoby definovat rozložení prostřednictvím XML souboru (ručně nebo pomocí grafického editoru) nebo vytvořit návrh ze zdrojového kódu. (Smith a Friesen, 2011) Druhou možnost je vhodné použít, pokud při kompilaci aplikace není zřejmé jak bude rozložení vypadat např. pokud se návrh vytvoří na základě dat načtených z databáze. Návrhem rozložení ze zdrojového kódu lze dosáhnout téměř všeho, jako návrhem pomocí struktury XML. Tato varianta je nicméně časově náročnější a málo přehledná. Tvorba návrhu ze zdrojového kódu se skládá z vytvoření instance tříd

20 3.2 Android aplikace 20 konkrétních prvků návrhu (všechny dědí od třídy View) a nastavení vlastností pro dosažení požadovaného vzhledu a chování. Běžnější variantou je definice rozložení prvků pomocí stromové struktury XML souboru, čehož lze dosáhnout manuálním zápisem nebo s pomocí grafického editoru (ten je součástí jak prostředí Eclipse, tak Android Studio). Kořenovým elementem je obvykle párový element typu kontejner, jehož potomky jsou buďto další kontejnery, nebo nepárové elementy widgety. Atributy těchto elementů pak určují jejich vlastnosti vzhled a chování. Propojení XML souboru se zdrojovým kódem je dosaženo pomocí metody třídy Activity setcontentview(r.layout.activity_main), kde parametrem je specifikace XML dokumentu. K tomu, aby bylo možné přistupovat k jednotlivým prvkům návrhu, je nutné jim přiřadit identifikátor. Následně lze k prvku přistoupit využitím metody findviewbyid(r.id.formtextview), kde parametrem je specifikace konkrétního identifikátoru, který zastupuje prvek návrhu. (Allen, 2013) Ještě před samotnou definicí konkrétních prvků je důležité zmínit jejich podstatné vlastnosti. Každému prvku v návrhu by měl vývojář nastavit jeho rozměry (android:layout_width pro šířku a android:layout_height pro výšku), což lze udělat třemi způsoby: pevně daným rozměrem např. 90 dip. hodnotou wrap_content widget vyplní prostor odpovídající jeho velikosti a pokud je příliš velký, bude zalomen. hodnotou match_parent widget vyplní všechen zbývající prostor v daném směru. Jednotlivým prvkům je také možné přiřadit prioritu, podle které si rozdělí volné místo. V závislosti na orientaci je elementům nastaven jeden z atributů android:layout_width nebo android:layout_height na hodnotu 0 a přidán atribut android:layout_weight. Ten bude nastaven podle toho, kolik procent volného místa mají jednotlivé prvky zabírat, ukázka návrhu viz sekce Dále je často nutné definovat volné místo kolem prvku k tomu slouží atributy android:padding a android:layout_margin. První z nich určuje mezeru uvnitř hranic elementu, čehož lze využít např. v případě, kdy má být prvek umístěn o něco výše, než je střed návrhu. Druhá vlastnost, margin, vymezuje volné místo mezi hranicí elementu a ostatními prvky. Oba tyto atributy v základním zápisu definují volné místo kolem celého prvku, lze však specifikovat také mezeru pouze pro určitou stranu např. android:layout_marginleft="20dip", vymezí volné místo o velikosti 20 dip nalevo od prvku. (Smith a Friesen, 2011) Kontejnery a widgety Stejně jako jiné sady nástrojů pro tvorbu uživatelského rozhraní, tak i systém Android poskytuje soubor základních widgetů. Na tomto místě budou uvedeny nej-

21 3.2 Android aplikace 21 používanější z nich. Widgetům a kontejnerům se podrobně věnují Allen (2013) a Murphy (2012). Popisky jedná se o jednoduchý widget sloužící k zobrazení textu, který uživatel nemůže upravovat. Ze zdrojového kódu jej lze vytvořit instancí třídy TextView. Častější variantou je však vložení elementu TextView do struktury XML návrhu. Zde je třeba nastavit atribut android:text na hodnotu, která bude v popisku zobrazena. Mimo jiné lze rovněž definovat velikost písma (android:textsize), jeho styl (android:style) a nebo barvu (android:textcolor). Tlačítka v systému Android reprezentuje třída Button. Tato třída dědí od třídy TextView a proto lze definovat všechny její vlastnosti, jako například barvu textu. Navíc je nutné přiřadit tlačítku funkcionalitu, čehož toho lze dosáhnout dvěma způsoby: implementací rozhraní View.OnClickListener a metody onclick(). V tomto případě je nutné pomocí metody třídy Button setonclicklistener(onclicklistener listener) nastavit tlačítku konkrétní naslouchač (listener) implementací metody návratového typu void s jediným parametrem typu View. Název této metody je pak třeba definovat jako hodnotu atributu android:onclick. Textová pole slouží pro zadávání textu od uživatele. Jsou zastoupena třídou EditText a stejně jako u tlačítka jde o podtřídu třídy TextView. Vývojář má pomocí atributu android:inputtype možnost specifikovat typ vkládaného textu (jen číslice, skryté znaky, první písmeno velké, ). Existuje také třída AutoCompleteTextView, která poskytuje automatické doplňování textu. Obrázky lze v systému Android zobrazit pomocí widgetů ImageView a ImageButton (podtřída třídy Button). Oba mají v definici atribut android:src, který identifikuje zdrojový obrázek obvykle se jedná o odkaz na zdroj z kategorie drawable. Zaškrtávací pole nabízí dva stavy (zaškrtnuto a nezaškrtnuto) a v systému Android jej implementuje třída CheckBox, která je podtřídou třídy TextView. Ve zdrojovém kódu jazyka Java lze zjistit současný stav pole voláním metody ischecked() a nastavit jej pomocí metody setchecked(). Změnu stavu tlačítka je možné zachytit implementací rozhraní OnCheckedChangeListener a metody oncheckedchanged(). Přepínače mají několik stejných vlastností jako zaškrtávací pole mohou se nacházet pouze ve dvou stavech a odvozují se od třídy CompoundButton, která dědí od třídy TextView. Přepínače však lze navíc seskupit tak, aby bylo možné v jeden okamžik aktivovat pouze jeden ze skupiny. Skupinu předsta-

22 3.2 Android aplikace 22 vuje třída RadioGroup a jednotlivé přepínače třída RadioButton. Jak skupině, tak přepínačům je třeba nastavit identifikátor a poté lze k řízení využít metody třídy RadioGroup check() pro aktivování konkrétního přepínače a getcheckedradiobutton() pro získání identifikátoru aktuálně aktivovaného přepínače. Zadávání data a času pro usnadnění zadávání data a času jsou v OS Android nadefinované widgety, které jsou součástí návrhu a dialogy, které lze vyvolat jako reakci na určitou událost. Pro zadávání data slouží třída DatePicker / DatePickerDialog a pro určení času třída TimePicker / TimePickerDialog. K odchycení události, kdy uživatel zadá nové datum nebo čas, slouží OnDateSetListener a OnTimeSetListener. K organizaci struktury widgetů jsou v systému Android využívány tzv. kontejnery. Jak již bylo zmíněno výše, kořenový element XML souboru je obvykle kontejner a kontejnery lze rovněž vkládat jako jeho potomky. Běžně používanými kontejnery jsou LinearLayout, RelativeLayout a TableLayout, přičemž každý z nich definuje jiná pravidla pro vkládání widgetů. Kořenovým elementem může být i třída ScrollView, která se využívá k implementaci posuvných návrhů. Tento element může obsahovat pouze jednoho přímého následovníka obvykle kontejner. (Smith a Friesen, 2011) LinearLayout funguje na principu polí widgety nebo kontejnery se skládájí do řádku nebo sloupce podle zvolené orientace. Tu lze specifikovat přidáním atributu android:orientation a nastavením na hodnotu vertical pro sloupec nebo horizontal pro řádek. Standardně jsou prvky v kontejneru LinearLayout umisťovány od levého horního rohu, atributem android:layout_gravity lze zarovnání prvku změnit. Na obr. 5 je ukázka návrhu, ve kterém je využito prioritního vkládání prvku (atribut weight). RelativeLayout je kontejner, ve kterém je pozice prvků definována na základě polohy vůči ostatním elementům v kontejneru nebo vůči kontejneru samotnému. Lze tak např. umístit prvek nahoru a napravo od konkrétního widgetu nebo do pravého spodního rohu kontejneru. Prvky, na které je v návrhu odkazováno, musí mít přiřazen identifikátor. To vývojář udělá vložením atributu se syntaxí android:id="@+id/new_element", čímž je vytvořen nový identifikátor new_element, na který je možné odkázat pomocí android:id="@id/new_element. TableLayout je založen na tabulkové struktuře a využívá se společně s dalším kontejnerem TableRow. Zatímco TableLayout řídí celkové chování kontejneru, samotné widgety jsou vkládány do TableRow, který definuje jeden řádek tabulky. Tabulka bude mít minimálně tolik sloupců, kolik je nejvyšší počet widgetů v některém z řádků. Šířka sloupce pak odpovídá místu, které zabírá nejšiřší widget ve sloupci.

23 3.2 Android aplikace 23 Obrázek 5: Ukázka návrhu rozložení pomocí kontejneru LinearLayout Kontejner ScrollView umožňuje posouvat jeho obsah ve vertikálním směru. Jelikož může obsahovat pouze jednoho přímého následovníka, bývá tímto potomkem obvykle jiný kontejner. Pokud je třeba posouvat obsah v horizontálním směru, lze využít kontejner HorizontalScrollView, který byl přidán ve verzi systému Android Aktivity Architektura uživatelského rozhraní Android aplikací je složená z tzv. aktivit, které dědí od třídy Activity. Zatímco hlavní aktivita (specifikována v řídícím souboru AndroidManifest) je spuštěna automaticky při startu aplikace, ostatní aktivity jsou spouštěny prostřednictvím záměrů (intent). (Smith a Friesen, 2011) Nejjednodušší formou záměru je spuštění další aktivity v aplikaci. Tento záměr je specifikován jako new Intent(FirstActivity.this, SecondActivity.class), kde FirstActivity je název spouštěcí aktivity a SecondActivity označení spouštěné aktivity. OS Android se však skládá z mnoha volně spojených komponent, a tak je možné využívat také služeb jiných aplikací (fotoaparát, prohlížeče, editory,.). V tomto případě je záměr složen z příslušné akce a URI (Uniform Resource Identifier), které je v systému Android reprezentováno třídou Uri a na které je odkazováno jako

24 3.2 Android aplikace 24 na data. Příslušnou akcí může být mimo jiné ACTION_VIEW pro spuštění prohlížeče specifikovaných dat (např. prohlížeče fotografií), ACTION_EDIT pro jejich modifikaci dat nebo ACTION_PICK pro výběr dostupné položky ze seznamu. S každou další verzí systému Android narůstá počet dostupných akcí. (Allen, 2013) Na následující ukázce je záměr, vytvořený s pomocí instance třídy Uri a zamýšlené akce v tomto případě je záměrem spustit dostupný prohlížeč map se zaměřením na zadanou zeměpisnou šířku a délku. Uri u r i = Uri. p a r s e ( geo : , ) ; I n t e n t i n t e n t = new I n t e n t ( I n t e n t.action_view, u r i ) ; K samotnému záměru může programátor navíc přibalit instanci třídy Bundle, což je přepravka dat, do které lze vkládat hodnoty atomických typů a jejich polí nebo pomocí serializace i složitější objekty. Jak popisuje Allen (2013), záměr je dále nutné předat systému, který spustí příslušnou aktivitu. K tomu slouží metody třídy Activity nejčastěji využívané jsou startactivity(intent intent) a startactivityforresult(intent intent, int activitycode), kde activitycode je jedinečné číslo volané aktivity. V prvním případě se spouštěcí aktivita nedozví, kdy spouštěná aktivita skončí. Ve druhém případě je možné implementací zpětně volané metody onactivityresult() odchytit ukončení spuštěné aktivity a provést potřebné operace (např. obnovit data z databáze). Tato metoda zároveň vrací tato data: identifikátor ukončené aktivity. kód výsledku ukončené aktivity nastavený metodou setresult(). Základní možnosti jsou RESULT_OK nebo RESULT_CANELED, lze však vytvářet své vlastní kódy výsledků. volitelně proměnnou typu String. volitelně instanci třídy Bundle obsahující výsledná data. Jelikož mají mobilní zařízení méně paměti RAM než stolní počítače, vyhrazuje si systém Android právo ukončit neaktivní aktivity (aplikace). Proto aktivity prochází tzv. životním cyklem, ve kterém se vždy nachází v jednom ze 4 stavů: aktivní: běží v popředí. pozastavená: běží v popředí, ale je překryta prioritním upozorněním (příchozí hovor, nová zpráva, vybitá baterie, ). zastavená: skrytá za jinými aktivitami, které byly spuštěny po ní. mrtvá: aktivita byla násilně ukončena systémem nebo se ji nepodařilo spustit. Při přechodech mezi těmito stavy jsou volány metody, jejichž implementací se přechody řídí. Při některých přechodech je voláno více těchto metod, avšak nemusí

25 3.2 Android aplikace 25 být volána žádná (např. z nedostatku paměti je třeba aktivitu urgentně ukončit). (Activities) Metoda oncreate() bývá využívána zejména k inicializaci uživatelského rozhraní a také k provádění metod, které je třeba vykonat pouze jednou při startu. Parametrem této metody je objekt Bundle, který je při prvním spuštění aktivity prázdný (null), lze do něj však vkládat data, které je třeba uložit před restartem aktivity viz níže. Metoda ondestroy() je obykle volána na konci životního cyklu aplikace. Hodí se k uvolnění prostředků získaných v oncreate(). Pokud je v aktivitě pracováno s obsahem získaným z databázé nebo adaptéru, je zde vhodné tyto prostředky uzavřít zavolat metodu close(). Metoda onstart() je volána buďto bezprostředně po oncreate(), nebo po metodě onrestart(), k jejímuž zpětnému volání dojde, pokud byla aktivita zastavena (skryta) a znovu spuštěna. Metoda onstop() je volána před přejitím aplikace do režimu zastavení. Metoda onresume() se volá těsně před tím, než je aktivita přesunuta do popředí zde je vhodné aktualizovat uživatelské rozhraní. Naopak pokud se aktivita přesouvá na pozadí, je důležité uvolnit prostředky získané v onresume(), k tomu slouží metoda onpause(). V určitých situacích systém Android ukončí všechny spuštěné nebo pozastavené aktivity a znovu je spustí při jejich opětovném zobrazení. Mezi tyto situace patří i změna orientace obrazovky. U některých zařízení je tato změna vyvolána vysunutím hardwarové klávesnice, u většiny pak otočením přístroje (využívají akcelerometry). Stav aktivity je možné uložit v metodě onsaveinstancestate() do dodaného objektu Bundle. Tento objekt je při opětovném spuštění aktivity parametrem metody oncreate() Seznamy Mezi hojně využívané kontejnery v OS Android patří kontejner ListView, který poskytuje kontrolu nad seznamy. Uživatel s ním tak mimo jiné pracuje při výběru kontaktu, zprávy nebo položky nastavení. ListView má v sobě již zabudované posouvání obsahu a nelze jej využít společně s kontejnerem ScrollView. Tématu seznamů se podrobně věnují Allen (2013) a Murphy (2011). Kontejner ListView je plněn na základě předloženého seznamu, což může být jednoduše pole hodnot typu String nebo také seznam složitějších objektů. Tento seznam je třeba ve zdrojovém kódu s návrhem položky seznamu předat tzv. adaptéru, který je v systému Android často zastupován třídou ArrayAdapter pro seznamy definované ve zdrojovém kódu nebo CursorAdapter pro seznamy získané z databáze. V nejjednodušším případě jsou položky zobrazovaného seznamu složeny pouze z textového řetězce, ve složitější verzi pak mohou obsahovat různé ikony nebo více ře-

26 3.2 Android aplikace 26 tězců. Nejsložitější pro implementaci je však situace, kdy položky seznamu obsahují interaktivní widgety (zaškrtávací pole, lišta s hodnocením, ). Pokud si vývojář vystačí s jednoduchým návrhem, může využít některého z již předdefinovaných, které systém Android nabízí. V mnoha případech je však třeba specifikovat vlastní návrh. Při zobrazení a posouvání obsahu seznamu dochází k načítání zdrojů položek (widgety, obrázky, ) ve třídě ArrayAdapter se o tuto operaci stará metoda getview(), ve třídě CursorAdapter pak metody bindview() a newview(). Jelikož jsou tyto operace výkonově nákladné, dochází k recyklaci položek seznamu zdroje jsou načteny pouze jednou a poté uloženy do paměti. Jak uvádí Allen(2013), ListView, které využívá recyklace, poskytuje o 150 % vyšší výkon než ListView, které recyklaci nepoužívá. Stejně jako je v mnoha případech nutné definovat vlastní návrhy rozložení položek seznamu, je také v mnoha případech třeba implementovat adaptéry, které dědí od některého ze základních adaptérů. V těchto implementacích je pak nutné přepsat metody starající se o načítání položek seznamu. Zde je důležité myslet především na recyklaci, kterou v metodě getview() usnadňuje předávaná instance třídy View (podle konvence nazvaná convertview ) pokud je stejná položka seznamu načtena opětovně, je uložena právě zde. Položku seznamu neboli její návrh je možné načíst následujícím způsobem: View l i s t I t e m = n u l l ; i f ( convertview == n u l l ){ L a y o u t I n f l a t e r i n f l a t e r = g e t L a y o u t I n f l a t e r ( ) ; l i s t I t e m = i n f l a t e r. i n f l a t e (R. l a y o u t. l i s t I t e m, n u l l ) ; } e l s e { l i s t I t e m = convertview ; } l i s t I t e m. findviewbyid (R. i d. itemicon ) ; Pokud je položka zobrazena poprvé, LayoutInflater se postará o načtení návrhu (nákladná operace), v opačném případě je položka již načtená v convertview. Následně je možné metodou findviewbyid() přistupovat k jednotlivým prvkům návrhu položky seznamu Úložiště dat Práce se soubory v OS Android je téměř totožná jako v jazyce Java. Adresace souborů je však přizpůsobena možnosti výběru mezi interní a externí pamětí zařízení cesty k souborům nejsou zadávány absolutně, ale využívají se metody, kterými lze k souborům přistoupit nebo je vytvořit. Soubory uložené v interním paměti flash jsou ve výchozím nastavení přístupné pouze aplikaci, která je vytvořila jiné aplikace nemají práva čtení a zápisu. Někteří uživatelé systému Android však svá zařízení tzv. rootují, a tím získávají práva superuživatele mohou přistupovat ke kterémukoliv souboru. K tomuto úložišti je možné přistoupit prostřednictvím metod openfileinput() a openfileoutput(),

27 3.2 Android aplikace 27 které vrací instance třídy FileInputStream nebo FileOutputStream. Jako parametr je těmto metodám předáván název souboru. (Murphy, 2011) Nevýhodou integrované flash paměti je obvykle její nízká kapacita, což je často důvodem k využití externího úložiště. To představuje paměťová karta nebo část interní paměti, vyhrazené pro externí použití. Naopak nevýhodou tohoto typu paměti je přístupnost pro všechny aplikace soubory zde uložené nejsou nijak zabezpečené. K získání adresy externího úložiště je doporučeno využít metodu getexternal- FilesDir(), kterou nabízí každá aktivita nebo její kontext. Pokud soubory vytvořené aplikací náleží spíše uživateli, je vhodné je pomocí metody getexternalstoragepublicdirectory() třídy Environment umístit do správné složky. Tato metoda vrací instanci třídy File odkazující do příslušné složky podle zadaného typu souboru v parametru např. DIRECTORY_MOVIES pro video nebo DIRECTORY_PICTURES pro obrázky. V systému Android existují samozřejmě i jiné možnosti ukládání dat. Jednu z nich představuje třída SharedPreferences, která funguje na principu čtení a zápisu párů klíč-hodnota. Lze ji využít k ukládání uživatelských nastavení (i pro více uživatelů) nebo dat, pro které by nebylo vhodné vytvářet tabulky v databázi. Další možnost nabízí databáze SQLite, kterou se zabývá kapitola 3.3. (Saving Data) Vlákna V některých případech potřebuje aplikace Android provést časově náročnější operace jako je např. stahování dat z Internetu, práce se soubory nebo jakékoliv náročné výpočty. Jelikož aplikace komunikuje s uživatelem prostřednictvím tzv. vlákna uživatelského rozhraní, časově náročné operace spuštěné v tomto vlákně zpomalují reakci systému. Pokud aplikace nereaguje po dobu několika sekund, bude systémem ukončena. Proto je vhodné tyto časově náročné úlohy neprovádět v hlavním vlákně uživatelského rozhraní, ale vytvořit vlákno, které operaci vykoná na pozadí. (Allen, 2013) Důležité je si uvědomit, že zasahovat do uživatelského rozhraní lze pouze z hlavního vlákna aplikace, nikoliv z vláken spuštěných na pozadí. Pokud je však třeba z takového vlákna uživatelské rozhraní nějakým způsobem aktualizovat, existuje v systému Android třída Handler, jejíž instance je schopná přijmout signál z jiných vláken a vykonat potřebné operace v hlavním vlákně. Handler může přijímat zprávy, které jsou prázdné (obsahují pouze kód zprávy) nebo nesou určitý obsah (objekt Bundle). Dále lze obslužnému objektu předat objekt typu Runnable, a ten jej následně spustí ve vlákně uživatelského rozhraní. Jak uvádí Allen (2013), OS Android poskytuje podporu vláken jazyka Java, která je založena na třídě Thread. Dále je možné využít třídu z balíčku android.os AsyncTask. První možností je vytvoření instance třídy Thread s implementací rozhraní Runnable. Kód, který má být spuštěn v rámci vlákna na pozadí je třeba zapsat

28 3.3 Databáze SQLite a práce s daty v OS Android 28 do metody run(). Ke spuštění takto definovaného vlákna slouží metoda třídy Thread start(). Druhou možností je implementace podtřídy třídy AsyncTask. Protože tato třída využívá obecné datové typy, není vytvoření její podtřídy tak jednoduché jako implementace rozhraní Runnable. Kontrola vlákna je však v tomto případě poměrně jednoduchá. AsyncTask obsahuje metody, které je možné přepsat: onpreexecute() se spouští v hlavním vlákně před vykonáním úlohy na pozadí. V této metodě je např. možné spustit widget ProgressDialog, který informuje uživatele o stavu procesu. doinbackground obsahuje kód, který je spuštěn ve vlákně na pozadí. onpostexecute() je spuštěna v hlavním vlákně po vykonání úlohy spuštěné na pozadí, zde je možné aktualizovat uživatelské rozhraní např. ukončit ProgressDialog. onprogressupdate() je volána, pokud je třeba dát uživateli najevo, že při vykonávání úlohy spuštěné na pozadí došlo k pokroku. 3.3 Databáze SQLite a práce s daty v OS Android V této kapitole je popsána zejména databáze SQLite a její využití v operačním systému Android. Dále jsou zde mimo jiné vysvětleny základy práce s třídami Cursor a ContentValues Databáze SQLite SQLite je vestavěná relační databáze, která je distribuována jako open-source projekt. Tento projekt vytvořil v roce 2000 Richard Hipp a dnes produkty obsahující databázi SQLite dodávají firmy jako Google, Adobe, Sun nebo Apple. Je také obsažena v mnoha dalších open-source projektech Mozilla, PHP, Python a další. (Owens, 2006) Na rozdíl od mnoha jiných databází nefunguje SQLite jako databázový server umístěný mimo samotnou aplikaci, která jej využívá. Tento server je vestavěný přímo v programu, který jej chce využívat, a každá tato aplikace tak obsahuje kompletní a soběstačný relační databázový systém. Samotnou databázi představuje jeden soubor v úložišti a veškerá aplikační logika serveru je systému dodána jako součást knihovny. Nativní rozhraní SQLite je naprogramováno v jazyce C, nicméně k dispozici jsou i jiná rozhraní API. Tato databáze používá pro manipulaci s daty dialekt jazyka SQL, který se v některých ohledech liší od standardů SQL-92 a SQL-99, což je ale poměrně běžné.

29 3.3 Databáze SQLite a práce s daty v OS Android 29 Základní rysy databáze SQLite uvádí Owens (2006): Nulová konfigurace konfigurace a správa systému jsou velmi jednoduché. Instalace spočívá pouze v poskytnutí knihovny SQLite. Přenositelnost - lze ji provozovat na různých operačních systémech (Windows, Linux, BSD, Mac OS X, ) a různých architekturách (16-bit, 32-bit, 64-bit). Kompaktnost SQLite byla navržena s ohledem na samostatnost a nízké paměťové nároky. Velikost celého systému (klient, server, virtuální stroj, ) není větší než 300 kb. Jednoduchost API SQLite je uživatelsky přívětivé a dobře dokumentované. Jelikož se jedná o otevřený systém, je navíc možné vytvořit nové SQL funkce v jazyce C. Flexibilita databázový systém je poměrně výkonný a flexibilní. Není třeba konfigurovat robustní databázové servery a rovněž odpadávají případné problémy se spojením. Navíc je systém nezávislý na platformě a je zdarma. Spolehlivost 97 % zdrojového kódu je pokryto testy. Komfort SQLite nabízí několik jedinečných funkcí jako je dynamické typování, řešení konfliktů nebo schopnost přistupovat k více databázím v jeden okamžik. Tato funkcionalita zvyšuje komfort práce s databází. Zajímavé srovnání databází SQLite a MySQL podává Schimpf (2012). Ten uvádí, že mezi výhody SQLite patří rychlost instalace (stačí programu poskytnout knihovnu SQLite), zabudovanost (vyhýbá se problémům se spojením) a jednoduché testování. Naopak oproti MySQL nepodporuje škálování (změna velikosti podle požadavků aplikace) a ani není možné nastavit uživatelská práva k datům může přistupovat každý, kdo má přístup k souboru. Největší rozdíl mezi SQLite a ostatními relačními databázemi však spočívá v typování dat. Ačkoliv při vytváření tabulek může vývojář specifikovat datový typ sloupců, systém ho bere pouze jako doporučení. Do sloupců typu Integer lze tedy vložit hodnoty typu řetězec a naopak. Data se typují prostřednictvím tzv. manifestu, kdy je datový typ přidělen samotné hodnotě a ne sloupci. SQLite specifikuje 5 nativních datových typů INTEGER, REAL, TEXT, BLOB a NULL. (Owens, 2006) Jelikož vývojář nemá možnost přesně specifikovat datové typy hodnot, je komfort práce s daty a časem nižší než např. v MySQL. Pokud je nutné využít některou z funkcí pro práci s datumy nebo časem (které SQLite nabízí), je třeba, aby byly hodnoty v databázi uloženy v některém z určených formátů. Lze pracovat s datem uloženým ve formátu YYYY-MM-DD a časem ve formátu HH:MM:SS.SSS, HH:MM:SS nebo HH:MM a případně jejich kombinací.

30 3.3 Databáze SQLite a práce s daty v OS Android SQLite v OS Android Do Android projektů není třeba knihovnu SQLite nijak dodávat je dodávána spolu se systémem. Původní verze systému Android obsahovala verzi databáze 3.5.9, v nejnovějších verzích (Jelly Bean, KitKat) je již SQLite verze Databáze jsou ukládány do úložiště typu flash, obvykle do interní paměti zařízení. Ačkoliv paměť samotná není příliš rychlá, čtení dat poměrně rychlé je odpadá nutnost přesouvání čtecích dat pevného disku. Zápis dat již tak rychlý není a navíc je jeho rychlost kolísavá v závislosti na objemu uložených dat a dalších aspektech. Někdy lze zápis provést za několik milisekund, jindy může tato operace trvat i stovky milisekund (i při ukládání malého množství dat). Proto je vhodné zapisovat data do databáze spíše na pozadí než v hlavním vláknu aplikace. (Murphy, 2011) K vytvoření databáze je vhodné použít třídu SQLiteOpenHelper, která obaluje logiku samotné databáze. Při vytváření podtřídy této třídy je nutné přepsat tři metody: Konstruktor zřetězený s konstruktorem třídy SQLiteOpenHelper. Metodu oncreate, která v parametru předává objekt třídy SQLiteDatabase. Tento objekt zastupuje samotnou databázi a zde je třeba jej naplnit tabulkami a případně i daty. Metodu onupgrade, která rovněž předává objekt třídy SQLiteDatabase. Zde je vhodné definovat operace, které budou provedeny v případě přechodu na novou verzi schématu. Pokud nejsou původní data důležitá, lze jednoduše odstranit původní tabulky a vytvořit nové. K modifikaci stávajících tabulek je možné využít SQL příkazu ALTER TABLE. (Allen, 2013) Pro provádění SQL dotazů nebo úpravu dat je třeba získat objekt třídy SQLiteDatabase. Toho lze dosáhnout pomocí metod třídy SQLiteOpenHelper pro zapisovatelnou databázi je zde metoda getwriteabledatabase() a getreadabledatabase() pro získání objektu databáze pouze pro čtení. Po dokončení práce s objektem SQLiteOpenHelper je důležité zavolat jeho metodu close(), která databázi uvolní. To je vhodné provést při ukončení aktivity v metodě ondestroy(). Jak uvádí Allen (2013), při práci s databází zastoupenou třídou SQLiteDatabase a SQL dotazy je možné využít některou z následujících metod: execquery() tato metoda nic nevrací, a proto ji nelze použít k vykonání SQL příkazu SELECT. V parametru je této metodě předáván příkaz SQL, který bude vykonán např. CREATE TABLE pro vytvoření tabulky, DROP TABLE pro smazání tabulky nebo INSERT INTO pro vložení řádku do tabulky. rawquery() výsledkem metody je objekt třídy Cursor, který je popsán v sekci Je tedy vhodné tuto metodu využít k vykonání SQL příkazu SELECT. Metodě je třeba předat dva parametry prvním je samotný příkaz a druhým je

31 3.3 Databáze SQLite a práce s daty v OS Android 31 pole hodnot, které jsou do příkazu doplněny na místo pozičních parametrů. Ty jsou v dotazu specifikovány zástupným znakem?, na jehož místo jsou hodnoty vloženy v uvedeném pořadí. Pokud dotaz neobsahuje poziční parametry, vloží se do parametru null. query() prostřednictvím této metody lze sestavit SQL příkaz SELECT pomocí jeho oddělených částí. V parametrech přebírá oddělené části příkazu, sestaví z nich dotaz a vrátí objekt typu Cursor. Metoda má, co se parametrů týče, více podob, na tomto místě budou zmíněny základní parametry: název tabulky pole s názvy hodnot, které je třeba vybrat volitelně klauzule WHERE a případně výčet hodnot, kterým se nahradí poziční parametry volitelně klauzule GROUP BY volitelně klauzule HAVING volitelně klauzule ORDER BY insert() pomocí této a dalších metod uvedených níže se lze do značné míry vyhnout syntaxi jazyka SQL (stejného výsledku lze však také dosáhnout prostřednictvím metody execsql()). Metoda insert slouží ke vkládání nového řádku do tabulky. Parametry jsou: název tabulky název sloupce, kterému se přiřadí hodnota null, pokud je následující parametr také null instance třídy ContentValues, která je popsána v sekci update() slouží k aktualizaci jednoho nebo více sloupců v jednom nebo více řádcích tabulky. Je jí třeba předat následující parametry: název tabulky instanci třídy ContentValues, reprezentující výčet sloupců a jejich aktualizovaných hodnot volitelně klauzule WHERE a případně výčet pozičních parametrů delete() odstraní jeden nebo více řádků tabulky. V parametrech přebírá: název tabulky volitelně klauzule WHERE a případně výčet pozičních parametrů

32 3.3 Databáze SQLite a práce s daty v OS Android Třída Cursor a třída ContentValues Jak již bylo zmíněno výše, výstupem metod výběrových dotazů je instance třídy Cursor, což je verze databázového kurzoru používaného v mnoha jiných systémech. (Smith a Friesen, 2011) Tato třída poskytuje metody, kterými je možné: procházet řádky kurzoru movetonext(), movetofirst(), isafterlast( zjistit počet řádků kurzoru getcount() přistupovat k jednotlivým sloupcům v řádku např. getstring(int columnindex) pro získání hodnoty typu řetězec, kde columnindex je pořadové číslo sloupce zjistit číslo sloupce podle jeho názvu getcolumnindex(string columnname) zavřít kurzor close() Následuje ukázka kódu, kde je nejprve za pomocí metody rawquery() získána instance třídy Cursor a následně jsou do konzole vypsány všechny jeho řádky na obrazovku. S t r i n g out = n u l l ; Cursor c u r s o r = db. rawquery ( SELECT name, surname FROM person, n u l l ) ; i f ( c u r s o r!= n u l l && c u r s o r. movetofirst ( ) ) { // pruchod kurzorem w h i l e (! c u r s o r. i s A f t e r L a s t ( ) ) { out = ; f o r ( i n t i =0; i <c u r s o r. getcount ( ) ; i ++){ out += c u r s o r. g e t S t r i n g ( i ) + ; } // v y p i s radku do k o n z o l e System. out. p r i n t l n ( out ) ; c u r s o r. movetonext ( ) ; } } Kurzor může být také poskytnut adaptéru (obvykle CursorAdapter nebo jeho podtřída), který je poté předán výběrovému kontejneru (např. ListView). Pokud je používán CursorAdapter, je nutné, aby kurzor obsahoval sloupec s názvem _id a jeho hodnoty byly jedinečné. Je také možné vytvářet své vlastní implementace třídy CursorAdapter. V tomto případě je třeba přepsat metody bindview() a newview(). Pokud je položka seznamu zobrazena poprvé, zavolá se pro ni nejprve metoda newview() a poté bindview(). Pokud je položka již recyklována, je volána pouze metoda bindview(). Jedná se o jiný způsob implementace metody getview() popsané v sekci 3.2.8, princip je však stejný. (Allen, 2013)

33 3.4 Informační systém QI a nástroj QI Builder 33 Další důležitou třídou při práci s databází SQLite je třída ContentValues, kterou lze přirovnat k přepravce párových hodnot. Tato třída implementuje rozhraní Map a navíc má dodatečné metody pro práci s primitivními datovými typy. Kromě standardní metody get(), která vrací instanci třídy Object lze tak např. využít i metody getasstring() nebo getasinteger(). Všem těmto metodám je předáno unikátní označení hodnoty, která má být vrácena. (Murphy, 2011) K vložení hodnoty do tabulky slouží metoda put(), která má dva parametry označení hodnoty a hodnotu samotnou. 3.4 Informační systém QI a nástroj QI Builder Tato část se zabývá Informačním systémem QI, jeho architekturou a distribucí. Dále je zde představen CASE nástroj QI Builder, s nímž úzce souvisí makrojazyk QI a webové služby, které je možné prostřednictvím tohoto nástroje vytvořit Informační systém QI QI je modulární ERP (Enterprise Resource Planning) informační systém, tedy systém pro plánování firemních zdrojů. Vytvořila jej a stále vyvíjí společnost DC Concept a. s., která byla založena v roce 2000 a QI uvedla na trh o rok později. Informační systém QI je jejím jediným produktem. (DC Concept, c2012) Systém je elastický, což znamená, že lze funkcionalitu do jisté míry přizpůsobit konkrétnímu zákazníkovi podle jeho představ. V současné době je QI složeno z 29 modulů a každý zákazník si tak může pořídit pouze moduly, které využije. Navíc je součástí systému QI builder, což je jedinečný CASE nástroj, pomocí kterého lze funkcionalitu přidávat nebo upravovat viz sekce 3.4.4). (Foltýn, 2013) Informační systém QI cílí na malé a střední společnosti s 1 až 250 zaměstnanci. Aktuálně (Březen 2014) má společnost DC Concept 789 zákazníků. (DC Concept, c2012) Architektura systému Architekturu systému popisuje ve své případové studii Foltýn (2013). QI je založeno na vícevrstvé architektuře systém je složen z několika vzájemně komunikujících vrstev. Tyto vrstvy jsou zobrazeny na obr. 6, struktura nasazení systému je pak na obr. 7. SQL server slouží pouze jako úložiště dat a nezajišťuje žádnou funkcionalitu, čímž je oddělena aplikační logika od dat samotných. Komunikace mezi aplikačním serverem a relačním SQL serverem je realizována prostřednictvím všeobecně uznávaného jazyka SQL. Jsou zde uložena jak aplikační data, která popisují samotného uživatele, tak funkční data popisující vzhled formulářů. QI podporuje databázové servery společnosti Microsoft od verze 2008 R2 a vyšší. Existují však také řešení pro jiné platformy (např. Oracle nebo Sybase).

34 3.4 Informační systém QI a nástroj QI Builder 34 Obrázek 6: Architektura QI (Foltýn, 2013) Datové rozhraní je realizováno pomocí softwarového API ODBC, které zprostředkovává přístup k databázovému serveru nezávisle na programovacím jazyku. Aplikační logika je zprostředkována aplikačním serverem, který je výkonnou částí celého systému. Server reaguje na požadavky uživatele a poskytuje mu data, která si vyžádá od SQL serveru. Dále také kontroluje přístupové nebo aktivační klíče, čímž lze měnit přístupová práva bez nutnosti restartu systému. Komunikační vrstva realizuje spojení mezi aplikačním serverem a grafickou podobou klienta pro MS Windows nebo Internet konektorem. Ke komunikaci je využíván protokol TCP/IP. Webové rozhraní poskytuje možnost práce se systémem prostřednictvím webového prohlížeče. O tuto možnost zobrazení se stará modul Internet konektor, který systém transformuje do prostředí webu. Uživatel není při práci ve webovém prohlížeči omezen z hlediska pohybu v systému, nicméně některá data se nepřenáší (např. zástupci na ploše). Vzhled webového uživatelského rozhraní lze přizpůsobit pomocí kaskádových stylů (CSS) Distribuce a implementace Pokud se společnost rozhodne pro koupi informačního systému QI, pořídí si ho jako službu, nikoliv jako krabicový software. S tím je spojeno hrazení poplatků za tento produkt existují dva druhy poplatků: základní poplatek je účtován na začátku platební periody. Jeho výše se pohybuje od 0 do 82 % z celkového poplatku podle toho, jak to zákazníkovi vyhovuje.

35 3.4 Informační systém QI a nástroj QI Builder 35 Obrázek 7: Struktura nasazení QI (Foltýn, 2013) licenční poplatek svojí výší odpovídá zbytku celkové částky, která nebyla uhrazena základním poplatkem. Tento poplatek je možné rozdělit na několik částí, které jsou hrazeny v průběhu platební periody. Počet zakoupených licencí a modulů lze měnit kdykoliv za chodu systému pouze na základě změny aktivačního klíče, který je dodáván výrobcem. (Foltýn, 2013) Na rozdíl od mnoha jiných informačních systémů není QI zákazníkovi implementováno samotným výrobcem. Společnost DC Concept má síť partnerů, kteří jsou rozděleni do skupin podle úlohy, kterou v procesu zastávají. Implementační partneři zavádí systém u samotného zákazníka. Týmy implementačních partnerů jsou složeny z odborníků certifikovaných výrobcem systému. Obchodní partneři se starají o získání nového zákazníka. Jejich náplní práce je zejména prezentace systému. Zároveň se spolu s implementačním partnerem podílí na zavedení systému u zákazníka. Vývojoví partneři mají za úkol tvorbu a modifikaci komponent systému a také provádí zakázkové úpravy dle potřeb zákazníka. Nastupují v momentě, kdy jsou požadované úpravy nad rámec možností implementačního partnera. Samotná implementace informačního systému QI není ohraničena pouhým zavedením systému do společnosti zákazníka. Předchází jí předinstalační analýza a následuje podpora provozu již zavedeného systému. Všechny tyto služby jsou neoddělitelnou součástí balíku, který si zákazník zakoupí. Implementace je tak možná pouze za účasti některého z partnerů. Společnost DC Concept přesně stanovuje metodiku implementace, která popisuje jednotlivé kroky od analýzy až po předání systému zákazníkovi. Je nezbytně

36 3.4 Informační systém QI a nástroj QI Builder 36 nutné, aby se na zavedení systému výrazně podílel také zákazník. Bez přesné specifikace jeho požadavků a jeho aktivního zapojení by nebylo možné dosáhnout kvalitního výsledku QI Builder Jak je zmíněno výše, součástí systému QI je i CASE nástroj nazvaný QI Builder, kterým lze modifikovat síťový datový model a programové funkce systému. Pomocí QI Builderu je možné upravit informační systém podle potřeb zákazníka vytvářet nebo upravovat grafické prvky systému (formuláře, dialogy, tiskové sestavy, ), programovat makra fungující v rámci systému, poskytovat webové služby a jiné. (Klčková a Sodomka, 2009) Datový model QI je velmi rozsáhlý a bylo by obtížné při práci s daty přistupovat přímo k jednotlivým třídám tohoto modelu. Proto je možné pracovat s tzv. datovými řezy, které jsou v systému již vytvořeny nebo může vývojář vytvořit svá vlastní. Datový model je složen jak z tříd obsahujících konkrétní záznamy, tak z tzv. vazebních tříd, skrze které je přistupováno k třídám s daty. Při programování maker je k jakémukoliv záznamu v systému QI (datový řez, třídy datového řezu, makro, webová služba, jednotlivý záznam v tabulce, ) přistupováno prostřednictvím jeho identifikátoru. Tento identifikátor je rozdělen na dvě části oddělené čárkou: IC specifikuje jednoznačný identifikátor v rámci licence systému U specifikuje licenci systému, ve kterém byl údaj vytvořen Makrojazyk QI V mnoha případech je třeba v QI obsloužit události, jako je např. volání webové služby, stisknutí tlačítka nebo uložení záznamu, svou vlastní funkcionalitou. K tomu v informačním systému QI slouží tzv. makra, vytvářená v editoru, který je součástí QI Builderu. QI definuje svůj vlastní objektový programovací jazyk, který svou syntaxí připomíná jazyk Pascal. Tento makrojazyk si neklade za cíl být komplexním programovacím jazykem, ale disponuje příkazy a funkcemi, kterými lze doplnit systém o analytické řešení. Makrojazyk disponuje základními datovými typy, strukturovanými příkazy, procedurami a funkcemi. Není však možné definovat vlastní datové typy. (Makrojazyk QI, 2011) Makrojazyk QI nepodporuje datový typ pole. Do značné míry však lze tento nedostatek odstranit prostřednictvím definovaných funkcí pro práci se seznamem řetězců (objekt třídy TStringList). Pomocí funkcí StringToSl() a SlToString() lze převádět řetězce na seznam a opačně. V parametru je vždy třeba zadat oddělovač řetězců.

37 3.4 Informační systém QI a nástroj QI Builder 37 Struktura a konstrukce překladače makrojazyka QI je popsána obr. 8. Obrázek 8: Struktura překladače makrojazyka QI (Makrojazyk QI, 2011) Zdrojový kód posloupnost znaků reprezentující algoritmus s požadovanou funkčností. Lexikální analýza náplní tohoto procesu je čtení znaků ze zdrojového kódu a jejich sestavení do posloupnosti lexikálních symbolů. Syntaktická analýza předpokladem pro úspěšné spuštění makra je bezchybné dokončení tohoto procesu. Posloupnost lexikálních symbolů je zde sestavena do hierarchické struktury, kterou tvoří např. výrazy, příkazy, procedury, atd. Interpretr na základě výstupu syntaktické analýzy vykonává příkazy zdrojového kódu. Debugger slouží k trasování programu a ladění chyb QI webové služby Architektura systému QI je servisně orientovaná (SOA Service Oriented Architecture). Pomocí nástroje QI Builder je možné vytvářet webové služby, jejichž cílem je zpřístupnit strojově snadno zpracovatelné zdroje, a tím i umožnit spolupráci systémů nezávisle na platformách. Jak uvádí Melzer (2007), webové služby v systému QI jsou založeny na protokolu SOAP, který byl zmíněn v sekci Seznam těchto služeb a také popis způsobu, jak tyto služby využívat, je klientovi poskytován prostřednictvím WSDL (Web Services Description Language). Na obr. 9 je zobrazena struktura webových služeb v QI.

38 3.4 Informační systém QI a nástroj QI Builder 38 Obrázek 9: Struktura webových služeb v QI (Melzer, 2007) Při samotné definici webové sloužby v nástroji QI Builder je zvykem uvádět identifikaci webové služby v systému, název služby, přiřadit obsluhující makro a specifikovat vstupní a výstupní parametry. Název služby stejně jako názvy jejích parametrů budou uvedeny v dokumentu WSDL. Počet, pořadí a typ parametrů by měl být shodný s parametry obslužného makra. Pro serializaci dat je v QI vhodné použít formát XML. Je zde připravená funkcionalita, díky které lze přesně definovat strukturu XML a na jejím základě dokument parsovat nebo vytvořit.

39 4 SOUHRN POŽADAVKŮ 39 4 Souhrn požadavků V této kapitole jsou specifikovány požadavky na funkcionalitu vyvíjené aplikace (funkční požadavky) a požadavky, které specifikují například uživatele nebo systém, na kterém bude aplikace spuštěna (nefunkční požadavky). Funkční požadavky jsou popsány také diagramem případů užití na obr Obecný popis Aplikace bude využívána ke vzdálenému přístupu ke konkrétní instanci informačního systému QI prostřednictvím mobilního zařízení. Tento software nebude sloužit jako plnohodnotná náhrada desktopového klienta QI účelem je zpřístupnit pouze vybrané funkce a data, které informační systém poskytuje. Komunikace se systémem bude realizována využitím webových služeb, které QI nabízí. K instanci tohoto informačního systému bude moci přistupovat každý uživatel, který je autorizován pro jeho využívání. Vzhledem ke své současné dominanci na trhu mobilních zařízení byl Android zvolen jako platforma, pro kterou bude aplikace vyvinuta. 4.2 Funkční požadavky Aplikace umožní vzdálený přístup do instance ERP systému QI se zaměřením na správu úkolů uživatele, správu kalendáře uživatele a správu obchodních partnerů. Uživatelé se budou do aplikace přihlašovat zadáním svého uživatelského jména a hesla, kterým se přihlašují do instance systému QI. Uživateli bude poskytnut přehled obchodních partnerů a jejich detailů bude zde možnost zobrazit všechny atributy obchodního partnera, které je možné zobrazit v systému QI. Obchodní partnery nebude prostřednictvím mobilní aplikace možné mazat ani editovat. Součástí sekce obchodních partnerů bude také správa jejich bankovních účtů a členů. Bude možné zobrazit detail osoby (atributy titul, jméno, příjmení, datum narození ) a detail bankovního účtu (atributy číslo účtu, název banky, kód banky, měna). Všechny zobrazené atributy v těchto sekcích bude možné editovat a jednotlivé položky odstranit nebo vložit nové. Uživatel bude mít možnost přiřadit k obchodnímu partnerovi nového člena z množiny všech osob, které jsou uloženy v konkrétní instanci QI. Jednotlivá členství bude také možné rušit. V sekci osob bude aplikace podporovat zobrazení jejich kontaktů. V detailu kontaktu budou uživateli zprostředkovány atributy popisující samotný kontakt a typ kontaktu, které bude možné editovat. Jednotlivé kontakty bude možné

40 4.3 Nefunkční požadavky 40 vytvářet a také odstraňovat. Aplikace nabídne podporu pro importování osob a jejich kontaktů do mobilního zařízení. Uživateli bude skrze aplikaci umožněna správa jeho úkolů přijatých a zadaných. U každého úkolu bude možné zobrazit všechny atributy, které je možné zobrazit v ERP QI. Prostřednictvím aplikace uživatel úkol vytvoří, edituje nebo odstraní. Při vkládání nového a editaci zadaného úkolu bude možné editovat pouze vybrané atributy název úkolu, realizátor úkolu, předpokládaná spotřeba času, časová jednotka, druh úkolu, popis úkolu a kód nadřízené akce. U přijatého úkolu bude moci uživatel editovat atributy název úkolu, čas zahájení, čas ukončení, druh úkolu, kód nadřízené akce a popis realizace. Aplikace bude zahrnovat správu kalendářních aktivit uživatele v systému QI. Uživatel bude moci aktivity editovat, vytvářet a odstraňovat. V této sekci mu bude umožněno pracovat se všemi atributy, se kterými může pracovat v QI. Viditelnost všech zobrazovaných atributů v aplikaci bude parametrizovatelná pro jednotlivé uživatele. Předpokládá se, že může nastat situace, kdy bude jedno zařízení využívat více uživatelů QI. Data přenášená při komunikaci budou šifrována vybraným algoritmem. 4.3 Nefunkční požadavky Mobilní aplikace bude vyvinuta pro platformu Android a bude ji možné využívat od API verze 2.2. Bez připojení k Internetu není možné aplikaci využívat. Aplikace nebude volně distribuována (např. prostřednictvím služby Google Play). K napojení na konkrétní instanci systému QI bude třeba zásahu programátora, který nastaví adresu serveru na straně klienta a implementuje webové služby a makra na straně QI. Uživatel aplikace bude jakýkoliv autorizovaný uživatel konkrétní instance ERP QI.

41 4.3 Nefunkční požadavky 41 Obrázek 10: Diagram případů užití

42 5 ANALÝZA A NÁVRH 42 5 Analýza a návrh Obsahem této kapitoly je analýza a návrh celého systému. Je zde navržen datový model aplikace, statická struktura systému, procesy, které v systému probíhají a uživatelské rozhraní. 5.1 Datový model Stěžejním bodem celého návrhu je volba mezi aplikací bez vlastní databáze a aplikací, která všechna získaná data ukládá do databáze SQLite. Mezi výhody aplikace bez vlastní databáze patří jednodušší implementace a vyšší bezpečnost (data jsou v zařízení uložena pouze dočasně). Navíc také odpadá nutnost synchronizace databáze. Nevýhodou je však přenášení vyšších objemů dat (při každém načtení seznamu je třeba přenést celý seznam apod.), což při využívání mobilních dat může být problém. Výhodou řešení s vlastní databází je také možnost budoucího rozšíření aplikace o offline prohlížení dat. Ze dvou výše zmíněných důvodů bylo přistoupeno k návrhu aplikace, která bude obsahovat databázi SQLite. Do této databáze budou ukládána veškerá data získaná z QI serveru a data získaná vstupem od uživatele. Na obr. 11 je zobrazen entitně-relační diagram (ERD), což je návrh datového modelu. Tento model zahrnuje hlavní tabulky, jako např. úkol, obchodní partner nebo kalendářní aktivita, a také tabulky, do kterých budou ukládány tzv. číselníky např. typ kontaktu, banka, měna apod. Dále je zde navržena podpora pro parametrizaci viditelnosti atributů jednotlivých uživatelů. Jak bylo zmíněno v sekci 3.3.1, databáze SQLite podporuje pouze 5 datových typů, které je možné přiřadit jednotlivým sloupcům, a navíc je toto přiřazení typu sloupci bráno pouze jako doporučení. Jediným zástupcem řetězcového datového typu je typ TEXT, který byl přiřazen všem atributům určeným pouze pro čtení a také např. atributům určujícím datum nebo čas. Identifikátory jednotlivých řádků v tabulkách se budou shodovat s identifikátory položek v systému QI. Ty se skládají ze dvou částí oddělených čárkou (viz sekce 3.4.4), a proto bude doporučeným datovým typem pro tyto atributy typ TEXT. 5.2 Systém Systém byl navržen jako několik tříd reprezentujících jednotlivé Android aktivity (dědí od třídy Activity) a dále několik tříd, které tyto aktivity využívají. Základní návrh systému je reprezentován doménovým modelem (typ diagramu tříd) na obr. 12. Mezi aktivity patří např. třída LoginActivity, která bude obsluhovat přihlášení uživatele, nebo třída MenuActivity, která nabídne hlavní menu aplikace. Dále zde budou aktivity reprezentující formuláře a třída SelectActivity, která bude zastupovat seznamy a uživateli zprostředkuje možnost výběru.

43 5.2 Systém 43 Obrázek 11: ER diagram

44 5.2 Systém 44 Jelikož bude aplikace uživateli poskytovat správu svého kalendáře v informačním systému QI, je třeba navrhnout s tím související aktivity. Třída CalendarActivity zprostředkuje výběr konkrétního dne z grafického kalendáře a třída DayActivity zobrazí Ganttův diagram reprezentující jednotlivé události vybraného dne. Výše zmíněné aktivity pak využívají služeb (metod), které nabízí třídy zmíněné v následujících sekcích Třída DatabaseManager Tato třída bude dědit od třídy DbHelper a jejím prostřednictvím bude přistupováno k databázi SQLite. Bude zde třeba implementovat metody pro vytvoření databáze, její smazání a také metody, které usnadní práci s touto databází. V metodě oncreate() bude implementována funkcionalita, která zajistí vytvoření tabulek v databázi a případně naplnění základními daty. Tato metoda je volána při vytvoření databáze. Metoda onupgrade() je volána při přechodu na novou verzi databáze. Budou v ní odstraněny všechny tabulky a vytvořeny nové. Metoda getstringvaluesfromid() vrátí vybrané atributy konkrétního řádku jako řetězec. Metoda getvaluesfromid() vrátí instanci třídy ContentValues obsahující atributy vybraného řádku. Metoda getidfromvalue() vrátí ID řádku, jehož vybraný sloupec obsahuje hledanou hodnotu. Metoda adduser() umožní přidat nového uživatele do databáze. Budou zde vytvořeny nové záznamy v tabulce atributů, čímž bude možné implementovat podporu parametrizace viditelnosti atributů. Metoda isuserindb() podle přihlašovacího jména zjistí, zda je uživatel v databázi již uložen. Součástí třídy DatabaseManager je také třída DbCreatorAsyncTask, která dědí od třídy AsyncTask (viz sekce ). Jejím účelem je vytvoření databáze na pozadí aplikace a navíc zde bude implementována metoda deletecontent(), která se postará o vymazání obsahu databáze Třída FormGenerator Jelikož je celá aplikace založena zejména na formulářích, bude třeba poskytnout podporu pro jednoduché vkládání jednotlivých polí. Základní prvky těchto formulářů jsou v systému Android reprezentovány widgety EditText (editovatelné pole),

45 5.2 Systém 45 Obrázek 12: Diagram tříd

46 5.2 Systém 46 TextView (needitovatelné pole) a CheckBox (zaškrtávací pole). Tyto prvky jsou podrobně popsány v sekci Za účelem vkládání těchto polí budou implementovány metody inserteditable- Field(), insertnoneditablefield() a insertcheckbox(). Mimo jiné bude v těchto metodách řešeno automatické načítání obsahu z databáze, nastavení titulku polí a další funkcionalita Třída InputManager Ve formulářích, které obsahují uživatelem editovatelný obsah, je třeba kontrolovat zda byla vyplněna všechna povinná pole, nebo např. zda uživatel provedl ve formuláři nějakou změnu. K podpoře této a jiné funkcionality budou implementovány následující metody. Metoda checkrequired() provede kontrolu vyplnění povinných polí. Metoda checkrequiredpair() provede kontrolu vyplnění polí, které je nutné vyplnit párově mohou být vyplněna obě nebo žádné. Metoda issame() ověří, zda uživatel provedl v editované položce nějakou změnu. Metoda isempty() zjistí, zda je formulář prázdný. Metoda insertemptyfields() vloží zástupný řetězec na místo prázdných polí. Tato metoda bude využita při odesílání změn na server v případě, kdy uživatel smaže obsah vyplněného pole. Tato funkcionalita bude podrobněji vysvětlena v sekci Třída QiConnector Účelem aplikace je zpřístupnění určité funkcionality a dat konkrétní instance informačního systému QI. Z tohoto důvodu je součástí návrhu třída QiConnector, která bude obsluhovat komunikaci mezi klientskou Android aplikací a aplikačním serverem QI. Součástí této třídy jsou metody pro parsování a vytvoření XML dokumentu a také třída QiAsyncTask, která bude popsána níže. Metoda createxml() zajistí na základě obsahu instance třídy ContentValues vytvoření XML dokumentu, který bude odeslán na server. Metoda parsexml() přijme XML dokument odeslaný z QI serveru, rozparsuje ho a provede příslušné operace v databázi. V novějších verzích systému Android je požadováno, aby veškerá komunikace prostřednictvím sítě Internet byla prováděna mimo hlavní vlákno aplikace. (Allen, 2013)

47 5.2 Systém 47 Proto budou veškeré metody, jejichž implementace zahrnuje komunikaci s aplikačním serverem QI, volány na pozadí. Zmíněné metody jsou navrženy jako součást třídy QiAsyncTask (dědí od třídy AsyncTask) a budou využívat makra, implementovaná na straně aplikačního serveru. Patří sem metody pro přihlášení a odhlášení uživatele (login(), logout()), pro importování položek ze serveru (v diagramu předpona receive), pro vkládání a editaci položky (v diagramu předpona send) a také pro odstranění položky removeitem(). Jelikož změnou rotace displeje dojde k restartování spuštěné aktivity, budou jako součást třídy QiAsyncTask implementovány metody pro zamknutí a odemknutí rotace obrazovky (lockscreenrotation() a unlockscreenrotation()). Účelem této funkcionality je zabránění otočení orientace displeje při komunikaci mezi aplikací a serverem. Ještě před zamknutím rotace displeje bude pomocí metody isonline() zjištěno, zda je mobilní zařízení připojeno k síti Internet, a pokud nastane během komunikace chyba, bude logována do souboru vytvořeného v paměti zařízení (writeexceptionintofile()). Dále bude tato třída obsahovat metody obtainuserid pro zjištění ID autentizovaného uživatele a getdownloaditems pro vytvoření seznamu již stažených položek více v sekci Součástí zadání práce je také požadavek na bezpečnost používání aplikace. Přenášená data proto budou šifrována vybraným algoritmem. Šifrování a dešifrování dat bude provedeno v metodách encrypt() a decrypt() Třída AppSettings Jak bylo popsáno v sekci 3.2.9, Android disponuje třídou SharedPreferences, kterou lze využít pro ukládání nejen uživatelských dat. Právě instanci této třídy a metody, které tuto instanci využívají, bude obsahovat třída AppSettings. Výhodou je, že tímto způsobem lze k datům přistupovat a ukládat bez inicializace databáze a zároveň jsou uložena i v době, kdy není aplikace spuštěna. Do instance třídy SharedPreferences budou ukládána data popsaná níže. ID aktuálně přihlášeného uživatele. Volba, zda má být provedena úplná synchronizace (včetně detailů položek více v sekci 5.3.2). Ticket, získaný při přihlášení (řetězec, který je předáván jako parametr webových služeb). První start aplikace po přihlášení uživatele bude třeba provést synchronizaci databáze. K identifikaci prvního startu aktivity (aktivita může být restartována pouhým otočením displeje) bude sloužit atribut typu boolean ve třídě SharedPreferences.

48 5.3 Procesy Procesy V další části budou mimo jiné popsány procesy synchronizace aplikace s aplikačním serverem QI, ukládání záznamu, přihlášení uživatele a také proces pohybu uživatele v aplikaci. Většina diagramů aktivit, které popisují procesy v systému, byla umístěna do přílohy A. Jak uvádí Miles (2006), k modelování procesů slouží v UML 2.0 diagram aktivit. Na obr. 13 je diagram aktivit popisující proces pohybu uživatele v aplikaci. Vzhledem k rozsáhlosti obsahu tohoto procesu byl diagram na několika místech zjednodušen a aktivity jako např. přihlášení nebo synchronizace databáze budou vysvětleny na separátních diagramech. Ze stejného důvodu nejsou v tomto diagramu zakresleny zpětné kroky, nicméně je známo, že uživatel se může přesunout na předchozí aktivitu stisknutím tlačítka zpět Přihlášení uživatele Proces přihlášení uživatele popisuje diagram aktivit na obr. 23 v přílohách. Do instance systému QI se může přihlásit každý jeho autorizovaný uživatel zadáním svého přihlašovacího jména a hesla, přičemž heslo není povinné. Po zadání údajů uživatelem a požadavku na přihlášení pokračuje procedura kontrolou přihlašovacích údajů na aplikačním serveru QI. Pokud je odpověď systému kladná, uživatel je přihlášen. V opačném případě uživatel může opětovně zadat přihlašovací údaje nebo aplikaci ukončit Synchronizace databáze Podstatným bodem analýzy a návrhu je synchronizace databáze. Jelikož je vývojář v tomto případě omezen funkcionalitou QI Builderu, nebude možné databázi synchronizovat při každé změně, která bude provedena mimo samotnou aplikaci. Databáze bude synchronizována po úspěšném přihlášení uživatele (při startu MenuActivity). Mobilní aplikace prostřednictvím webové služby odešle aplikačnímu serveru QI požadavek na synchronizaci konkrétní kategorie (např. úkolů) společně se seznamem identifikátorů aktuálně stažených položek. Odpovědí bude v ideálním případě XML soubor obsahující položky (včetně jejich detailů), které dosud nebyly staženy a ID položek, které byly odstraněny mimo mobilní aplikaci. Proces synchronizace popisuje diagram aktivit na obr. 22. To znamená, že nebude možné rozeznat změnu, která byla provedena mimo samotnou aplikaci v některé z již stažených položek. Tento nedostatek lze částečně odstranit volbou kompletní synchronizace, kdy je před samotnou synchronizací smazán obsah tabulek v databázi a následně jsou přeneseny všechny položky. Tuto možnost bude uživatel moci zvolit v nastavení aplikace, je však nutné vzít v úvahu vyšší objem přenášených dat a s tím spojenou delší dobu synchronizace. Jak je však vidět na obr. 24, jedinou výhodou, kterou uživatel kompletní synchronizací oproti synchronizaci základní získá, je aktualizace řetězců, které zastupují

49 5.3 Procesy 49 položky v seznamech (např. název obchodního partnera). Poté, co uživatel vybere položku ze seznamu, je na server odeslán požadavkem s ID položky. Server odpoví odesláním detailu položky, která bude následně aktualizována v databázi mobilní aplikace a zobrazena uživateli Vložení a odstranění položky Proces vložení/editace a odstranění položky je popsán diagramy na obr. 25 a 26. Uživatel bude položku moci uložit stisknutím tlačítka zpět nebo stisknutím tlačítka uložit. Poté bude aplikací zkontrolováno, zda byly ve formuláři provedeny nějaké změny a pokud ano, dojde k odeslání položky na server. V případě kladné odpovědi serveru bude položka uložena také do databáze mobilní aplikace. Odstranění položky uživatel provede ve výběrové aktivitě, případně v aktivitě Ganttova diagramu. Opět bude třeba vyčkat na kladnou odpověď serveru (položka byla ze serveru odstraněna) a až poté položku odstranit i z databáze mobilní aplikace.

50 5.3 Procesy 50 Obrázek 13: Diagram aktivit proces pohybu uživatele v aplikaci

51 5.4 Návrh uživatelského rozhraní Návrh uživatelského rozhraní Cílem návrhu uživatelského rozhraní je uživatelsky přívětivá a intuitivní mobilní aplikace. Aby bylo možné takové aplikace dosáhnout, je třeba se řídit návrhovými vzory, které definují, jak uživatelské rozhraní vhodně navrhnout. Návrhové vzory uživatelských rozhraní popisuje Tidwell (2010). Na tomto místě bude zmíněno několik vybraných vzorů, kterými byl návrh uživatelského rozhraní řízen. Safe exploration je třeba, aby měl uživatel pocit, že může aplikaci prozkoumat bez toho, aby změnil něco zásadního, a tím se dostal do problému. Instant gratification uživatel by měl okamžitě vidět důsledky svých akcí. Například pokud vloží nový záznam do databáze, měl by se okamžitě zobrazit v aktualizovaném seznamu. Clear entry points uživatel se v aplikaci musí dobře orientovat a mělo by mu být jasné, kterou akcí se přiblíží ke svému cíli. One window drilldown veškerý obsah aplikace je vnořen pouze do jednoho okna. Pokud dojde k zobrazení nového obsahu, bude překryta původní obrazovka. Jelikož se v případě této práce jedná o mobilní aplikaci, nemá smysl ji rozdělovat do více oken. Structured format formuláře aplikace budou obsahovat jak pole, do kterých uživatel bude moci zadat jakýkoliv text, tak pole, která vyžadují strukturovaný formát zápisu (např. datum). Aplikace bude pro získání strukturovaného formátu využívat např. widgety pro nastavení data a času. Fill in the blanks do některých polí ve formuláři bude uživatel vybírat jednu z několika nabízených možností ze seznamu. Input prompt v případě editovatelných polí, u kterých by nemuselo být uživateli jasné, co přesně do tohoto pole vložit, je vhodné využít vzor Input Hint nebo Input Prompt. Zatímco hint je text poblíž pole, prompt je krátký text uvnitř editovatelného pole. Autocompletion prostřednictvím automatického doplňování textu lze zvýšit komfort zadávání textu. Tohoto vzoru je možné využít, pokud jsou známé přípustné nebo často zadávané sekvence, jako např. přihlašovací jméno. Same page error messages pokud nastane chyba (např. nebudou vyplněna všechna povinná pole), bude o ní uživatel informován prostřednictvím zprávy zobrazené ve stejném kontextu. U mobilních aplikací Android se k zobrazení upozornění využívá tzv. Toast, což je zpráva zobrazená v popředí po dobu několika sekund. (Murphy, 2011)

52 5.4 Návrh uživatelského rozhraní 52 Vertical stack vzor určený zejména mobilním aplikacím. Jednotlivé widgety je vhodné vkládat do vertikálního sloupce, jehož obsah může uživatel posouvat. Výše zmíněnými a dalšími vzory byl řízen také návrh designu uživatelského rozhraní obr. 14, 15 a 16. Obrázek 14: Návrh designu uživ. rozhraní pro aktivitu přihlašování a menu

53 5.4 Návrh uživatelského rozhraní 53 Obrázek 15: Návrh designu uživ. rozhraní aktivity výběru a formuláře Obrázek 16: Návrh designu uživ. rozhraní pro aktivitu kalendáře a Ganttova diagramu

54 6 IMPLEMENTACE 54 6 Implementace V této kapitole bude popsán způsob implementace klientské Android aplikace a maker na straně aplikačního serveru QI. 6.1 Klient Systém identifikátorů atributů Aby bylo možné efektivně pracovat s jednotlivými atributy v tabulkách databáze, je třeba zavést systém identifikátorů, které budou tyto atributy zastupovat. Systém Android umožňuje vytvořit identifikátory v XML souboru, ke kterým je z kódu možné přistupovat jako ke zdrojům. Syntaxe vytvoření nového identifikátoru je následující. <r e s o u r c e s > <item name= p a r t n e r T i t l e </r e s o u r c e s > type= id > p a r _ t i t l e </item> Android při kompilaci ke každému zdroji vytvoří celočíselnou hodnotu, která tento zdroj zastupuje. Prostřednictvím konvence Context.getResources().get- String(R.id.partnerTitle) lze získat z identifikátoru definovaný řetězec v tomto případě par_title. Takto definovaný identifikátor má jak řetězcovou, tak i celočíselnou složku (R.id.partnerTitle). Ke každému atributu v databázi byl přiřazen identifikátor, který reprezentuje název atributu. Prostřednictvím tohoto identifikátoru pak lze jednoduše přistupovat k jednotlivým atributům v tabulkách. Tuto funkcionalitu by bylo možné nahradit vytvořením třídy, která obsahuje pouze konstanty řetězcového typu, což by pravděpodobně bylo jednodušší řešení. Jak však bude zmíněno v sekci 6.1.3, formulářovým prvkům jsou přiřazeny stejné identifikátory jako atributům, které tyto prvky zastupují. A zatímco názvy atributů v databázi SQLite musí být řetězcového typu, identifikátory, které lze v systému Android jednotlivým prvkům v návrhu přiřadit, jsou typu celočíselného. Databázovým atributům tak bude přiřazena řetězcová forma identifikátoru a prvkům v návrhu forma číselná. Dále byly tyto identifikátory atributů využity při práci s přepravkou párových hodnot ContentValues a také při vytváření a parsování XML souborů Parametrizace viditelnosti atributů Jak bylo zmíněno v kapitole č. 4, jedním z požadavků na aplikaci je parametrizace viditelnosti atributů jednotlivých uživatelů. Z ER diagramu vyplývá, že každému uživateli v databázi náleží atributy, které spadají do určitých kategorií. Tyto položky reprezentují veškeré atributy, které jsou uživateli zobrazeny ve formulářích například jméno nebo příjmení osoby.

55 6.1 Klient 55 Poté, co se nový uživatel mobilní aplikace úspěšně přihlásí do systému, je tento uživatel vytvořen v databázi a s ním také všechny atributy, které jsou základně nastaveny jako viditelné. Viditelnost většiny těchto atributů pak lze změnit prostřednictvím nastavení v jednotlivých sekcích (detail obchodního partnera, osoby, úkolu, ) nebo z aktivity zastupující menu. Ukázka nastavení viditelnosti atributů úkolu je na obr. 17. Obrázek 17: Aktivita pro nastavení atributů Za účelem podpory této funkcionality byla implementována aktivita SimpleSettingActivity pro jednoduché zobrazení přehledu atributů a aktivita TabsSettingActivity pro zobrazení atributů ve více záložkách. Vstupem do těchto aktivit je název kategorie atributů, které mají být zobrazeny. Jednotlivé položky (atributy) seznamu jsou obsahem kontejneru ListView, který je plněn přímo z databáze prostřednictvím adaptéru SettingItemAdapter (dědí od třídy CursorAdapter). Implementace adaptéru využívá recyklace prvků seznamu, čímž jsou sníženy nároky na výkon. Návrh řádku zmíněného seznamu obsahuje popisek (TextView), reprezentující název atributu a zaškrtávací pole (CheckBox), kterým uživatel ovládá viditelnost konkrétního atributu. Při plnění seznamu je každému řádku nastaven tzv. tag, nesoucí identifikátor řádku v tabulce atributů. Pokud uživatel změní stav zaškrtávacího pole, je tento stav na základě tohoto identifikátoru změněn také v databázi Formulářová aktivita Jelikož je aplikace založená zejména na formulářích, bylo třeba implementovat aktivitu, která formulář zobrazí, umožní uživateli editovat vybraná pole, odešle záznam na server, apod. Jak již bylo navrženo v diagramu tříd, budou jednotlivé formuláře rozděleny do separovaných aktivit. K tomuto řešení bylo přistoupeno zejména z důvodu přehlednosti a jednoduchosti jednotlivých aktivit. Pokud by veškeré formuláře byly vtěsnány

56 6.1 Klient 56 do jedné aktivity, byla by tato aktivita velmi nepřehledná. Naopak nevýhodou tohoto řešení je složitější implementace změn, které není možné provést na jednom místě. Za účelem jednoduchého generování formulářových polí byla implementována třída FormGenerator. Tato třída umožňuje vložit needitovatelné pole TextView, editovatelné pole EditText a zaškrtávací pole CheckBox. Tato pole jsou vkládána do kontejneru LinearLayout s vertikální orientací. Generování formuláře probíhá v metodě oncreate(), kdy jsou do přepravky ContentValues načteny hodnoty konkrétního záznamu z databáze (pokud se nejedná o vkládání nového záznamu). Tato přepravka je následně předložena instanci třídy FormGenerator, která na základě hodnot v přepravce vyplní generovaná pole. Dále je v metodách této třídy implementována podpora viditelnosti jednotlivých atributů. Z databáze je získán údaj o viditelnosti konkrétního atributu a na jeho základě nastavena viditelnost vkládaného prvku. Ke kontrole vstupu od uživatele a případně vložení zástupného řetězce prázdného pole je využívána třída InputManager. Při parsování XML na straně QI je prázdný element považován za bezvýznamný a QI se chová, jako by tento element nebyl v dokumentu obsažen. To je problém v případě, kdy uživatel v mobilní aplikaci smaže obsah pole na server je odeslán prázdný element, který QI nepovažuje za důležitý a není tak možné aktualizovat konkrétní atribut. Z tohoto důvodu je třeba do takového elementu vložit řetězec, který zastupuje prázdný řetězec a přizpůsobit tomu makra webových služeb na straně QI. Pokud uživatel chce opustit aktivitu (stisknutím tlačítka zpět nebo uložit ), je nejprve zjištěno, zda má smysl provádět další kontroly a případně záznam uložit na server a do interní databáze. V případě vkládání nového záznamu je kontrolováno, zda je formulář prázdný a v případě editace již vloženého záznamu, zda byly provedeny nějaké změny. Pokud se jedná o editaci záznamu, je základem vytvoření nové instance třídy ContentValues a její naplnění aktuálním obsahem polí formuláře, což zajišťuje metoda getcurrentvalues(), kterou implementují jednotlivé aktivity. Tato instance je pak srovnána s instancí naplněnou v metodě oncreate(), která byla předávána třídě FormGenerator. Pokud má smysl záznam ukládat, je volána metoda checkrequired(), které je předáno pole identifikátorů atributů, na jehož základě je provedena kontrola vyplnění povinných polí. Jakmile je možné záznam uložit, je využita metoda createxml() třídy QiConnector k sestavení XML dokumentu. Získané XML je následně předáno některé z metod, které prostřednictvím webových služeb volají makra pro uložení záznamu. V případě, že se záznam podaří uložit na straně serveru, je uložen také v interní databázi.

57 6.1 Klient 57 Ukázka formulářové aktivity pro editaci události v kalendáři je na obr. 18. Obrázek 18: Formulářová aktivita Výběrová aktivita Za účelem možnosti výběru položky ze seznamu byla implementována aktivita SelectActivity. Stejně jako u aktivity pro nastavení atributů jsou jednotlivé položky součástí kontejneru ListView, který je plněn přímo z databáze prostřednictvím vlastní implementace třídy CursorAdapter. Tato implementace opět využívá systému recyklace prvků pro snížení nároků na výkon. Kromě výběru samotné položky umožňuje výběrová aktivita jednotlivé položky také odstraňovat. SelectActivity je parametrizovaná pomocí přepravky Bundle, kterou je možné přiložit k záměru. Spouštěcí aktivita musí výběrové aktivitě mimo jiné sdělit dotaz, kterým budou z databáze načtena data, název tabulky, kód aktivity, která bude spuštěna v případě výběru položky, zda má obsahovat tlačítko pro přidání záznamu do seznamu a jaká akce bude provedena po stisknutí tohoto tlačítka, zda mají jednotlivé položky obsahovat tlačítko pro odstranění záznamu, titulek, který bude zobrazen v horní části aktivity. Kliknutí uživatele na položku je odchyceno posluchačem OnItemClickListener v metodě onitemclick(). Pokud je aktivita spuštěna za účelem výběru položky

58 6.1 Klient 58 (např. z číselníku), kdy není cílem spustit další aktivitu, je výběrová aktivita ukončena a spouštěcí aktivitě je sdělen výsledek. Součástí výsledku je také identifikátor vybrané položky. V případě, kdy je cílem zobrazit detail vybrané položky, je tuto položku nejprve třeba aktualizovat. K tomu jsou využívány metody třídy QiAsyncTask, pro exportování položek z QI do mobilní aplikace mimo hlavní vlákno. SelectActivity implementuje rozhraní Callback a přepisuje metodu handle- Message(), ve které je zachycena zpráva vyslaná třídou QiAsyncTask po dokončení úlohy na pozadí. Tato zpráva nese informaci o tom, zda byla prováděná úloha dokončena bez problémů, a pokud ano, tak také, zda je tato zpráva reakcí na úlohu aktualizace položky nebo její odstranění. V případě odstranění je položka vymazána rovněž z interní databáze a v případě aktualizace je spuštěna vybraná aktivita. Formulářové aktivity jsou spouštěny metodou startactivityforresult(), aby bylo možné identifikovat jejich ukončení a v metodě onactivityresult() aktualizovat seznam. Aby se uživatel mohl v seznamu rychleji orientovat, poskytuje výběrová aktivita možnost vyhledávání. Za tímto účelem bylo implementováno rozhraní TextWatcher, díky kterému je možné reagovat na změnu textu ve vyhledávacím poli (EditText). Jakmile dojde ke změně, je z databáze získán aktualizovaný kurzor, který je předán metodě adaptéru changecursor(). Ukázka výběrové aktivity je na obr. 19. Obrázek 19: Výběrová aktivita Aktivita kalendáře a aktivita denních událostí K organizaci svého QI kalendáře z mobilní aplikace může uživatel využít aktivitu CalendarActivity pro výběr data a DayActivity pro zobrazení Ganttova dia-

59 6.1 Klient 59 gramu. Jelikož se návrh těchto aktivit mění v závislosti na konkrétním měsíci či vybraném dni, bylo třeba některé prvky návrhu vytvářet dynamicky přímo v kódu. Kalendář je zobrazen pomocí pole o velikosti 7 6 prvků, reprezentující jeden měsíc. Jednotlivé prvky jsou vkládány do kontejneru LinearLayout s horizontální orientací reprezentující řádek a jednotlivé řádky do kontejneru stejného typu s vertikální orientací. Každému prvku je nastaven posluchač pro zachycení kliknutí uživatele na prvek (OnClickListener), a dále prvky nesou instance třídy Object tzv. tagy. Tyto tagy identifikují den, měsíc a rok, které prvek reprezentuje, a jsou využívány v metodě onclick(), kde je spuštěna aktivita pro zobrazení Ganttova diagramu vybraného dne. Při generování prvků je z databáze zjišťováno, zda jednotlivé dny obsahují alespoň jednu aktivitu. Na tomto základě jsou pak dny vizuálně odlišeny, aby měl uživatel přehled, ve kterých dnech má v kalendáři něco naplánováno. K výběru roku a měsíce lze využít widgety typu Spinner, které po kliknutí zobrazí uživateli seznam, ze kterého je možné vybrat jednu položku. Měsíce lze také přepínat pohybem prstu doleva nebo doprava a roky pohybem nahoru a dolů. Za tímto účelem byla vytvořena vlastní implementace rozhraní OnTouchListener. Kalendářní události jsou v QI rozděleny na časové a celodenní. Aktivita pro zobrazení událostí vybraného dne zobrazuje v horní části výpis názvů celodenních událostí a pod nimi Ganttův diagram událostí časových. Ganttův diagram byl implementován pomocí tabulkového kontejneru Table- Layout. Nejprve jsou zjištěny časy, které je třeba zobrazit, a poté vytvořeny prvky zastupující jednotlivé aktivity. Časy jsou zobrazeny widgetem TextView a rozestup mezi nimi je půl hodiny. Jednotlivé události se mohou překrývat. Způsob implementace Ganttova diagramu v tabulkovém kontejneru je zřejmý z obr. 20. Jak titulkům Obrázek 20: Ganttův diagram implementovaný v kontejneru TableLayout aktivit, tak i všem buňkám tabulky, které aktivity představují, je přiřazen posluchač

60 6.1 Klient 60 OnClickListener. Těmto prvkům je také přidělen tag, nesoucí informaci o identifikátoru události. Uživatelovo kliknutí na událost je odchyceno v metodě onclick(), ve které je spuštěna formulářová aktivita s detailem vybrané události. Obrázek 21: Aktivita kalendáře a Ganttova diagramu Generování a parsování XML Komunikace mezi Android aplikací a aplikačním serverem QI je založena na formátu XML, který byl popsán v sekci Metody pro vytvoření a parsování XML byly implementovány jako součást třídy QiConnector a využívají tříd standardních Java balíčků javax.xml.parsers a javax.xml.transform. Metoda createxml() se na základě instance třídy ContentValues předané v parametru postará o vytvoření řetězce ve formátu XML. Kořenový element nese název tabulky (např. person ) a jeho následovníky jsou elementy, pojmenované stejně jako klíče (identifikátory atributů) v předané instanci ContentValues. Za účelem zpracování formátu XML na základě předloženého řetězce byla implementována metoda parsexml(). Tuto metodu je možné využívat pro následující formát. <root > <added_items> <person> <first_name >Jan</first_name > <last_name>novák</last_name> </person> </added_items> <removed_items>

61 6.1 Klient 61 <person >154,9999< person> <bank_account >165,9999 < bank_account> </removed_items> </root > V tomto konkrétním případě server aplikaci sděluje, že má do databáze přidat novou osobu se jménem Jan Novák a dále je třeba z databáze odstranit dvě položky osobu s identifikátorem 154,9999 a bankovní účet s ID 165,9999. Element přidané nebo aktualizované položky nese název tabulky, ve které se změny mají provést. Jeho následovníky jsou další elementy, jejichž hodnoty reprezentují hodnoty databázových atributů totožného jména, jako je označení těchto elementů. Odebrané položky jsou zastoupeny pouze jedním elementem, jehož hodnota reprezentuje identifikátor v tabulce pojmenované stejně jako tento element. Díky tomuto principu je možné XML zprávy odeslané z aplikačního serveru jednoduše parsovat a automatizovaně provádět změny v databázi Komunikace s aplikačním serverem QI Veškerá komunikace s aplikačním serverem QI probíhá v rámci třídy QiAsyncTask, která dědí od třídy AsyncTask, popsané v sekci Tato třída obsahuje vlastní implementaci metod onpreexecuted() (volané před spuštěním úlohy na pozadí), doinbackground() (spouštěné na pozadí) a onpostexecute() (spouštěné po dokončení úlohy na pozadí). Dále tato třída obsahuje metody, které využívají webové služby, implementované na straně serveru. Jedná se o metody, kterými lze volat makra pro export dat ze serveru do aplikace a makra pro vytváření a editaci záznamů z mobilní aplikace. Tyto metody jsou spouštěny z metody doinbackground() výběr metody probíhá na základě zvoleného kódu, který zastupuje jednotlivé akce. Pokud aktivita spustí instanci třídy QiAsyncTask, je uzamknuta rotace obrazovky a uživatel musí vyčkat, než se prováděná úloha dokončí. Spouštěcí aktivita se obvykle potřebuje dozvědět, kdy byla úloha dokončena a s jakým výsledkem. To proto, aby bylo možné provést změny v databázi a aktualizovat uživatelské rozhraní. Spouštěcí aktivity proto vytváří instanci třídy Handler, které je třeba předat implementaci rozhraní Callback, s překrytou metodou handlemessage(). V této metodě je možné odchytnout zprávy, vyslané objektem typu Handler. Tato instance je třídě QiAsyncTask předána v konstruktoru, aby mohla být v metodě onpostexecute() odeslána zpráva, která obsahuje informaci o výsledku prováděné operace. Za účelem využití webových služeb založených na protokolu SOAP bylo třeba využít knihovnu vhodnou pro OS Android, která SOAP zprávy dokáže přijmout a vytvořit. Samotný programovací jazyk Java ani platforma Android tuto funkcionalitu bohužel nenabízí. Proto byla vybrána knihovna třetí strany ksoap2 ve verzi pro Android (dostupná z Aby bylo

62 6.2 Server 62 možné tuto knihovnou využívat, je třeba znát adresu URL, na které se webové služby SOAP nachází, jmenný prostor a názvy jednotlivých služeb. Aby bylo možné zajistit bezpečnost komunikace prostřednictvím sítě Internet, je nutné šifrovat přenášená data. QI podporuje symetrické kryptosystémy RC6 nebo AES a asymetrický systém RSA. Jelikož není nutné sítí přenášet klíč (je zadán jak na straně aplikace, tak na straně serveru), jsou symetrické systémy pro tyto účely dostačující. Pro šifrování a dešifrování dat, přenášených mezi QI a mobilní aplikací, byl vybrán kryptosystém AES s délkou klíče 128 bitů. K implementaci metod určených k šifrování a dešifrování dat bylo využito tříd ze standardního Java balíčku javax.crypto. Implementace algoritmu AES na straně QI využívá kódování Base64. Na straně Android aplikace bylo podpory tohoto kódování dosaženo prostřednictvím knihovny třetí strany Apache Commons Codec ve verzi 1.9. Tuto knihovnu je možné získat z Server Podpora XML Komunikace mezi mobilní aplikací a serverem je založena na formátu XML, jehož vytváření a parsování QI Builder podporuje. Pomocí tohoto nástroje lze sestavit strukturu XML dokumentu, na jejímž základě je tento dokument plněn nebo parsován. Jednotlivé struktury jsou považovány za tzv. datové moduly, které je třeba v QI vytvořit. Do těchto modulů jsou vkládány datové řezy, reprezentující elementy, kterým je v další části přiřazena vytvořená třída. Tato třída obsahuje podmnožinu atributů, které v XML souboru nesou informaci. Atributům byl přiřazen název, datový typ a počet bytů, které budou v paměti zabírat. Dále je třeba specifikovat, zda bude konkrétní atribut v XML reprezentován jako samostatný element nebo jako tzv. atribut, který je součástí jiného elementu. V této práci bylo využito řešení, kdy jsou atributy reprezentovány samostatnými elementy. Každému datovému modulu, datovému řezu a atributu je v QI automaticky přiřazen identifikátor, který je využíván při práci s modulem. Datový modul je v makrojazyku QI zastoupen třídou TDataModule, která obsahuje metodu GetDataSet(dataSetId). Tato metoda vrací instanci třídy TDataModule, která reprezentuje datový řez obsahující samotné atributy. K těmto atributům je možné přistoupit metodou FieldByName(attributeId) Implementovaná makra V QI Builderu byla implementována makra sloužící k vytváření nebo editaci záznamů a makra pro export záznamů z databáze QI.

63 6.2 Server 63 Makra pro vytváření nebo editaci záznamu přijmou v parametru řetězec ve formátu XML, který je metodou ImportFromString(xml) parsován do datového modulu. Následně je otevřen pro zápis datový řez, do kterého bude vkládán (případně upravován) záznam. Atributům tohoto řezu jsou přiřazeny hodnoty atributů datových řezů získaných z XML modulu. U každého atributu XML datového modulu je kontrolováno, zda je v XML obsažen, a pokud ano, tak zda jeho hodnota není zástupným řetězcem prázdného řetězce. V tomto případě by došlo ke smazání obsahu atributu v editované položce datového řezu. Pokud se nový záznam podaří úspěšně vložit do databáze, je výstupním parametrem vráceno jeho ID. Makra pro export záznamů přijmou v parametrech ID konkrétního záznamu (v případě jeho aktualizace v mobilní aplikaci) a seznam identifikátorů záznamů, které jsou v aplikaci již obsaženy. Jeden z těchto parametrů by měl vždy zůstat prázdný. Pokud není identifikátor konkrétního záznamu prázdný, naplní se datový modul XML hodnotami atributů z požadované položky příslušného datového řezu a je převeden na řetězec ve formátu XML (metodou ExportToString()). V případě, kdy je třeba synchronizovat databázi mobilní aplikace s DB na straně QI, je makru pro export záznamů předán seznam identifikátorů, které mobilní aplikace již obsahuje. Tento seznam je reprezentován jako řetězec, ve kterém jsou jednotlivé položky oddělené středníkem. Aby bylo možné tímto seznamem procházet, je převeden na objekt typu TStringList (metodou StringToSl). Průchodem tohoto seznamu jsou do XML modulu přidány položky, které byly na straně serveru odebrány a následně jsou přidány detaily položek, které v aplikaci naopak chybí. Při přidávání těchto položek byla využita metoda IndexOf() třídy TStringList, pomocí které lze zjistit, zda je řetězec v seznamu obsažen. V návrhu datových modulů, reprezentujících strukturu XML souborů, byly elementům, které zastupují atributy, přiřazeny stejné názvy (identifikátory) jako v mobilní aplikaci. Tento princip umožňuje automatizovaně a efektivně pracovat s XML soubory jak na straně maker serveru, tak na straně mobilní aplikace. Pro potřeby mobilní aplikace bylo vytvořeno celkem 14 maker a stejný počet webových služeb, které makra spouští. K šifrování a dešifrování dat byl využit algoritmus AES s délkou klíče 128 bitů.

64 7 TESTOVÁNÍ 64 7 Testování Mobilní aplikace byla testována ve dvou fázích nejprve jejím autorem, a poté firmou it2b, s. r. o., která se podílela na zadání této diplomové práce. Autor aplikaci otestoval na několika fyzických a virtuálních zařízeních (emulátorech). Seznam fyzických zařízení je zobrazen v tab. 2. Tabulka 2: Fyzická zařízení, na kterých byla aplikace testována Název Android Úhlopříčka disp. Rozlišení disp. Acer Iconia Tab A LG G Pad , ASUS Fonepad GoClever TAB T76GPSTV Samsung Galaxy S4 mini , Samsung Galaxy S , Samsung Galaxy Ace , Samsung Galaxy Ace 2.2 3, Sony Xperia Miro 4.0 3, Po otestování aplikace autorem byla práce předána k otestování společnosti it2b, s. r. o. Během jednoho měsíce byly následně odladěny chyby a pozměněny některé části aplikace. V současné době lze aplikaci považovat za otestovanou. Mobilní aplikaci je možné nainstalovat na všech zařízeních s operačním systémem Android od verze 2.2 (API level 8). Zároveň musí mít displej těchto přístrojů hustotu pixelů minimálně na úrovni mdpi viz obr. 4 v sekci

65 8 DISKUSE 65 8 Diskuse Vyvinutý systém poskytuje uživateli vzdálený přístup do ERP systému QI, konkrétně ke správě úkolů, kalendáře a obchodních partnerů. Na tuto závěrečnou práci by bylo možné navázat rozšířením sekcí, které aplikace podporuje nyní nebo přidáním nových oblastí. V budoucnu by tak mobilní klient mohl uživateli navíc poskytnout správu faktur, vykazování svých činností nebo vyšší počet editovatelných atributů. Díky zavedenému systému identifikátorů atributů, který byl popsán v sekci 6.1.1, je možné parametrizovat jejich viditelnost a také jednoduše přidat nové v případě rozšiřování funkcionality aplikace. Tohoto systému je využíváno při plnění formulářů, ukládání dat nebo při práci s XML soubory, které jsou prostředkem výměny informací mezi aplikačním serverem QI a mobilní aplikací. Slabinu aplikace z pohledu možných rozšíření autor vidí v současném řešení formulářových aktivit. Každý formulář je reprezentován samostatnou aktivitou (třídou), což je problém v případě, kdy je třeba ve formulářových aktivitách hromadně provést změnu musí být implementovány v každé aktivitě zvlášť. Z tohoto důvodu by bylo vhodné současné řešení vylepšit tak, aby byly formuláře reprezentovány pouze jedinou, parametrizovatelnou aktivitou. Problémem je však různorodost jednotlivých formulářů a aktivit. Některé jsou např. rozděleny na více částí, mezi kterými uživatel přepíná pomocí tlačítek v horní části, a jiné jsou zobrazeny pouze jako jeden formulář. Navíc je třeba odlišně reagovat na výběr položky ze seznamu a jiné události. Bylo by vhodné navrhnout řešení, které umožní provádět změny pouze na jednom místě a zároveň bude jeho implementace přehledná. Další možné rozšíření spočívá v poskytnutí offline prohlížení dat, tedy bez připojení k síti Internet. V tomto režimu jsou data uživateli zobrazena pouze pro čtení. Přihlášení by bylo umožněno uživateli, který již aplikaci v minulosti použil a jeho autentizace a autorizace proběhly úspěšně v zařízení by byly uloženy přihlašovací údaje. Rizikem tohoto přístupu však je možná neaktuálnost dat a případně i přihlašovacích údajů. I když je nyní systém Android instalován do většiny mobilních zařízení, významný podíl na trhu mají také operační systémy ios společnosti Apple a Windows Phone společnosti Microsoft. Stálo by proto za úvahu, zda nepokrýt i tyto platformy. Pro každou z nich by však musela být vyvinuta samostatná aplikace.

66 9 ZÁVĚR 66 9 Závěr Cílem diplomové práce bylo navrhnout, implementovat a ověřit funkčnost řešení vzdáleného přístupu do ERP systému QI pro platformu Android. Úkolem tohoto mobilního klienta je pokrýt správu úkolů uživatele, jeho kalendáře a také správu obchodních partnerů společnosti. Systém byl navržen a popsán UML diagramy. Aplikace využívá vlastní databázi SQLite, která je synchronizována s databází na straně serveru. K této synchronizaci dochází po přihlášení uživatele do aplikace a také při otevření detailu položky. V rámci práce byly na straně serveru vytvořeny webové služby a také makra, která tyto služby obsluhují. Makra a webové služby byly implementovány na aplikačním serveru, který poskytla společnost it2b, s. r. o. Tyto implementace je však možné přenést do libovolného informačního systému QI. Uživatel Android aplikace získá možnost položky prohlížet, přidávat, upravovat a odstraňovat. Je mu mimo jiné umožněno vkládat kontakty osob z QI do kontaktů mobilního zařízení nebo přímo z aplikace vytočit číslo zástupce obchodního partnera. Vzdálený přístup jistě ocení mnoho uživatelů ve chvíli, kdy nemají k dispozici stolní počítač nebo notebook. Výstupem práce je funkční, spolehlivá a bezpečná Android aplikace, která byla interně otestována firmou it2b, s. r. o. Aplikace splňuje všechny požadavky, které byly uvedeny v sekci 4. V současné době se jedná o jediného mobilního QI klienta, kterého je možné dále rozvíjet. Možnosti dalšího vývoje byly diskutovány v kapitole č. 8.

67 10 LITERATURA Literatura Activities. In: Android developers [online]. [cit ]. Dostupné na Allen, G. Android 4: průvodce programováním mobilních aplikací. 1. vyd. Brno: Computer Press, 2013, 656 s. ISBN App Resources. In: Android developers [online]. [cit ]. Dostupné na Dashboards. In: Android developers [online]. [cit ]. Dostupné na Dc concept a.s. [online]. c2012 [cit ]. Dostupné na Debugging. In: Android developers [online]. [cit ]. Dostupné na Foltýn R. Implementace ERP systému: Případová studie [online] [cit ]. Masarykova univerzita, Fakulta informatiky. Dostupné na Jackson, J. Google eases Android app development with a new IDE. In: PCWorld [online] [cit ]. Dostupné na Iconography. In: Android developers [online]. [cit ]. Dostupné na Klčková, H. a Sodomka, P. ERP systémy na českém trhu QI [online] [cit ]. Dostupné na Makrojazyk QI: Uživatelská příručka. DC Concept a.s. Česká republika, Melzer, J. Využití webových služeb v distribučním řetězci [online] [cit ]. Dostupné na ERP_Invex SOAP_JAM.pdf. Miles, R. Learning UML st ed. Sebastopol: O Reilly, 2006, 269 s. ISBN Murphy, M. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Překlad Jakub Mužík. Brno: Computer Press, 2011, 375 s. ISBN

68 10 LITERATURA 68 Owens, M. The definitive guide to SQLite. New ed. Apress, 2006, 464 s. ISBN Palandurkar, A. DVM vs. JVM. In: Aatul Palandurkar [online] [cit ]. Dostupné na Saving Data. In: Android developers [online]. [cit ]. Dostupné na Schildt, H. Java 7: výukový kurz. 1. vyd. Brno: Computer Press, 2012, 664 s. ISBN Schimpf G. SQLite vs MySQL. In: All about Programming [online] [cit ]. Dostupné na Skonnard, J. a Gudgin M. XML - pohotová referenční příručka: referenční příručka programátora ke XML, XPath, XSLT, XML Schema, SOAP a dalším. 1 vyd. Praha: Grada, 2006, 342 s. ISBN Smith, D. a Friesen, J. Android recipes. 1. vyd. NewYork: Apress, 2011, 442 s. ISBN Snell, J. Programming Web services with SOAP. Beijing: O Reilly, 2002, 216 s. ISBN Supporting Multiple Screens. In: Android developers [online]. [cit ]. Dostupné na The beginner s guide to Android: Android architecture [online]. [cit ]. Dostupné na Tidwell, J. Designing interfaces 2nd ed. Sebastopol: O Reilly, 2010, 547 s. ISBN Whittaker, Z. Android, ios score 96 percent of smartphone share in Q4 rankings. In: ZDNet [online] [cit ]. Dostupné na

69 A DIAGRAMY AKTIVIT PROCESŮ V SYSTÉMU 69 A Diagramy aktivit procesů v systému Obrázek 22: Diagram aktivit proces synchronizace databáze

70 A DIAGRAMY AKTIVIT PROCESŮ V SYSTÉMU 70 Obrázek 23: Diagram aktivit proces přihlašování uživatele Obrázek 24: Diagram aktivit proces aktualizace položky Obrázek 25: Diagram aktivit proces ukládání záznamu

71 A DIAGRAMY AKTIVIT PROCESŮ V SYSTÉMU 71 Obrázek 26: Diagram aktivit proces smazání záznamu